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.

ADS8166: Td_CKDO and SCLK Max Rate

Part Number: ADS8166

Hi Folks,

The ADS8166’s SPI interface can operate @ 70MHz. The period of the clock cycle @ 70 MHz (~14.3 ns) is shorter than the 19ns (max) for the SDO delay (td_CKDO) from rising clock edge. So the delay could be 1-whole clock-cycle behind the SCLK.

Is there a discrepancy in the datasheet in this spec? Or is there some relation to the td_CKDO and SCLK frequency that prevents a potential misalignment of SDO information?

Thanks,

  • Hi Chris,

    Per our email discussion, I'm looking into this with the team and will get back to you shortly.

    Regards,

    Ryan

  • Hi Chris,

    After some discussion, I do think this delay spec is a bit of an oversight in our data sheet. It's not a typo, but clearly there is some conflict when trying to operate SCLK @ 70 MHz because it allows for the possibility of two consecutive capture edges to occur within the same bit on SDO.

    Is there a reason that the customer wants to use the maximum SCLK frequency? At only 250 kSPS, the SCLK just has to be faster than 4 MHz clock, even with single-SDO configuration.

    Let me know if you have any further questions.

    Regards,

    Ryan

  • Hi Ryan,

    70 MHz isn't being used, 25 MHz is. But this doesn't make the argument that the datasheet is unclear moot.

    If the max delay is in fact 19ns, this seems to be incompatible with the 70 MHz SPI clock that the datasheet indicates the device can operate at.

    Does the SDO delay change with SCLK? If so, what's the relationship? Otherwise one can only presume that the delay to design around must be 19ns. At 25 MHz SCLK, a 19ns delay puts the data valid point ~mid-point in the clock cycle; acceptable but close to the falling edge which could degrade further if any translation or buffering occurs.

    I believe the datasheet should be revised to add clarity on this spec.

    Thoughts?

  • Hi Chris,

    I agree these two timing specs are conflicting and this clearly was an oversight when this part was released. I'll make a note of this feedback if the team is planning a datasheet update. 

    One other suggestion I would make is to consider using the clock re-timer feature in this device, which uses the READY pin to provide a source-synchronous clock back to the host along with SDO. This may help to align the falling edge closer to the data-valid mid-point and alleviate other concerns with translation or buffering delays.

    Regards,

    Ryan