ADS131A04 - Multiple Device Configuration Using Asynchronous Interrupt Mode

I have a quick question regarding the CLKIN of the ADS131A. For our application, we have 3 devices that are using the Multiple Device Configuration Using Asynchronous Interrupt Mode shown in Figure 99 of the Sept 2016 datasheet.

Is it required that all three devices CLKIN be the same clock source?

We have been looking at various clock distribution and fan-out architectures and we are curious if each ADS131A device can be clocked from their own local oscillator/crystal?

Are there any disadvantages of doing so?

If required  to be source synchronous, is it appropriate to use a standard buffer with some delay like SN74LVC3G07-EP or should a low skew buffer like CDCV304-EP be utilized?

Thank you,

Aaron

  • Hello Aaron,

    Sorry about the delay in my response. The same clock must be used for all devices to avoid a F_RESYNC fault which causes the un-synchronized device's digital filter to reset. As for your question about the delay from the clock buffer, the datasheet is light on details for the timing of the synchronization event. I'm currently working with the design team to figure out the actual timing. Bear with me as it will likely be a little longer before I have a comprehensive answer.

    Regards,
    Brian Pisani
  • Aaron,

    So here are the specifics on the DRDY timing. The DRDY output for the Asynchronous Interrupt mode device (DRDY falling low) is generated on the falling edge of CLKIN. The DRDY input on the Synchronous Slave device is clocked in on the following negative CLKIN edge. The DRDY signal must appear at the input before the 10 ns setup time to avoid the resynchronization fault.

    Clocks must be synchronized to ensure proper operation. I recommend a configuration where CLKIN edges come as close to simultaneously as you can manage. If there is some distance between the devices, buffering is ok as long as you find a way to synchronize the edges. You could imagine a poorly designed setup where the CLKIN delay is so great for the Synchronous Slave devices that DRDY actually appears at the inputs too early and becomes un-synchronized.

    Regards,
    Brian Pisani
  • In reply to Brian Pisani:

    Hi Brian,
    In regard to this multiple device chaining, I have noticed that the devices have a lower maximum clkin than when they are operating in single device configuration. According to the data sheet, the minimum clock period for clkin in the multiple device chaining mode is 56 ns or 17.8571 MHz. What happens if the clkin is greater than this frequency but less than the single device clkin of 25 MHz?
    Thank you,
    Aaron
  • In reply to Aaron Lancour:

    Hey Aaron,

    The difference in max clock frequency exists because at a higher frequency in multi-device configurations it is impossible to meet the set-up and hold times for certain interface signals.

    If you were to run the clock faster, it's possible that you will violate these times and collect corrupted data.

    Brian
  • In reply to Brian Pisani:

    Hi Brian,

    To get to a common frequency multiple to support two separate software configurable sampling frequencies, we are providing a CLKIN that is slightly above the recommended max of 17.8571 MHz (56 ns) for multiple device chaining; however, we are running the SCLK at 12.5 MHz (80 ns) instead of the max 15.6250 MHz (64 ns). Is there a tradeoff between these two that would enable us to run the CLKIN at the frequency to support both operating modes? It seems to be working currently but we have not tested over temperature yet?

    Thank you,

    Aaron

  • In reply to Aaron Lancour:

    Hey Aaron,

    I can't be totally sure, and I cannot recommend that you operate outside of the datasheet operating conditions, but if you do, there are plenty of built-in data integrity checks on this part that could provide you with some peace of mind.

    When it comes to determining if your setup is valid or not, it is worth it to analyze all of the setup and hold times for the various signals in your connection scheme and try to see if any of them will be violated. Like I said, the minimum period specified for multi-device mode was done so because operating faster risked hitting some of those keep-out zones.

    Brian