Occasional Contributor
Regular ContributorHi,
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
Occasional ContributorThanks 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
