UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Participant nanjing2002
Participant
561 Views
Registered: ‎01-25-2014

RS-encoder : I dont understand why there are Variable_Number_Of_Check_Symbols and Variable_Block_Length?

https://www.xilinx.com/support/documentation/ip_documentation/ru/rs-encoder.html read as the following:

xc7k480t ffg901 -1 k7_1_custom Custom true true 285 1 0 255 239 Optimized_For_Area 1 aclk 260 738 491 0 0 1 PRODUCTION 1.12 2017-02-17

I dont understand why there are Variable_Number_Of_Check_Symbols and Variable_Block_Length?I think, RS(255,239) is fixed.How to understand it?

 

 

 

 

0 Kudos
2 Replies
Moderator
Moderator
399 Views
Registered: ‎08-01-2007

回复: RS-encoder : I dont understand why there are Variable_Number_Of_Check_Symbols and Variable_Block_Length?

RS(255,239) has a fixed number of block length and fixed number of check symbols, 255 is the block length while 239 is the number of check symbols, so both of them are fixed, however, some applications require variable number of check symbols or various number of block length, 

0 Kudos
368 Views
Registered: ‎11-26-2018

Re: RS-encoder : I dont understand why there are Variable_Number_Of_Check_Symbols and Variable_Block_Length?

Reed-Solomon codecs, particularly the one you specified allow variations in the number of payload symbols, and redundancy symbols. Changing these numbers affects the amount of payload versus checksum symbols, hence the overhead paid for an amount of error correction. Selecting these values often falls to practical considerations in implementation, however they are typically associated with various tenets and principles of communication theory. RS codecs are better suited to high-speed silicon because of practical implementation concerns. They achieve sufficient code gain to enhance data reliability by achieving lower BER. They are by no means a panacea or substitute for good design. They introduce added delay in the data path, something that isn't always desirable.

In the case of an RS(255,239), this usually involves 8-bit symbols, and defines the Galois field used to perform the arithmetic. The maximum length of the codeword (payload+checksum) of non-extended codewords is 255, it can also be shorter. Shortening the codeword increases the overhead and correspondingly the fraction of payload that can be corrected, within bounds. When you take the difference between 255 and 239, you get 255-239=16. The error-correcting capability of of this RS codec is therefore 16/2 = 8 symbols.

If you wish to increase the error-correcting capability, you could have (if that is an option in the IP) a RS(255,235): 255-235=20, 20/2=10 symbol correcting code. Notice that this increase in error correcting capability comes at the expense of payload. You can't go over 255, unless you move to 10-bit Galois field as is common for RS(544,514), or RS(528,514). These are (544-514)/2=15 and (528-514)/2=7 symbol-correcting codes, each symbol being 10-bits.

RS(2xx,2xx) are block codes and operate on 8-bit symbols, this is the nature of these type of codes. This means you can correct 8-bit symbols, whether there is a single bit-error or all 8 bits are in error. You can then only correct the number of symbols corresponding to "t", which is the common variable name associated with the (255-239)/2 = t. The correlation is that single-bit errors cost you precious error-correcting capability, whereas burst-errors make this type of block code more efficient. It is also key to understand the nature of the impairments as well as the error signatures typical in a communication channel.

Yes, RS(5xx,5xx) correct 10-bits at a time, and you have as many bullets as "t" dictates. Essentially, you have as many corrections as half the redundancy symbols, because the information they encode includes a location indicator and a signature (both as long as the characteristic length of the Galois field used).

The math is really interesting because if you were able to deduce the location of the errors with 100% certainty using some other means (such as convolutional code, or checksums), you could correct 2*t errors! However these techniques also cost you overhead.

Ultimately that is the game, all these strategies do actually enhance communication systems. However it always comes with added cost and complexity.

You can also add interleaving that can multiply the maximum tolerable error burst, however these do not increase the overall error-correcting capability of the FEC strategy. Interleavers also multiply delay of the RS codec, and when tightly coupled can complicate the implementation.

0 Kudos