02-20-2019 06:41 AM
Is there any indication from the GT(X) transceiver that the RX side is locked to data and clock (CDR?)?
I couldn't find any port that can be used for it.
I don't use the buffer in the GT core.
It looks like it doe not matter if the cable that is connected to the transceiver is connected or not, all port show the same output.
My logic most of the time works, but sometimes there are issues with the connection and I get errors on the data.
I noticed that by reserting the support logic, I can fix this issue, but I would like to know if there is any indication from the PHY itself that some thing is wrong or not with the incoming data and\or clock.
02-20-2019 07:59 AM
There is a port called RXCDRLOCK which has the obvious function (despite being "reserved" in the GTX user guide). Does this help?
02-20-2019 11:49 PM
RXCDRLOCK indicates CDR is stable. It could be locked to local frequency or remote partner.
you can also check RXDATA. If RXDATA is valid for a while, it indicates CDR is locked. This is handled by higher level user logic, not inside GT.
If 8b10b is used, you can use the decode error ports (RXNOTINTABLE, RXDISPERR) to validate the RX data.
Also the following answer record describes another way to indicate CDR status.
02-21-2019 05:36 AM
Thank you very much for the help but the "RXCDRLOCK" signal is constant high, despite this, I can see that the data might not be valid part of the time.
Is there away for example to know if CDR lock indicets locked to local frequency or to a remote partner?
02-21-2019 06:04 PM
GT doesn't have indicator to tell if CDR is locked to local or remote.
User logic needs to validate data for implying the CDR lock to remote.