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


  • thanks Scott

    ODR = 850 kHz, and Frame Size is 48. As per Pg 72

    ODR Time > tDCLK × Frame Size + 6 × tDCLK or tDIGCLK (whichever is higher)

    As per this formulae the Max ODR supported is 825k.

    incase not tried already can you reduce the ODR and see if it helps? also pull DCLK lower to check.


  • 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.