How does CLKOUT works on the LTC2323-12 ADC on "High-speed" speed mode?

Question

http://www.farnell.com/datasheets/1833817.pdf

I was assigned a task where I have to connect an LTC2323-12 ADC (analogic to digital converter) to an FPGA.

Reading the LTC2323-12 datasheet seemingly it has two ways to be controlled. One way is through the SCK (clock-like) input that cycle by cycle shift the ADC results out of the ADC to SDO port.

The other way is described as a "high speed" that can "ease the timming requirements for the FPGA" (would you clarify this for me?) , this last one method is trough the CLKOUT signal, which is seemingly a Clock that comes out of the ADC that is matching (or latching) the ADC results out of the SDO port. Is that correct? Did I get it correctly?

So do I have to design the FPGA module in order to output the CNV signal of startup, then keep it for TCNVH nanoseconds, then release it, then just wait until ADC AUTOMATICALY send the first CLKOUT, so I can register it and count 11 more of these CLKOUT, while passing the SDO data out to my own registers on each of these CLKOUT cycles?

Then after the last 14 CLKOUT clocks, I must design a counter that trigger a valid signal that will start another counter of TDSCKLCNVH nano seconds, and at the same time porting out of this register register and a "Finishing" signal (so another top module with the same clock than my fpga module, can make use of these signals in another moment.

I would like you to correct me if I misunderstood something about the behavior of the LTC2323-12 ADC and the way to approach it. Thanks in advance.

Answer 1

The other way is described as a "high speed" that can "ease the timming requirements for the FPGA" (would you clarify this for me?) , this last one method is trough the CLKOUT signal, which is seemingly a Clock that comes out of the ADC that is matching (or latching) the ADC results out of the SDO port. Is that correct? Did I get it correctly?

Yes, that is correct. Your data receiver can use CLKOUT to latch the data coming from the ADC. The CLKOUT signal and the data out can be delayed by PCB tracks feeding the FPGA (receiver) and if both are created at the ADC and generally routed along similar paths to the FPGA then they will remain in sync no matter whether it's millimetres or several centimetres between ADC and FPGA.

The SCK line comes from your FPGA and if it was used to latch in your digital data then there is a clock delay going to the ADC and a delay to the data coming back and this can mean (on longer PCB tracks) that you won't latch clean data.

So do I have to design the FPGA module in order to output the CNV signal of startup, then keep it for TCNVH nanoseconds, then release it, then just wait until ADC AUTOMATICALY send the first CLKOUT, so I can register it and count 11 more of these CLKOUT, while passing the SDO data out to my own registers on each of these CLKOUT cycles?

Yes, to get optimum high speed performance on longer PCB tracks.

Then after the last 14 CLKOUT clocks, I must design a counter that trigger a valid signal that will start another counter of TDSCKLCNVH nano seconds

Yes, according to the timing diagram above (which I've also added a few minimum timings to).

Answer 2

This device requires a pretty fast interface clock for sustained 5 MS/sec performance.

I am reproducing the timing diagram so I can talk through it:

CNV (as you correctly state) kicks off a conversion and must be held high long enough for the internal samplers to acquire the signal; 35 nsec in this particular case.

You must then wait SCK quiet time from CNV going low (10 nsec) before driving SCK to the ADC.

You then are required to drive SCK 14 times to move the data out; the key here is that CLKOUT is an output version of your SCK that is aligned to the output data so you do not have to concern yourself with round trip timing skew.

You do need to drive SCK to the ADC; if you are driving quite fast, then your output SCK at T0 will arrive at the ADC at some time T0 + x and the data will arrive back at you at T0 + 2x + data delay and your FPGA may well get invalid data.

Looking carefully at the datasheet, Data Out appears on the ADC pins no later than 2 nsec after SCK in, and CLKOUT will appear no sooner than 2.5 nsec after SCK.

That means that the clock you receive (assuming matched track lengths) will arrive back no sooner than 500 psec after the data from the ADC; that is probably easily within the setup time of your input (this could be used to form a timing closure rule).

(I have had to play software games with some of the LTC ADC interfaces as they can be a little unusual on occasion)