High Speed Rees Solomon

[OLevy1]

hi,

i am looking for a solution supporting RS(255,223).

the data bus i am using is 256b (32B) and no matter which 'Parallelism' value i choose, the 'in_symbols_in' bus is always a multiple of 8b (16b, 24b, 32b.....) so in order to use the core i need some kind of byte_enable signal.

The data stream is continuous and i am working with 256b bus. since each FEC Codeword is 255B, there should be 8 writings but the in the lase writing the Decoder should consider only 31bytes and not 32bytes (7x256b + 248b).

according to what i have found the High Speed Reed Solomon IP does not have 'Byte_en' input option in 'Custom' mode.

checking the 'Fracturable 100G Ethernet' mode i have noticed there are other inputs that are not explained in the UserGuide. 

i saw that 'Reed Solomon 2' core supports 8b as an input so it is what i will probably use, but it requires much higher clock.

please let me know if i missed something regarding the High Speed RS.

Oren

[CheePin_C_Intel]

Hi,

Sorry for the delay. Since there seems to be no specific info on this in the documentation, I have been running several test cases (Encoder and Decoder) on my side to understand further on how to handle the additional byte after the 255th symbol. 

Based on my analysis on the IP generated simulation example for Encoder, I noticed that the test bench will pad a value of '0' to the last byte. For example, with 8 bits per symbol and parallelism = 2, from the simulation, I observed that last input[15:8] of a codeword will = 0. At the output of the encoder, it will discard the padded '0' and encode the codeword correctly. Note that at the encoded output, the last byte will be padded with '0' as well to fill up the 16 bits output bus.

Based on the understanding from the encoder, similar should apply to decoder as well. In your case, you can fill the last redundant 8 bits symbol with 0. 

Please let me know if there is any concern. Thank you. 

Best regards,

Chee Pin

[OLevy1]

Thanks Chee,

are you sure the decoder will not consider the last byte as the first byte of the next codeword???

as far as i know, if a decoder is configured to handle 255Bytes codewords, in case there are 256 valid Bytes the decoder will consider the last byte as the first byte of the next codeword.

Oren

[CheePin_C_Intel]

Hi Oren,

Thanks for your update. For your information, that is my observation from the simulation since there is no information available on this in the documentation. It would be great if you could try out using simulation with your expectation input and output data to further verify on this. If not, then you might need to use the other RS II IP which support 8b interface.

Please let let me know if there is any concern. Thank you.

[CheePin_C_Intel]

Hi,

Just to follow up with you on this. Thank you.

[OLevy1]

thanks.

[CheePin_C_Intel]

Thanks for your update. I believe the initial inquiry has been addressed. This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

[OLevy1]

thanks.