0

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

scpaulson42
  • 79
  • 5
  • 1
    how much data are you planning to capture after the event (at most)? This will dominate the complexity of a suitable solution. – Marcus Müller Feb 13 '21 at 17:00
  • *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*. – Marcus Müller Feb 13 '21 at 17:58
  • By the way, you might want to react to the answers you got to your pretty related previous question (by downvoting, or acception, or upvoting, or asking for clarification). People there explained why SDRAM is problematic here, and you don't even mention that in your question here, so I'm not sure you've made good use of the time we spent on writing answers. – Marcus Müller Feb 13 '21 at 18:01
  • 2
    I think the [Red Pitaya](https://www.redpitaya.com/) can do what you want, but you should double check the specs. – bobflux Feb 13 '21 at 18:35
  • 1
    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. – Marcus Müller Feb 13 '21 at 18:55
  • I used SDRAM in this case as more of an example case, and I am looking into the "proper" memory structure to use for my application. For right now, I'm just trying to get a better understanding of what I'm looking for in a FPGA at the chip level. The amount of data per event will be relatively low, sampling at most 100,000 points for 1.0 Mbit or 125 kB of data for one event. – scpaulson42 Feb 13 '21 at 21:29
  • For that little amount of data, sdram is the wrong choice. End of story - FPGA with sdram controllers have more built in SRAM block memories than that, which is way better suited... Multiple people have seemed to try to explain this to you... You're not looking for anything to talk to sdram, really. You're looking for an FPGA that has enough internal block RAM. You need quite a bit of internal buffer anyways - as others have told you in your previous question, sdram is unsuited for continuously clocked operation and needs refresh cycles, during which you need to buffer your incoming samples. – mmmm Feb 14 '21 at 00:43
  • 1
    You might want to look at PYNQ which might lower the learning curve for you. – Kartman Feb 14 '21 at 07:22

2 Answers2

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.

Lorenzo Marcantonio
  • 8,231
  • 7
  • 28
  • 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 – scpaulson42 Feb 13 '21 at 21:40
  • 1
    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? – Kartman Feb 14 '21 at 00:37
  • @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 – mmmm Feb 14 '21 at 00:52
  • @Kartman Funny you mention the Teensy4, as I was looking at the Teensy4.1 as a central device. After talking with people on the Teensy forums, it didn't seem like it would work without significant overclocking. Hence the pivot to fpga – scpaulson42 Feb 14 '21 at 02:56
  • @mmmm I understand that the fpga has no function without being defined by my programming. In my comment above, I'm looking at a hypothetical situation in which I have defined the path for the data to follow. Essentially, I'm trying to get a sense of what the limits are, and how the "programming" may affect the timing of the system. – scpaulson42 Feb 14 '21 at 03:03
  • 1
    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. – Marcus Müller Feb 14 '21 at 10:26
  • 1
    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. – Marcus Müller Feb 14 '21 at 10:29
  • @MarcusMüller This is really helpful, both in giving additional information about the drawbacks of SDRAM and in the operation of FPGAs in general. Especially for someone like me who is still thinking in terms of "instructions" for a processor rather than a flexible layout in a FPGA. – scpaulson42 Feb 14 '21 at 15:16
  • @scpaulson42 Here's a number for you: I know my cheap Artix-7 board can handle at least 200MHz clocks (just incrementing a counter to flash an LED). Haven't tried faster. It also has 8:1 SERDES units (useless on this particular board, but different Artix-7 chips can use them) so it can probably read serial data at least as fast as 1600MHz. 20MHz data processing should be no sweat. YMMV depending on the logic you write though. You can't guarantee anything before you actually test it out in the real world. – user253751 Feb 16 '21 at 18:01
0

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

Dave Tweed
  • 168,369
  • 17
  • 228
  • 393