You can use the parameter editor to implement a variety of filter types, including single rate, decimation, interpolation, and fractional rate filters.
Many digital systems use signal filtering to remove unwanted noise, to provide spectral shaping, or to perform signal detection or analysis. FIR filters and infinite impulse response (IIR) filters provide these functions. Typical filter applications include signal preconditioning, band selection, and low-pass filtering.
To design a filter, identify coefficients that match the frequency response you specify for the system. These coefficients determine the response of the filter. You can change which signal frequencies pass through the filter by changing the coefficient values in the parameter editor.
- Avalon® Streaming (Avalon-ST) interfaces
- DSP Builder ready
- Testbenches to verify the IP core
- IP functional simulation models for use in Altera-supported VHDL and Verilog HDL simulators
- Exploiting maximal designs efficiency through hardware optimizations such as:
- Decimation half-band
- Time sharing
- Easy system integration using Avalon® Streaming (Avalon-ST) interfaces.
- Memory and multiplier trade-offs to balance the implementation between logic elements (LEs) and memory blocks (M512, M4K, M9K, M10K, M20K, or M144K).
- Support for run-time coefficient reloading capability and multiple coefficient banks.
- User-selectable output precision via truncation, saturation, and rounding.
Altera offers the following device support levels for Altera IP cores:
- Advance support—the IP core is available for simulation and compilation for this device family. FPGA programming file (.pof) support is not available for Quartus Prime Pro Stratix 10 Edition Beta software and as such IP timing closure cannot be guaranteed. Timing models include initial engineering estimates of delays based on early post-layout information. The timing models are subject to change as silicon testing improves the correlation between the actual silicon and the timing models. You can use this IP core for system architecture and resource utilization studies, simulation, pinout, system latency assessments, basic timing assessments (pipeline budgeting), and I/O transfer strategy (data-path width, burst depth, I/O standards tradeoffs).
- Preliminary support—Altera verifies the IP core with preliminary timing models for this device family. The IP core meets all functional requirements, but might still be undergoing timing analysis for the device family. You can use it in production designs with caution.
- Final support—Altera verifies the IP core with final timing models for this device family. The IP core meets all functional and timing requirements for the device family. You can use it in production designs.
|Arria® II GX||Final|
|Arria II GZ||Final|
|MAX® 10 FPGA||Final|
|Stratix® IV GT||Final|
|Stratix IV GX/E||Final|
|Other device families||No support|
|Release Date||May 2016|
Altera verifies that the current version of the Quartus Prime software compiles the previous version of each IP core. Altera does not verify that the Quartus Prime software compiles IP core versions older than the previous version. The Altera IP Release Notes lists any exceptions.
- Simulate the behavior of a licensed IP core in your system.
- Verify the functionality, size, and speed of the IP core quickly and easily.
- Generate time-limited device programming files for designs that include IP cores.
- Program a device with your IP core and verify your design in hardware.
OpenCore Plus evaluation supports the following two operation modes:
- Untethered—run the design containing the licensed IP for a limited time.
- Tethered—run the design containing the licensed IP for a longer time or indefinitely. This operation requires a connection between your board and the host computer.
For IP cores, the untethered time-out is 1 hour; the tethered time-out value is indefinite. Your design stops working after the hardware evaluation time expires. The Quartus Prime software uses OpenCore Plus Files (.ocp) in your project directory to identify your use of the OpenCore Plus evaluation program. After you activate the feature, do not delete these files..
When the evaluation time expires, the ast_source_data signal goes low.
- Filter IP Catalog to Show IP for active device family or Show IP for all device families. If you have no project open, select the Device Family in IP Catalog.
- Type in the Search field to locate any full or partial IP core name in IP Catalog.
- Right-click an IP core name in IP Catalog to display details about supported devices, open the IP core's installation folder, and click links to IP documentation.
- Click Search for Partner IP to access partner IP information on the web.
The parameter editor prompts you to specify an IP variation name, optional ports, and output file generation options. The parameter editor generates a top-level Qsys system file (.qsys) or Quartus® Prime IP file (.qip) representing the IP core in your project. You can also parameterize an IP variation without an open project.
The IP Catalog is also available in Qsys (View > IP Catalog). The Qsys IP Catalog includes exclusive system interconnect, video and image processing, and other system-level IP that are not available in the Quartus® Prime IP Catalog. For more information about using the Qsys IP Catalog, refer to Creating a System with Qsys in Volume 1 of the Quartus® Prime Handbook.
- In the IP Catalog (Tools > IP Catalog), locate and double-click the name of the IP core to customize. The parameter editor appears.
- Specify a top-level name for your custom IP variation. The parameter editor saves the IP variation settings in a file named <your_ip> .qsys. Click OK. Do not include spaces in IP variation names or paths.
Specify the parameters and options for your IP variation in the parameter
editor, including one or more of the following:
Note: Refer to your IP core user guide for information about specific IP core parameters.
- Optionally select preset parameter values if provided for your IP core. Presets specify initial parameter values for specific applications.
- Specify parameters defining the IP core functionality, port configurations, and device-specific features.
- Specify options for processing the IP core files in other EDA tools.
- Click Generate HDL. The Generation dialog box appears.
- Specify output file generation options, and then click Generate. The synthesis and/or simulation files generate for your IP variation according to your specifications.
- To generate a simulation testbench, click Generate > Generate Testbench System. Specify testbench generation options, and then click Generate.
- To generate an HDL instantiation template that you can copy and paste into your text editor, click Generate > Show Instantiation Template.
Click Finish. Click
Yes if prompted to add files representing the IP
variation to your project. Optionally turn on the option to
Automatically add Quartus Prime IP Files to All
Projects. Click Project > Add/Remove Files in Project to add IP files at any time.
Figure 3. Adding IP Files to Project
For Arria 10 devices, the generated .qsys file must be added to your project to represent IP and Qsys systems. For devices released prior to Arria 10 devices, the generated .qip and .sip files must be added to your project for IP and Qsys systems.
The generated .qsys file must be added to your project to represent IP and Qsys systems.
and instantiating your IP variation, make appropriate pin assignments to
Note: Some IP cores generate different HDL implementations according to the IP core parameters. The underlying RTL of these IP cores contains a unique hash code that prevents module name collisions between different variations of the IP core. This unique code remains consistent, given the same IP settings and software version during IP generation. This unique code can change if you edit the IP core's parameters or upgrade the IP core version. To avoid dependency on these unique codes in your simulation environment, refer to Generating a Combined Simulator Setup Script.
<my_ip>.qsys (Quartus Standard)
The Qsys system or top-level IP variation file.
Describes the connections and IP component parameterizations in your Qsys system. You can parse the contents of this file to get requirements when you develop software drivers for IP components.
Downstream tools such as the Nios II tool chain use this file. The .sopcinfo file and the system.h file generated for the Nios II tool chain include address map information for each slave relative to each master that accesses the slave. Different masters may have a different address map to access a particular slave component.
|<my_ip>.cmp||The VHDL Component Declaration (.cmp) file is a text file that contains local generic and port definitions that you can use in VHDL design files.|
A report that contains connection information, a memory map showing the slave address with respect to each master that the slave connects to, and parameter assignments.
|<my_ip>_generation.rpt||IP or Qsys generation log file. A summary of the messages during IP generation.|
|<my_ip>.debuginfo||Contains post-generation information. Passes System Console and Bus Analyzer Toolkit information about the Qsys interconnect. The Bus Analysis Toolkit uses this file to identify debug components in the Qsys interconnect.|
Contains all the required information about the IP component to integrate and compile the IP component in the Quartus® Prime software.
|<my_ip>.csv||Contains information about the upgrade status of the IP component.|
A Block Symbol File (.bsf) representation of the IP variation for use in Block Diagram Files (.bdf).
Required input file for ip-make-simscript to generate simulation scripts for supported simulators. The .spd file contains a list of files generated for simulation, along with information about memories that you can initialize.
|<my_ip>.ppf||The Pin Planner File (.ppf) stores the port and node assignments for IP components created for use with the Pin Planner.|
|<my_ip>_bb.v||You can use the Verilog blackbox (_bb.v) file as an empty module declaration for use as a blackbox.|
|<my_ip>.sip||Contains information required for NativeLink simulation of IP components. You must add the .sip file to your Quartus project to enable NativeLink for Arria II, Arria V, Cyclone IV, Cyclone V, MAX 10, MAX II, MAX V, Stratix IV, and Stratix V devices. The Quartus® Prime software does not support NativeLink simulation.|
|<my_ip>_inst.v or _inst.vhd||HDL example instantiation template. You can copy and paste the contents of this file into your HDL file to instantiate the IP variation.|
|<my_ip>.regmap||If the IP contains register information, the Quartus® Prime software generates the .regmap fil. The .regmap file describes the register map information of master and slave interfaces. This file complements the .sopcinfo file by providing more detailed register information about the system. This file enables register display views and user customizable statistics in System Console.|
Allows HPS System Debug tools to view the register maps of peripherals connected to HPS within a Qsys system.
During synthesis, the Quartus® Prime software stores the .svd files for slave interface visible to the System Console masters in the .sof file in the debug session. System Console reads this section, which Qsys can query for register map information. For system slaves, Qsys can access the registers by name.
|<my_ip>.v <my_ip>.vhd||HDL files that instantiate each submodule or child IP core for synthesis or simulation.|
Contains a ModelSim® script msim_setup.tcl to set up and run a simulation.
Contains a Riviera-PRO script rivierapro_setup.tcl to setup and run a simulation.
Contains a shell script vcs_setup.sh to set up and run a VCS® simulation.
Contains a shell script vcsmx_setup.sh and synopsys_ sim.setup file to set up and run a VCS MX® simulation.
Contains a shell script ncsim_setup.sh and other setup files to set up and run an NCSIM simulation.
|/submodules||Contains HDL files for the IP core submodule.|
|<IP submodule>/||For each generated IP submodule directory, Qsys generates /synth and /sim sub-directories.|
The Quartus® Prime software provides integration with your simulator and supports multiple simulation flows, including your own scripted and custom simulation flows. Whichever flow you chose, IP core simulation involves the following steps:
- Generate simulation model, testbench (or example design), and simulator setup script files.
- Set up your simulator environment and any simulation script(s).
- Compile simulation model libraries.
- Run your simulator.
The Quartus® Prime software integrates with your preferred simulation environment. This section describes how to setup and run typical scripted and NativeLink simulation flows. The Quartus® Prime Pro Edition software does not support NativeLink simulation.
The MATLAB simulation uses the file <variation name>_input.txt to provide input data. The output is in the file <variation name>_model_output.txt.
This IP core supports DSP Builder. Use the DSP Builder flow if you want to create a DSP Builder model that includes an IP core variation; use IP Catalog if you want to create an IP core variation that you can instantiate manually in your design.
The FIR II IP core provides a default 37-tap coefficient set regardless of the configurations from filter settings. The scaled value and fixed point value are recalculated based on the coefficient bit width setting. The higher the coefficient bit width, the closer the fixed frequency response is to the intended original frequency response with the expense of higher resource usage.
You can load the coefficients from a file. For example, you can create the coefficients in another application such as MATLAB or a user-created program, save the coefficients to a file, and import them into the FIR II IP core.
|The type of FIR filter.|
|Interpolation Factor||1 to 128||The number of extra points to generate between the original samples.|
|Decimation Factor||1 to 128||The number of data points to remove between the original samples.|
|Maximum Number of Channels||1–128||The number of unique input channels to process.|
|Clock Frequency (MHz)||1–500||The frequency of the input clock.|
|Clock Slack||Integer||The amount of pipelining you can control independently of the clock frequency and therefore independently of the clock to sample rate ratio.|
|Input Sample Rate (MSPS)||Integer||The sample rate of the incoming data.|
|The coefficient scaling mode. Select Auto to apply a scaling factor in which the maximum coefficient value equals the maximum possible value for a given number of bits. Select None to read in pre-scaled integer values for the coefficients and disable scaling.|
|Coefficient Data Type||
Signed Fractional Binary
|The coefficient input data type. Select Signed Fractional Binary to monitor which bits are preserved and which bits are removed during the filtering process.|
|Coefficient Bit Width||2–32||The width of the coefficients. The default value is 8 bits.|
|Coefficient Fractional Bit Width||0–32||The width of the coefficient data input into the filter when you select Signed Fractional Binary as your coefficient data type.|
|Coefficients Reload Options|
|Coefficients Reload||—||Turn on this option to allow coefficient reloading, which allows you to change coefficient values during run time. Also, additional input ports are added to the filter.|
|Base Address||Integer||The base address of the memory-mapped coefficients.|
|The read and write mode that determines the type of address decode to build.|
|Back Pressure Support||—||Turn on for backpressure support. When you turn on this option, the sink indicates to the source to stop the flow of data when its FIFO buffers are full or when there is congestion on its output port.|
|Specifies whether your filter design uses non-symmetric, symmetric, or anti-symmetric coefficients. The default value is Non Symmetry.|
|L-th Band Filter||
|Specifies the appropriate L-band Nyquist filters. Every Lth coefficient of these filters is zero, counting out from the center tap.|
|Specifies the coefficient scaling mode. Select Auto to apply a scaling factor in which the maximum coefficient value equals the maximum possible value for a given number of bits. Select None to read in pre-scaled integer values for the coefficients and disable scaling.|
|Coefficient Data Type||
Signed Fractional Binary
|Specifies the coefficient input data type. Select Signed Fractional Binary to monitor which bits are preserved and which bits are removed during the filtering process.|
|Coefficient Width||2–32||Specifies the width of the coefficients. The default value is 8 bits.|
|Coefficient Fractional Width||0–32||Specifies the width of the coefficient data input into the filter when you select Signed Fractional Binary as your coefficient data type.|
|Banks||0–Number of coefficient bank -1||Click + to add coefficient banks, then select which coefficient bank to display in the coefficient table and frequency response graph.|
|Import from file||URL||Specify the file from where you want to load coefficients.|
|Export to file||URL||Specify the file where you want to save coefficients.|
Click Import coefficients, in the File name box, specify the name of the .txt file containing the coefficient set.
Note: The file must have a minimum of five non-zero coefficients.
- In the .txt file, separate the coefficients file by either white space or commas or both.
- Use new lines to separate banks.
- You may use blank lines as the FIR II IP core ignores them.
- You may use floating-point or fixed-point numbers, and scientific notation.
- Use a # character to add comments.
- Specify an array of coefficient sets to support multiple coefficient sets.
- Specify the number of rows to specify the number of banks.
- All coefficient sets must have the same symmetry type and number of taps. For example: # bank 1 and 2 are symmetric 1, 2, 3, 2, 1 1 3 4 3 1 # bank 3 is anti-symmetric 1 2 0 -2 -1 # bank 4 is asymmetric 1,2,3,4,5
- Click Apply to import the coefficient set.
|Input Data Type||
Signed Fractional Binary
|Signed binary or signed fractional binary format input data. Select Signed Fractional Binary to monitor which bits the IP core preserves and which bits it removes during the filtering process.|
|Input Bit Width||1–32||The width of the input data sent to the filter.|
|Input Fractional Bit Width||0–32||The width of the data input into the filter when you select Signed Fractional Binary as your input data type.|
|Output Data Type||
Signed Fractional Binary
|Signed binary or a signed fractional binary format output data. Select Signed Fractional Binary to monitor which bits the IP core preserves and which bits it removes during the filtering process.|
|Output Bit Width||0–32||The width of the output data (with limited precision) from the filter.|
|Output Fractional Bit Width||0–32||The width of the output data (with limited precision) from the filter when you select Signed Fractional Binary as your output data.|
|Output MSB Rounding||Truncation/ Saturating||Truncate or saturate the most significant bit (MSB).|
|MSB Bits to Remove||0–32||The number of MSB bits to truncate or saturate. The value must not be greater than its corresponding integer bits or fractional bits.|
|Output LSB Rounding||Truncation/ Rounding||Truncate or round the least significant bit (LSB).|
|LSB Bits to Remove||0–32||The number of LSB bits to truncate or round. The value must not be greater than its corresponding integer bits or fractional bits.|
<sign> <integer bits>.<fractional bits>
A signed binary fractional number is interpreted as shown below:
<sign> <x1 integer bits>.<y1 fractional bits> Original input data
<sign> <x2 integer bits>.<y2 fractional bits> Original coefficient data
<sign> <i integer bits>.<y1 + y2 fractional bits> Full precision after FIR calculation
<sign> <x3 integer bits>.<y3 fractional bits> Output data after limiting precision
where i = ceil(log2ceil(number of coefficients/interpolation factor)) + x1 + x2
For example, if the number has 3 fractional bits and 4 integer bits plus a sign bit, the entire 8-bit integer number is divided by 8, which gives a number with a binary fractional component.
The total number of bits equals to the sign bits + integer bits + fractional bits. The sign + integer bits is equal to Input Bit Width – Input Fractional Bit Width with a constraint that at least 1 bit must be specified for the sign.
|MSB||Truncate||In truncation, the filter disregards specified bits..|
|Saturate||In saturation, if the filtered output is greater than the maximum positive or negative value that can be represented, the output is forced (or saturated) to the maximum positive or negative value.|
|LSB||Truncate||Same process as for MSB.|
|Round||The output is rounded away from zero.|
|Resource Optimization Settings|
|Device Family||Menu of supported devices||The target device family.|
|Speed grade||Fast, medium, slow||The speed grade of the target device to balance the size of the hardware against the resources required to meet the clock frequency.|
|Memory Block Threshold||Integer||The balance of resources between LEs and small RAM block threshold in bits.|
|Dual Port RAM Threshold||Integer||The balance of resources between small and medium RAM block threshold in bits.|
|Large RAM Threshold||Integer||The balance of resources between medium and large RAM block threshold in bits.|
|Hard Multiplier Threshold||Integer||The balance of resources between LEs and DSP block multiplier threshold in bits. The default value is -1.|
|Number of LUTs||-||Shows the number of LUTs.|
|Number of DSPs||-||Shows the number of DSPs.|
|Number of memory bits||-||Shows the number of memory bits.|
- To make more delays using block RAM, enter a lower number, such as a value in the range of 20–30.
- To use fewer block memories, enter a larger number, such as 100.
- To never use block memory for simple delays, enter a very large number, such as 10000.
Implement delays of less than three cycles in LEs because of block RAM behavior.
Note: This threshold only applies to implementing simple delays in memory blocks or logic elements. You cannot push dual memories back into logic elements.
The IP core implements any dual-port memory in a block memory rather than logic elements, but for some device families different sizes of block memory may be available. The threshold value determines which medium-size RAM memory blocks IP core implements instead of small-memory RAM blocks. For example, the threshold that determines whether to use M9K blocks rather than MLAB blocks on Stratix IV devices.
- Set the default threshold value, to implement dual memories greater than 1,280 bits as M9K blocks and dual memories less than or equal to 1,280 bits as MLABs.
Change this threshold to a lower value such as 200, to implement dual memories greater than 200 bits as M9K blocks and dual
memories less than or equal to 200 bits as MLAB blocks.
Note: For device families with only one type of memory block, this threshold has no effect.
- Set the number of bits in a memory or delay greater than this threshold, to use M-RAM.
- Set a large value such as the default of 1,000,000 bits, to never use M-RAM blocks.
- Set the default to always use hard multipliers. With this value, IP core implements a 24 × 18 multiplier as two 18 × 18 multipliers.
- Set a value of approximately 300 to keep 18 × 18 multipliers hard, but transform smaller multipliers to LEs. The IP core implements a 24 × 18 multiplier as a 6 × 18 multiplier and an 18 × 18 multiplier, so this setting builds the hybrid multipliers that you require.
- Set a value of approximately 1,000 to implement the multipliers entirely as LEs. Essentially, you are allowing a high number (1000) of LEs to save using an 18 × 18 multiplier.
- Set a value of approximately 10 to implement a 24 × 16 multiplier as a 36 × 36 multiplier. With the value, you are not even allowing the adder to combine two multipliers. Therefore, the system has to use a 36 × 36 multiplier in a single DSP block.
|Reconfiguarable carrier||Turn on to implement a reconfigurable FIR filter.|
|Number of modes||Enter the number of modes.|
|Mode to edit||Select the mode to edit.|
|Channel mode order||Edit the mapping. For example, for 0,1,2,3, the second element of mode 1 is 1, which means the IP core processes channel 1 on the second cycle, when you set the FIR to mode 1.|
|Set mode||Click to set.|
Interpolation increases the sample rate by inserting zero-valued samples between the original samples, while decimation discards samples to decrease the sample rate. The FIR II IP core automatically creates interpolation and decimation filters that have polyphase decomposition. Polyphase filters simplify the overall system design and also reduce the number of computations per cycle required by the hardware.
The FIR II IP core implements interpolation filters using a single engine that the different phases timeshare to optimize area. This implementation changes the overall throughput of the filter and the input sample rate. The throughput of the filter is the rate at which the filter generates the output (one output every K clock cycles). The input sample rate is the rate at which the filter processes input data samples (the input needs to be held for L clock cycles).
The values of K and L for the throughput and input sample rate of FIR II interpolation filters depend on the filter architecture.
K = N
L = N I
K = N/M
L = N I / M
K = 1
L = I
K = C
L = C I
For systems that require higher throughput and input data rate, Altera recommends that you use parallel or multicycle variable structures.
The FIR II IP core implements decimation filters using a single engine that is time-shared by the different phases to optimize area. This implementation changes the overall throughput of the filter and the input sample rate. The throughput of the filter is the rate at which the filter generates the output (one output every K clock cycles). The input sample rate is the rate at which the filter processes input data samples (the input needs to be held for L clock cycles).
The values of K and L for the throughput and input sample rate of FIR II decimation filters depend on the filter architecture.
K = ND
L = N
K = ND/M
L = N / M
K = D
L = 1
K = CD
L = C
For systems that require higher throughput and input data rate, Altera recommends that you use parallel or multicycle variable structures.
By clocking a FIR II IP core faster than the sample rate, you can reuse the same hardware. For example, by implementing a filter with a TDM factor of 2 and an internal clock multiplied by 2, you can halve the required hardware.
To achieve TDM, the IP core requires a serializer and deserializer before and after the reused hardware block to control the timing. The ratio of system clock frequency to sample rate determines the amount of resource saving except for a small amount of additional logic for the serializer and deserializer.
|Clock Rate (MHz)||Sample Rate (MSPS)||Logic||Multipliers||Memory Bits||TDM Factor|
When the sample rate equals the clock rate, the filter is symmetric and you only need 25 multipliers. When you increase the clock rate to twice the sample rate, the number of multipliers drops to 13. When the clock rate is set to 4 times the sample rate, the number of multipliers drops to 7. If the clock rate stays the same while the new data sample rate is only 36 MSPS (million samples per second), the resource consumption is the same as twice the sample rate case.
You can vectorize the FIR II IP core. If data going into the block is a vector requiring multiple instances of a FIR filter, the IP core creates multiple FIR blocks in parallel behind a single FIR II IP core block. If a decimating filter requires a smaller vector on the output, the data from individual filters is automatically time-division multiplexed onto the output vector. You do not have to join filters together with custom logic.
This approach is unlike traditional methods because you do not need to manually instantiate two FIR filters and pass a single wire to each in parallel. Each FIR II IP core block internally vectorizes itself. For example, a FIR II IP core block can build two FIR filters in parallel and wire one element of the vector up to each FIR. The same paradigm is used on outputs, where high data rates on multiple wires are represented as vectors.
The input and output wire counts are determined by each FIR II IP core based on the clock rate, sample rate, and number of channels.
The output wire count is also affected by any rate changes in the FIR II IP core. If there is a rate change, such interpolating by two, the output aggregate sample rate doubles. The output channels are then packed into the fewest number of wires (vector width) that will support that rate. For example, an interpolate by two FIR II IP core filters might have two wires at the input, but three wires at the output.
Any necessary multiplexing and packing is performed by the FIR II IP core. The blocks connected to the inputs and outputs must have the same vector widths. Vector width errors can usually be resolved by carefully changing the sample rates.
- clockRate is the system clock frequency (MHz).
- inputRate is the data sample rate per channel (MSPS).
- inputChannelNum is the number of channels. Channels are enumerated from 0 to inputChannelNum–1.
- The period (or TDM factor) is the ratio of the clock rate to the sample rate and determines the number of available time slots.
- ChanWireCount is the number of channel wires required to carry all the channels. It can be calculated by dividing the number
of channels by the TDM factor. More specifically:
- PhysChanIn = Number of channel input wires
- PhysChanOut = Number of channel output wires
- ChanCycleCount is the number of channels carried per wire. It is calculated by dividing the number of channels by the number
of channels per wire. The channel signal counts from 0 to ChanCycleCount–1. More specifically:
- ChansPerPhyIn = Number of channels per input wire
- ChansPerPhyOut = Number of channels per output wire
If the number of channels is greater than the clock period, multiple wires are required. Each FIR II IP core in your design is internally vectorized to build multiple FIR filters in parallel.
The channel signal is used for synchronization and scheduling of data. It specifies the channel data separation per wire. Note that the channel signal counts from 0 to ChanCycleCount–1 in synchronization with the data. Thus, for ChanCycleCount = 1, the channel signal is the same as the channel count, enumerated from 0 to inputChannelNum–1.
For a case with single wire, the channel signal is the same as a channel count.
For ChanWireCount > 1, the channel signal specifies the channel data separation per wire, rather than the actual channel number. The channel signal counts from 0 to ChanCycleCount–1 rather than 0 to inputChannelNum–1.
Notice that the channel signal remains a single wire, not a wire for each data wire. It counts from 0 to ChanCycleCount–1.
This result appears to be vertical, but that is because the number of cycles is 1, so on each wire there is only space for one piece of data.
The input data format in this case is 32 cycles long, which comes from the TDM factor. The number of channels is 15, so the filter expects 15 valid cycles together in a block, followed by 17 invalid cycles. You can insert extra invalid cycles at the end, but they must not interrupt the packets of data after the process has started. If the input sample rate is less than the clock rate, the pattern is always the same: a repeating cycle, as long as the TDM factor, with the number of channels as the number of valid cycles required, and the remainder as invalid cycles.
The input format in this case is 20 cycles long, which comes from the TDM factor. The number of channels is 22, so the filter expects 11 (ChansPerPhyIn) valid cycles, followed by 9 invalid cycles (TDM factor – ChansPerPhyIn = 20 – 11). Y
You can insert extra invalid cycles at the end, which mean the number of invalid cycles can be greater than 9, but they must not interrupt the packets of data after the process has started.
The FIR filter can switch between different coefficient banks dynamically, which enables the filter to switch between infinite number of coefficient sets. Therefore, while the filter uses one coefficient set, you can update other coefficient sets.You can also set different coefficient banks for different channels and use the channel signal to switch between coefficient sets.
The IP core uses multiple coefficient banks when you load multiple sets of coefficients from a file.
RT**Refer to “Loading Coefficients from a File” on page 3–3.
Based on the number of coefficient banks you specify, the IP core extends the width of the ast_sink_data signal to support two additional signals— bank signal (bankIn) and input data (xIn) signal. The most significant bits represent the bank signals and the least significant bits represent the input data.
You can switch the coefficient bank from 0 to 3 using the bankIn signal when the filter runs.
Coefficient reloading starts anytime during the filter run time. However, you must reload the coefficients only after you obtain all the desired output data to avoid unpredictable results. If you use multiple coefficient banks, you can reload coefficient banks that are not used and switch over to the new coefficient set when coefficient reloading is complete. You must toggle the coeff_in_areset signal before reloading the coefficient with new data. The new coefficient data is read out after coefficient reloading to verify whether the coefficient reloading process is successful. When the coefficient reloading ends by deasserting the coeff_in_we, the input data is inserted immediately to the filter that is reloaded with the new coefficients.
The symmetrical or anti-symmetrical filters have fewer genuine coefficients, use fewer registers, and require fewer writes to reload the coefficients. For example, only write the first 19 addresses for a 37-tap symmetrical filter. When you write to all 37 addresses, the IP core ignores last 18 addresses because they are not part of the address space of the filter. Similarly, reading coefficient data from the last 18 addresses is also ignored.
When the FIR uses multiple coefficient banks, it arranges the addresses of all the coefficients in consecutive order according to the bank number. The following example shows a 37-tap symmetrical/anti-symmetrical filter with four coefficient banks:
- Address 0–18: Bank 0
- Address 19–37: Bank 1
- Address 38–56: Bank 2
- Address 57–75: Bank 3
The following example shows a 37-tap non-symmetrical/anti-symmetrical filter with 2 coefficient banks:
- Address 0–36: Bank 0
- Address 37–73: Bank 1
If the coefficient bit width parameter is equal to or less than 16 bits, the width of the write data is fixed at 16 bits. If the coefficient bit width parameter is more than 16 bits, the width of the write data is fixed at 32 bits.
The IP core performs a write cycle of 9 clock cycles to reload the whole coefficient data set. To complete the write cycle, assert the coeff_in_we signal, and provide the address (from base address to the max address) together with the new coefficient data. Then, load the new coefficient data into the memory corresponding to the address of the coefficient. The IP core reads new coefficient data during the write cycle when you deassert the coeff_in_we signal. When the coeff_out_valid signal is high, the read data is available on coeff_out_data.
The input rate determines the bandwidth of the FIR. If you turn off Reconfigurable carrier (nonreconfigurable FIR), the IP core allocates this bandwidth equally amongst each channel. The reconfigurable FIR feature allows the IP core to allocate the bandwidth manually. You set these allocations during parameterization and you can change which allocation the IP core uses at run-time using the mode signal. You can use one channel's bandwidth to process a different channel's data. You specify the allocation by listing the channels you want the IP core to process in the mode mapping. For example, a mode mapping of 0,1,2,2 gives channel 2 twice the bandwidth of channel 0 and 1, at the cost of not processing channel 3.
The sink and source interfaces implement the Avalon-ST protocol, which is a unidirectional flow of data. The number of bits per symbol represents the data width and the number of symbols per beat is the number of channel wires. The IP core symbol type supports signed and unsigned binary format. The ready latency on the FIR II IP core is 0.
The clock and reset interfaces drive or receive the clock and reset signals to synchronize the Avalon-ST interfaces and provide reset connectivity.
The input interface is an Avalon-ST sink and the output interface is an Avalon-ST source. The Avalon-ST interface supports packet transfers with packets interleaved across multiple channels.
Avalon-ST interface signals can describe traditional streaming interfaces supporting a single stream of data without knowledge of channels or packet boundaries. Such interfaces typically contain data, ready, and valid signals. Avalon-ST interfaces can also support more complex protocols for burst and packet transfers with packets interleaved across multiple channels. The Avalon-ST interface inherently synchronizes multichannel designs, which allows you to achieve efficient, time-multiplexed implementations without having to implement complex control logic.
Avalon-ST interfaces support backpressure, which is a flow control mechanism where a sink can signal to a source to stop sending data. The sink typically uses backpressure to stop the flow of data when its FIFO buffers are full or when it has congestion on its output.
When the packet size is greater than one (multichannel), the source interface expects your application to supply the count of data starting from 1 to the packet size. When the source interface receives the valid flag together with the data_count = 1, it starts sending out data by driving both the ast_source_sop and ast_source_valid signals high. When data_count equals the packet size, the ast_source_eop signal is driven high together with the ast_source_valid signal.
If the downstream components are not ready to accept any data, the source interface drives the source_stall signal high to tell the design to stall.
|clk||Input||1||Clock signal for all internal FIR II IP core filter registers.|
|reset_n||Input||1||Asynchronous active low reset signal. Resets the FIR II IP core filter control circuit on the rising edge of clk.|
|coeff_in_clk||Input||1||Clock signal for the coefficient reloading mechanism. This clock can have a lower rate than the system clock.|
|coeff_in_areset||Input||1||Asynchronous active high reset signal for the coefficient reloading mechanism.|
|ast_sink_ready||Output||1||FIR filter asserts this signal when can accept data in the current clock cycle. This signal is not available when backpressure is turned off.|
|ast_sink_valid||Input||1||Assert this signal when the input data is valid. When ast_sink_valid is not asserted, the FIR processing stops until you re-assert the ast_sink_valid signal.|
|ast_sink_data||Input||(Data width + Bank width) × the number of channel input wires (PhysChanIn)
Bank width= Log2(Number of coefficient sets)
|Sample input data.
For a multichannel operation (number of channel input wires > 1), the LSBs
of ast_sink_data map
to xln_0 of the FIR
II IP core filter.
ast_sink_data[7:0] --> xln_0[7:0]
ast_sink_data[15:8] --> xln_1[7:0]
ast_sink_data[23:16] --> xln_2[7:0]
For multiple coefficient banks, the MSBs of the channel data are mapped to the bank input signal and the LSBs of the channel data map to the data input signal. For reconfigurable FIR filters, the MSBs map to the mode signal.
Single channel with 4 coefficient banks:
ast_sink_data[9:8] --> BankIn_0
ast_sink_data[7:0] --> xln_0
Multi-channel (4 channels) with 4 coefficient banks:
ast_sink_data[9:8] --> BankIn_0
ast_sink_data[7:0] --> xln_0
ast_sink_data[19:18] --> BankIn_1
ast_sink_data[17:10] --> xln_1
ast_sink_data[29:28] --> BankIn_2
ast_sink_data[27:20] --> xln_2
ast_sink_data[39:38] --> BankIn_3
ast_sink_data[37:30] --> xln_3
|ast_sink_sop||Input||1||Marks the start of the incoming sample group. The start of packet (SOP) is interpreted as a sample from channel 0.|
|ast_sink_eop||Input||1||Marks the end of the incoming sample group. If data is associated with N channels, the end of packet (EOP) must be driven high when the sample belonging to the last channel (that is, channel N-1), is presented at the data input.|
|ast_sink_error||Input||2||Error signal indicating Avalon-ST protocol violations on the sink side:
|ast_source_ready||Input||1||The downstream module asserts this signal if it is able to accept data. This signal is not available when backpressure is turned off.|
|ast_source_valid||Output||1||The IP core asserts this signal when there is valid data to output.|
|ast_source_channel||Output||Log2(number of channels per wire)||Indicates the index of the channel whose result is presented at the data output.|
|ast_source_data||Output||Data width × number of channel output wires (PhysChanOut)||FIR II IP core filter output. For a multichannel operation (number of channel output wires > 1), the least significant bits
of ast_source_data are mapped to xOut_0 of the FIR II IP core filter.
xOut_0[7:0] --> ast_source_data[7:0]
xOut_1[7:0] --> ast_source_data[15:8]
|ast_source_sop||Output||1||Marks the start of the outgoing FIR II IP core filter result group. If '1', a result corresponding to channel 0 is output.|
|ast_source_eop||Output||1||Marks the end of the outgoing FIR II IP core filter result group. If '1', a result corresponding to channels per wire N-1 is output, where N is the number of channels per wire.|
|ast_source_error||Output||2||Error signal indicating Avalon-ST protocol violations on the source side:
|coeff_in_address||Input||Number of coefficients||Address input to write new coefficient data.|
|coeff_in_clk||Input||-||Clock input for coefficients.|
|coeff_in_areset||Input||-||Reset input for coefficients.|
|coeff_in_we||Input||1||Write enable for memory-mapped coefficients.|
|coeff_in_data||Input||Coefficient width||Data coefficient input.|
|coeff_in_read||Input||Coefficient width||Read enable.|
|coeff_out_valid||Output||1||Coefficient read valid signal.|
|coeff_out_data||Output||Coefficient width||Data coefficient output. The coefficient in memory at the address specified by coeff_in_address.|
|August 2014||14.0 Arria 10 Edition||
|May 2013||13.0||Updated interpolation and decimation factor ranges.|
|November 2012||12.1||Added support for Arria V GZ devices.|
|IP Core Version||User Guide|
|15.1||FIR II IP Core User Guide|
|15.0||FIR II IP Core User Guide|
|14.1||FIR II IP Core User Guide|