Transmission errors seen at high line rate with the GT wizard example design using 8B/10B encoding

[wscisme]

Dear experts,

We are trying to practice using the GT wizard to do customized data loopback tests on a KCU105 test board when we found these puzzling transmission errors at high line rate, and am wondering if you could provide us some insight on the issue.

Quick summary of the problem:

Pretext:

- We are doing some practice study using the KCU105 testboard, with a Kintex Ultrascale FPGA (xcku040-ffva1156-2-e)

- The test has been performed between the 2 SFP connectors on board

  - The TX from one port is connected to the RX of another port

- We first test the optical transmissions with the IBERT IP core, and it has been working fine (with no errors) at least up to 12.5Gb/s

- The test also been performed with the FMC loopback card, so we believe the transmission errors are not due to the transceivers

- We trying to do a loopback test with the example design for the GT wizard

  - Screenshot of the GT wizard config please see [1]

- Our target is to achieve over 10 Gb/s data rate, and we start with 8B/10B encoding as it's the most simple option

  - Though we noticed that there're no preset with 8B/10B encoding for high line rate transmissions

Problem description:

- We found errors in the received bytes at high line rate (> 9 Gb/s), but not low line rate 

  - e.g. data (32bit) transmitted at 7e5c0bac is be received as 7e5e0bac (byte 5c -> 5e)

    - Screenshot of an example by the ILA probe please see [2]

    - To list a few others: 1c->5e, 2c->21, 34->30, 3c->3e, d4->d0, 4c->41, 54->50, fc->de, 6c->ee

    - Errors can also happen at the comma word (3c), when that happens, it is not recognized as a k-character by the RX

  - At 8.75 Gb/s, it starts appearing with rate 10^-12 packets

  - Error rate grows to 10^-8 at 10 Gb/s and much higher afterwards (lost count at 12.5 Gb/s)

  - To change the line rate we compile a different version of the firmware with change at the IP config

We would be very grateful for any idea that could guide us in the right direction!

[1] Screenshot for the GT wizard setup, there's no change from the default values for those not shown. Clock correction or channel bonding are not enabled.

[2] The RX userdata output from the gtwizard wrapper, since both TXs are sending the same userdata at the same time, 

the RX output of userdata can be compared to notice which byte went wrong.

[eschidl · Accepted solution]

Hi @wscisme,

your problem lies probably with the selected equalisation. You did put 20dB insertion loss with automatic equalization mode selection. This will lead to the selection of DFE. Have a look at UG576, page 207. You will see that the DFE can have problems with 8b10b encoded signals. And from your description this seems to happen for you.

You could select LPM mode manually in the wizard and try again. Also put a somehow correct value for the insertion loss in. Should you still have issues then you could try to hold the LPM adaptation. The channel to the SFP ports is short and you have active modules, so you might not need the adaptation.

Another point would be to switch the coding. It sounded that you were not that fixed on it. So maybe you can go to 64b66b coding and use more random data.

[wscisme]

Thank you very much for your advice, I can confirm that after setting it LPM mode manually (and change the insertion loss) fix the problem.

We did test with the 64b66b schemes and it had worked without a problem, but we also liked 8b10b as it may be faster in reaching the alignment.