Hi,
It's not easy to debug link training log without the decoder.
- Do you also have the link training passing log file to serve as reference ?
From your link training failure log file, it's hard to tell whether this is link training failure issue or link training stuck issue.
- Initially, I did see from the log file 0x202h (line 32, 33) that it already passed TPS1 clock recovery phase with 11h result indicating lane0_cr_done = 1, lane1_cr_done = 1
- After that, there is whole bunch of aux_defer command. Looks like sink is not ready to process source command request
- Finally, source started TPS1 clock recovery training again but this time it's failing.
It's tough to isolate whether the issue is with DP source chip, DP sink chip or the board connection design itself.
- May I know how many failure cases so far ?
- Does the link training failure is intermittent issue or permanent failure issue ?
Some debug proposal as below.
- For DP sink - Do you have a way to monitor the status of DP sink chip to maybe indicate link training failure is caused high bit rate error (BER) or receiver channel CDR loose lock ?
- For DP source - Quartus v15.1 is pretty old and very hard to find out whether there is any bug in the past or not. You can try upgrade to latest Quartus version like maybe v19.1 standard edition and retest the failure units again.
- Can you lower the video resolution to 1.62Gbps data rate to see whether it helps to improve the link training result or not ?
Thanks.
Regards,
dlim
New Contributor
