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)?

  • 1
    \$\begingroup\$ how much data are you planning to capture after the event (at most)? This will dominate the complexity of a suitable solution. \$\endgroup\$ Feb 13, 2021 at 17:00
  • \$\begingroup\$ From what I understand, FPGAs get around this bottleneck by programming the data path beforehand. One could put it that way, yes, but it's really more that you define the hardware: realize that FPGAs are essentially like very large boards where you can plug together arbitrary logic elements. When designing a solution for an FPGA, you're doing hardware design. \$\endgroup\$ Feb 13, 2021 at 17:58
  • 2
    \$\begingroup\$ I think the Red Pitaya can do what you want, but you should double check the specs. \$\endgroup\$
    – bobflux
    Feb 13, 2021 at 18:35
  • 1
    \$\begingroup\$ by the way, an FPGA doesn't have "a clock rate". It's hardware you design, so you design the data path, and assuming that path is clocked, that means you define the clock rate – and since you can do arbitrary things, it's not clear what you expect us to answer here. Different parts of your FPGA design will run at different rates (especially if you should actually use SDRAM, which I maintain is probably not a great idea here unless you can explain why). Considering that confusion, and as you still haven't defined how much data you want to capture: Vote close as in need of clarity. \$\endgroup\$ Feb 13, 2021 at 18:55
  • 1
    \$\begingroup\$ You might want to look at PYNQ which might lower the learning curve for you. \$\endgroup\$
    – Kartman
    Feb 14, 2021 at 7:22

2 Answers 2


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.

  • \$\begingroup\$ Thank you for your explanation, it does help me get a clearer picture of how FPGAs operate and the difference from MCUs. So if I have a port operating at 80 MHz, does each connected logic gate operate from that frequency as well? Or should I look at it as a port that reads on a rising edge and sends the data to the next "stage" on the falling edge? I realize it is likely much more complex than this, but trying to get some idea of how the FPGA cycles through the input data \$\endgroup\$ Feb 13, 2021 at 21:40
  • 1
    \$\begingroup\$ With a fpga you're spoilt for choice. You can clock your logic at 80MHz, or you might run a much higher internal clock and only clock the data in at 80MHz. Realistically, reading the adc is the least of the problems - you need to put the data somewhere - that is where the crux of your problem is. Something like a Teensy4 can easily read the adc data - but it has limited ram and by limited, let's say 512k bytes. Is this sufficient for your requirements? \$\endgroup\$
    – Kartman
    Feb 14, 2021 at 0:37
  • \$\begingroup\$ @scpaulson42 The FPGA doesn't "cycle through the data" by itself. An FPGA in itself is just a meaningless "sea of logic" (I like that metaphor) without any functionality before you define how the hardware looks like. Your comment is still assuming an FPGA is a fixed-functionality thing that can be programmed like a CPU. It's not. It's a hardware to be designed by you. You design all the hardware. All the data processing is done how you define the logic should work. Please read up a bit more on what FPGAs really are \$\endgroup\$
    – mmmm
    Feb 14, 2021 at 0:52
  • 1
    \$\begingroup\$ Well the problem there is that FPGAs are usually used to give you exactly that kind of freedom, @scpaulson42: your ADC interface needs to run at the ADC rate, sure, but after that you can do things like move the samples to a much higher clock domain of your own definition, if that suits your needs. For example, if you actually want to use SDRAM (don't!), then you'll have to do that: due to the burst nature of SDRAM transfers, and the need for refresh "pauses" in data flow, you'll need to transfer data at higher rates than your ADC produces them at when you can, so that the average works out. \$\endgroup\$ Feb 14, 2021 at 10:26
  • 1
    \$\begingroup\$ I really think, however, that thinking about clock rates takes you down the wrong road there: It's not something you can select an appropriate FPGA by! The maximum rate an FPGA design (Notice how I avoid the word "programming here"; it's really more of a layout than a program) can run at is not defined by the FPGA (alone), but by your design and how much you try to do within a single clock cycle. Combine that with the inherent ability to have multiply dependent or independent clock domains, and you'll see how meaningless it's to ask for clock rates. \$\endgroup\$ Feb 14, 2021 at 10:29

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).


Not the answer you're looking for? Browse other questions tagged or ask your own question.