03-26-2019 02:15 AM
I implemented a design on a US+ using GTHs and 8b10b encoding. The data transmitted are generated with the IP “Xilinx PRBS Generator (PRBS 31)”, send trough the GTH ports, and looped back to the US+ (thanks to a custom board) to be checked with an IP “Xilinx PRBS checker”. The GTH line rate is fixed to 2.5Gbps.
The issue is that the amount of useful data (from the PRBS Generator) transmitted represents only 10% of the total amount of data transmitted. I know that using 8b10b encoding reduce bandwidth by 25% but here I noted a loss of bandwidth of 90%.
Moreover, I monitored signals provided by the 8b10b decoder (RXCTRL0, RXCTRL1, RXCTRL2, and RXCTRL3) and the signal RXCTRL0 (K character detected) is most of the time set to 1.
My questions are:
Is there a way to reduce this gap between the total amount of data transmitted and the amount of useful data transmitted?
Is it usual that as much of K characters are transmitted among the useful data?
03-26-2019 07:58 AM
With an 8B10B encoder and no comma characters in your bitstream (and in this case it doesn't need them) there is no way to increase the useful payload which is 75%. There is also no way to decrease it. Something is wrong with your calculation or your set up. Make sure the data width the RXDATA port is set up for matches your PRBS-31 generators data width.
03-26-2019 08:35 AM
I know that my useful playload should be 75%. But K-charachters seems to be inserted (signaled by RXCTRL0) by the 8b10b encoder. Is there a way to decrease the amout of K-charachters or commas characters inserted ?
Concerning my setup :
- User data width is set to 32 bits
- Internal data width is set to 40 bits
- Comma alignement is set to "Any byte boundary"
03-26-2019 08:43 AM
The problem is that you have no comma characters in the data so the incoming data is not aligned. The misaligned data is then randomly seen as K characters. I would suggest not using 8B10B in this case and just transmitting raw data. PRBS data does not need to be aligned. If you want to send it the way you are then I would suggest using the bitslip operation until the not in table and disparity errors go away.