12-13-2019 03:49 PM
I would like to implement the interlaken retransmission feature because I am getting CRC errors and dropped packets with optical cables at 50 Gbps.
I checked in the example design and there are no retransmission features implemented in the example design. Is there an example design with the retransmission feature included?
01-03-2020 04:50 PM
No there is none, and the user guide describing its usage is quite difficult to understand the first time around, so I'll try to give you some pointers. From your other post, it seems you will connect two VCU118 together and this will ease greatly your implementation. OOBFC stands for Out-of-Band flow control which is defined in section 188.8.131.52 of Interlaken specification which can be used in to transmit data to the other chip. It is the recommended and somewhat standard way of transmiting a retransmission request, but it is not mandatory.
First step is to pick a way to transmit your retransmission request. Next, you'll have to calibrate your retransmission buffer so that it's large enough to account for the delays between the transmission of the retransmission request from the one chip and its reception by the other chip. The user guide has information about this.
01-10-2020 02:37 PM - edited 01-10-2020 02:39 PM
The reason for doing the retransmission is due to the poor integrity of the interlaken data transfer with optical cables.
At the lowest data rate, 12.5Gbps, I am getting 0.5% of the packets dropped and out of the packets received, 0.02% of the packets have a CRC error in them.
At 50 Gbps, I am getting 1.3% of the packets dropped and out of the packets received, 0.07% of the packets have CRC errors in them.
I have done this exact same test using the loopback adapter on one board, and I get no dropped packets and no CRC errored packets.
When replacing the loopback adapter with an optical cable between two boards, I get data integrity problems.
Any idea as to why there is such low integrity (aside from the fact that it is a very high speed data transfer protocol)? The CRC errored packets, we can live with, but the high dropped packet rate is too much.
01-10-2020 03:51 PM
I'm no signal integrity expert nor a guru of the Interlaken spec, but my very naive answer would be: it's not designed to do that.
Interlaken is, to my knowledge, used for High speed chip to chip communication for chips on the same board close to each other. CRC would be there to assure the integrity of the packet, but from memory, there's nothing protecting the data itself unlike with Ethernet.
With Ethernet, depending on the transport mode, you get different encodings, electrical interfaces, etc. Ethernet is designed for this kind of scenario where your data goes through a cable for some unknown distance so it is designed to be more resilient.