They for sure have a future. But imho the main usage scenario for FPGAs is not the acceleration of things which are otherwise run on CPUs and GPUS.

I think one of the main values of FPGAs when you need custom hardware/"glue" between other chips, because you e.g. need to connection 30 I²S connections to your application processor or need to handle multiple video streams with different formats for which no custom IC exists. That's for sure niche applications, but lots of these products reach 6digits of sales. The other usecase is when you need superhard-realtime behavior, which means things should work exactly synchronously to a hardware clock. E.g. I used it back at university for radar systems, but there are also lots of applications around telecomms, networking and audio/video processing and transmission. These are often low to medium volume products, where custom ASICs are not lucrative or updateability is required. Afaik custom ASICs also got more expensive over time through higher process costs, so you need a higher volume to justify it instead of going for FPGAs.

and here is an example of exactly that sort of application:

http://accelconf.web.cern.ch/AccelConf/ICALEPCS2013/papers/t...

Ah someone that's actually used them eh :) ? My experience is the same.

People have this impression that they're being used for all this exciting stuff when the average FPGA is because you need some multiplexing on IO lines and you're not running a RTOS. Basically using them in place of what would be software if your micro was better suited to your application

They've grown beyond prototyping a long time ago. They are full featured SoCs with great flexibility that fill niches where CPUs, GPUs, ASICs can't compete in flexibility/power consumption/development cost.

- ASICs are too rigid and require high volumes to be profitable

- GPUs are too power hungry

- CPUs are not good for massively parallel processing

FPGAs are heavily used in industrial/military/aerospace applications

If you think GPUs are too power hungry then you're in for a shock with FPGAs. Switching FPGAs are incredibly power hungry since they run on much larger processes.

FWIW most modern FPGAs use discrete DSPs anyway so you're not really getting the flexibility at that level.

The processes used for FPGA are VERY competitive with GPUs. Stratix 10 is at 14nm, for example. Stratix V was built using 28 nm process and that was at least 5 years ago - on par or exceed NVidia.

You can fuse more operations into DSP using FPGA and/or you can perform less operations per FLOP. One example is to avoid rounding and packing/unpacking when creating deep pipelines for floating point processes.

Cheapest Stratix V I can find on digikey starts at ~$1,800 and quickly goes up to $10k for the bare chip in quantities of 24.

For open source hardware I doubt you'll see people shell out the cost of a used car to be able to match modern ~$200 GPUs.

I don't even what to know what Stratix 10 starts at.

The complete devkit solution is about $7K - https://www.altera.com/products/boards_and_kits/dev-kits/alt...

The Xeon Phi board https://www.cnet.com/products/intel-xeon-phi-coprocessor-712... is $4.2K..$5K

The Stratix V board will not consume more than 60W when used as PCI Express card. The requirements for Xeon Phi is at least 250W.

With a difference of ~200W, there will be difference in ~4.5kW/h per day or ~1600kW/h or $160 in hard cash per year (US average). Very probably more - getting rid of heat produced, etc.

Wow. These things just scream military use. My guess is phased array radar.

I worked on a space based imaging radar which used an FPGA. It cost mid 6 figures per chip...

This was admittedly a space certified radiation hardened chip. Still alarming when you had to pick it up and carry it somewhere

> Switching FPGAs are incredibly power hungry since they run on much larger processes.

I don't think the comment about process is really true, from what I can tell, Xilinx is only a few months behind the biggest SoC makers in terms of its process adoption, and is shipping 14nm parts currently. Not sure about Altera, but they are on Intel's process, which is bit ahead of the competitors anyway.

In terms of switching power, you definitely pay a penalty to have the reconfigurability in hardware, but on the other hand you don't have all the unused logic that you would on a GPU. I'd guess the comparative efficiency depends on the specific problem and specific implementation, but I don't have any numbers to back that up.

It's a couple things, process is a large part. You're also dealing with 4-LUT instead of transistors so you pay both in switching power and leakage since you can't get the same logic-to-transisitor density that's available on ASICs.

Also there's a ton of SRAM for the 4-LUT configuration so you're paying leakage costs there as well.

Tell me more about leakage.

NVidia managed to get it right about year and half ago. Before that their gates leaked power all over the place.

The LUTs on Stratix are 6-to-2, with specialized adders, they aren't at all that 4-LUTs you are describing here.

All in all, there are places where FPGAs can beat ASICs. One example is complex algorithms like, say, ticker correlations. These are done using dedicated memory (thus aren't all that CPU friendly - caches aren't enough) and logic and change often enough to make use of ASIC moot.

