Post Go back to editing

Non-zero delay in zero-delay mode with AD9546

Category: Hardware
Product Number: AD9546

I am running an AD9546 with an input that is a 125 MHz clock with an embedded tagged/modulated clock at 100 Hz. The 125 MHz is divided down to 200 kHz and used to compensate the system clock, TDCs, NCOs, and PLL0, through the AuxPLL; PLL0 is locked to the tagged 100 Hz data in zero-delay mode. This all works very well and stably.

What I was confused by is that if I use the skew measurement processor to measure the skew between the input 100 Hz tagged samples and the PLL0 feedback timestamps, the result is not quite zero. Instead, the average skew after convergence is reliably something like -13 ps. Everything is clearly locked correctly -- this number wanders around -13 ps at the sub-picosecond level, at the expected statistical jitter of the measurement. I except some small jitter on the skew, of course, but was very surprised to see an offset on the mean, especially since I would assume that the skew measurement processor is looking at exactly the same timestamps that the feedback loop is and so I would expect the mean offset to be zero.

This is not necessarily a problem -- the offset is easy to measure and compensate for -- but I am worried it suggests something else is wrong that I do need to worry about.

Thanks for any help!



Minor rewording for clarity.
[edited by: nwhitehorn at 4:31 PM (GMT -4) on 26 Aug 2024]
  • HI,

    please send me the stp file, so we can discuss on the same file. I created for myself a configuration that matches whatever info you gave me, but I still believe using your file is better.

    The 125MHz reference is indeed divided down to 200kHz. Then the DPLL tags the 100Hz embedded clock. The feedback clock is 100 Hz (I suppose an output is 100Hz and you feedback it in internal zero delay mode). The DPLL DPD functions at 100Hz. 

    Now you say you measured the skew between the reference clock (200kHz with 100 Hz tags) and the feedback clock (100Hz) and you see  a 13 ps skew instead of an expected 0ps. This depends on the lock detector settings you set in the reference monitor window. By default, the phase and frequency lock detectors are set at 700 ps, so as soon as the DPD lock detectors decide these levels have been met, the DPLL stops trying to get lower values. The dats sheet states at page 128 that these limits should not be set lower than 50 ps, so I do not believe you should expect 0ps skew.

    Use table 18, page 23 to get an idea of the delay between the output relative to the reference clock in internal zero delay.

    Petre

  • Thanks for the reply -- unfortunately, this device is on a custom board and programmed entirely with custom software, so I do not have any such file, though could probably make one if really needed. As an example of the convergence process, here are the residuals between the input and output 100 Hz signals right before convergence, as measured with the skew processor (all values in picoseconds) and measured approximately every two seconds. The lock detector has reported lock achieved at all of these times.

    418093.96
    201095.19
    96719.72
    46515.76
    22367.06
    10751.88
    5144.40
    2467.49
    1180.98
    561.64
    263.99
    120.69
    51.32
    18.17
    2.49
    -5.23
    -8.64
    -9.90
    -11.08
    -10.80
    -10.82
    -11.12
    -12.03
    -11.50
    -11.84
    -12.38

    And then it stays very close to that value for the next several weeks. Whatever this final value is seems to be hardware dependent -- this one ends up at -12 +/- 0.5 ps and another one I have ends at -16 +/- 0.5 ps. I'm not sure table 18 applies, if I have read it correctly, since I think that is the physical output delay and would add to the internal delta I am measuring here.

    If this is expected behavior, which you say it is, I am perfectly happy with it.

  • Hi,

    We usually recommend to use the evaluation software to create a desired configuration for the AD9546. This chip has 1354 registers and it is very hard to set them all correctly. Just use this software, get the register values and then compare them against yours. 

    Petre