Post Go back to editing

AD4134 Multi-Device Synchronisation

Category: Datasheet/Specs
Product Number: AD4134


I am looking for some clarification regarding synchronisation of 8 AD4134 devices with common MCLK and common ODR signals.

I note in the datasheet that a DIG_IF_RESET is required to ensure device-to-device synchronisation. It is not clear what ODR or DCLK should be doing when we apply this reset. Or indeed whether there needs to be a defined relationship between ODR and the SPI broadcast to all devices.

We are seeing very mixed results operating the ADC at 1 MSPS. A large proportion of captures seem to be out of phase by an entire ODR clock period, that is some chips are in one phase while the rest are in another (see attached plots sampling rising edge of square wave).

A DIG_IF_RESET is applied between the shots in the attached PDF. This reset is applied by a hardware process, after the falling edge of ODR, and consists of an SPI write to reg 0x01 with data equal to 0x82. The ADC is constantly sampling throughout, (constant ODR and gated DCLK).

Any further guidance you can provide would be much appreciated.


S Robson


  • hi S Robson

    Apologies for coming back late.

    i presume that you are operating the devices in High Performance, ASRC mode(ODR Input) with DCLK gated as input. 

    the DIG_IF_RESET command needs to be simultaneous to all devices and should be given once the PLL is locked.

    Please also check if PLL unlocks when you see that 1 ODR difference. Let me know how it goes.


  • Hi folks,

    Apologies for the delay. I missed the forum notification.

    We are operating all the ADCs in :
    • ASRC Slave mode
    • SPI Control Mode
    • DCLK gated mode, INPUT, 50 MHz
    • 16-bit mode
    • High-Performance mode
    • Sinc3 filter with a sample rate of 1 MHz (or 850 kHz when we include the CRC and status bits for debug).

    Janine, here is the updated signal trace including the DCLK.

    Wa$im, you can also see that I have included the PLL Lock in pink.

    I have dropped the sample rate to 850 kHz so that I can include the CRC and status bits in the data word, and see the status of the PLL on every sample.

    Then I can look for my lock signal ever being "not equal" to ffff. Once we've established ODR the lock never drops.

    We also had a conversation yesterday with one of your local Apps engineers who may share further details with you once I provide an updated report.



  • So we double the 6? Because we're doing 2 channels per lane?

    Ok I'll give that a try and get back to you.

  • Also, should the ERR_DCLK flag not set if the rate is unsupported?



  • Signal trace with ODR running at 825 kHz. PLL remains locked but still seeing a 1 sample ODR error on some data captures

    Is there anything else I could monitor to help diagnose?

  • Hi Scott

    Apologies for coming back late, there is one experiment to check if DCLK is causing any issue.

    Steps are

    1. configure all SPI registers as per Need

    2. Start the ODR only (Not DCLK) and wait for the PLL to lock

    3. once PLL locks, Provide the DIG_IF_RST simultaneously to all devices.

    4. Start DCLK


  • I am still looking at this after a few days vacation. I will have a further update tomorrow



  • Hi,

    Well this is new behaviour.

    We can't tell if the PLL is locked from the data word without the DCLK running, so I am relying on the software SPI registers to tell me that we have initial LOCK on the PLLs after boot.

    Then when we apply the DIG_IF_RESET, we get a couple of cycles where the chip report PLL LOCKED before losing lock and re-establishing LOCK a few cycles later. Is this expected behaviour? Perhaps this has been the source of our problem all along but previously I do not think I was seeing LOCK drop at any time.



  • Can you comment on whether the PLL unlocking after a DIG_IF_RESET is expected behaviour?

  • No, this is not the expected behavior. the blocks are different so PLL should not Unlock.

    PLL can only unlock incase of a config change or ODR change

  • An update on where we are at the moment.

    I have not been able to rely on the "No Chip Error" bit in SPI reg 0x02 (henceforth SPI Chip Error) to indicate whether the chip is completely happy or not. In fact I can create examples where the SPI Chip Error and the signals from the "Data Interface Status bits" (henceforth ADC Chip Error) are not in agreement.

    Thus, I believe the only thing that can be trusted is the ADC Chip Error

    This means that for our current scheme, we are making a sacrifice on AD4134 sample rate (so that we can afford to include the extra status bits in the data word, and still have time to shift in the data before the next conversion).

    Procedure is as follows :

    1. Turn off SW SPI poll as we now know that SPI writes can cause chip errors / LOL.

    2. Set up ODR

    3. Program all of the ADCs.

    4. As a final programming step, change the ADC Data Format to include the status bits and CRC. There is a non-zero chance that this will cause an ADC Chip Error

    5. Switch off ODR, then switch it back on. There is a high probability that this will clear Chip Errors. After this :

    5a. If No ADC Chip Error then block all further SPI transactions and continue to data capture

    5b. If there is still an ADC Chip Error then revert to step 1 and repeat all steps

    This is a major compromise but we have exhausted the time allocated to this project and have not been able to find a better solution. Either we have something misconfigured or the chips are not behaving as specified for some other reason.

  • Apologies Rob for coming back late

    do you Observe that No_CHIP_ERR Is cleared whenever you do any SPI operation?

    secondly do you say that status header and the SPI registers are no in agreement?


Reply Children