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.

TFP410: DVI Differential Output Clock frequency is jumping

Part Number: TFP410

Hello,

Our customer is seeing a problem on our product which uses a TFP410 encoder in which the DVI Tx diff out clock frequency is jumping from 121.5MHz (1400x1050@60Hz) to ~153MHz for about 9us interval. The IDCLK input is reported to be stable during this event as well as the DC power supply. Based on the frequency jump failure results where it changes from 121MHz to 153Mhz in one clock period (see CH1 scope shot below), were surmising that the TFP410 has an internal DLL and what our customer is seeing is a skip on a DLL tap selection.

My question is does the TFP410 use an internal DLL? If so, what else besides input (ref) clock and power quality what else could cause the observed failure our customer is seeing? If there is no internal DLL are there any other means that would cause the frequency to jump momentarily?

Thx

  • Hi Tom,

    Yes, you can see the PLL in the block diagram on page 11.

    Do you see this issue at different supply voltage values? Additionally, do you see any abnormal behavior on the PVdd pin when the frequency changes?

    Regards,
    I.K.
  • Thx for the confirmation that it is a PLL and not a DLL. Based on new data from our customer the clock actually shifts from 121MHz to 153MHz and then drifts back to 121MHz over time.

    As for the PVdd (course view screenshot from customers scope) it doesn't look like there are any glitches (at trigger) on the rail but I need to convert wfm data file and zoom in (will post later). As for circuit design, the filtering on the power supply has the 10uF prior to the bead (vs after as recommended) but we've used this design on over a thousand units (10+ years) and have never seen an issue. Our customer has used the board in two different applications (bench setup with bench power supply) and second setup installed in their embedded system and both setups have seen the frequency jump/skip issue.

    Also, the skip does not appear to be related to Hsync as the event occurred in the middle of the line on several captures. We also checked the static timing analysis and constraints on the fpga and all looked good. Question: Is the Hsync (or Vsync) used in the PLL for clock generation (e.g. gated sample window)? Or does it just track the IDCK?

    We are still unable to reproduce locally at our site the failure our customer is seeing. We have 80+ units on hand that have passed acceptance test and we are in the process of performing more extensive bench test on our units to see if we can duplicate the frequency jump including thermal cycling and noise susceptibility testing on input power. 

  • Hi Tom,

    Sorry for the delay, I have been on travel. I will need to look more into your question about HSYNC and VSYNC.

    Do you know how many boards the customer has seen this issue in? Are there any boards on their end that don't show this issue? Also, do you know if the customer saw this issue at specific temperatures, or did it happen across the recommended operating temperature range?

    Have you seen any results from your more extensive bench testing yet?

    Regards,
    I.K.
  • I.K.

    The customer has seen the problem on 4 out 5 units on the last batch of 15 units delivered (other 11 remained un-tested). One of the failing units is being returned to us for analysis. The customer originally encountered the failure during cold temperature testing but it was reproduced at room temperature on two different setups. The frequency jump usually occurs within 20 minutes of power-up and more often than not within 5 minutes. We have done some minimal temperature testing (freeze spray / heat gun) at our facility with no duplication of the failure.

    We tried two tests on our side to re-produce the failure by forcing the failure by insertion of input timing errors and noise injection on the power supply. The first test was to phase shift the data in clock relative to the data/sync inputs until visual effects were noted. The thought here was to test if there was any interaction between Hsync not meeting setup and hold timing requirements versus PLL operation. We did not see any shifts on the output clock and the design appeared to have plenty of timing margin.

    The second test used a signal generator to modulate the input power to the board at between 1 to 5% duty cycle (off) ranging from 100kHz to 5MHz modulation. This injected about +/-100 to 200mV of noise on the +3.3V rail. The test did at times generate perturbations on the DVI output clock but generally resulted in a falling clock rate in which it appeared the PLL went offline momentarily. It did not duplicate what our customer was seeing.

  • Hi Tom,

    If you're unable to replicate the issue it's possible the issue may be related to the customer's setup. Can you check to see if they see the issue at different resolutions? Also, in the second setup when it's installed in their embedded system, do they also see visual abnormalities on their display when the jump happens or is just observed on the oscilloscope?

    Regards,
    I.K.
  • I.K.

    We believe it is something with customers setup but we also did a webcam review of their setup and it looked OK.

    Its at a fixed resolution (1400x1050 hard coded in fpga) because it's in an embedded system and is the same on the bench. The frequency jump occurred on both setups and is visually noticeable.

    We did receive back a failing card from the customer and were unable to replicate the failure but also suspect there is ESD or over-voltage damage on fpga (higher than normal current draw and low impedance on core voltage rail). Not sure if it's related or a separate failure. Our next step is to visit customer site in person.

    Tom 

  • Hi Tom,

    Understood, please keep this thread updated with results from the customer visit.

    Regards,
    I.K.
  • Hi Tom,

    I will go ahead and close this thread for now but please feel free to reply to this thread again if you have any updates or more concerns.

    Regards,
    I.K.
  • I.K.
    I just returned from visiting the customer (overseas) and verified that there was nothing wrong with their setup. We verified that only certain units were failing and even with four different power supplies (from an embedded system to bench top supplies) they still failed. We tested units from four different date code batches but the units that failed came from a single batch (build of 51 units) in which certain ones failed and certain ones passed. I'm suspecting the parts were damaged in some way but not sure how. The customers lab was setup with ESD mats/benches/chairs/ smocks/wrist straps or ESD shoes, etc plus fairly humid environment.

    We returned with four of failing units, verified they fail here, and plan to replace the 410 and verify that the problem goes away. At that point we will probably need to engage TI for FA - I assume i need to work that through the supply chain correct?

    Thx - Tom
  • Hi Tom,

    Thanks for the update. And that's correct, please contact your local TI field office for the FA process.

    Regards,
    I.K.
  • I.K.

    We're working on getting FA setup for it but in the mean time can you think of any failure mechanism that would cause this strange behavior where it operates normally most of the time but occasionally glitches the clock output? If the failure was due to an external ESD or over-voltage event on the DVI Tx out clock, one would think the output drive gate would be damaged but would not affect the internal PLL operation. I'm trying to think of a scenario where the part could be partially damaged (PLL in particular) in which results in these "soft" failures. Any ideas?

    Thx - Tom

  • Hi Tom,

    I'm actually not sure myself what exactly could be causing this. As you mentioned, I can only guess the PLL is somehow getting partially damaged, but it's difficult to think of a scenario where that would cause these types of failures. For now I think it's best to wait for FA results.

    Regards,
    I.K.