Spec-ing ADC to interface with FPGA

[abquke]

So supposing one has a specific FPGA in mind for a design, an ADC is going to be connected to FPGA, and the requirements of the ADC are basically "at least N-bits, this or that kind of input, but as fast of sample rate as the FPGA will reliably allow". Do I look at the "x to output" setup time on the FPGA datasheet and add a bit of wiggle and compare that to an ADC datasheets "I need x time to set up output"? Or are there more subtle constraints to worry about before max possible I/O is a thing?

[nvmR]

Hey OP,

I would probably spec it according to an interface, say SPI if a high rate ADC is being discussed.
Then, looking at available IP-cores for the relevant interface, I would look at the rate supported, and at the maximal fabric frequency to see that this is in the ballpark.
From there, I would take a look at the requirements in terms of data output, as we are probably interested in taking the ADC data out of the FPGA in some way - say a UART/ethernet etc.

Even more generally, try to use the simplest FPGA you can get away with, and if possible single supply.

[pcprogrammer]

There is a wide array of things to consider.

What does the FPGA have to do with the data. Store it to memory inside the FPGA or memory attached to the FPGA. Is there an external CPU controlling the FPGA and does it need to do real time processing on the data, or does the FPGA have to do real time DSP processing on the data, and so on.

There are fast n-bit ADC's that use one or more serial lanes that can reach higher speeds then ones with CMOS based parallel buses to go beyond the maximum "external" io speed of the FPGA making it a fully internal matter.

[abquke]

The FPGA will do some DSP and one way or another reduce the data bandwidth going on to a CPU.

The more I have to put into words, the more I'm finding that I'm trying to capture all the possible use cases for ADC->FPGA->CPU rather than "Make a thing that does x"...

[pcprogrammer]

Well then the thing is to determine which of the interfaces is the slowest and use that as a starting point to select the ADC to use.

If, for instance, the CPU interface can only handle lets say 25MSa/s and the DSP is capable of reducing the data quantity by 20% the ADC only needs to deliver 31.25MSa/s. Then having found this value you check if the ADC -> FPGA interface is capable of handling this speed.

[Someone]

The more I have to put into words, the more I'm finding that I'm trying to capture all the possible use cases for ADC->FPGA->CPU rather than "Make a thing that does x"...

Yes, as:

the requirements of the ADC are basically "at least N-bits, this or that kind of input, but as fast of sample rate as the FPGA will reliably allow

the question is very wide space. To take it to the extreme you would reserve ALL the io pins and run them at the fastest bit/symbol rate they allow (possibly using another FPGA to re-arrange the data into the most efficient packing/format for the endpoint FPGA, there are volume products doing just this!). Does the "customer" really want a 120GS/s ADC? there are probably other constraints in cost and functionality.

In more general you'd get a list of ADCs and their interfaces, then pick the one that fits within the pin+frequency limits of the endpoint FPGA.

[radiolistener]

The FPGA will do some DSP and one way or another reduce the data bandwidth going on to a CPU.

it depends on what DSP you're want to do. For example if your ADC running at 100 MHz clock, most FPGA will be unable to apply 1024 tap FIR filter at full speed, because there is a lack of hardware multipliers and FPGA speed limitations. So, you will needs to use CIC filter before FIR filter in order to reduce computation cost. It will add some limitations on DSP dynamic range, signal purity and frequency selection. You're needs to know your DSP structure to estimate your needs.

Also it very depends on ADC dynamic range. Since high dynamic range ADC needs more bits for processing, your FPGA will needs more resources to implement DSP blocks. For example I'm using 14-bit ADC running at 100 MHz, and CIC filter that I use needs to use 86-bit registers and more in order to avoid overflow.

Usually DDC/DUC DSP eats about 5-20 kLE (depends on your needs). Also you will need some high speed interface, like GMII, so you're needs to add about 3-5 kLE for GMII, ARP, DHCP and UDP stack implementation.

Also, note that different ADC using different output interfaces (serial/parallel, different logic levels standard), so make sure your FPGA is compatible with ADC output and can handle it with no limitations.