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.

ADC08D1020: Q Channel Inconsistencies

Part Number: ADC08D1020

With the latest lot of these ADC's I am seeing Q-channel oddities if a calibration is performed after device usage/warm-up.  If the device is power on from ambient storage the power-on cal is run and subsequently an on-demand calibration is run during clock initialization (within 30 second of UUT power up) and performance is expected. If the UUT is power cycled, and the same startup and on-demand calibration occurs there is extreme amplitude variation on the Q-channel only (I-channel remains stable).  If power is removed for extended period of time, and restarted then performance is stable again on the Q channel. This has been isolated to devices with lot code 8CZF9F4G3 and cannot be reproduced with devices of lot code 6AZCCH7G3.

  • Hi Kevin

    Can you share some more details regarding the clock initialization and on-demand calibration sequence?

    Please share the following:

    • Configuration pin settings
    • If Extended Control Mode is used, provide the register writes performed.
    • What is the clock frequency being used?
    • Once the clock is stable, how much later is the on-demand calibration initiated?
    • Is the on-demand calibration initiated using the CAL bit or the CAL pin?
    • A schematic showing the ADC connections would be helpful. In particular, are you using one or both DCLK outputs to capture data into your FPGA?

    Here are a few debugging steps you could try:

    • Are the device power supplies consistently at the correct voltages? There could be some supply current differences from lot to lot, and a higher current consumption could affect the voltage if regulation is marginal.
    • Once the Q-channel is showing the amplitude variation can you enable test pattern mode and verify that the bits are all correct and aligned?
    • Can you set the RTD (resistor trim disable) bit before performing the on-demand calibration? This will prevent the output DCLK(s) from stopping during the initial phase of calibration. Sometimes stopping and re-starting the DCLK outputs can cause problems with consistency of data capture.

    I hope this is helpful.

    Best regards,

    Jim B


    PDQ held Low

    ECE disabled, so no register writes

    720MHz input clock

    The on-demand cal in this setup hasn't really been working the way it should. It was doing it right after the input clock was being reset. I have moved it to many seconds later after clock is stable but still fall into this instability issue.

    CAL pin is used for on-demand, hold low and hold high. I've monitored CALRUN and it does transition high for 1-3ms after driving CAL high.

    Only using 1 DCLK output as we use the OR signal for monitoring. 

    Output data is still sinusoidal but with only 4-6 bits of variation where as a typical good signal would be about 60-80 bits of pk-pk variation (centered on bit 127/128)

    Voltage is regulator sourced, 1.87V measured; 1.5A capable.

    Unfortunately I'm just the integrator for the card level test and do not have access to the FPGA code.  Since ECE is not natively used I am not sure how plausible it is to investigate test pattern and RTD but it is something I am suggesting to get additional troubleshooting data.

  • Hi Kevin

    Is it possible to reset or re-start the FPGA data capture block after the ADC on-demand calibration is performed? I would like to see if doing that results in the same behavior, or if anything changes. If the problem is with data capture the behavior may change or be resolved. If the issue is with the ADC then nothing will change.

    In your list above you didn't mention CalDly/DES/SCSb, Vcmo or Vbg pins. How are these connected?

    Also, how are the control pins pulled high or low? How strong are the pull-ups or pull-downs? Please list resistor value or driver type used.


    Jim B

  • The on-demand cal is only ran once, prior to any valid data applied to the I/Q inputs. I can keep getting data (it fills a FIFO, I extract from FIFO and the FIFO is filled again) and its all over the place, sometimes as expected, other times very attenuated.  The analog test point just prior to the ADC shows steady RF signal.

    Missed a few:

    CalDly is pulled high.

    CalDly/SCLK/SDATA/ECE/DCLK_RST/DRST_SEL are driven by 74LVC3G34 drivers.

    CalDly is defaulted high on the driver input with a 4.75k to 1.9V

    PD/DCLK_RST are defaulted low on the driver input with 1K to ground

    VMCO/PDQ are hard ground

    REXT is 3.3k to ground

    FSR is 5.1K to 1.9V

    VPG is 0ohm to 1.9V

    All remaining are buffer driven by the FPGA I/O and appear to be default high.

    I did learn that the operational NHA usage of the unit (where it apparently functions fine) holds the FPGA in reset while the on-demand calibration is issued. I am structuring my startup to mimic this. There are clock dependencies that may be causing unknown pin states to happen during initialization, the reset tries to make those states more predicable.

  • Hi Kevin

    Most of those pin settings look OK. The only one I might recommend changing is the FSR pin. Since it has internal 50k pullup and pulldown it is best to use external drive that is somewhat stronger than 5.1k. I would recommend 1k or less pullup to 1.9V. Having said that I don't think that should be causing what you are seeing. Even if the pin was being sensed as mid-level (ALT_ECE function) I would expect similar behavior between I and Q channels. 

    Let me know what you see after changing the FPGA reset behavior.

    Since Vcmo is tied to GND the device will be in AC-coupled operating mode. Please confirm that AC-coupling capacitors are used in the signal path, and what value of capacitors are used.

    Best regards,
    Jim B

  • Yes, AC Coupled with 1000pF series for both I/Q channel inputs.

    And I agree, it is quite confusing it is only impacting the Q channel sampling. Both inputs are using the same datarate.

    I'll hopefully have the new initialization coded today and will know the result later this afternoon.

    I appreciate the tips and insight you are providing.

  • Holding the FPGA in reset during the clock configuration and ADC calibration has apparently resolved this issue. My best guess is the state of some of the FPGA to ADC pins are unknown or changing. Luck must have been on our side for the previous lots to have become an issue now.