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.

ADC08D500 Startup Time

Other Parts Discussed in Thread: ADC08D500

Hello, I'm using the ADC08D500 and am observing long startup times on the order of 10 seconds on initial powering. Specifically, it takes ~10 seconds from when the the chip is first powered to when there is a stable clock output on DCLK. I can't find anywhere in the datasheet that provides information on whether or not this is normal.

Some additional details on my circuit:

The ADC is being clocked by a Silicon Labs 500MHz clock. The clock is powered shortly after (~1us) the ADC is powered. I have verified that it stabilizes within the 10ms specified in its datasheet.

The ADC is powered on in Extended Control Mode. Once DCLK is stable, I write to the configuration registers, perform a calibration, and enable DES mode. The ADC works perfectly from this point forward. Also after re-enabling the ADC after being in power down mode, the clock begin immediately with no delay.

Thanks for any help. 

  • Hi Schuyler

    What is the value of AC coupling capacitors you are using between your clock circuitry and the ADC08D500 CLK+/- inputs? These inputs are internally connected to the Vbias voltage using 50k resistors. If the AC coupling capacitor value is large then it will take some time for the input voltage to stabilize at the proper input common mode voltage. Using a smaller capacitor value should improve the startup time. On our evaluation boards we typically use a capacitor value of 4.7 nF for the clock AC coupling capacitors.

    Regards,

    Jim B

  • Hi Jim,

    I'm also using 4.7 nF for the clock AC coupling capacitors. Do you know how long the evaluation boards take to startup? I used a lot of the evaluation board reference design in my board design. It's ok with me if this behavior is normal(-ish), but if it's not I'd like to figure out what mistake I made. Thanks for your help,

    -Schuyler

  • Hi Schuyler

    The ADC startup itself should be much quicker than 10s, but the EVM itself requires the FPGA firmware to be loaded every time it is powered up. This prevents validating the startup time in this platform.

    If you can attached your schematics of all ADC connections I would be happy to take a look and confirm everything looks OK. I would also recommend you monitor the 1.9V supply voltage and Vbg voltage just to get an idea if something else is going on.

    Also, what is the part number of the Silicon Labs clock you're using? I would like to learn more about that device as well.

    Regards,

    Jim B

  • Hi Jim, 

    I figured that 10s is too long - I just was looking for some confirmation before I spent time investigating any more issues. I'll check the board tomorrow to see what Vbg looks like. It could also be an issue on the FPGA side that I haven't thought of.

    The clock is SI530. The variant I'm using is LVDS output, and pre-programmed to 500MHz. I spent a long time investigating various clocking solutions that would meet the low jitter requirements, and this one was by far the simplest. The only downside is you cannot change its frequency. Since my application requires the ADC to mostly be in DES mode, the simplicity outweighed flexibility.

    http://www.silabs.com/Support%20Documents/TechnicalDocs/si530.pdf

    -Schuyler

  • Hi Jim,

    I've done some more prodding today, and still don't have any definitive answers. I've double checked that the supply voltages come on as expected: first the ADC supply turns on, and takes ~200us to reach 1.9V. Once it reaches 1.9V it appears stable after that. The clock supply is turned on after the ADC and also takes around 200 us to reach it's voltage but then is stable. Vbg reaches its value also in ~200us from when the ADC power turns on. There is slight overshoot, and then it settles.

    I also measured the actual time it takes from when the ADC power turns on to when the FPGA sees the clock, and it turns out that this appears to be a function of how long the ADC has been turned off. The first time I turn the ADC on, it takes ~25 seconds to turn on. Once it's on, if I just quickly (~1s) turn the ADC power off and then back on again, it takes as little as 13 seconds to see the clock again. This tends to agree with your first suggestion that it has to do with some capacitor charging.

    Some additional info: On the ADC, the PD pin is pulled up to the ADC supply and also connected to the controller FPGA. The FPGA pin is high impedance output, so PD tracks the supply voltage. After the ADC and clock are turned on and some warmup time has passed, then the FPGA brings the PD pin low. I've verified with the scope that this is happening.

    I've also attached the schematic. I appreciate all of your help so far.

    -Schuyler

    FastDataAcq.pdf
  • Hi Schuyler

    Do you have access to an oscilloscope that is fast enough to look at the LVDS DCLK signal? Is DCLK accessible on your board maybe at a via somewhere?

    I would like to get some visibility of the DCLK operation through something other than the FPGA, just to make sure we are working on the problem from the right direction.

    Another thing to try would be disabling/enabling the ADC using the ADC_PD signal instead of turning the ADC power completely off and on. When coming out of powerdown the DCLK should start up very quickly. If you see similar behavior between the previous tests and using PD then I suspect the issue may be more related to dalys in the FPGA 'recognizing' the DCLK rather than the DCLK starting slowly.

    Regards,

    Jim B

  • Hi Jim,

    Yes, I have a 1.5GHz scope which I have been using to measure the various signals. Unfortunately DCLK is not accessible to probe - I've been kicking myself for not putting in a test point.

    There are a few tests I've done that suggest it's not an issue on the FPGA side. The DCLK signal is buffered by the FPGA I/O but it is not sent to a clock manager/pll. I have forwarded that clock signal to a general purpose output pin, and viewed that on the scope. It demonstrates the problem behavior - i.e. no clock signal for many seconds and then it's fine. The other reason I think the problem is on the ADC side is that if I try to calibrate the ADC immediately on power-up, I need to wait for many seconds for the calibration output on the ADC to go high and then low again.

    Lastly, ADC_PD works perfectly. Coming out of power-down the clock is immediately detected.

    I'm inclined to think that it's maybe a problem with the ADC clock like you first suggested. I might try contacting Silicon Labs to see if they have any ideas.

    Thanks for your help - it's reassuring to know that I'm at least thinking of the right things to check. I'll let  you know if I figure it out.

    -Schuyler

  • Hi Schuyler

    Here is one more thing to try. Can you change your board temporarily so that the ADC PD input is tied low by default instead of high at power-up? If possible do the same with the CAL signal. 

    I want to see if having these low at power up affects the behavior at all.

    Regards,

    Jim B

  • Hi Jim,

    Sorry for the slow reply. I tried your suggestion and it didn't change the behavior, however it made me think of something else: currently the DCLK_RST pin is not used and is left floating. I thought I had read somewhere to leave it floating if I wasn't using it, but can't find that reference anywhere now. Do you think I should try grounding this pin?

    -Schuyler

  • Hi Schuyler

    The DCLK_RST feature is always active, so if the unterminated DCLK_RST input is floating above a logic 1 threshold then the DCLK output will be held in reset.

    Try grounding the DCLK_RST input pin and observe if the behavior changes.

    Regards,

    Jim B

  • Hi Jim,

    Finally! That did the trick. Thanks for sticking with me until it was figured out.

    In summary, the DCLK_RST pin needs to be grounded when not used. If its floating, the ADC takes 10s of seconds to start when power is applied - and I guess there's a chance it would never actually start.

    -Schuyler

  • Hi Schuyler

    That's great news. I'm glad the cause of the delay is finally understood.

    As I recall the DCLK_RST signal is controlled by your capture FPGA. To avoid problems like this I prefer to have resistors on the board that will set the default state of any ADC control pins whenever it is powered, in case the FPGA is not yet configured. Then when the FPGA is ready it can overdrive the resistors to change the ADC mode if needed.

    Good luck with the rest of your development work.

    Regards,

    Jim B