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 code 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 calculations the following encoding process is assumed
1. Input payload size: input_payload_size [bytes]
2. The payload is divided into two and padded to 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 using Reed-Solomon
4. All the for payloads are encoded with Hamming (for each 8 bytes, 1
parity byte is added): ham_payloads_size = div_payload_size +
(div_payload_size/8)
5. Each payload is prefixed with FEC header of 9 bytes
output_payload_size = ham_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 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.
- The figure of the FEC decoder (below) was prepared by analogy of the encoder.
- The 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 fragments, we store the fragments without FEC header and after de-Hamming, so a fragment is 752 byts
- We can receive fragments in different 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