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_size/8).
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 for payloads are encoded with Hamming (for each 8 bytes, 1
parity byte is added): ham-ed_payloads_size = div_payload_size +
(div_payload_size/8).
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
- ? [bytes].
6. Each payload is prefixed with a standard Ethernet Header.
WR FEC core consists of two separate modules:
1. FEC encoder:
- It expects to receive Ethernet Frame (whose size could be greater then standard). The max size of the input payload is to-be-decided, for the time being we assume max of 1500 bytes, but according to the "WR and robustenss" doc (www.ohwr.org/project/white-rabbit/wikis/Documents/White-Rabbit-and-Robustness:-Draft-for-Comments), it could be 5000 bytes
- 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
FECencoder.jpg!
2. FEC decoder
- It is not there yet and it is to be implemented (hopefully) in the embedded CPU.
- 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
way:
- 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)