Proper 10-bit 100mhz parallel ADC interface

So as said, I've got a 10-bit parallel ADC which I want to run at 100mhz and I want to bring the samples properly back into a the FPGAs 100mhz clock domain (clk100). The FPGA sends a 100mhz output clock to the ADC and it sends back 10-bit samples and a return clock. The output clock is clk100 or derived from it.

So I'm synchronizing multi-bit data samples between clock domains that are identical in frequency. There is going to be a new sample every single clock and the data is used in a real-time feedback loop where low latency is desirable.

This isn't rocket science and I'm generally aware of domain crossing techniques but am looking for other opinions on the best choice for this particular application.

Its also theoretically possible to tune the phase (one way or another) of the output clock to guarantee that the return data can be sampled by my main 100mhz clock, although I've initially ruled this out as unwise for a 100mhz bus with only 10ns to work with.

Thoughts?

asdf44 said:

So as said, I've got a 10-bit parallel ADC which I want to run at 100mhz and I want to bring the samples properly back into a the FPGAs 100mhz clock domain (clk100). The FPGA sends a 100mhz output clock to the ADC and it sends back 10-bit samples and a return clock. The output clock is clk100 or derived from it.

Click to expand...

run everything on the clk100 (ADC return clock) instead of your 100MHz output to ADC clock. That will probably be the easiest way to avoid clock domain crossings, that is as long as the ADC always generates an output clock (you didn't give an ADC part number or anything).

asdf44 said:

So I'm synchronizing multi-bit data samples between clock domains that are identical in frequency. There is going to be a new sample every single clock and the data is used in a real-time feedback loop where low latency is desirable.

Click to expand...

not a very well defined requirement, what is "low" latency 1 clock 10 clocks? 0 clocks? What is the actual requirement?

asdf44 said:

This isn't rocket science and I'm generally aware of domain crossing techniques but am looking for other opinions on the best choice for this particular application.

Click to expand...

well you could just add an asynchronous shallow FIFO or register file. and start the reading of the FIFO with hysteresis say don't start reading from empty until there are 2 samples in the FIFO. Once you start reading there will never be less than 1 sample in the FIFO/register_file.

asdf44 said:

Its also theoretically possible to tune the phase (one way or another) of the output clock to guarantee that the return data can be sampled by my main 100mhz clock, although I've initially ruled this out as unwise for a 100mhz bus with only 10ns to work with.

Thoughts?

Click to expand...

Another option is to add a training mode to attempt to align the clock phases on the fly periodically to account for any drift due to thermal, voltage, and process (between units) differences.

ads-ee said:

run everything on the clk100 (ADC return clock) instead of your 100MHz output to ADC clock. That will probably be the easiest way to avoid clock domain crossings, that is as long as the ADC always generates an output clock (you didn't give an ADC part number or anything).

Click to expand...

Well right now I have a DCM taking in a crystal and putting out 3 clocks of which the 100 is one and I'm relying on its constrained phase lock to a second output. I get what you're saying and could do it if I used one DCM to generate the 100 out and then used the returned 100 as my main internal 100 and fed it to a second DCM to generate my other two clocks (of which one will have constrained phase lock to this 100).

For some reason I've never like the idea of putting the ADC in series with my main FPGA clocking scheme but I guess there isn't a strong reason not too.

not a very well defined requirement, what is "low" latency 1 clock 10 clocks? 0 clocks? What is the actual requirement?

Click to expand...

Well I haven't had time to define it yet but 4 is probably good and I imagine 10 would be fine.

well you could just add an asynchronous shallow FIFO or register file. and start the reading of the FIFO with hysteresis say don't start reading from empty until there are 2 samples in the FIFO. Once you start reading there will never be less than 1 sample in the FIFO/register_file.

Click to expand...

And in this case where frequency lock is guaranteed would you bother sending a synchronized pointer across domains in a FIFO implementation? It seems that if an enable is properly sent across the domains both sides can theoretically free-run on a circular buffer while safely avoiding each other.

Another option is to add a training mode to attempt to align the clock phases on the fly periodically to account for any drift due to thermal, voltage, and process (between units) differences.

Click to expand...

And what hardware does this? Memory controller? DCM? Specifically I'm using an Artix.

Hi,

For some reason I've never like the idea of putting the ADC in series with my main FPGA clocking scheme but I guess there isn't a strong reason not too.

Click to expand...

My recommendation:
* Generate a 200MHz FPGA clock...as general FPGA internal main clock source.
* from this clock generate a (divided) 100MHz clock to supply the ADC.
* Use the ADC_return_clock for the first input DFF inside the FPGA
* then do the clock domain crossing

There is a good reason why the ADC returns the clock. It has a fixed (ADC controlled) timing between this clock and the data.
But the total clock delay depends on FPGA_output_delay + signal_runtime + ADC_delay + eventual_buffer_delay + FPGA_input_delay.
The 200MHz clock eases and makes clock domain crossing more reliable in case there the return clock is delayed by about 10ns.
Choose either the odd or the even 200MHz clock edge (depending on clock delay) for clock domain crossing, to avoid that sync_clock_edge meets return_clock_edge.

Klaus