Application Acceleration With FPGAs
Programmable Acceleration Cards (PACs), DCP, DLA, Software Stack, and Reference Designs
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.

High Speed Rees Solomon

OLevy1
Beginner
486 Views

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

0 Kudos
7 Replies
CheePin_C_Intel
Employee
461 Views

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
Beginner
459 Views

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
Employee
426 Views

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
Employee
415 Views

Hi,


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


OLevy1
Beginner
411 Views
CheePin_C_Intel
Employee
403 Views

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
Beginner
209 Views
Reply