This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SN65DP159: Cannot consistently acquire correct link training for 2160p60 (4K2K@60Hz)

Part Number: SN65DP159
Other Parts Discussed in Thread: LMH1218, TPS74201, TPS74,
We are in development of a DisplayPort 1.2 switcher with two inputs, each using the SN65DP159RGZ (in X-mode), one DisplayPort output, using the SN75DP130SSRGZ, and various SDI outputs, with a Xilinx Kintex UltraScale FPGA at the heart of the system.  On the DisplayPort input and output interfaces, we only support 4K2K@60Hz, reduced blanking.
We are in the second of three phases of our design, with each phase adding functionality to the overall product.  We successfully completed Phase 1 of the design, which only contained the DisplayPort devices.  Phase 2 is a new PCB, with the addition of SDI devices (LMH1218's) and DDR4 RAM (needed as a framebuffer for framerate and resolution conversions for the SDI outputs).  The DisplayPort portion of the Phase 2 design is identical to our Phase 1 design, with the exception that the Phase 2 PCB is 16 layers whereas Phase 1 was 6, and we replaced a single home-brew 1.1V power supply for both DP159's with a TPS74201 LDO for each DP159.  We have had numerous issues which seem to stem from the DP159's and the TPS74201's.  We feel we have resolved the TPS74201 issues (which were initially caused by our assembler installing them backwards), and after many rounds of rework, we are now getting stable, consistent voltages from them.  We had a total of two Phase 2 board assemblies made.  On one, the first input works and the second does not, and on the other board, the second input works and the first does not.  On the working inputs, we get the proper 5.4Gbps x 4-lane configuration.  However, the non-working input on one board trains at 2.7Gbps x 1 lane, and the other at 1.62Gbps x 1 lane.  Needless to say, we get no video on the output in those scenarios as the input is not correctly configured.  Any time I think I find a pattern and/or root cause, another event occurs to disprove the theory.  On one of the boards, reflowing the solder on the non-working DP159 allows that input to work for a short time, then goes out, never to be functional again until another attempt at reflow.  On the other board, repeated attempts to replace and/or reflow the DP159 has resulted in no change.
In order to attempt to get more clues, I have downloaded the DP159 EyeScan Tool, but due to a bug in the silicon, mentioned in https://e2e.ti.com/support/interface/f/138/t/511893?DP159-Eye-Scan-Tool, I cannot see a valid eye because we are running at 5.4Gbps.
Since this is long past becoming an exercise in severe frustration, I would like a design review from TI of the DP receiver portion of the circuit, as well as any other ideas for debugging the issue.
  • Hi

    Would you please send me the schematic and layout for review?

    Do you have any DP link training log file you can also share?

    From your thread, it looks like there may be a solder joint issue. Does the board shop have a x-ray machine to check for the solder joint? Please refer to this app note for the recommended thermal package assembly. 

    In the app note, it recommends "Based on experimental and modeling data (Figure 12 and Figure 13), Texas Instruments recommends a minimum solder joint area of 50% of the package thermal pad area when the part is assembled on a PCB. The results of the PCB assembly study conducted with Solectron-Texas indicate that standard board assembly processes and materials normally achieves greater than 80% solder joint area without any attempt to optimize the process for thermally enhanced packages". I would recommend having 70% coverage to additional marginality.

    Thanks

    David

  • I can send the PDF of the schematic.  I would prefer a non-public way to get it to you so as not to expose our company's proprietary information.  The same is true for the PCB layout, which is in Altium Designer.

    What kind of link training log would you be after?  I can check with our software engineer to see if we can capture any console debug output of Xilinx's DisplayPort RX Subsystem IP.

    We were told by our assembly house that an x-ray of a QFN package would be inconclusive as it would only show a large dark mass.

    I would also like to know if there are specific things I can do using the EyeScan tool (such as manipulating registers) to help gather more data.  Unfortunately, the PC will not send any signal over the link when training fails.  Our custom EDID is instructing the PC that the only valid mode is VESA 4K@60Hz, reduced blanking, so when it is unable to negotiate that, it just gives up.

    Thanks,

    Greg

  • Greg

    Would you please accept my friendship request and then you can use the private message to send me the schematic/layout? I use Allegro for my layout, so you will have to convert from Altium to PADS for me to review the layout. 

    For X-ray, base on the dark/grey difference, they should able to tell the solder coverage. If you are seeing a difference from board to board, and able to get one board to work for awhile after reflow, this to me like a possible manufacturing issue and we need to resolve this issue first so we can get a consistent, even if not passing, result across the boards.

    DP link training consists a clock recovery training phase and equalization training phase. Both phases have to pass in order for the DP to work. If the FPGA can capture and dump out the entire sequence, we can see if there is a signal integrity issue associated with the system design. One thing you could try is to change the custom EDID so you are running 1.62G across 1 lane first, and then builds up the data rate and lane count when 1.62G 1 lane is working correctly.

    Have you also verified that the DP159 and DP130 follow the power sequence as outlined in the datasheet?

    Thanks

    David 

  • David,

    I have sent the schematic.  I will need some time to convert the PCB layout.

    You mentioned a manufacturing issue to cause a part to work for a while after reflow.  In this case, when the part stops working, the part itself has not failed because after further reworking further we are sometimes able to get it functional again, but the longest it has ever run is 46 minutes.  What could cause it to quit after a time period?  We have verified that the part is not overheating due to poor thermal pad connection.  (This was one theory I had until it was debunked with good operating temperature.)

    Regarding the power sequencing, the DP130 on the output port has never been a problem, plus we are using the "SS" version of it which only has a 3.3V supply.  Officially, we are violating timing between VCC and VDD, but once the FPGA starts running, it pulls OE low for a time, releases it, and then configures the DP159 via I2C.  Our Phase 1 had the same violation, but it always worked.  We have not had problems until the Phase 2 build.  Thinking that this could have been a factor, I made a modification to the one board that had a working Input #1 and non-working Input #2, and applied the modification only to the non-working input.  The mod involves supplying neither VCC nor VDD to the DP159 until the CFG_DONE signal of the FPGA goes high.  That way, OE is already low when VCC and VDD are supplied.  I verified the timing on a scope, but that DP input still does not work.

  • Greg

    Would you please clarify on this statement, "In this case, when the part stops working, the part itself has not failed because after further reworking further we are sometimes able to get it functional again, but the longest it has ever run is 46 minutes"? Does the DP159 completely not functional after 46min or DP159 is still functional but no video input?

    For the non-working condition, can you put scope probe on the AC coupling cap closer to the FPGA input and see how the signal looks?

    Thanks

    David

  • David,

    After the 46 minutes (and usually shorter than that), the video drops out and the link cannot be successfully retrained, even across power-cycling the system.  I say the part has not failed in the sense that it is not permanently damaged.  Reworking it, sometimes several times, can get it working again (where it trains at 5.4Gbps x 4 lanes), but the working condition is never "permanent".  In all cases, the I2C configuration interface with the FPGA is always functional.

    Probing the non-working situation may be of little use because the PC will not send signal over the lanes when the link cannot be successfully brought up.

    As an aside, I have attempted to probe the high speed lanes on the input side of the DP159 on the working channel so I can see what the working channel looks like, but the signal drops out whenever I put the probe on it.  It is an 8GHz active differential probe.  I would have thought it would work.

  • David,

    I have made another observation regarding odd behavior of the TPS74201's on our board.  If there is any stray conductive path from the soft-start pin to ground, the regulator will not operate correctly.  It will output something like 0.2V.  Repeated cleaning with isopropyl alcohol and compressed air to remove all flux residue will make it operate correctly again and output the desired 1.1V.

    Is this something anyone has seen before?  Is there a way to make this thing not be so sensitive?

    Thanks,

    Greg

  • Greg

    I am not familiar with the TPS74201, so I moved this post to our power group for support on the TPS74201. 

    But from the layout, I do not see a signal integrity issue with the DP159.

    Thanks

    David

  • Hi Greg,

    While the soft-start pin provides many benfits such as reducing the startup ramp rate and reducing the output noise of the LDO, to create that RC filter/time delay requires this node to be high impedance meaning this pin is more sensitive to leakage currents. Most customers do not have an issue in their applications, however this is a failure mode which we see from time to time on LDOs with soft start or noise reduction pins. 

    As for ways to make it less sensitive, as you've noted making sure the boards are thoroughly cleaned after any soldering and rework (particularly when working on the LDO itself or the capacitor connected to these types of pins) is usually enough to resolve this problem. Other options would include adding extra spacing around this pin and the cap to reduce the likelihood of a leakage path from ever developing or in systems where the leakage path may build up over time due to long term board use in tough environments then the use of a conformal coating can also help eliminate the problem in those types of applications. 

  • Hi Kyle,

    Are there any other LDO's that are pin-compatible with the TPS74201RGW that don't have the soft-start feature?

  • Hi Greg,

    Unfortunately these high PSRR, low noise devices all have NR and/or SS pins in order to help improve performance in noise sensitive applications so we do not have a pin to pin compatible part without soft start. 

  • Hi Kyle,

    I had done some digging of my own, and found the TPS74301RGW, which is almost pin compatible except that it has a TRACK pin in place of the SS pin.  It appears that I could potentially use it if I depopulate the soft-start capacitor from the board and instead run a pull-up resistor to a nearby 3.3V source (which is the Vin supply).  Does this seem like some something that could be feasible, or could there be other pitfalls in exchange?

  • Hi Greg,

    The concept behind your idea is a good one, however it's important to note that the TRACK pin is only used for startup tracking anc once Vtrack>=0.8V the LDO will switch over to the internal reference voltage. So you'll still need to set an external resistor divider on Vout to set the gain for Vout=3.3V with the internal Vref=0.8V but by shorting Vin to TRACK the potential issue of PCB leakage current is mitigated. 

    Page 14 of the datasheet addresses this in case you want to review it further. 

  • We are in the process of having two more boards assembled.  They are supposed to be done on Thursday, 3/19.  I am hoping those work without issue, or if they don't, that they can supply us with more data points.

  • I am happy to report that the two new boards we had built are both working perfectly! 

    We still have no real explanation as to the behavior of the first two, other than originally the TPS74201's for Input #1 were installed in the wrong orientation, causing overvoltage (2.5V) on what should have been a 1.1V rail.  Assuming that the SN65DP159's for that input were damaged, we did have those replaced along with the TPS74201's, though that only fixed the issue for Input #1 on one of the two original boards.  None of that explains the non-working behavior of Input #2, other than the effect of having residue on the board possibly causing unknown damage to the 2nd SN65DP159 because its TPS74201 supply was also outputting the wrong voltage (which was anywhere from 0.2V to 0.6V before the residue was 100% removed).  Could having incoming signals on the high-speed lanes damaged the SN65DP159 if the 1.1V supply was missing?

  • Hi Greg

    We will need to have these units back in TI for failure analysis first. But if you have incoming signal on the high speed lane while 1.1V supply is off, it could create a leakage path in the DP159. Please reach out to our local FAE if you wish to submit these units for failure analysis.

    Thanks

    David