02-26-2021 02:00 AM
To spare you the details I will skip right to the point.
I have an 8-bit-wide data stream.
Bits (7, 6) need to be encoded with a Reed Solomon encoder.
Bits (5, 4) need to be encoded too but not in the same packet.
Bits (3, 2) need to be encoded too but in yet an other packet.
Bits (1, 0) same as above.
Thankfully, the Xilinx ® LogiCore™ IP Reed-Solomon Encoder (https://www.xilinx.com/support/documentation/ip_documentation/rs_encoder/v9_0/pg025_rs_encoder.pdf) gives the ideal option of multiple channels.
The problem is that if multiple channels are used, then the codes' message size can not be configurable.
That is, I can not switch from, say, [255, 251] to [255, 239] on the fly.
Is there a way to get around this problem?
Is there perhaps an other IP that give this sort of flexibility?
03-01-2021 11:50 PM
Reed-Solomon codes are usually referred to as (n,k) codes, where n is the total number of symbols in a code block and k is the number of information or data symbols. The symbol width can be set from 3 bits to 12 bits. The core generates systematic code blocks where the complete code block is formed from the k information symbols, followed by the (n-k) check symbols.
For the multi-channel, the code settings n_block, k_block and r_block are the same for all channels. The multichannel configuration is not available when a variable number of check symbols is required. That said, the only one RS encoder does not provide a way to change N or K on the fly.
As each code block is independent, so multiple encoders and encoders can be used to process blocks in parallel, which may be one way to get around your problem.
03-11-2021 05:24 AM
Do you have a feel for the impact on the size of the design, by doing this? In our design we today have 4 RS with 4 channels each. Would then require 16 IP's (16 encoders, 16 decoders, which would have >4x the throughput we need). I don't see a way to use the RS IP's in an efficient way without buffering, which would hit on latency, which is not acceptable.
We would like to be able to support at least (255,239), (255,247), (255,251),(255,253) and we would switch settings on the 4 channels simultaniously.
03-11-2021 05:34 AM - edited 03-11-2021 05:55 AM
A golden rule for FPGA is that you have to choose between speed or area, you can't have both.
So, if area is a problem here, my suggestion is that you buffer data and process each bit slice in rounds (at 4x speed if that is possible)
Actually, because your data rate for each slice is already divided by 4, there shouldn't be much penalty on speed.
The fact of being different size for each channel makes it a bit ugly but it looks doable for me.
03-11-2021 06:05 AM
The problem with your solution is that I now need to buffer the whole RS frame before encoding, today I have almost zero latency as I use the parallell encoders for interleaving.
In the decoder I end up with the same.
Alternativly I can give up some error correcting capability in the system, by not do interleaving.
But in the end I think the golden rule is that an IP never does what you want it to do, and you should plan for implementing them your self.
03-11-2021 06:24 AM
IPs I suppose are made for the most general case, some times for the case of a partner that pays half of it and allows it to be sold on another channel.
In that case it looks like you will need four of them or else make yours from scratch.
If encoding is different for each channel, I would expect such a core to be about 4 times the size, for the multichannel option with single encoding I suppose only data is quadruplicated, not FSMs etc. That could be another reason to not to offer that feature "they can just drop as many as they need" someone may have said.