Xilinx Reed-Solomon

Xilinx Reed-Solomon LogiCORE

Frequently Asked Questions:

What is Reed-Solomon?

Reed-Solomon codecs (coder/decoders) are all about error correction. The maths behind RS codes was developed by Irving Reed and Gus Solomon back in 1959, hence the name. In recent years this type of coding has been used in many applications where data is transmitted and received. Examples include cellphones, digital TV broadcast, space communications and CD players. In fact any application where data is likely to be corrupted by noise or other error sources. Users are likely to be any company involved in wireless communications, communications or data transmission. RS codes are specified in many data transmission standards, e.g. the ATSC digital TV standard.

RS codes provide extremely good error correction. It is one of the most effective forms of coding for errors that occur in a burst. For this reason they are often coupled with Viterbi codecs in a system. Viterbi (or convolution) coding is another type of error correction that is very good at random errors.

RS is a block-code, i.e. data is processed a block at a time. Each block contains n words (or symbols). Of the n symbols, k are the original information symbols to be transmitted and (n-k) are extra check symbols added by the RS Encoder. The RS Decoder is able to correct (n-k)/2 wrong symbols, no matter where they are in the block.

The core can report how many errors were found and also attempts to determine if it failed to correct the block, due to too many errors.

Erasures are an optional extra that double the number of errors that can be corrected at the expense of a much bigger circuit. An erased symbol is one that is coming in and the system already knows it has an error. An extra input to the Decoder tells it the symbol is erased. This sort of information can come from a threshold detector in a demodulator for example. Therefore the system designer has to add extra hardware to his board. For this reason erasure decoding isn't that common.

The coding is based on Galois Field arithmetic and this is where terms like "primitive polynomial" come from. The user doesn't actually need to know anything about this.

What size is the core?

The area of the core increases with the parameters n, n-k and the symbol width. Some example configurations are shown in the data sheets. These can be used to give a ballpark figure for your particular set of parameters. To obtain a precise figure, the core must be generated and passed through the Xilinx place and route tools.
The CLB counts can be reduced slightly by selecting the option to map primary I/O registers into IOBs during placement. This option should certainly be selected if the core I/Os are to be connected directly onto a PCB via the FPGA package pins. This will give lower output clock-to-out times and predictable set up and hold times.
The results in the data sheet were obtained with the "-c 1" packfactor option applied during mapping. This causes the Xilinx mapper to pack as much logic as possible into each CLB.

What is the maximum clock frequency?

Performance increases as n, n-k and the symbol width decrease. The examples in the data sheet can be used to give ballpark figures for your particular set of parameters.
It is important that the core's clock input, "clk", is driven by a global buffer ("bufg") component. This guarantees low clock skew and minimizes routing delays on the clock net. It is also important to set a maximum period constraint on the core clock input.
The core asynchronous reset input, "reset", should be driven by the global set/reset driver using the appropriate "startup" component. Information on driving GSR and "startup" components is available in the Xilinx on-line documentation.
It may be possible to improve slightly on the values in the data sheet by trying different seed values for the place and route software. A seed value of 1 was used in the data sheet examples. The place effort level was also set to the maximum possible value.
If necessary, performance can easily be increased by selecting a part with a faster speed grade.

How do I instantiate the supplied EDIF netlist into my design?

Files are supplied with the core, illustrating how to instance the cores in a higher level VHDL or Verilog design. You may give the core entity any name you like, but you must ensure the netlist for the core has the same name. It is assumed that a synthesis tool will take care of adding ipads and ibufs to the primary inputs and obufs and opads to the primary outputs. The "reset" signal should be driven onto the GSR (Global Set Reset) net and the "clk" signal onto a global clock net. Most synthesis tools have a command to allow this to be specified. If not, it can be done explicitly by instancing a "startup" and a "bufg" component. This is explained in the Xilinx on-line documentation.
Synthesis tools should treat the core as a black box. You may need to set some option, such as "don't touch", depending on your synthesis tool.
If you use a schematic editor then you must create a symbol either manually or automatically, if your design entry system has an HDL component to symbol conversion tool.
The comments within the example files explain how to instantiate a behavioral model for simulation, instead of a black box component for synthesis. Another option is to instantiate a netlist, back-annotated from the Xilinx tools. The necessary modifications are also explained in the comments within the file.

