Page 22 of the data sheet (Rev F) states: "However, due to the possibility of performance degradation, digital activity should occur only prior to the safe data reading/ writing time, tDATA, because the AD7949 provides error correction circuitry that can correct for an incorrect bit during this time."
Page 29 of the data sheet shows the following:
As such, the data sheet contradicts itself, further, it seems that the digital acquisition is split across two different conversions which makes no sense.
Can anyone clarify how this ADC is actually supposed to work?
The intent of the diagram is to demonstrate the ability to read the previous conversion data result across or "spanning" the conversion start signal; the intent of this mode is to allow maximum throughput for processors that are unable to provide the required serial clock rate. You can always elect to read the entire conversion result after the EOC event and prior to the next CNV pulse if this makes more sense for your application. The datasheet is highlighting that the only restriction is that the serial clock must be idled for TDATA to prevent corruption of the internal conversion process. This restriction would only apply to the read span/during convert case. Could you please indicate what you feel is contradictory or unclear between the timing diagram and the description in the text. This will help us improve the clarity of our documentation in the future.
As an example of how this feature might be used, consider the following "PSEUDOCODE" for SPI peripheral communication in a microcontroller; please assume setup is to use a GPIO for CNV, A SPI peripheral for communication and a single timer (wait) for process timing.
1) Set CNV High // Initiate Conversion
2) Set CNV Low // Setup Data Access
3) Send 1 Byte to TXBUF of SPI Peripheral // CAPTURE LSBS of PREVIOUS Conversion in READ
Read Byte from RXBUF of SPI Peripheral, store in LSBYTE
4) Assemble conversion result as MSBYTE <<8 + LSBYTE
5) Wait X ns for Conversion to end // Alternatively use BUSY as IRQ for synchronous operation.
6) Send 1 Byte to TXBUV of SPI Peripheral // CAPTURE MSBS of CURRENT Conversion in READ
Read Byte from RXBUF of SPI Peripheral, store in MSBYTE
7) Loop 1-6 for N conversions.
Actually, that confuses me even more. According to the diagram, there is sck activity DURING tDATA, which according to the verbage, it should only occur PRIOR TO tDATA. So what I'm getting here is that we can perform a convert, then get data after the conversion is complete, then perform another convert after receiving the data, and wait for the convert to complete (tDATA time) and continue in this way. No sck activity during conversion.
Most ADCs operate in such a way, that you first must perform an initial convert, THEN perform a second convert, and while that second convert is in progress, receive the data out the serial port which according to this data sheet is during tDATA.
In other words, every time a convert is started, it is considered tDATA time, and during any convert, there can be no sck activity. Yet, the timing diagram shows sck activity DURING tDATA. So, one is correct, and the other is incorrect.
Your explanation tells me that no SCK activity can occur during tDATA, which is DURING conversion, so conversion and data acquisition must happen serially, and not in parallel.
I see the disconnect now and I had misspoke in my response; I got caught up on the QUIET TIME indication in the diagram rather than looking at the tDATA portion. What I should have stated is.
The datasheet highlights the only restriction for reading during the conversion process is that the serial clock CAN only be active during the time, TDATA, to prevent corruption of the internal processes.
The datasheet should state that you may read data during conversion ONLY during the time period TDATA after CNV. I believe they were trying to describe reading prior to the expiration of TDATA but I can see how the chosen wording is confusing.
I will have the datasheet edited to clarify this statement. I apologize for the confusion and appreciate you bringing this to our attention.
Please do let me know if this makes the intended operation clearer or if you have any further questions.