CIC filters use only adders and registers; they require no multipliers to handle large rate changes. Therefore, CIC is a suitable and economical filter architecture for hardware implementation, and is widely used in sample rate conversion designs such as digital down converters (DDC) and digital up converters (DUC).
- Avalon® Streaming (Avalon-ST) interfaces
- DSP Builder for Altera® FPGAs ready
- Testbenches to verify the IP core
- IP functional simulation models for use in Altera-supported VHDL and Verilog HDL simulators
- Interpolation and decimation filters with variable rate change factors (2 to 32,000), a configurable number of stages (1 to 12), and two differential delay options (1 or 2).
- Single clock domain with selectable number of interfaces and a maximum of 1,024 channels.
- Selectable data storage options with an option to use pipelined integrators.
- Configurable input data width (1 to 32 bits) and output data width (1 to full resolution data width).
- Selectable output rounding modes (truncation, convergent rounding, rounding up, or saturation) and Hogenauer pruning support.
- Optimization for speed by specifying the number of pipeline stages used by each integrator.
- Compensation filter coefficients generation.
Altera offers the following device support levels for Altera FPGA 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|
|Intel® Arria® 10||Final|
|Intel® Cyclone® 10||Final|
|Intel® MAX® 10 FPGA||Final|
|Stratix® IV GT||Final|
|Stratix IV GX/E||Final|
|Intel® Stratix® 10||Advance|
|Other device families||No support|
|Release Date||November 2017|
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 FPGA IP Release Notes lists any exceptions.
- Number of stages: 8
- Rate change factor: 8
- Differential delay: 1
- Integrator data storage: Memory (whenever possible)
- Differentiator data storage: Memory (whenever possible)
- Input data width: 16
- Output data width: Full precision
- Output rounding: No rounding
The target fMAX is 1 GHz.
|Device||Filter Type||ALM||Memory||Registers||fMAX (MHz)|
|Arria V||Decimator 5 Channels||1,162||2||--||3,749||6||207|
|Arria V||Decimator 5 Channels 3 Interfaces||911||37||--||1,722||6||255|
|Arria V||Decimator Hogenauer Pruning||352||1||--||785||12||304|
|Arria V||Decimator Trunction||463||2||--||1,055||5||198.69|
|Arria V||Decimator Variable Rate Change||919||37||--||1,730||7||256|
|Arria V||Interpolator 5 Channels||762||1||--||2,369||27||288|
|Arria V||Interpolator 5 Channels 3 Interfaces||886||27||--||1,776||17||232.61|
|Arria V||Interpolator Convergent Rounding||352||1||--||785||12||304|
|Arria V||Interpolator Variable Rate Change||889||27||--||1,772||23||235|
|Cyclone V||Decimator 5 Channels||1,162||2||--||3,748||8||190.15|
|Cyclone V||Decimator 5 Channels 3 Interfaces||906||37||--||1,719||9||204|
|Cyclone V||Decimator Hogenauer Pruning||352||1||--||784||14||246|
|Cyclone V||Decimator Truncation||463||2||--||1,054||4||177|
|Cyclone V||Decimator Variable Rate Change||917||37||--||1,730||5||193.27|
|Cyclone V||Interpolator 5 Channels||760||1||--||2,383||11||235|
|Cyclone V||Interpolator 5 Channels 3 Interfaces||890||27||--||1,747||48||168|
|Cyclone V||Interpolator Convergent Rounding||352||1||--||784||14||246.06|
|Cyclone V||Interpolator Variable Rate Change||894||27||--||1,725||70||165|
|Stratix V||Decimator 5 Channels||1,176||--||1||3,750||8||413|
|Stratix V||Decimator 5 Channels 3 Interfaces||1,891||--||11||5,562||8||450.05|
|Stratix V||Decimator Hogenauer Pruning||361||--||0||790||13||450|
|Stratix V||Decimator Truncation||483||--||1||1,059||4||376|
|Stratix V||Decimator Variable Rate Change||1,900||--||11||5,574||3||450|
|Stratix V||Interpolator 5 Channels||771||--||0||2,390||8||450|
|Stratix V||Interpolator 5 Channels 3 Interfaces||1,625||--||8||4,635||70||450|
|Stratix V||Interpolator Convergent Rounding||361||--||0||790||13||450|
|Arria 10||Interpolator Variable Rate Change||464||--||0||128||128||451|
The Intel® Quartus® Prime software installs IP cores in the following locations by default:
|<drive>:\intelFPGA_pro\quartus\ip\altera||Intel® Quartus® Prime Pro Edition||Windows®|
|<drive>:\intelFPGA\quartus\ip\altera||Intel® Quartus® Prime Standard Edition||Windows|
|<home directory>:/intelFPGA_pro/quartus/ip/altera||Intel® Quartus® Prime Pro Edition||Linux®|
|<home directory>:/intelFPGA/quartus/ip/altera||Intel® Quartus® Prime Standard Edition||Linux|
- Simulate the behavior of a licensed Intel® FPGA 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.
Intel® FPGA IP Evaluation Mode supports the following operation modes:
- Tethered—Allows running the design containing the licensed Intel® FPGA IP indefinitely with a connection between your board and the host computer. Tethered mode requires a serial joint test action group (JTAG) cable connected between the JTAG port on your board and the host computer, which is running the Intel® Quartus® Prime Programmer for the duration of the hardware evaluation period. The Programmer only requires a minimum installation of the Intel® Quartus® Prime software, and requires no Intel® Quartus® Prime license. The host computer controls the evaluation time by sending a periodic signal to the device via the JTAG port. If all licensed IP cores in the design support tethered mode, the evaluation time runs until any IP core evaluation expires. If all of the IP cores support unlimited evaluation time, the device does not time-out.
- Untethered—Allows running the design containing the licensed IP for a limited time. The IP core reverts to untethered mode if the device disconnects from the host computer running the Intel® Quartus® Prime software. The IP core also reverts to untethered mode if any other licensed IP core in the design does not support tethered mode.
When the evaluation time expires for any licensed Intel® FPGA IP in the design, the design stops functioning. All IP cores that use the Intel® FPGA IP Evaluation Mode time out simultaneously when any IP core in the design times out. When the evaluation time expires, you must reprogram the FPGA device before continuing hardware verification. To extend use of the IP core for production, purchase a full production license for the IP core.
You must purchase the license and generate a full production license key before you can generate an unrestricted device programming file. During Intel® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit.
Altera® licenses IP cores on a per-seat, perpetual basis. The license fee includes first-year maintenance and support. You must renew the maintenance contract to receive updates, bug fixes, and technical support beyond the first year. You must purchase a full production license for Intel® FPGA IP cores that require a production license, before generating programming files that you may use for an unlimited time. During Intel® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit. To obtain your production license keys, visit the Self-Service Licensing Center or contact your local Intel FPGA representative.
The Altera® FPGA Software License Agreements govern the installation and use of licensed IP cores, the Intel® Quartus® Prime design software, and all unlicensed IP cores.
All IP cores in a device time out simultaneously when the most restrictive evaluation time is reached. If there is more than one IP core in a design, a specific IP core's time-out behavior may be masked by the time-out behavior of the other IP cores. 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 II software uses Intel® FPGA IP Evaluation Mode Files (.ocp) in your project directory to identify your use of the Intel® FPGA IP Evaluation Mode evaluation program. After you activate the feature, do not delete these files..
When the evaluation time expires, the data output 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, to open the IP core's installation folder, and for 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 Intel® Quartus® Prime IP file (.ip) for an IP variation in Intel® Quartus® Prime Pro Edition projects.
The parameter editor generates a top-level Quartus IP file (.qip) for an IP variation in Intel® Quartus® Prime Standard Edition projects. These files represent the IP variation in the project, and store parameterization information.
- Create or open an Intel® Quartus® Prime project (.qpf) to contain the instantiated IP variation.
- In the IP Catalog (Tools > IP Catalog), locate and double-click the name of the IP core to customize. To locate a specific component, type some or all of the component’s name in the IP Catalog search box. The New IP Variation window appears.
- Specify a top-level name for your custom IP variation. Do not include spaces in IP variation names or paths. The parameter editor saves the IP variation settings in a file named <your_ip> .ip. Click OK. The parameter editor appears.
Set the parameter values in the parameter editor and view the
block diagram for the component. The Parameterization Messages tab at the bottom displays any errors
in IP parameters:
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 simulation files generate 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.
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.
|Top-level IP variation file that contains the parameterization of an IP core in your project. If the IP variation is part of a Platform Designer system, the parameter editor also generates a .qsys file.|
|<your_ip>.cmp||The VHDL Component Declaration (.cmp) file is a text file that contains local generic and port definitions that you use in VHDL design files.|
|<your_ip>_generation.rpt||IP or Platform Designer generation log file. Displays a summary of the messages during IP generation.|
|<your_ip>.qgsimc (Platform Designer systems only)||
Simulation caching file that compares the .qsys and .ip files with the current parameterization of the Platform Designer system and IP core. This comparison determines if Platform Designer can skip regeneration of the HDL.
|<your_ip>.qgsynth (Platform Designer systems only)||
Synthesis caching file that compares the .qsys and .ip files with the current parameterization of the Platform Designer system and IP core. This comparison determines if Platform Designer can skip regeneration of the HDL.
Contains all information to integrate and compile the IP component.
|<your_ip>.csv||Contains information about the upgrade status of the IP component.|
A symbol representation of the IP variation for use in Block Diagram Files (.bdf).
Input file that ip-make-simscript requires to generate simulation scripts. The .spd file contains a list of files you generate for simulation, along with information about memories that you initialize.
|<your_ip>.ppf||The Pin Planner File (.ppf) stores the port and node assignments for IP components you create for use with the Pin Planner.|
|<your_ip>_bb.v||Use the Verilog blackbox (_bb.v) file as an empty module declaration for use as a blackbox.|
|<your_ip>_inst.v or _inst.vhd||HDL example instantiation template. Copy and paste the contents of this file into your HDL file to instantiate the IP variation.|
|<your_ip>.regmap||If the IP contains register information, the Intel® Quartus® Prime software generates the .regmap file. 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 that connect to HPS within a Platform Designer system.
During synthesis, the Intel® 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 Platform Designer queries for register map information. For system slaves, Platform Designer accesses the registers by name.
|<your_ip>.v <your_ip>.vhd||HDL files that instantiate each submodule or child IP core for synthesis or simulation.|
Contains a msim_setup.tcl script to set up and run a ModelSim 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>/||Platform Designer generates /synth and /sim sub-directories for each IP submodule directory that Platform Designer generates.|
The Intel® Quartus® Prime software provides integration with many simulators and supports multiple simulation flows, including your own scripted and custom simulation flows. Whichever flow you choose, 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 scripts.
- Compile simulation model libraries.
- Run your simulator.
This IP core supports DSP Builder for Altera® FPGAs. Use the DSP Builder for Altera® FPGAs flow if you want to create a DSP Builder for Altera® FPGAs 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.
In a CIC filter, both the integrator and comb sections have the same number of integrators and differentiators. Each pairing of integrator and differentiator is a stage. The number of stages (N) has a direct effect on the frequency response of a CIC filter. You determine the response of the filter by configuring:
- The number of stages N
- The rate change factor R
- The number of delays in the differentiators (differential
delay) M. Generally, set the differential delay to 1 or 2.
Figure 7. Three-stage CIC Decimation Filter Frequency Response. CIC decimation filter with N = 3, M = 2 and R = 32
Using a combined filter uses fewer resources than using many individual CIC filters. For example, a two-channel parallel filter requires two clock cycles to calculate two outputs. The resulting hardware needs to run at twice the data rate of an individual filter, which is especially useful for higher rate changes where adders grow particularly large.
The CIC achieves time sharing by providing multiple input interfaces and processing chains for the high rate portions. It then combines all of the processing associated with the lower rate portions into a single processing chain. This strategy can lead to full utilization of the resources and represents the most efficient hardware implementation.
The sampling frequency of the input data only allows time multiplexes of two channels per bus. Therefore, you must configure the CIC filter with two input interfaces. For two interfaces, the rate change factor must also be at least two to exploit this architecture. The CIC support up to 1,024 channels by using multiple input interfaces in this way.
Like the MISO, you can share the low sampling rate differentiator section among more channels than the higher sampling frequency integrator sections. Therefore, this architecture features a single instance of the differentiator section and multiple parallel instances of the integrator sections.
After processing by the differentiator section, the CIC splits the channel signals into multiple parallel sections for processing in a high sampling frequency by the integrator sections.
The required sampling frequency of the output data only allows time multiplexes of two channels per bus. Therefore, you must configure the CIC filter with four output interfaces. The rate change factor must also be at least four to exploit this architecture, but this example shows a rate change of eight.
The total number of input channels must be a multiple of the number of interfaces. To satisfy this requirement, you may need to either insert dummy channels or use more than one CIC IP core.
The CIC transfers data as packets using Avalon Avalon-ST interfaces.
For a decimation filter, the gain at the output of the filter is:
G = RM N
Therefore, the data width at the output stage for if full resolution is:
B out = B in + Nlog2(RM)
where Bin is the input data width.
For an interpolation filter, the gain at each filter stage is:
Hence the required data width at the ith stage is:
W i = [B in + log2(G i )]
and the data width at the output stage is:
B out = [B in + Nlog2(RM) - log2(R)]
where B in is the input data width.
When the differential delay is one, the bit width at each integrator stage is increased by one to ensure stability.
For more information about these calculations, refer to Hogenauer, Eugene. An Economical Class of Digital Filters For Decimation and Interpolation, IEEE Transactions on Acoustics, Speech and Signal Processing, Vol. ASSP-29, pp. 155-162, April 1981.
|Truncation||The CIC drops the LSBs. (Equivalent to rounding to minus infinity.)|
|Convergent rounding||Also known as unbiased rounding. Rounds to the nearest even number. If the most significant deleted bit is one, and either the least significant of the remaining bits or at least one of the other deleted bits is one, then one is added to the remaining bits.|
|Round up||Also known as rounding to plus infinity. Adds the MSB of the discarded bits for positive and negative numbers via the carry in.|
|Saturation||Puts a limit value (upper limit in the case of overflow, or lower limit in the case of negative overflow) at the output when the input exceeds the allowed range. The upper limit is +2n-1 and lower limit is –2n|
The existing algorithms for computing the Hogenauer bit width growth for large N and R values are computationally expensive.
For more information about these algorithms, refer to U. Meyer-Baese, Digital Signal Processing with Field Programmable Gate Arrays, 2nd Edition, Spinger, 2004.
The CIC IP core has precalculated Hogenauer pruning bit widths. The CIC does not have to calculate Hogenauer pruning bit widths if you enable Hogenauer pruning for a decimation filter.
Typically, decimation or interpolation filtering applications require flat passband and narrow transition region filter performance. However, the CIC filter has drooping passband gains and wide transition regions. To overcome these problems connect the decimation or interpolation CIC filter to a compensation FIR filter, which narrows the output bandwidth and flattens the passband gain.
You can use a frequency sampling method to determine the coefficients of a FIR filter that equalizes the undesirable passband droop of the CIC and construct an ideal frequency response.
Determine the ideal frequency response by sampling the normalized magnitude response of the CIC filter before inverting the response.
Generally, only equalize the response in the passband, but you can sample further than the passband to fine tune the cascaded response of the filter chain.
The CIC IP core generates a MATLAB script <variation_name>_fir_comp_coeff.m in the project directory. You can run this script in MATLAB to generate FIR coefficients that provide appropriate passband equalization. The generated coefficients are saved in a text file, for use by the FIR IP.
The MATLAB script requires the following parameters for the compensation FIR filter:
- L: FIR filter length, which is same as the number of taps or the number of coefficients
- F S : FIR filter sample rate in Hz before decimation/interpolation
- F C: FIR filter cutoff frequency in Hz
B: Coefficient bit width if coefficients
are written in fixed-point numbers
Figure 12. CIC and Compensation Filter Responses
|Filter type||Decimator, Interpolator||Selects a decimator or interpolator.|
|Number of stages||1 to 12||Specifies the required number of stages.|
|Differential delay||1, 2||Specifies the differential delay in cycles.|
|Enable variable rate change factor||On or Off||Turn on to enable a variable rate change factor that you can change at runtime. When this option is on, the Rate change factor parameter is not available but you can specify minimum and maximum values.|
|Rate change factor||2 to 32000||Specifies the rate change factor.|
|Number of interfaces||1 to 128||Specifies the number of MISO inputs or SIMO outputs The product of the Number of interfaces and the Number of channels per interface must be no more than 1024.|
|Number of channels per interface||1 to 1024||Specifies the number of channels per interface. The product of the Number of interfaces and the Number of channels per interface must be no more than 1024|
|Input data width||1 to 32||Specifies the input data width in bits.|
|Output Rounding Options||None, Truncation, Convergent rounding, Rounding up, Saturation, Hogenauer pruning||Selects the required rounding output mode. Select None for full output resolution. The saturation limit is the maximum value for overflow or the minimum value for negative overflow. Hogenauer pruning is available only when a Decimator filter type is selected in the Architecture page.|
|Output data width||1 to calculated maximum data width||Specifies the output data width in bits.|
|Integrator data storage||Logic Element, Memory||Selects whether to implement the integrator data storage as logic elements or memory. The Memory option is available for integrator data storage when the Number of channels per interface is greater than 4.|
|RAM type of integrator data storage||AUTO, M9K, M10K, M20K, M144K, MLAB||When you select Memory, you can select the RAM type for integrator data storage. The Memory option is available for integrator data storage when the Number of channels per interface is greater than 4.|
|Differentiator data storage||Logic Element, Memory||Selects whether to implement the differentiator data storage as logic elements or memory. The Memory option is available for differentiator data storage when the product of the Differential delay, Number of channels per interface and Number of interfaces is greater than 4.|
|RAM type of differentiator data storage||AUTO, M9K, M10K, M20K, M144K, MLAB||When you select Memory, you can select the RAM type for differentiator data storage. The options available depend on the target device family. When AUTO is selected, the Quartus II software automatically selects the optimum RAM type for the currently selected device family.|
|Pipeline stages per integrator||—||Enter the pipeline stages per integrator. This option is available when the Number of channels per interface is greater than or equal to 2 (or greater than or equal to 6, when you select the Memory option for integrator data storage).
Use this option for multichannel designs that have large input bit width and require high fMAX, but not for designs targeting Cyclone devices.
|Pipeline stages per integrator||1 to 4||Specifies the number of pipeline stages used by each integrator. Adding additional integrators can improve fMAX but increases the resource utilization.
The maximum number of pipeline stages depends on the number of channels and whether you select Memory or Logic Cells for integrator data storage. For Memory, the maximum number of pipeline stages equals the number of channels minus 5. For Logic Cells, the maximum number of pipeline stages equals the number of channels.
|SYMBOLS_PER_BEAT||Single input, single output architectures, have one symbol per beat at the source and the sink. MISO architectures have <number of interfaces> symbols per beat at the sink, and a single symbol per beat at the source. SIMO architectures have <number of interfaces> symbols per beat at the source, and a single symbol per beat at the sink.|
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.
|av_st_in_data||Input||In Qsys systems, this Avalon-ST-compliant data bus includes all the Avalon-ST input data signals. For multi-interface designs Interface 0 is in the MSB; Interface N is the LSB.|
|clk||Input||Clock signal for all internal registers.|
|clken||Input||Optional top-level clock enable.|
|reset_n||Input||Active low reset signal. You must always reset the CIC MegaCore function before receiving data. If not, the CIC filter may produce unexpected results because of feedback signals.|
|in_data||Input||Sample input. For multiple input cases, the input data ports are in0_data, in1_data, and so on.|
|in_endofpacket||Input||Marks the end of the incoming sample group. For N channels, the end of packet signal must be high when the sample belonging to the last channel, channel N-1, is presented at in_data.|
|in_error||Input||Error signal indicating Avalon-ST protocol violations on input side:
|in_ready||Output||Indicates when the IP core can accept data.|
|in_startofpacket||Input||Marks the start of the incoming sample group. The start of packet is interpreted as a sample from channel 0.|
|in_valid||Input||Asserted when data at in_data is valid. When in_valid is not asserted, processing is stopped until valid is re-asserted. If clken is 0, in_valid is not be asserted.|
|av_st_out_data||Output||In Qsys systems, this Avalon-ST-compliant data bus includes all the Avalon-ST output data signals. For multi-interface designs Interface 0 is in the MSB; Interface N is the LSB.|
|out_channel||Output||Specifies the channel whose result is presented at out_data.|
|out_data||Output||Filter output. The data width depends on the parameter settings. For multiple output cases, the output data ports are named as out0_data, out1_data, and so on.|
|out_endofpacket||Output||Marks the end of the outgoing result group. If '1', a result corresponding to channel N-1 is output, where N is the number of channels.|
|out_error||Output||Error signal indicating Avalon-ST protocol violations on source side:
|out_ready||Input||Asserted by the downstream module if it is able to accept data.|
|out_startofpacket||Output||Marks the start of the outgoing result group. If '1', a result corresponding to channel 0 is output.|
|out_valid||Output||Asserted by the IP core when there is valid data to output.|
|rate||Input||This signal is available when the variable rate change factor option is enabled. You can use it to change the decimation or interpolation rate during run time. It has the size Ceil(log2(maximum rate)).|
The source provides data and asserts valid on cycle 1, even though the sink is not ready. The source waits until cycle 2, when the sink does assert ready, before moving onto the next data cycle. In cycle 3, the source drives data on the same cycle and because the sink is ready to receive it, the transfer occurs immediately. In cycle 4, the sink asserts ready, but the source does not drive valid data.
Packet data transfers are used for multichannel transfers. Two additional signals (startofpacket and endofpacket) are defined to implement the packet transfer.
The multiple symbols per beat scenario applies to both the sink interface on MISO CIC filters and the source interface of SIMO CIC filters. All other interfaces operate with a single symbol per beat, but the interfaces also support multiple channels using packets.
During cycle 1, the CIC IP core asserts startofpacket, and transfers the first four bytes of packet. During cycle 5, the CIC IP core asserts endofpacket indicating that this is the end of the packet. The channel signal indicates the channel index associated with the data. For example, on cycle 1, the data D0, D1, D2, and D3 associated with channel 0 are available.
|IP Core Version||User Guide|
|14.1||CIC IP Core User Guide v14.1|
|August 2014||14.0 Arria 10 Edition||
|November 2012||12.1||Added support for Arria V GZ devices.|