Do I need to use any special options when running the Xilinx mapping and place and route tools?

The results in the data sheet were obtained with the "-c 1" packfactor option applied during mapping. This causes the Xilinx mapper to pack as much logic as possible into each CLB but usually results in a slightly slower implementation. In most cases the packfactor can be left at the default value.
The "-pr b" option can also be used to force the primary I/O registers to be mapped into IOBs if required.
During place and route (par) the seed was set to 1 and the effort level set to maximum. The number of delay-based clean up passes was set to 1.

How many different parameter combinations am I entitled to ask for?

Once the core has been purchased you may generate as many different parameter combinations as required.

Should I select "create RPM"?

This option is available for the Encoder core. When selected, the core generator adds placement information to the core to create a relationally placed macro (RPM). RPMs can result in more predictable performance when used with other cores and user-defined logic, and usually require less time to place and route.
If a very small target device is used, the Encoder core shape may not fit within the rectangular CLB matrix of the FPGA, even though the FPGA appears to have sufficient CLBs. In this case the "create RPM" option should be de-selected.
The Decoder is composed of many smaller RPMs. It is always left to the placer to automatically place the smaller RPMs relative to each other.

Does the Decoder handle continuous input data (no gaps between blocks)?

Continuous code blocks can always be handled, but this may require more than one clock period per symbol for some parameter selections. For the Decoder to be able to decode continuous code blocks, the Processing Delay must not be greater than the number of symbols in a block (n). The Processing Delay may be calculated using the equation given in the data sheet, or using the GUI on the core web page. The processing delay can always be reduced as much as required by increasing the number of clock periods per symbol.
Note that the Processing Delay should not be confused with the Latency, which is also described in the core data sheet.

Can some input symbols be ignored?

Yes, on the Decoder the optional clock enable ("ce") input can be used to freeze the core for one or more clock cycles. Any changes on the other synchronous inputs will be ignored while "ce" is low. The Encoder has an "enable" input that has a similar purpose.

Does the Decoder support erasures?

Yes, although erasure decoding increases the size of the core considerably. It is therefore only recommended for codes where n-k is less than eight. The core does support erasures for larger values of n-k but there will be a large area overhead compared to the same core without erasure support. Some figures for example implementations are given in the data sheet.

Can I use one core for several different code specifications?

For example, say you need to switch between a (n=255, k=239) code and a (n=204, k=188) code. For the Decoder, the only way to do this is to generate two decoders and multiplex between them. This technique could also be used for the Encoder. If (n-k) and the generator polynomial are the same for the different code specifications then another solution is to pad the smaller code blocks with zeroes.
For example, in the above case, a single (255,239) Encoder would be generated. When it was required to switch to a (204,188) code, the first (255-204=51) information symbols shifted into the Encoder should be zero. The first 51 bytes coming out on "data_out" should be ignored. They will all be zero. The next 204 symbols will be the correct symbols for a (204,188) code.
This solution means that a code block always takes n1 symbol periods, where n1 is the number of symbols in the largest code block.

What can I do if the core is too slow for my clock but fast enough for my symbol rate?

For example, if the master clock frequency is 100MHz but the timing analyzer reports that the core will only operate at 60MHz and below. If the symbol rate is 50MSymbols/s then a Virtex DLL can be used to generate a 50MHz clock internal to the FPGA. This can be perfectly synchronized to the 100MHz clock, i.e. there will be zero skew between the 50MHz clock edges and the 100MHz clock edges. The 50MHz clock can then be used as the core's clock input.
Another way of tackling this problem is to clock the core at 100MHz but only enable it every second clock cycle, with the clock enable input. The problem with this approach is that the Xilinx static timing analyzer used in timing driven routing will still assume all signals are changing at 100MHz and will fail.