|Feature||High-Speed Reed-Solomon||Reed-Solomon II|
- High-performance greater than 100 Gbps encoder or decoder for
error detection and correction:
- Fully parameterizable:
- Number of bits per symbol
- Number of symbols per codeword
- Number of check symbols per codeword
- Field polynomial
- Multichannels and backpressure for decoders
- Fracturable decoder that supports 100 Gbps Ethernet (GbE), 2 x 50 GbE, and 4 x 25 GbE
- Avalon® Streaming (Avalon-ST) interfaces
- Testbenches to verify the IP core
- IP functional simulation models for use in Altera-supported VHDL and Verilog HDL simulators
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—Alteraverifies 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 GX||Preliminary|
|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|
|Ordering Code||IP-RSCODEC-HS (IPR-RSCODEC-HS)|
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.
|Parameters||ALM||Memory M20K||fMAX (MHz)|
|RS Code||Parallelism (P)||Latency||Favor ROM|
|Parameters||ALM||Memory M20K||fMAX (MHz)|
|Parameters||ALM||Memory M20K||fMAX (MHz)|
|RS Code||Parallelism (P)||Latency||Favor ROM|
|RS Code||Parallelism (P)|
|RS Code||Parallelism (P)|
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 Prime 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, out_data 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.
The High-speed Reed-Solomon IP core has a parallelized architecture to achieve very high throughout. The inputs and outputs contain multiple data symbols.
The fracturable decoder has preset parameters to support 4 x 25 GbE, 2 x 50 GbE and 1 x 100 GbE with parallelism p of 8, 16, and 32, respectively.
The encoder may use backpressure on the upstream component when it generates the check symbols and the parallelism is smaller than the number of check symbols.
The received encoded codeword may differ from the original codeword due to the noise in the channel. The decoder detects errors using several polynomials to locate the error location and the error value. When the decoder obtains the error location and value, the decoder corrects the errors in a codeword, and sends the codeword to the output. As the number of errors increases, the decoder gets to a stage where it can no longer correct but only detect errors, at which point the decoder asserts the out_error signal.
|Parameter||Legal Values||Default Value||Description|
|Reed-Solomon Core||Fractuarable 100G Ethernet or custom||Custom||-|
|Reed-Solomon module||Encoder or Decoder||Decoder||An encoder or a decoder.|
|Custom IP Core|
|Number of channels||1 to 10||1||Decoder only.|
|Number of bits per symbol||3 to 12||8||The number of bits per symbol (M).|
|Number of symbols per codeword||1 to 2M – 1||255||The total number of symbols per codeword (N).|
|Number of data symbols per codeword||2 to N– 2||239||The number of data symbols per codeword (K = N - R). Where R is the number of check symbols.|
|Field polynomial||Any valid polynomial||285||The primitive polynomial defining the Galois field. The parameter editor allows you to select only legal values. If you cannot find your intended field polynomial, contact Altera MySupport.|
|Parallelism||P < N/2||3||The number of parallel inputs and outputs. The last output fills up with zeros.|
|Bypass Mode||No or yes||No||Turn on to produce the received codeword without error correction but with only error detection. A message is output after few clock cycles.|
|Fractuarable IP core Parameters|
|100G Ethernet||On||On||A single 100G channels with parallelism 32.|
|2 x 50G Ethernet||On or off||On||Two independent 50 GbE channels with parallelism 16.|
|4 x 25G ethernet||On or off||On||Four independent 25 GbE channels with parallelism 8.|
|Custom and Fracturable IP Core Parameters|
|Latency||N/P+ (BM speed x R) +10; with BMspeed is 1, 2, 4 or 6.||BMspeed is 4||The latency as a function of the Berlekamp–Massey (BM) speed (decoder only).|
|Favor ROM||No or yes||Yes||Uses M20K memory to reduce the ALMs. Savings are significant with large parallelism.|
|Use true dual-port ROM||No or yes||Yes||-|
|Refresh ROM content||No or yes||No||The IP core continuously rewrites the ROM contents.|
|Use backpressure||No or yes||No||Decoder only. When you select Yes, you can use the out_ready signal to assert when the source is ready, but this option might limit fMAX.|
|Hyper-optimisation||Low, medium, high||Low||-|
|Decoder Output Signal Options|
|Output decoding failure||On or off||On||Turns on out_decfail signal|
|Output error symbol count||On of off||On||Turns on out_errors_out signal.|
|Output error symbol values||On or off||On||Turns on out_errorvalues_out signal.|
|Output start and end of packet||On or off.||On||Use Avalon-ST SOP and EOP signal to indicate start and end of packet|
The clock and reset interfaces drive or receive the clock and reset signal to synchronize the Avalon-ST interfaces and provide reset connectivity. The status interface is a conduit interface that consists of three error status signals for a codeword. The decoder obtains the error symbol value, number of error symbols, and number of error bits in a codeword from the status signals.
Avalon-ST interfaces define a standard, flexible, and modular protocol for data transfers from a source interface to a sink interface.
The input interface is an Avalon-ST sink and the output interface is an Avalon-ST source.
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 support backpressure, which is a flow control mechanism where a sink can indicate 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.
|clk_clk||clk||Input||The main system clock. The whole IP core operates on the rising edge of clk_clk .|
|reset_reset_n||reset_n||Input||An active low signal that resets the entire system when asserted. You can assert this signal asynchronously. However, you must deassert it synchronous to the clk_clk signal. When the IP core recovers from reset, ensure that the data it receives is a complete packet.|
|in_ready||ready||Output||Data transfer ready signal to indicate that the sink is ready to accept data. The sink interface drives the in_ready signal to control the flow of data across the interface. The sink interface captures the data interface signals on the current clk rising edge.|
|in_valid||valid||Input||Data valid signal to indicate the validity of the data signals. When you assert the in_valid signal, the Avalon-ST data interface signals are valid. When you deassert the in_valid signal, the Avalon-ST data interface signals are invalid and must be disregarded. You can assert the in_valid signal whenever data is available. However, the sink only captures the data from the source when the IP core asserts the in_ready signal.|
|in_data||data||Input||Data input for each codeword, symbol by symbol.
Valid only when you assert the in_valid signal. Width is P x M bits.
For the encoder, the number of information symbols (N - CHECK) is not necessarily a multiple of P. It means that the last input symbol may have to be filled with zeros.
|out_data||data||Output||Encoder output. In Qsys systems for the decoder, this Avalon-ST-compliant data bus includes all the Avalon-ST output data signals (out_error_out, out_decfail, out_symol_out),) with length log2(R+1) + 1.|
|out_errors_out||error||Output||Number of error symbol that the IP core decides. Size is log2(R+1)|
|out_ready||ready||Input||Data transfer ready signal to indicate that the downstream module is ready to accept data. The source provides new data (if available) when you assert the out_ready signal and stops providing new data when you deassert the out_ready signal. If the source is unable to provide new data, it deasserts out_valid for one or more clock cycles until it is prepared to drive valid data interface signals.|
|out_symbols_out||data||Output||Contains decoded output when the IP core asserts the out_valid signal. The corrected symbols are in the same order that they are entered.|
|out_valid||valid||Output||Data valid signal. The IP core asserts the out_valid signal high, whenever a valid output is on out_data ; the IP core deasserts the signal when there is no valid output on out_data .|
|in-valid||Valid||Input||1||Master valid signal. If in_valid is low it sets all valid_ch_in to low.|
|in-data||Data||Input||320 symbols_in + 4 valid_ch_in + 2 mode_in + sync_in||Data input.|
|valid_ch_in||Part of in_data||Input||4||Input valid signal for each channel.|
|symbols_in||Part of in_data||Input||32||Input symbols.
|mode_in||Part of in_data||Input||2||
|sync_in||Part of in_data||Input||1||Synchronize the output channels.|
|out_valid||Valid||Output||1||Master valid signal. out_valid is valid if any valid_ch_out is valid, i.e. if valid_ch0 or valid_ch1 etc are valid.|
|out_data||Data||Output||320 decoded symbols + 4 valid_out + 2 mode_out + 4 sop_out + 4 eop_out +4 decfail+ 12 errors_out||Output data.|
|errors_out||Part of out_data||Output||12||Number of error symbols that the IP core decides.|
|decfail||Part of out_data||Output||4||(Optional) decfail of each output channel|
|eop_out||Part of out_data||Output||4||(Optional) eop of each output channel|
|sop_out||Part of out_data||Output||4||(Optional) sop of each channels|
|mode_out||Part of out_data||Output||2||Output mode.|
|valid_ch_out||Part of out_data||Output||4||Valid signal for each channel|
|symbols_out||Part of out_data||Output||320||Output symbols:
|Document Date||Software Version||Changes|
|2015.11.01||15.1||Corrected encoder and decoder diagrams|
|IP Core Version||User Guide|
|16.0||High-speed Reed-Solomon IP Core User Guide|
|15.1||High-speed Reed-Solomon IP Core User Guide|