WR Forward Error Correction (FEC) core is responsible for reliable data
delivery by introducing redundancy into the data. We use concatenated
Reed-Solomon and Hamming codes.
FEC core is transparent to the other modules (between which it sits,
i.e. WRCore and EtherBone). It communicates with outside world with
pipelined Wishbone (WB) interface.
In the below estimations of RAM usage (figures) the following encoding
process is assumed
1. Input payload size: input_payload_size [bytes]
2. The input payload is divided into two and padded so that we have two
payloads of the size being multiple of 8 bytes: div_payload_size =
8*CEIL (input_payload_size/8) [bytes].
3. The two payloads are used to produce two more payloads of the same
size, these two additional payloads contain Reed-Solomon parity bytes.
4. All the payloads are encoded with Hamming (for each 8 bytes, 1
parity byte is added): ham-ed_payloads_size = div_payload_size +
5. Each payload is prefixed with FEC header of 9 bytes (I will probably
add CRC of few bytes) output_payload_size = ham-ed_payloads_size + 9
6. Each payload is prefixed with a standard Ethernet Header.
WR FEC core consists of two separate modules:
1. FEC encoder:
It is activated by writing the size of the payload-to-be-encoded to
the appropriate WB address (parameter/to-be-decided) at the
beginning of the data transfer.
If not activated, input data is passed directly to the output.
The architecture of the current implementation is depicted in the
figure - this is optimized for speed not resources, i.e. the usage
of RAM is definitely not optimal
2. FEC decoder
It is not there yet and it is to be implemented (hopefully) in the
The figure of the FEC decoder (below) was prepared by the analogy to
the encoder (whether it's implemented in VHDL or embedded CPU, the
functionality and needed memory resources are the same)
The "Received Frame" RAM size needed was estimated in the following
Assuming max size of the payload inputed to the FEC encoder to
be 1500 bytes
Payload of 1500 bytes is encoded into 4 fragments of 855 bytes
We need to receive only two valid fragments to encode the
original payload, we store the fragments without FEC header (and
CRC) and after de-Hamming, so a fragment is 752 bytes (if we are
not able to perform de-Hamming or CRC is wrong after de-Hamming,
we drop the fragment and re-use the RAM space).
We can receive fragments in wrong order and from different
original payloads, let's say we want to store 5 fragments (so
2.5 of original message),
Put it all together: 5x752 bytes = 470 words of 64 bits
The "Decoded Part" RAM:
We can start sending out the decoded Ethernet Frame as soon as
we know we have two valid fragments.
If we need to decode R-S fragment, we need to store the decoded
result before it's send (this will be max div_payload_size, so
752 bytes). We could use the
"Received Frame" RAM can be used for this purpose, but it makes
the design more complex (i.e.: single RAM needs to be accessed
by many concurrent