From my customer:
We’re using your DP159 as a Displayport retimer (and tying into a Xilinx FPGA). We can’t seem to initialize a link with a Displayport source, we’re using your app note SLLA358 to try and bring it up but it’s not happening so far. Because we’re not VESA members, we’re unable to access the DP spec so it’s hard to debug when we don’t have visibility into what the link initialization process is supposed to be. Couple that with the fact that I have only lower-end o’scopes that can’t possibly look at the differential signaling rates that are passed between source and DP159.
Access to some kind of DP protocol analyzer is what we think we need right now, we’re looking at options. If you have any resources that would be of use to us we would certainly appreciate it.
Below is what Chris earlier outlined to me as our specific issue:
------------------------------------------------------------------------------------
Following the steps outlined in http://www.ti.com/lit/an/slla358/slla358.pdf, the DP159 does not report the PLL lock after reading address zero 512 times.
The steps (from a high level):
-
Bring the DP159 out of reset
-
Initialize the DP159 registers using the table in Section 4.1 – Initial Power-up Configuration
-
Program the Bandwidth (LBW_HBR2 – 5.40 Gbps) and Number of Lanes (4) based on the function BW_handler in Section 4.2
-
In Section 4.3.1, the software needs to wait for the register at address zero to report the PLL is locked, but I’m not seeing it lock.
What I need to know is how to determine that the ‘DisplayPort source’ is actually sending the TPS1 pattern mentioned in the first paragraph of Section 4.3. My assumption is that may not be happening, or the PLL would lock.
Can we provide any guidance on this?
