Xilinx FPGA GTX: The exact meaning of TXCHARDISPVAL

Displayport’s standard requires that the TPS2 and TPS3 training sequences have a known running disparity on the transmitted characters. It uses a plus-minus notation (e.g. K28.5-) to indicate the disparity, and also clarifies the meaning of this notation by writing out the bit sequences of K28.5- and K28.5+.

Xilinx, on the other hand, is slightly less definitive: Working with Virtex-7′s GTH, Table 3-6 in UG476 outlines how to set TXCHARDISPVAL to obtain a known disparity, given that TXCHARDISPMODE is ’1′. Unfortunately, the description for TXCHARDISPVAL=0 is “Forces running disparity negative when encoding TXDATA” which is slightly ambiguous. One would expect it to mean that e.g. a K28.5- character would be sent and not a K28.5+, but it could also mean the opposite. Does “forcing running disparity” relate to the history of RD, meaning it would transmit a K28.5+ to make up for the existing cumulative negative running disparity, or does it force the current symbol negative?

I hoped that my Displayport monitor would resolve this by rejecting a training sequence with the disparities flipped, but trying it both ways, it turned out it happily accepted it either way.

So I set up a GTX channel between two FPGAs, one transmitting 8b/10b encoded data, and the second receiving data without 8b/10b decoding. This way I got the actual bits on the wire. I tried loopback first by the way, but it didn’t work out to enable encoding on one direction, and disabling it on the other. Not even by manipulating the Verilog sources that Vivado generated.

Test results

The results of this experiment was as follows:

• With TXCHARDISPVAL = 0, K28.5 is transmitted as 0011111010 on wire.
• With TXCHARDISPVAL = 1, K28.5 is transmitted as 1100000101 on wire.
• And to be sure that the bit polarity isn’t reversed, I verified that D17.1 indeed appears as 1000111001 (it’s indifferent to disparity)

All this relates to TXCHARDISPMODE  = 1, of course.

The bit notation here is the bit transmitted first to the left (even though it appears as LSB on the parallel data signals)

Conclusion

TXCHARDISPVAL = 0 = “running disparity negative” = “Current RD -”  in Appendix C of UG476. This is also what is referred to as e.g. K28.5- in the Displayport standard.

This is what I expected, as a matter of fact. But I wanted to be sure.