Reed-Solomon II IP Core User Guide
Subscribe
Send Feedback
UG-01090
2015.05.01
101 Innovation Drive
San Jose, CA 95134
www.altera.com
TOC-2
Contents
About the Reed-Solomon II IP Core...................................................................1-1
Reed-Solomon II IP Core Getting Started..........................................................2-1
Altera DSP IP Core Features...................................................................................................................... 1-1
Reed-Solomon II IP Core Features............................................................................................................1-1
DSP IP Core Device Family Support.........................................................................................................1-1
DSP IP Core Verification............................................................................................................................1-2
Reed-Solomon II IP Core Release Information.......................................................................................1-2
Reed-Solomon II IP Core Performance and Resource Utilization.......................................................1-3
Installing and Licensing IP Cores..............................................................................................................2-1
OpenCore Plus IP Evaluation........................................................................................................ 2-1
Reed-Solomon II IP Core OpenCore Plus Timeout Behavior...................................................2-2
IP Catalog and Parameter Editor...............................................................................................................2-2
Specifying IP Core Parameters and Options............................................................................................2-3
Files Generated for Altera IP Cores...............................................................................................2-4
Simulating Altera IP Cores in other EDA Tools..................................................................................... 2-7
DSP Builder Design Flow............................................................................................................................2-8
Reed-Solomon II IP Core Functional Description.............................................3-1
Architecture..................................................................................................................................................3-1
Encoder..............................................................................................................................................3-1
Decoder............................................................................................................................................. 3-2
Multiple Input Channels.................................................................................................................3-4
Reed-Solomon II IP Core Parameters.......................................................................................................3-5
Reed-Solomon II IP Core Interfaces and Signals.................................................................................... 3-7
Avalon-ST Interfaces in DSP IP Cores..........................................................................................3-7
Reed-Solomon II IP Core Signals.................................................................................................. 3-7
Document Revision History................................................................................4-1
Altera Corporation
2015.05.01
www.altera.com
101 Innovation Drive, San Jose, CA 95134
About the Reed-Solomon II IP Core
1
UG-01090
Subscribe
Send Feedback
Altera DSP IP Core Features
• 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
Reed-Solomon II IP Core Features
• High-performance encoder or decoder for error detection and correction:
• • Fully parameterizable:
• Number of channels
• Number of bits per symbol
• Number of symbols per codeword
• Number of check symbols per codeword
• Field polynomial
• Erasures-supporting decoder—-the decoder can correct symbol errors up to the number of check
symbols, if you give the location of the errors to the decoder
• Error symbol output—the decoder provides the error values
• Bit error output—either split count or full count
• Multiple channels for resource sharing
DSP IP Core Device Family Support
©
2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos are
trademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified as
trademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performance
of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any
products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information,
product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device
specifications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
1-2
DSP IP Core Verification
Altera® offers the following device support levels for Altera IP cores:
• 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.
Table 1-1: DSP IP Core Device Family Support
Device Family Support
Arria® II GX Final
Arria II GZ Final
Arria V Final
Arria 10 Final
Cyclone® IV Final
Cyclone V Final
MAX® 10 FPGA Final
UG-01090
2015.05.01
Stratix® IV GT Final
Stratix IV GX/E Final
Stratix V Final
Other device families No support
DSP IP Core Verification
Before releasing a version of an IP core, Altera runs comprehensive regression tests to verify its quality
and correctness. Altera generates custom variations of the IP core to exercise the various parameter
options and thoroughly simulates the resulting simulation models with the results verified against master
simulation models.
Reed-Solomon II IP Core Release Information
Use the release information when licensing the IP core.
Table 1-2: Release Information
Item Description
Altera Corporation
Version 15.0
Release Date May 2015
Ordering Code
IP-RSCODECII (Primary License)
IPR-RSCODECII (Renewal License)
About the Reed-Solomon II IP Core
Send Feedback
UG-01090
2015.05.01
Item Description
Reed-Solomon II IP Core Performance and Resource Utilization
Product ID 00E5 (Encoder/Decoder)
Vendor ID 6AF7
Altera verifies that the current version of the Quartus II software compiles the previous version of each IP
core. Altera does not verify that the Quartus II software compiles IP core versions older than the previous
version. The Altera IP Release Notes lists any exceptions.
Related Information
• Altera IP Release Notes
• Errata for Reed-Solomon IP core in the Knowledge Base
Reed-Solomon II IP Core Performance and Resource Utilization
Table 1-3: Performance and Resource Utilization
Typical expected performance for a Reed-Solomon II IP Core using the Quartus II software with the Arria V
(5AGXFB3H4F40C4), Cyclone V (5CGXFC7D6F31C6), and Stratix V (5SGSMD4H2F35C2) devices.
Device
Parameters
Type Check
Symbols
Bits Per
Symbol
Bits Per
Check
Symbol
ALM
Memory Registers
M10K M20K Primary Secondary
1-3
fMAX
(MHz)
Arria V Erasures
decoder
Arria V Erasures
variable
decoder
Arria V Full
error
decoder
Arria V Split
error
decoder
Arria V Standard
decoder
large
Arria V Standard
decoder
medium
Arria V standard
decoder
small
16 8 204 1,687 1 -- 1,765 291 217
16 8 204 1,688 1 -- 1,810 269 213
16 8 204 952 1 -- 989 170 239
16 8 204 976 1 -- 999 144 224
32 8 255 1,628 1 -- 1,751 285 215
16 8 204 944 1 -- 974 178 225
6 4 15 201 1 -- 272 23 315
About the Reed-Solomon II IP Core
Send Feedback
Altera Corporation
1-4
Reed-Solomon II IP Core Performance and Resource Utilization
UG-01090
2015.05.01
Device
Type Check
Arria V Standard
encoder
Arria V Variable
decoder
Arria V Variable
encoder
large
Arria V Variable
encoder
small
CycloneVErasures
decoder
CycloneVErasures
variable
decoder
CycloneVFull
error
decoder
Parameters
Symbols
Bits Per
Symbol
Bits Per
Check
Symbol
ALM
Memory Registers
M10K M20K Primary Secondary
fMAX
(MHz)
16 8 204 87 0 -- 164 0 422
16 8 204 964 1 -- 1,019 174 209
32 8 204 904 0 -- 299 0 234
16 8 204 444 0 -- 169 0 259
16 8 204 1,670 1 -- 1,769 366 192
16 8 204 1,683 1 -- 1,812 342 196
16 8 204 953 1 -- 989 232 215
CycloneVSplit
error
decoder
CycloneVStandard
decoder
large
CycloneVStandard
decoder
medium
CycloneVstandard
decoder
small
CycloneVStandard
encoder
CycloneVVariable
decoder
CycloneVVariable
encoder
large
CycloneVVariable
encoder
small
16 8 204 968 1 -- 1,003 198 209
32 8 255 1,631 1 -- 1,752 409 193
16 8 204 938 1 -- 972 227 222
6 4 15 200 1 -- 272 56 275
16 8 204 87 0 -- 164 0 372
16 8 204 968 1 -- 1,016 241 220
32 8 204 905 0 -- 299 0 188
16 8 204 444 0 -- 169 0 217
Altera Corporation
About the Reed-Solomon II IP Core
Send Feedback
UG-01090
2015.05.01
Reed-Solomon II IP Core Performance and Resource Utilization
1-5
Device
Type Check
Stratix V Erasures
decoder
Stratix V Erasures
variable
decoder
Stratix V Full
error
decoder
Stratix V Split
error
decoder
Stratix V Standard
decoder
large
Stratix V Standard
decoder
medium
Parameters
Symbols
Bits Per
Symbol
Bits Per
Check
Symbol
ALM
Memory Registers
M10K M20K Primary Secondary
fMAX
(MHz)
16 8 204 1,648 -- 1 1,765 423 367
16 8 204 1,664 -- 1 1,802 405 368
16 8 204 955 -- 1 987 252 424
16 8 204 969 -- 1 1,003 248 424
32 8 255 1,624 -- 1 1,749 432 404
16 8 204 939 -- 1 972 281 410
Stratix V standard
decoder
small
Stratix V Standard
encoder
Stratix V Variable
decoder
Stratix V Variable
encoder
large
Stratix V Variable
encoder
small
6 4 15 197 -- 1 272 52 525
16 8 204 87 -- 0 164 0 610
16 8 204 966 -- 1 1,017 270 409
32 8 204 902 -- 0 299 0 397
16 8 204 435 -- 0 169 0 434
About the Reed-Solomon II IP Core
Send Feedback
Altera Corporation
2015.05.01
acds
quartus - Contains the Quartus II software
ip - Contains the Altera IP Library and third-party IP cores
altera - Contains the Altera IP Library source code
<IP core name> - Contains the IP core source files
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Reed-Solomon II IP Core Getting Started
2
UG-01090
Subscribe
Send Feedback
Installing and Licensing IP Cores
The Altera IP Library provides many useful IP core functions for your production use without purchasing
an additional license. Some Altera MegaCore® IP functions require that you purchase a separate license
for production use. However, the OpenCore® feature allows evaluation of any Altera IP core in simulation
and compilation in the Quartus® II software. After you are satisfied with functionality and perfformance,
visit the Self Service Licensing Center to obtain a license number for any Altera product.
Figure 2-1: IP Core Installation Path
Note: The default IP installation directory on Windows is <drive>:\altera\<version number>; on Linux it is
<home directory>/altera/ <version number>.
Related Information
• Altera Licensing Site
• Altera Software Installation and Licensing Manual
OpenCore Plus IP Evaluation
Altera's free OpenCore Plus feature allows you to evaluate licensed MegaCore IP cores in simulation and
hardware before purchase. You need only purchase a license for MegaCore IP cores if you decide to take
your design to production. OpenCore Plus supports the following evaluations:
• 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.
©
2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos are
trademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified as
trademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performance
of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any
products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information,
product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device
specifications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
2-2
Reed-Solomon II IP Core OpenCore Plus Timeout Behavior
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 requires a
connection between your board and the host computer.
Note: All IP cores that use OpenCore Plus time out simultaneously when any IP core in the design times
out.
Reed-Solomon II IP Core OpenCore Plus Timeout Behavior
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, the time-out behavior of the other IP cores may mask the timeout behavior of a specific IP core .
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 timeout value is indefinite. Your design stops working after the hardware evaluation time expires. The Quartus
II 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, for encoders out_data goes low, rst goes high; for decoders, data
goes low, rst goes high .
UG-01090
2015.05.01
Related Information
• AN 320: OpenCore Plus Evaluation of Megafunctions
IP Catalog and Parameter Editor
The Quartus II IP Catalog (Tools > IP Catalog) and parameter editor help you easily customize and
integrate IP cores into your project. You can use the IP Catalog and parameter editor to select, customize,
and generate files representing your custom IP variation.
Note:
The IP Catalog (Tools > IP Catalog) and parameter editor replace the MegaWizard™ Plug-In
Manager for IP selection and parameterization, beginning in Quartus II software version 14.0. Use
the IP Catalog and parameter editor to locate and paramaterize Altera IP cores.
The IP Catalog lists installed IP cores available for your design. Double-click any IP core to launch the
parameter editor and generate files representing your IP variation. 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 II IP file (.qip) representing the IP core in your
project. You can also parameterize an IP variation without an open project.
Use the following features to help you quickly locate and select an IP core:
• 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 view links to documentation.
• Click Search for Partner IP, to access partner IP information on the Altera website.
Altera Corporation
Reed-Solomon II IP Core Getting Started
Send Feedback
Search for installed IP cores
Double-click to customize, right-click for
detailed information
Show IP only for target device
UG-01090
2015.05.01
Figure 2-2: Quartus II IP Catalog
Specifying IP Core Parameters and Options
2-3
Note: 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 II IP Catalog. For more information about using the Qsys IP Catalog, refer
to Creating a System with Qsys in the Quartus II Handbook.
Specifying IP Core Parameters and Options
You can quickly configure a custom IP variation in the parameter editor. Use the following steps to
specify IP core options and parameters in the parameter editor. Refer to Specifying IP Core Parameters
and Options (Legacy Parameter Editors) for configuration of IP cores using the legacy parameter editor.
1. In the IP Catalog (Tools > IP Catalog), locate and double-click the name of the IP core to customize.
The parameter editor appears.
2. 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.
3. Specify the parameters and options for your IP variation in the parameter editor, including one or
more of the following. Refer to your IP core user guide for information about specific IP core
parameters.
Reed-Solomon II IP Core Getting Started
Send Feedback
Altera Corporation
View IP port
and parameter
details
Apply preset parameters for
specific applications
Specify your IP variation name
and target device
2-4
Files Generated for Altera IP Cores
• 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.
4. Click Generate HDL, the Generation dialog box appears.
5. Specify output file generation options, and then click Generate. The IP variation files generate
according to your specifications.
6. To generate a simulation testbench, click Generate > Generate Testbench System.
7. To generate an HDL instantiation template that you can copy and paste into your text editor, click
Generate > HDL Example.
8. Click Finish. The parameter editor adds the top-level .qsys file to the current project automatically. If
you are prompted to manually add the .qsys file to the project, click Project > Add/Remove Files in
Project to add the file.
9. After generating and instantiating your IP variation, make appropriate pin assignments to connect
ports.
Figure 2-3: IP Parameter Editor
UG-01090
2015.05.01
Files Generated for Altera IP Cores
The Quartus II software generates the following IP core output file structure:
Altera Corporation
Reed-Solomon II IP Core Getting Started
Send Feedback
<your_testbench>_tb.csv
<your_testbench>_tb.spd
<your_ip>.cmp - VHDL component declaration file
<your_ip>.ppf - XML I/O pin information file
<your_ip>.qip - Lists IP synthesis files
<your_ip>.sip - Contains assingments for IP simulation files
<your_ip>.v or .vhd
Top-level IP synthesis file
<your_ip>.v or .vhd
Top-level simulation file
<simulator_setup_scripts>
<your_ip>.qsys - System or IP integration file
<your_ip>_bb.v - Verilog HDL black box EDA synthesis file
<your_ip>_inst.v or .vhd - Sample instantiation template
<your_ip>_generation.rpt - IP generation report
<your_ip>.debuginfo - Contains post-generation information
<your_ip>.html - Connection and memory map data
<your_ip>.bsf - Block symbol schematic
<your_ip>.spd - Combines simulation scripts for multiple cores
<your_ip>_tb.qsys
Testbench system file
<your_ip>.sopcinfo - Software tool-chain integration file
<project directory>
<EDA tool setup
scripts>
<your_ip>
IP variation files
<testbench>_tb
testbench system
sim
Simulation files
synth
IP synthesis files
sim
simulation files
<EDA tool name>
Simulator scripts
<testbench>_tb
<ip subcores> n
Subcore libraries
sim
Subcore
Simulation files
synth
Subcore
synthesis files
<HDL files>
<HDL files>
<your_ip> n
IP variation files
testbench files
UG-01090
2015.05.01
Figure 2-4: IP Core Generated Files
Files Generated for Altera IP Cores
2-5
Table 2-1: IP Core Generated Files
File Name Description
<my_ip>.qsys
<system>.sopcinfo Describes the connections and IP component parameterizations in
Reed-Solomon II IP Core Getting Started
Send Feedback
The Qsys system or top-level IP variation file. <my_ip> is the name
that you give your IP variation.
your Qsys system. You can parse its contents 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.
Altera Corporation
2-6
Files Generated for Altera IP Cores
File Name Description
<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.
UG-01090
2015.05.01
<my_ip>.html
A report that contains connection information, a memory map
showing the address of each slave with respect to each master to
which it is connected, 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. Used to pass 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.
<my_ip>.qip
Contains all the required information about the IP component to
integrate and compile the IP component in the Quartus II software.
<my_ip>.csv Contains information about the upgrade status of the IP component.
<my_ip>.bsf A Block Symbol File (.bsf) representation of the IP variation for use
in Quartus II Block Diagram Files (.bdf).
<my_ip>.spd
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 black-box (_bb.v) file as an empty module
declaration for use as a black box.
<my_ip>.sip Contains information required for NativeLink simulation of IP
components. You must add the .sip file to your Quartus project.
<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 .regmap file generates.
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
enables register display views and user customizable statistics in
System Console.
Altera Corporation
Reed-Solomon II IP Core Getting Started
Send Feedback
UG-01090
2015.05.01
Simulating Altera IP Cores in other EDA Tools
File Name Description
2-7
<my_ip>.svd
<my_ip>.v
or
<my_ip>.vhd
mentor/
aldec/
/synopsys/vcs
/synopsys/vcsmx
Allows HPS System Debug tools to view the register maps of
peripherals connected to HPS within a Qsys system.
During synthesis, the .svd files for slave interfaces visible to System
Console masters are stored in the .sof file in the debug section.
System Console reads this section, which Qsys can query for register
map information. For system slaves, Qsys can access the registers by
name.
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.
/cadence
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.
<child IP cores>/ For each generated child IP core directory, Qsys generates /synth and /
sim sub-directories.
Simulating Altera IP Cores in other EDA Tools
The Quartus II software supports RTL and gate-level design simulation of Altera IP cores in supported
EDA simulators. Simulation involves setting up your simulator working environment, compiling
simulation model libraries, and running your simulation.
You can use the functional simulation model and the testbench or example design generated with your IP
core for simulation. The functional simulation model and testbench files are generated in a project
subdirectory. This directory may also include scripts to compile and run the testbench. For a complete list
of models or libraries required to simulate your IP core, refer to the scripts generated with the testbench.
You can use the Quartus II NativeLink feature to automatically generate simulation files and scripts.
NativeLink launches your preferred simulator from within the Quartus II software.
Reed-Solomon II IP Core Getting Started
Send Feedback
Altera Corporation
Post-fit timing
simulation netlist
Post-fit timing
simulation (3)
Post-fit functional
simulation netlist
Post-fit functional
simulation
Analysis & Synthesis
Fitter
(place-and-route)
TimeQuest Timing Analyzer
Device Programmer
Quartus II
Design Flow
Gate-Level Simulation
Post-synthesis
functional
simulation
Post-synthesis functional
simulation netlist
(Optional) Post-fit
timing simulation
RTL Simulation
Design Entry
(HDL, Qsys, DSP Builder)
Altera Simulation
Models
EDA
Netlist
Writer
2-8
DSP Builder Design Flow
Figure 2-5: Simulation in Quartus II Design Flow
UG-01090
2015.05.01
Note: Post-fit timing simulation is supported only for Stratix IV and Cyclone IV devices in the current
version of the Quartus II software. Altera IP supports a variety of simulation models, including
simulation-specific IP functional simulation models and encrypted RTL models, and plain text
RTL models. These are all cycle-accurate models. The models support fast functional simulation of
your IP core instance using industry-standard VHDL or Verilog HDL simulators. For some cores,
only the plain text RTL model is generated, and you can simulate that model. Use the simulation
models only for simulation and not for synthesis or any other purposes. Using these models for
synthesis creates a nonfunctional design.
Related Information
Simulating Altera Designs
DSP Builder Design Flow
DSP Builder shortens digital signal processing (DSP) design cycles by helping you create the hardware
representation of a DSP design in an algorithm-friendly development environment.
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. For more information about the DSP Builder flow, refer to the
Altera Corporation
Reed-Solomon II IP Core Getting Started
Send Feedback
UG-01090
2015.05.01
Related Information
Using MegaCore Functions chapter in the DSP Builder Handbook.
DSP Builder Design Flow
2-9
Reed-Solomon II IP Core Getting Started
Send Feedback
Altera Corporation
2015.05.01
1 238
Check Symbols
Data Symbol
239
2 ... 237
1 238
Encoded Codeword
239
2 ... 237
P1
...
P15
P16
RS II Encoder
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Reed-Solomon II IP Core Functional Description
3
UG-01090
Subscribe
Send Feedback
This topic describes the IP core’s architecture, interfaces, and signals.
Architecture
You can parameterize the Reed-Solomon II IP core as an encoder or a decoder.
The encoder receives data packets and generates the check symbols; the decoder detects and corrects
errors.
Encoder
When the encoder receives data symbols, it generates check symbols for a given codeword and sends the
input codeword together with the check symbols to the output interface. The encoder uses backpressure
on the upstream component when it generates the check symbols.
Figure 3-1: Reed-Solomon II Codeword Encoding
©
2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos are
trademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified as
trademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performance
of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any
products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information,
product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device
specifications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
clk_clk
reset_reset_n
in_valid
in_startofpacket
in_endofpacket
in_data[7:0]
in_ready
out_valid
out_startofpacket
out_endofpacket
out_data[7:0]
out_ready
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 236 237 238 239 1 2 3 4
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 234 235 236 237 238
239
1 114 61 30 24475 1 2
3-2
Decoder
Figure 3-2: Encoder Timing—One Channel
Shows the timing diagram of the RS II encoder with one channel.
The in_startofpacket signal starts a codeword; the in_endofpacket signals its termination. An
asserted in_valid signal indicates valid data. The in_startofpacket signal is only valid when you assert
the in_valid signal. For a 1-channel codeword, assert the in_startofpacket and in_endofpacket
signals for one clock cycle. The encoder uses backpressure by deasserting the in_ready signal when it
receives the in_endofpacket signal. During this time, the encoder signals that it cannot accept more
incoming symbols and generates the check symbols for the current codeword. The IP core does not verify
if the number of symbols (N) exceeds the maximum symbols per codeword. You must ensure that the
codeword sent to the core has a valid N. The reset_reset_n signal is active low and you can assert this
signal asynchronously. However, you have to deassert the reset_reset_n signal synchronously with the
clk_clk signal.
UG-01090
2015.05.01
Altera Corporation
Shortened Codewords
The RS II IP core supports shortened codewords. A shortened codeword contains fewer symbols than the
maximum value of N, which is 2M –1, where N is the total number of symbols per codeword and M is the
number of bits per symbol. A shortened codeword is mathematically equivalent to a maximum-length
code with the extra data symbols at the start of the codeword set to 0. For example, (204,188) is a
shortened codeword of (255,239). Both of these codewords use the same number of check symbols, 16. To
use shortened codewords with the decoder, use the parameter editor to set the codeword length to the
correct value; for the encoder assert endofpacket once it generates enough symbols.
Decoder
When the decoder receives the encoded codeword, it uses the check symbols to detect errors and correct
them.
Reed-Solomon II IP Core Functional Description
Send Feedback
1 238
Decoded Codeword
239
... 237
240
...
255
RS II Decoder
Encoded Codeword plus noise
...
...
clk_clk
reset_reset_n
in_valid
in_startofpacket
in_endofpacket
in_data[7:0]
in_ready
out_valid
out_startofpacket
out_endofpacket
out_data[7:0]
out_ready
out_error
0 1 2 3 4 5 6 105 216 193 137 138 139 140 141 245 246 247 248 249 250 251 252 253 254 245 246 247 248 249 250 251 252
0 X 1 2 3 4 5 6 105 216 193 137 138 139 140 141
1
status_error_value[7:0]
0
0
0
0
0
status_num_error_symbol[3:0]
0 0
0
8
status_num_error_bit[6:0]
0 0
0
0
UG-01090
2015.05.01
Figure 3-3: Codeword Decoding
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.
Table 3-1: Decoder Detection and Correction
Lists how the decoder corrects and detects errors (e) depending on the number of check symbols (R).
Number of Errors Description
Decoder
3-3
e ≤R/2 Decoder detects and corrects errors.
R/2 ≤ e ≤R Decoder asserts error signal and can only detect
errors.
e >R Unpredictable results.
For small numbers of check symbols, out_error is not always reliable. RS codewords have at least
different symbols: d = R + 1 A received packet containing e errors can be either the transmitted codeword
t1 with e errors, or another valid codeword t2 with d–e errors (if t2 exists). When e> R/2, the received
packet looks more like t2 than t1 (because d – e < e) so, the decoder outputs t2 and does not assert
out_error. The probability that t2 exists is inferior or equal to the inverse of factorial of R/2. It decreases
exponentially as R increases, but is nonetheless significant for small numbers of check symbols.
Figure 3-4: Decoder Timing—One Channel
shows the timing diagram of the RS II decoder with one channel.
d
Reed-Solomon II IP Core Functional Description
Send Feedback
Altera Corporation
valid
startofpacket
endofpacket
channel
data
Codeword 1
Codeword 0
1
0
1
0
ch 1. N-1
ch 0. N-1
1
0
10 1
ch 1.1ch 0.1
ch 1.0
0
ch 0.0
...
...
...
...
...
...
ch 1. N-1
ch 1. N-1 ch 0. N-1 ch 1. N-1
3-4
Multiple Input Channels
The codeword starts when you assert the in_valid signal and the in_startofpacket signal.The decoder
accepts the data at in_data as valid data. The codeword ends when you assert the in_endofpacket signal.
For a 1-channel codeword, assert the in_startofpacket and in_endofpacket signals for one clock cycle.
When the decoder deasserts the in_ready signal, the decoder cannot process any more data until it
asserts the in_ready signal again.
At the output, the operation is identical. When the decoder asserts the out_valid signal and the
out_startofpacket signal, the decoder provides valid data on out_data. The decoder asserts the
out_startofpacket signal and the out_endofpacket signal to indicate the start and end of a codeword.
The decoder automatically detects and corrects errors in a codeword and asserts the out_error signal
when it encounters a non-correctable codeword. The decoder outputs the full codeword including the
check symbols, which you should remove.
Variable Decoding
Under normal circumstances, the decoder allow variable decoding—you can change the number of
symbols per codeword (N) using sink_eop, but not the number of check symbols while decoding.
However, you cannot change the length of the codeword, if you turn on the erasure-supporting option. If
you turn on the variable option, you can vary the number of symbols per codeword (using the numn
signal) and the number of check symbols (using the numcheck signal), in real time, from their minimum
allowable values up to their selected values, even with the erasures-supporting option turned on.
UG-01090
2015.05.01
Multiple Input Channels
The RS II IP core processes multiple input channels simultaneously.
The IP core receives codewords in a fixed pattern. Symbols coming in through the channels are
interleaved. The IP core samples the first symbol of channel one on the first rising clock edge, then the
first symbol of channel two on the second rising clock edge, etc. Both information and check symbols are
output in the same sequence.
Figure 3-5: Codeword for C Channels and N Symbols
The channel signal indicates the channel associated to the current symbol. The channel sequence is fixed.
startofpacket indicates the first symbol of a codeword per channel. For a C-channel codeword,
startofpacket must be high for C consecutive cycles. endofpacket indicates the last symbol of a
codeword per channel. For a C-channel codeword, endofpacket must be high for C consecutive cycles.
Altera Corporation
Note:
The startofpacket and endofpacket governs the number of symbols per codeword, N. The IP
core does not verify if N exceeds the maximum symbols per codeword. The IP core also does not
verify the channel or data pattern. You must ensure that the codeword sent to the IP core has a
valid N and a valid pattern.
Reed-Solomon II IP Core Functional Description
Send Feedback
clk_clk
reset_reset_n
in_valid
in_startofpacket
in_endofpacket
in_data[7:0]
in_channel
in_ready
out_valid
out_startofpacket
out_endofpacket
out_data[7:0]
out_channel
out_ready
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232
0 1 2 3 4 5 6 7 8 9 10 11 12 13 215 216 217 218 219 220 221 222 163 211 153 119 68 157 153 239 209 70 223 224 225 226 227 228 229 230
223
clk_clk
reset_reset_n
in_valid
in_startofpacket
in_endofpacket
in_data[7:0]
in_channel
in_ready
out_valid
out_startofpacket
out_endofpacket
out_data[7:0]
out_channel
out_ready
out_error
0
1 2 3 4 5 6 19 124 84 44 237174 55 192 193194 195 196197 198 153154 155156 157158 159 160161162 163 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101
0 X 1 2 3 4 5 6 19 124 84 44 237 174 55 192193 194195 196 197198 1992001
status_error_value[7:0]
0 0
0
0
status_num_error_symbol[3:0]
0 0 8 90
status_num_error_bit[6:0]
0 0 0
UG-01090
2015.05.01
Reed-Solomon II IP Core Parameters
Figure 3-6: Encoder Timing—Two Channels
For a two-channel codeword, the encoder asserts the in_startofpacket and in_endofpacket signals for
two consecutive cycles.
Figure 3-7: Decoder Timing—Two Channels
For a two-channel codeword, the decoder asserts the in_startofpacket and in_endofpacket signals for
two consecutive cycles.
3-5
Reed-Solomon II IP Core Parameters
Table 3-2: Parameters
Reed-Solomon II IP Core Functional Description
Parameter Legal Values Default Value Description
Reed-Solomon Encoder or Decoder Encoder Specifies an encoder or a decoder.
Number of
channels
Send Feedback
1 to 16 1 Specifies the number of input channels (C)
to process. The channel pattern is fixed.
Altera Corporation
3-6
Reed-Solomon II IP Core Parameters
Parameter Legal Values Default Value Description
UG-01090
2015.05.01
Number of bits per
symbol
Number of symbols
per codeword
3 to 12 8 Specifies the number of bits per symbol
(M).
1 to 2M–1 255 Specifies the total number of symbols per
codeword (N). The decoder accept a new
symbol every clock cycle if 6.5R < N. If N>
=6.5R+1, the decoder shows continuous
behavior.
Number of check
symbols per
1 to N–1 16 Specifies the number of check symbols per
codeword (R).
codeword
Field Polynomial Any valid polynomial 285 Specifies 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.
Type of generator
polynomial
First root of the
polynomial
Classical or CCSDSlike
Classical Specifies the representation of the
generator polynomial.
1 to 2M–2 0 Specifies the first root of the generator
polynomial.
generator
Root spacing in the
polynomial
Any primitive
elements in the field
1 Specifies spacing between roots in the
generator polynomial.
generator
Erasures-
supporting decoder
On or off Off Specifies the erasures-supporting decoder.
This option substantially increases the
logic resources the design uses.
Variable codeword
length
Variable number of
check symbols
On or off Off Specifies variable codeword length with
numn signal.
On or off Off Specifies check symbols with numcheck
signal.
Error symbol value On or off On Specifies whether the decoder indicates the
error symbols.
Error symbol count On or off On Specifies whether the decoder indicates the
number of error symbols per codeword.
Error bit count On or off On Specifies whether the decoder indicates the
number of error bits per codeword.
Altera Corporation
Reed-Solomon II IP Core Functional Description
Send Feedback
UG-01090
2015.05.01
Reed-Solomon II IP Core Interfaces and Signals
Parameter Legal Values Default Value Description
3-7
Error bits count
format
Full or split Full Specifies full or split count:
• With full count the decoder just counts
the number of received error bit
• With split count the decoder counts the
number of received error bits with
initial value "1" (then corrects to value
"0") and outputs num_error_bit1 . It
also counts the number of received
error bits with initial value "0" (then
corrects to the value "1") and outputs
num_error_bit0
Reed-Solomon II IP Core Interfaces and Signals
The RS II Avalon-ST interface supports backpressure, which is a flow control mechanism, where a sink
can indicate to a source to stop sending data.
The ready latency on the Avalon-ST input interface is 0; the number of symbols per beat is fixed to 1.
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 in DSP IP Cores
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. 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 synchro‐
nizes 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.
Related Information
• Avalon Interface Specifications
Reed-Solomon II IP Core Signals
Reed-Solomon II IP Core Functional Description
Send Feedback
Altera Corporation
3-8
Reed-Solomon II IP Core Signals
Table 3-3: Clock and Reset Signals
Name Avalon-ST Type Direction Description
clk_clk clk Input The main system clock. The whole IP core operates
on the rising edge of clk_clk .
UG-01090
2015.05.01
reset_
reset_n
reset_n Input An active low signal that resets the entire system
when asserted. You can assert this signal asynchro‐
nously. 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.
Table 3-4: Avalon-ST Input and Output Interface Signals
Name Avalon-ST Type Direction Description
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.
in_channel channel Input Specifies the channel number for data the IP core
in_startofpacket
in_
endofpacket
Altera Corporation
Valid only when you assert the in_valid signal. For
Qsys systems, the in_data bus is:
[numn,numcheck,data] If you have no variable check
it is: [numn,data]
For example, for a maximum codeword length of
255 corresponding to 8 bits:
• in_data[7:0] = data
• indata_[15:0] = numn
transfers on the current cycle. The in_channel
signal is available only when you configure the IP
core to support multiple channels.
sop Input Start of packet (codeword) signal.
eop Input End of packet (codeword) signal.
Reed-Solomon II IP Core Functional Description
Send Feedback
UG-01090
2015.05.01
Reed-Solomon II IP Core Signals
Name Avalon-ST Type Direction Description
in_error error Input Error signal. Specifies if the input data symbol is an
error and whether the decoder can consider it as an
erasure. Erasures-supporting decoders only.
3-9
out_
startofpacket
sop Output Start of packet (codeword) signal. This signal
indicates the codeword boundaries on the in_
data[] bus. When the IP core drives this signal
high, it indicates that the start of packet is present
on the in_data[] bus. The IP core asserts this
signal on the first transfer of every codeword.
out_
endofpacket
eop Output End of packet (codeword) signal. This signal
indicates the packet boundaries on the in_data[]
bus. When the IP core drives this signal high, it
indicates that the end of packet is present on the
in_data[] bus. The IP core asserts this signal on
the last transfer of every packet.
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_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 .
out_data data Output Contains decoded output when the IP core asserts
out_channel channel Output Specifies the channel whose result is presented at
out_error error Output Indicates non-correctable codeword (decoder only).
Table 3-5: Status Interface Signals
Name Avalon-ST Type Direction Description
status_error_value conduit Output Error correction value for every
Reed-Solomon II IP Core Functional Description
the out_valid signal. The corrected symbols are in
the same order that they are entered.
out_data . Available only when you configure the
IP core to support multiple channels.
Valid when the IP core asserts out_endofpacket .
valid data symbol.
Altera Corporation
Send Feedback
3-10
Reed-Solomon II IP Core Signals
Name Avalon-ST Type Direction Description
UG-01090
2015.05.01
status_num_error_
symbol
status_num_error_
bit
status_num_error_
bit0
status_num_error_
bit0
conduit Output Number of error symbols in a
codeword. This signal is valid
when the IP core asserts out_
endofpacket . Only available
when you turn on Error symbol
count .
conduit Output Number of error bits in a
codeword. This signal is valid
when the IP core asserts the out_
endofpacket . Only available
when you turn on Error bit count
and select Full for Error bits
count format .
conduit Output Number of bit errors for the
correction from bit 1 to bit 0. The
latest is the correct bit. This signal
is valid when the IP core asserts
the out_endofpacket . Only
available when you turn on Error
bit count and select Split for
Error bits count format .
conduit Output Number of bit errors for the
correction from bit 0 to bit 1. The
latest is the correct bit. This signal
is valid when the IP core asserts
the out_endofpacket . Only
available when you turn on Error
bit count and select Split for
Error bits count format .
Altera Corporation
Reed-Solomon II IP Core Functional Description
Send Feedback
2015.05.01
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Document Revision History
4
UG-01090
Subscribe
Send Feedback
Reed-Solomon II IP Core User Guide revision history.
Date Version Changes
2015.05.01 15.0
2014.12.15 14.1
August 2014 14.0 Arria 10 Edition
June 2014 14.0
• Added in_data information
• Added final support for
MAX10 and Arria 10 devices
• Removed Appendix A
• Added support for Arria 10
devices.
• Added Arria 10 generated
files description.
• Removed table with
generated file descriptions.
• Removed support for
Cyclone III and Stratix III
devices
• Added support for MAX 10
FPGAs
• Added instructions for using
IP Catalog
©
2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos are
trademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified as
trademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performance
of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any
products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information,
product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device
specifications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
4-2
Document Revision History
Date Version Changes
UG-01090
2015.05.01
November 2013 13.1
• Updated performance data
• Added erasures-supporting
decoder
• Added status signals to
parameters description
• Added in_error signal
description (for erasuressupporting decoder).
• Added new wizard
parameters:
• Number of bits per
symbol
• Field polynomial
• Type of generator
polynomial
• First root of the generator
polynomial
• Root spacing in the
generator polynomial
• Erasures-supporting
decoder
• Decoder status signals
•
•
• Removed support for the
following devices:
• Arria GX
• Cyclone II
• HardCopy II,
• HardCopy III
• HardCopy IV
• Stratix
• Stratix II
• Stratix GX
• Stratix II GX
• Added final support for the
following devices
• Arria V
• Stratix V
May 2013
13.0 Added support for Cyclone IV E
devices.
November 2012 12.1 Added support for Arria V GZ
devices.
Altera Corporation
Document Revision History
Send Feedback
UG-01090
2015.05.01
Document Revision History
Date Version Changes
4-3
May 2011 2.0
• Updated About This
MegaCore Function with new
device family support.
• Updated Functional Descrip‐
tion with new status ports
and timing diagrams.
December 2010 1.0 Initial release.
Document Revision History
Send Feedback
Altera Corporation
Loading...