Another example is parsing network traffic (deep packet inspection). The algorithms in this field utilize memory in interesting ways (compute lot of different statistics for a packet and then compute KL divergence between reference model and your result to see the actual packet type - histograms created in random manner and then scanned linearly, all in parallel). GPUs and/or CPUs just do not have that functionality.

The Arria 10 (previous high-end Altera series) was at 20nm. The new Stratix 10 is at 14nm. UltraScale+ is in the 14-20nm range, I think, and Xilinx got there first.

(I don't know if you can publicly get Stratix 10 devkits yet, but you can get an Arria at least.)

Achronix had production Speedsters at 16nm in 2016. They should be on that list given they're 1.5GHz or sonething like that.

The unused logic part isn't exactly true. The way FPGA's are built doesn't allow for unused sections to be completely shut off. Instead of dark silicon it's more like grey silicon. The unused parts of the chip still use substantial power, unlike ASIC where these unused portions simply wouldn't exist

Not my personal/professional experience. Even with heavy DSP usage with nodes >14nm you can still create designs with lower than 30 W power consumption, since you can control the frequency and use low power design techniques. There are vendors like Microsemi/Lattice that specialize in low power FPGAs where you can do even better

So there might be specific products that hit certain market segments(FWIW I really like Lattice's offerings). It's just that Watt to Watt GPUs should be more efficient since they can use the latest process and don't have to carry around 4-LUT + SRAM.

On the DSP side, you're using a ASIC DSP(can't change the width for instance) anyway on most modern FPGAs so you're comparing ASIC to ASIC at that point.

Designing an ASIC with low power in mind will always beat an FPGA, no question there. But the design cost is prohibitive for many applications (not to mention the lack of flexibility to re-iterate/patch your design with little to no cost). But compared to GPUs I'm fairly certain you can do much better power-wise going with an FPGA. You have finer control over your frequency, over which sections to power down, how often to switch, etc.

Of course you can get better price/GFLOP with GPUs + quicker time to market

And yet they (GPUs) aren't (better for FLOP/watt than FPGA) everywhere.

GPUs have very particular cache and computation hierarchy which is not necessarily a best/good fit for all problems that are being thrown at them.

FPGAs are typically used as the some of the first non test chips for a new process due to their fairly regular structure.

And it's a valid use-case for putting a lot of SRAM on a chip.

That's really interesting

Agreed!

Just being a SoC has another advantage: reduced part count, so you can fit more functionality onto a smaller PCBA.

Another commenter mentioned the Cyclone V and Zynq SoCs. My day job is in the telco industry. The equipment vendors we sell to are always pushing for higher and higher densities in their chassis and line cards, and it drives a lot of our design decisions. Chips like the Cyclone V and Zynq help a lot in achieving those aims. Our PCBAs have shrunk dramatically (with increasing functionality) over the last decade.

The continual pressure to reduce costs and power consumption also leads to choices like minimizing the other available system resources (e.g. clocks, memory bandwidth, RAM, flash), which can end up reducing the effectiveness of a GPU.

As with everything in engineering, there are many different problem domains, each with unique constraints dictating different solutions.

You would need to compare performance per watt for your particular application. If you just read the Box, a GPU uses 250 Watts, while an FPGA is tens of Watts. But then consider that you are getting a large amount of very high speed memory and much higher clock speeds. Then once you take that into account, you can begin to start analyzing which is better for your project.

Sometimes they're good for "need ASIC-like results in a low-volume design" but that's more a special case of what you give, and of course the 'upgradable glue logic' case also is in play.

I think the killer application would be to have programatically reconfigurable FPGAs that reconfigure on the fly to fit the needs, which has been discussed in various overhyped ways in the past, but I don't think the tooling is there. This effort might or might not make that possible -- imagine a chip where, say, the regex you're going to use to scan 1GB of data could be turned into an FPGA and then it just shovels the whole thing through a "HW" FIFO that detects matches much faster than a processor could. Nifty... but is it worth the effort to do?

This is what I've used them for.

Low volume design as in thousands of chips a year rather than millions. Or cases where reprogrammability greatly improves the ability to provide fixes and improvements in the field as a part of very expensive support contracts.

You can kind of do this now if you want. The SOCs like the Cyclone V or Zinq have an arm core or two surrounded by FPGA fabric. The only barrier right now would be the dynamic reloading of the FPGA which I haven't seen done, but would be simple in principle (as opposed to having a soft core that would likely have it's state interrupted if you re-flashed everything)

Most newer Intel (Cyclone and beyond) and Xilinx (-7 series) support various levels of partial logic reconfiguration. If you plan your device layout right, you can simply reprogram a region of fabric that is hardwired wired to the 'shell' of your system (which is connected to the peripherials). If you have setups like Vivado's SDSoC/high-level synthesis, you can do things like dynamically reconfigure OpenCL kernels, etc.

