ADS52J90: Runtime change in clock to data delay

Part Number: ADS52J90

Tool/software:

Hello!

I have been using the ADS52J90 on a custom PCBA, and we have so far tested the design on about 15 or so PCBAs. I recently found that, on one PCBA, the clock to data delay varies after power on and initialization of the ADC. We have narrowed down the issue to a single ADC and have only seen this behavior on this one ADC across all of the PCBAs tested so far. Our FPGA receiver module provides the sampling clock to this ADC and performs an initialization sequence to start de-serializing the ADC data into separate channels (we are using 32 input mode), and by using the ADC's internal test pattern modes we are able to "lock" onto the bits corresponding to individual samples and then run indefinitely. Since the FPGA provides the sampling clock to the ADC directly, the ADC data clock and the FPGA deserializer do not slowly get out of sync over time. We have not previously noticed any issues with this startup alignment routine, even after running while continuously checking the received ramp pattern for bit hours for a day straight.

However, the problem that we are noticing now appears only a few minutes after the alignment routine successfully locks onto the incoming samples, which tells us that the ADC does not have a constant delay between its DCLK edges and the DATA lane edges, causing our deserializer state machine to start receiving skewed data. We have probed the power rails for the ADC, checked the temperature of the unit during this behavior, and have narrowed down the behavior to this specific ADC exhibiting a varying DCLK to DATA timing relationship.

Given that the ADS52J90 datasheet calls out tPROP and delta_tPROP as typical values, is there any measurement data on how tPROP varies over time or temperature for a single ADC? Since we have not seen this behavior before on any of our ADCs, are we to assume that this ADC has been damaged in some way?

Best,

Austen

  • Hi,

    What is your clock speed ? Is the issue dependent on clock speed ? 

  • Hi,

    Can you please check by writing the following register ? 

    Addr:0x0C  Data: 0x2000

  • Hello, this issue does not seem to be dependent on clock speed since all ADCs have been getting used with the same clock speed of 16 MHz (8 MSPS in 32 channel mode).

    What does that register write do? I don't see register 0x0c documented in the datasheet

  • Hi,

    We have seen earlier one failure at customer where at lower temp in very few devices LVDS clock gets disturbed  to give bad data at the output .So if it is same issue writing these register after reset will help. Can you please check that and update results ?

  • Hi Sachin,

    This issue appeared to resolve itself after letting the device sit powered off at room temperature for a day or two. It is unclear to us why.

    However, we have encountered a similar issue on another unit, and are working to root cause it. This time, the major differences are:

    1. We previously saw continuous slippage between the DCLK and DATA. Now, we see a slip several seconds into operation and no further slips.
    2. If we wait >10s between powering on the ADC and performing the clock alignment initialization sequence, we no longer see any bit slips.

    As we try to determine whether this is the same issue as the original post, could you please help us understand what the 0x0C register does? Why does writing 0x2000 to that register impact the DCLK and DATA alignment?

    Thanks!

  • Hi,

    We had seen in one customer issue was coming at low temp on few devices. 

    • After testing the device in multiple internal test modes, it was found that the PLL inside the LVDS block gets disturbed every cycle when this temperature shock occurs.
    • This happens due to a weak fuse which provides the values to the PLL at every clock cycle
    • By writing these bits we are freezing this fuse value .