Please note that E2E has undergone a major upgrade. Before logging in, please clear ALL your browser's cache and cookies.

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.

ADC3421: Time between CLK-in to valid data out

Part Number: ADC3421

In our application we programm the ADC via SPI before the CLKin is applied. The CLKin can only be applied for a certain time until the acqusition is done.

Once the CLKin is applied it will take some time until the PLL for DCLK/FCLK is locked - this is typically ~500us (as we measured until a stable FCLK output is present). 

But it needs much more time until valid output-data are available - even if testpattern (ramp or sine) are generated internally, it takes a longer time until the testpattern data are coming at the output.

I can't say how long it takes, but after ~2 seconds the output data are stable - but this is too much for our application.

I did not find any number in the datasheet for the delay between first CLKin edge and valid-data output.

Can you please let us know if the above described behaviour is expected and what the minimum time delay between CLKin and valid-data output is ?

  • Hi Holger,

    What sampling rate are you using for the ADC clock? Is your application using any ADC power down modes? What SPI writes are being performed before CLKin is applied?

    If the sampling clock is below 25 MSPS, the Low Speed bits should be set (with respect to 1 wire or 2 wire mode) in accordance with the datasheet (see pic below).

    Best Regards,

    Dan

  • Hi Dan,

    the SPI is programmed as:

    adc.writeSPI(dwf,hdwf,0x06, 0x01) #triggers internal software reset
    adc.writeSPI(dwf,hdwf,0x0A, 0x44) #CH A/B set test pattern 44=dig.ramp, 33=toggle, 99=0,599,2048,3496,4095,3496,2048,599,0

    adc.writeSPI(dwf,hdwf,0x0B, 0x44) #CH C/D set test pattern
    adc.writeSPI(dwf,hdwf,0x13, 0x03) #low speed enable for two wire mode

    adc.writeSPI(dwf,hdwf,0x15, 0x00) #power down channels

    adc.writeSPI(dwf,hdwf,0x25, 0xFF) #increase LVDS swing
    adc.writeSPI(dwf,hdwf,0x70A, 0x01) #power sysref

    I am using 2-wire mode to minimize the output DCLK frequency.

    In our application the ADC Sampleclock is 10MHz - I know it is below the min. frequency, but it is working (its a lab-test setup - not a product). We could try 20MHz if it would change the delay much.

    Today I investigated in the delay and measured a minimum of 10ms of ADC clock until the output data is valid - that is a problem for our application.

    What is the delay we need to expect with 10/20MHz ?

  • Hi Holger,

    I am looking into the expected delay under your conditions. For now, I would recommend trying a faster sampling rate (I would test 25 MSPS if possible), and see if you are getting the same delay for valid data out.

    Best Regards,

    Dan

  • Hi Dan,

    unfortunately I cannot use a higher sampling-rate in this application, as we do have fixed clocks.

    I already increased the sampling rate to 12MSPS (12MHz ADC clock) - but thats the maximum.

    Anyways I would be interested in the delays in both cases 12 and 25 MSPS.

    I do have one more question:

    In the datasheet it look like the sampled voltage is directly present during the next output frame.

    But I do have the suspicion that there is a pipeline inside the serializer which send the sampled voltage after 9 frames.

    Can you verify that ?

    I tested with a defined 01010011 pattern at the ADC input, and see that this pattern is coming after ~9 output frames.

  • Hi Holger,

    Yes, the delay for 2-Wire mode is 9 clock cycles as per page 16 (table7.13) of data sheet, so this is correct in regard to what you are measuring.

    See the note 1 for overall latency. t_pdi (clock propagation delay) is also stated in table 7.14, and should be around 50 nano seconds for 10 MSPS rate.

    I must also emphasize that the ADC datasheet states that 15 MSPS is the minimum supported sampling rate, so results cannot be guaranteed below that threshold.

    The delay will decrease from 12 MSPS to 25 MSPS since the sampling period decreases (~83ns to 40 ns), but the number of clock cycles remains the same (9). Additionally, t_pdi will decrease for the same reason (shorter sampling period).

    Best Regards,

    Dan

  • Hi Dan,

    thanks for pointing me to the proper datasheet table - that question is solved now.

    The only open issue is to find the "Time to valid data after clock-in first edge".

    Kind regards

    Holger

  • Hi Holger,

    Since this information is not available in the datasheet, I will attempt to make this measurement with the evaluation module, and will get back with you soon.

    Best Regards,

    Dan

  • Hi Holger,

    Getting an accurate measurement here is not as straight forward as originally thought. I am still working with the resources that I have available to get this information for you, so thank you for your patience.

    Best Regards,

    Dan

  • Hi Dan,

    thanks for keeping me updated.

    One more question I have - according to the datasheet, there are 9 cycles delay between sample taken (CLKIN rising) and FCLK data output started.

    In my application I measured 10 cycles delay - I am not sure if its just a miss-undertsanding or miss-interpretation of the definition of the 9-cycle-delay.

    Could you please provide a detailed timing diagram for this timing delay ?

    This is really missing in the datasheet.

    Thanks and best regards

    Holger

     

  • Hi Holger,

    The reason for a larger than 9 clock cycle delay is due to the tdpi. For 2 wire mode, this is 0.44*t_sample+t_delay. = 0.44*100nS+4.5ns which is equal to about 50 nS. While this isn't quite a full clock cycle, it does add additional delay.

    In regard to "time to valid data after first clock edge", this is not a parameter I am able to provide with the tools at my disposal, but maybe I can help provide some further understanding here. When the clock is applied to the ADC, the amplitude of the clock signal will start small and will eventually increase to its full voltage swing (due to internal capacitance and such). The ADC will start converting data at a certain point during this increase in clock amplitude, but does not output valid data until the amplitude is at the the minimum clock amplitude (200 mVpp), so this should be the threshold at which data would be valid, but then there will also be the 9 (plus tpdi delay) latency.

    This diagram from the datasheet 9.3.3.2 (figure 138) depicts how the data comes out with respect to the sampling clock. The 9 clock cycle latency is also with respect to the sampling clock, so this figure can be referenced.

    Best Regards,

    Dan

  • Hi Dan,

    I created a timing diagram (using "wavedom" - very helpful tool) to visualize the timing in 2-wire mode, please see below.

    Regarding your explanation above on the increasing amplitude of the internal clock - if it is as you descibe above - this would imply, that there is no clock, and thus no DCLK / FCLK if no input clock is applied. But this is not true.

    If no input clock is applied the internal PLL runs freely and is producing random output data at DATA, DCLK and FCLK. This means (in my opinion) that the internal clocks are already running but are not synchronized to any external clock.

    At the time an external clock is applied to CLKin, the internal PLL needs to synchronized and lock - I observed that this takes about ~1ms. After this ~1ms the FCLK is in sync with the CLKin. But still it takes more than ~10ms until valid output data is available.

    Too bad that you/TI cannot measure this "clockin-to-valid-data-out" time due to missing setup.

    I can strongly recommend the use of the "Digilent Digital Discovery" instrument. It is about ~80$ and allows to programm digital outputs freely (e.g. via Python) using different delay for the signal required.

    With this instrument I am running the ADC3421 in our lab.

    Kind regards

    Holger

  • Hi,

    correction, the tools name is "wavedrom".