Of course, the problem is synthesis, verification, testing etc is all rather difficult in practice and takes a long time. The boards themselves also can't do synthesis/compilation, obviously, since they're fairly limited and it's a time-consuming process. You'd have to make it act more like an OTA update system, but that comes with a lot of its own problems...

this is possible today. check out the digilent pynq ( www.pynq.io ). i just bought a dev board, i'm pumped to try a few things out.

I really wanted to get that board - but the price difference between academic and regular users was a bit too much given this was coming out of my own pocket (I ended up buying used FPGA dev boards from ebay, etc.).

I recall there was a lot of excitement around the Pynq. Has anything notable been done with it yet?

FPGAs are a useful means of accelerating any algorithm where you want more performance than you would get from executing it on a CPU, but can't afford to create your own ASIC because the volume is relatively low. For example, it may be used in DSP applications for things like radar. This use as a reprogrammable accelerator is also why Amazon has introduced instances with on-board FPGAs to AWS.

Also worth noting that for real time control you can't beat the speed. Essentially, everything you do on an FPGA happens at the same time. You could see a 1000 line Verilog file that completes a huge operation in a handful of cycles.

Also note that "speed" includes latency, and not just low latency but also deterministic. You can do things like adjust a timestamp or tweak a control equation knowing that a sample has been delayed through an N-stage pipeline/filter that advances at M hertz.

Yea, I misspoke there. %s/speed/latency/

Certain industries (esp nuclear) really like them because they can "prove" the set of attainable states in the FPGA.

Exactly.

There is an algorithm for detecting bursts of unusual activity which is extremely well suited for FPGAs: http://www.cs.nyu.edu/cs/faculty/shasha/papers/burst.d/burst...

Basically it is a tree of registers with checks. It can compute burst position and duration in the O(log(window size)) time (clocks). You look here at 2.5..5ns (200MHz..400MHz) multiplied by log2(window size) - 25..50 ns for window with 1024 samples. You just cannot get that kind of connectivity with CPU/GPU. Processing these samples in CPU will get you into several hundreds of ns, if not more.

>I'd go learn FPGA dev then if there were things that needed accelerating and were personally lucrative to me

HFT

Heat (and as a result: size), power generation and cost.

There are plenty of problems where, sure, you could get an x86 or a powerful GPU and do it faster, but you'll be paying for it with power usage.

E.g. take [1] - they're making a modern M68k compatible CPU in an FPGA. They're getting performance that's beating ASIC ColdFire CPUs (Motorola/Freescale's M68k descendant) and ASIC PPCs with several times the clock, and beating the fastest "real" M68k systems by a factor of 3x-10x.

You could beat that with a software emulator on a powerful enough x86, sure. Easily. Especially if investing enough time in dynamic translation and the like.

But this thing instead fits on a far less power hungry FPGA that gives off far less heat, and fits on a board that'll fit in one of the real small case Amiga's - try to do that with a x86 with heat sink..

[1] http://www.apollo-core.com/

The Apollo core only has a market because Amiga fans are willing to pay a premium in price, complexity, heat and reduced performance to use something other than ARM or x86. I wouldn't be surprised if software emulation on a low-power, cheap ARM core could beat it; JIT on a powerful x86 is apparently 5-7x faster. It's also the exact opposite of open source, being a proprietary core tied to a single-source commercial boards.

> The Apollo core only has a market because Amiga fans are willing to pay a premium in price, complexity, heat and reduced performance to use something other than ARM or x86.

Heat? Really? A modern x86 with a heatsink won't physically fit in the cases these boards go in. To be viable these cards must run cooler than the alternatives - that's part of the point.

> I wouldn't be surprised if software emulation on a low-power, cheap ARM core could beat it; JIT on a powerful x86 is apparently 5-7x faster.

The current boards are kept cheap - they're nowhere near using the fastest available FPGAs, and the cores keep making massive performance leaps iteration to iteration and have been tested and works on FPGAs more than twice as fast as the ones on the current Vampire boards. The publicly released cards are now beating ASIC PPC cores clocked 7x as fast on some benchmarks. If JIT on a powerful x86 is only 5-7x faster now, odds are they'll be able to reach parity with the UAE JIT soon.

> It's also the exact opposite of open source, being a proprietary core tied to a single-source commercial boards.

Which is entirely irrelevant to the point I was making.

They are better than GPUs at machine learning inference, so there's that. Ask those guys for some benchmark results, you'll be impressed: http://mipsology.com