# Choosing an FPGA based on ADC sampling rate

I have a project involving an ADC sampling at 500 MHz. I need to take this ADC data and boil it down into something a cheap CPU can process. I believe this is a good application for a low-grade FPGA, so I am trying to understand how best to approach selecting a specific FPGA device.

The math involved in the FPGA will be minimal. Basically, I need the 500 MHz sampling speed to capture the physical event, but the FPGA will be selectively discarding most of the samples. So I don't think I care about how many LUTs, cells, or RAM bits the FPGA has. I need relatively fast I/O, and I need it to be cheap.

How can I tell if one of the cheap FPGAs (example: Spartan-6) I'm looking at is fast enough to keep up with my ADC? For the purposes of the this question, assume the ADC has an LVDS connection. Two ADC chips I am considering are the AD9434 and the ADS5403. I'm trying to understand the minimum requirements to interface with an ADC of this caliber.

What dictates the limit on an FPGA's I/O communication speed?

What are the key datasheet parameters I should be paying attention to when looking for an appropriate part?

Note that this is an embedded application, so stringing together some dev boards can be effective to prove out chip performance, but ultimately this will be a custom design.

Also note that the final sampling speed for future work may differ, so I am interested in understanding and comparing key I/O parameters between FPGAs in general. Other applications may require 250MHz sampling, or 1GHz, or 1.5GHz. I want to understand the FPGA I/O bottlenecks so I can choose a cost-effective FPGA for whatever sampling speed may be required.

• If you already use an expensive fpga, maybe a cheap cpu can be upgraded to an expensive one? – PlasmaHH Oct 15 '18 at 20:46
• This is for a new PCB design; the baseline data capture device is a 2.5 GHz oscilloscope. We're trying to minimize overall cost, so, finding a way to do that while maintaining 500 MHz sampling is the challenge. – Chris Fernandez Oct 15 '18 at 20:50
• @JonRB: What the heck does "meta-hardening the input stream from the ADC" even mean? Why do you think that this would be anything other than a synchronous interface? – Dave Tweed Oct 15 '18 at 21:39
• High sample rate ADCs will generally be paired with an FPGA in the vendor reference design, one chosen to match whatever output scheme the ADC uses. You might eventually cost reduce this over the vendor choices but you should start by understanding how the reference design works. Also note that cheap solutions (ie, budget scopes) generally use a small number of moderate speed ADCs acting in turn rather than one super fast one; some of that is for the ability to divide the sample rate among channels, but also likely because moderate performance silicon in quantity is cheaper. – Chris Stratton Oct 15 '18 at 23:18
• @JonRB: Yes, all of those are issues, but those issues are exactly what the timing constraints on the interface are for, and the synthesis tools are very good at dealing with it. High-speed synchronous interfaces are done on FPGAs all the time. Heck, every evaluation board that includes external DDR SDRAM is handling data at the rates we're talking about here! – Dave Tweed Oct 16 '18 at 4:24

How can I tell if one of the cheap FPGAs (example: Spartan-6) I'm looking at is fast enough to keep up with my ADC?

There are many factors that determine how fast logic can run in an FPGA, most of the time you won't know until you put logic on the FPGA because the delays in the logic determine how fast the logic can operate. The way to check is the datasheet of each device, which is tedious. One thing for sure is no logic will run faster than the clock speed of the FPGA, and the logic will always run a bit slower (because of cascaded gate delays).

What are the key datasheet parameters I should be paying attention to when looking for an appropriate part?

The most important one would be the I/O that the ADC uses, high speed ADC's use trancievers most of the time, you'll need to make sure the transciever operates faster than the rate of the ADC, for example the spartian 6 datasheet has info on how fast the LVDS transceivers can operate:

Source: DS162 datasheet

Note that this is an embedded application, so stringing together some dev boards can be effective to prove out chip performance, but ultimately this will be a custom design.

Make sure you have the right equipment before attempting a very high speed design, you'll need at minimum a differential probe that runs 2x the frequency of your fastest I/O speed for troubleshooting. Make sure you know how to impedance match the traces. If you've never done high speed, I would not cut your teeth on this type of design unless you have a consultant or someone who has done it before around. If this is your first go around, and your running low quantity, I would buy an eval board and use that.

Another thing is there might be better ways to make your measurement than a 500MHz ADC, something like an SDR can go well past 500Mhz and be better for your application depending on the bandwidth

Instead of inventing a design from scratch, try to search for "Evaluation Boards - Analog to Digital Converters". Say, start with Digi-Key, and limit your search to 500 Msps products. Sort it by cheapest ones. The first item will point to a Renesas/Intersil reference board KMB001 for ISLA110P50 ADC. The datasheet shows "Spartan" on a fuzzy picture. Additional Google search for [Renesas KMB001 eval board] leads you to schematics, which reveals that the FPGA is just Spartan-3. The ADC reference will cost you $136, plus$324 for the FPGA card, hard to beat this price.

So, to literally answer your question, yes, Spartan-6 should be capable of getting 500 Mbps LVDS/SPI stream out of proper ADC.

To compare, Analog Devices uses an universal evaluation platform HSC-ADC-EVALCZ based on Virtex-4 for their mid-range ADC, which alone runs for ~\$700.

