Question regarding relative phase of multiple ADS5500 digitizer when DLL enabled

Hi Kang,

Thank you for your response. We have a follow up question, if we disable DLL will the relative phase of the two digitizers be fixed from one power up to the next?

Hello,

I am waiting for a response from designer. After thinking about this further, I believe that we may still run into the same limitation for DLL disabled. The ADS5500 device has Tstart specifications with typical of 2.2ns and max of 2.9ns. Without the knowledge of the internal chip architecture, we know it is possible that one chip may vary 0.7ns to another when the clock have trigger the capture for both ADCs. Since there is no minimum of the spec, we cannot predict the range of variation. Therefore, I believe that we may still not able to reliably estimate the latency difference between the two ADCs when they have a shared clock.

-Kang

Hi,

We plan to calibrate out the fixed delays and timing offsets between two A/Ds. Our question is: Will the delays and offsets vary by more than 10pS from one power up the the next, or over time?

Hi,

Sorry for such a long delay on this issue. To make sure we're on the same page about what you're trying to do, let me lay out how I would go about synchronizing multiple parts. I think the key here is using the input clock to the ADCs to capture the data in the FPGA rather than the output clock. See the block diagram below. The key timing specs are the total latency of the ADC (fixed at 17.5 clock cycles) and the tSTART and tEND parameters that define the data valid window relative to the input clock. If you match all of the clock trace lengths to the ADCs and FPGA and the data trace lengths from the ADCs to the FPGA, then this all simply comes down to meeting the timing constraints for all data bits (from all converters) relative to the single input clock to the FPGA based on the tSTART and tEND parameters in the datasheet. It should be no more difficult than achieving timing for a single ADC using the input clock to capture the data instead of the output clock, except for trying to meet timing with N times more data bits. In fact, the data trace lengths could be different if you account for the differences in your timing constraints as well.

Using the method above, the total data valid window is only 2.9 ns (tEnd(min) - tStart(max)). I'm guessing that we're on the same page as far as the method and that this small window is the reason for the inquiry. Unfortunately, our timing constraints are the worst case scenario across voltage and temperature and from part to part. This is usually sufficient for high volume production because individual delays cannot be calibrated out in mass production. For that reason, we do not usually characterize the worst case timing variance for a single part. 

So, I think the simple answer to your question is that we cannot guarantee that the offsets won't vary by more than 10 ps for a single part. The best we can guarantee is the tpd spec that's listed in the datasheet. I wouldn't expect a single part to vary over the full range of the tpd spec, but I would guess that the part will vary more than 10ps over temperature alone. However, for fixed operation conditions (voltage and temperature), a single part should exhibit little variance from startup to startup, but we do not have this characterized. The best we can do is measure a single part on the EVM from startup to startup to see the variance.

Regards,
Matt Guibord