FPGA Data Collector - What Specs Should I Look For? [closed]

Question

I'm working on a high-speed data collection device for an ADC running at 80 Msps. After digging through resources on MCUs and asking several questions here and in other forums, I've turned my attention to FPGAs. From what I understand, an FPGA-based circuit would be the fastest method to collect data from a series of inputs and store that data. The event I'm trying to capture will be relatively short and can be set up with a trigger, so I'm thinking of sending data to SDRAM during the event and extracting it later via USB or some other interface. The ADC I'm using is the MAX1448, which provides a 10-bit parallel output with each clock cycle at 80 MHz (with a pipeline delay of ~5.5 cycles).

When looking at MCUs, I gathered that for each input pin, instruction cycles were needed to send that bit from the GPIO to DMA or other peripherals. So just to execute one instruction for each bit, I needed a clock speed at least 10x my ADC sample rate. From what I understand, FPGAs get around this bottleneck by programming the data path beforehand. My question though, is what should I be looking for in a FPGA in order to store ADC data at a specified rate with a set number of bits/inputs? How does the clock speed of a FPGA determine the data transfer rate, or what clock speed do I need to look for to achieve 800 Mbps (or 10 data paths at 80 Mbps each)?

Answer 1

Not necessarily you need 10 times the sampling clock for the core logic. First of all, the FPGA, by definition, is a huge sea of logic gates and everyone works in parallel to the others.

So while in an MCU you'll have, say:

1. Set up the acquisition
2. Wait for data
3. Read the data
4. Do some calculation
5. Write the data to the memory

These would be like 5 steps to be done sequentially.

Now, in a gate array you would declare a module talking to the ADC which does steps 1-3 (a state machine), another module which does the computation (step 4) and yet another one that stores data into the memory (step 5) (I'm greatly simplifying here)

These three block now can work in parallel, not only strictly in sequence as in an MCU. So while the ADC module reads data, the computer can do the calculation on the previous value and at the same time the memory interface can store the previous-previous value. The technical name for this is "pipelining".

As for the required clock depends on your converter interface: if it has some parallel output you only need do implement the parallel circuitry (10 bits data paths and so on), clocked at 80MHz. If your output is serial (something like a JESD204 interface, con pump gigabits on the wire) you will have, as you tought, an 800Mbps bitstream but many FPGA (maybe not the very low end ones) have special circuitry that interfaces with these automatically. Look for 'SERDES' in your spec sheet, when choosing the FPGA.

This is what you called 'declare the data path' in advance, it's actually an hardened interface block.

It's quite complex in details but, in short, you attach you serial stream, declare a "gearing ratio" and logic inside will see a parallel port at 80 MHz.

So while the outer clock will be high, the fabric will only need to go at, like, 160 MHz (there will be some dead time, wait for memory bus cycles, handshaking and so on).

EDIT Woe on me. I didn't read you part number, sorry. Your Maxim is a parallel output converter. Any FPGA these days can interface with it, just declare the parallel logic. However if you want to use SDRAM you'll need an FPGA with a suitable interface.

Take notice that all FPGAs have a (small) amount of onboard RAM, if your events are short you could do without external memory.

Answer 2

Forget about the FPGA. The i.MX RT1060 processor used on the Teensy 4.1 mentioned in your previous post is perfectly capable of handling your 80 MHz, 10-bit parallel data all by itself.

The 3437-page reference manual (additional documentation here) for this chip is quite daunting, but take a look at chapter 34, "CMOS Sensor Interface" — specifically, section 34.5.3 ""Non-Gated Clock Mode", which explains how to capture large frames of data.

I doubt that you're going to find much in the way of preexisting library code for this peripheral, so you're going to have to get down-and-dirty with programming it yourself. You'll also need to get familiar with the Clock Controller Module (chapter 14).