• I appreciate the information. I'm aware that one method of solving this problem is to buy dev boards, prototype, then iterate with cheaper components until the design stops working. I was hoping to find a more general case approach towards identifying those FPGA bottlenecks from the beginning, rather than guess and check. Maybe there is no such method? But it seems obvious that there should be SOME hard limit to how quickly a given speed-grade FPGA can be clocked with an external ADC... – Chris Fernandez Nov 6 '18 at 15:48
• @ChrisFernandez, general case will be qualified as "too broad" and out of scope of this site. Iterate until it fails is a wrong idea unless you plan to sell your product in millions. And there is no need to "guess and check", every ADC interface has certain timing parameters, and every FPGA has design limits for their GPIOs. So this is a regular engineering. I can assure you that the reference designs are done by seasoned engineers and usually under cost constraints, so they already "iterated" the design. Reinventing the wheel is generally not the right idea. – Ale..chenski Nov 6 '18 at 16:14
• I respectfully disagree. I'm asking about the general case of a specific design problem...namely, how to understand the GPIO limits of FPGAs and compare families of parts accordingly. You mention in the comment that these limits exist....what are they called? How do I find them in a datasheet? What other possible bottlenecks exist? How do I compare them across different vendors? That's exactly the sort of information I am looking for in an answer to this question. I don't need a specific FPGA or ADC recommendation; I'm trying to understand the general theory behind these design limits. – Chris Fernandez Nov 6 '18 at 17:38
• @ChrisFernandez, again, general theory of interfaces is too broad. Depending on interface (with clock forwarding or self-clocking), you might be looking for clock insertion delay, setup-hold times, or clock-data recovery if a dedicated SERDES can be used, signal jitter, data alignment accuracy, ability of internal FPGA PLLs to generate high enough clocks to handle fast pipeline, presence of dedicated dual-edge flip-flops in I/O pads, etc.etc. Too broad. – Ale..chenski Nov 6 '18 at 18:07

It is certainly possible to achieve 500 Msps with one of the low end FPGAs, but you are approaching the limits of those devices. You need to look at the maximum speeds of the LVDS in the data sheet and the maximum clock rate of the FPGA.

Meta stability is rarely an issue because the FPGA drives the clock of the ADC. You just need to be careful about timing violations in your signal integrity analysis. You definitely need to do a transmission line level analysis on the ADC data and clock lines. You usually run the ADC on the inverted FPGA clock. So the ADC update on the negative edge and the FPGA latches the data on the positive edge. However at those high speeds you may need to use a different offset due to the line delays.

A bigger problem will be achieving the 500MHz internal clock that you need for the ADC IO. You don’t need to run the entire FPGA on it, but even achieving this speed for the IO logic is a challenge. At these speeds counters larger than a few bits stop working due to the carry propagation delay.

The way I would do it is like this: ADC -> shift register -> RAM. You have a shift register for each ADC bit. You fill the shift register with a couple of samples and then you save them into a buffer, which runs at a slower clock rate. The shift register in effect concatenates samples.

You will need a counter to count the number of samples in the shift register before pushing the data onto RAM. As I said you won’t be able to use a standard counter due to the high speed, but you can use an LFSR. Due to the carry chain an LFSR can run at the maximum FPGA clock rate.

A big red flag I noticed is that you want to go even faster. At higher sampling rates it becomes quite difficult to interface directly to the ADC without SERDES. In such situations a popular course of action is to use ADCs with the JESD204B standard. Then the SERDES can do the concatenation of the data for you and the clock is recovered from the data.

• Just an FYI: I don't have any immediate plans to run faster than 500 MHz, but I am interested in understanding what would be required to run at higher speeds. So if I am given Future Sampling Requirement X, I have a rough idea how that will translate into FPGA requirements. Your explanation of the JESD204B standard and SERDES is appreciated! – Chris Fernandez Nov 7 '18 at 15:09

A general case answer would be: No, you won't find a low-cost FPGA that can communicate with an arbitrary ADC running at 500 MSa/s.

The FPGAs I've dealt with (mostly Intel Cyclone V/10 line) list a maximum speed for the Clock tree of ~400MHz. I/O pins on the same part are limited to 200 Mbps. That said, most new FPGAs have dedicated hardware at their inputs that can translate standardized LVDS/DDR lines into something the rest of the FPGA can handle. Without knowing the communication standard of the ADC, it's impossible to tell. You'll find what you need to know in the datasheet under something along the lines of "Periphery" or "Peripheral" performance. (See page 25 of this datasheet for an example)

One thing you could do is build and synthesize a simplified version of the design, and then run timing analysis to see if your selected FPGA can handle it.

EDIT: The question was updated to refer to two specific ADCs: AD9434 and the ADS5403. These both use an LVDS interface. In the previously mentioned datasheet, the LVDS hardware is listed as supporting up to 840Mbps for the fastest grade (C6) device. This is well within the 500MHz required.

• I've updated the question to indicate an assumed LVDS interface on the ADC. Can you elaborate on the dedicated hardware that the rest of the FPGA can handle? One of my concerns is whether I need the FPGA's clock tree itself to run at 500 MHz, or just the I/O. More information on this distinction would be very helpful! – Chris Fernandez Nov 6 '18 at 20:19