# Why aren't FPGAs ubiquitous?

Reading about FPGAs, if I understand correctly, they are basically fully configurable logic gate circuits. Being this, one can design anything with them. One can design everything in the most customized way possible and hence, meet the same ends in a vastly more efficient manner which can be get using a microcontroller. Having this, it looks like an FPGA beats a microcontroller any time, any day. So my question is, if FPGAs are really this awesome, what keeps them from being much more prevalent than microcontrollers? From this point of view, to me it seems like FPGAs should have wiped out microcontrollers a long time ago. So why is this not the case? Is it the cost, difficulty to program an FPGA, or entirely something else?

• possible duplicate of Soft core Processors VS Hard core Processors – PeterJ Sep 13 '15 at 12:36
• You might also want to read this thread: electronics.stackexchange.com/questions/4382/… – Tom L. Sep 13 '15 at 12:37
• Helicopters are more flexible than cars, so why does anyone still use a car to commute to work? – Olin Lathrop Sep 13 '15 at 12:50
• Because all the FPGA companies give you utterly horrible proprietary tools that have a huge learning curve and are not accessible to most developers. Replace that with a fully open toolchain and they probably would be ubiquitous. – R.. GitHub STOP HELPING ICE Sep 14 '15 at 15:40
• @R.. ... or at least not a choice of absolute last resort option. – Dan is Fiddling by Firelight Sep 14 '15 at 19:10

You are ignoring a lot of factors that go into making design choices:

1. Cost. FPGAs are more expensive than micros for the same complexity of logic.

2. Logic complexity. Executable code can implement far more complicated logic than the same number of gates in the micro used directly.

3. Ease of development. It's easier to write executable code than to define logic for all but small problems. Even modest microcontroller projects have thousands of lines of code. Developing the equivalent logic definitions would take much longer and be much more difficult to debug and verify.

4. Power consumption. Since FPGAs are intended for high speed operations that micros can't handle (else you'd use a micro), they are not optimized for low power. This makes them unsuitable for some low power applications. Some micros have sleep currents under 1 µA, and can operate on just a few µA at slow clock rates. Try finding a FPGA that can do this.

The main advantages of FPGAs versus micros is that they are faster and can do more things in parallel. Other than that, you'd rather use a micro. Therefore in the design process, you usually start out with a micro, then grudgingly go to a FPGA when you really need the speed and/or concurrent high speed operation. Even then, you implement only the speed-critical parts in a FPGA, and leave the lower speed control functions and the like in the micro.

• "Even then, you implement only the speed-critical parts in a FPGA, and leave the lower speed control functions and the like in the micro." And that's because development for an FPGA is a pain, right? – Utku Sep 13 '15 at 12:45
• @Utku: Yes, that's reason 3 above, although reasons 1-2 usually apply too. FPGAs just aren't as cost effective as micros for the same task, unless that task has such high speed requirements that a micro just can't do it. – Olin Lathrop Sep 13 '15 at 12:47
• It's easy to tell that this answer is written from a CPU-user point of view. "grudgingly go to a FPGA when you really need the speed and/or concurrent high speed operation". They aren't that bad. There are applications where one would not even think to use a CPU over an FPGA. – stanri Sep 13 '15 at 21:18
• The way I usually explain it: It's hard to do things in parallel on a CPU, and it's hard to do things serially in an FPGA. – Ben Jackson Sep 13 '15 at 23:15
• One big thing to remember about FPGAs: the reconfigurability of the logic comes at a price - the equivalent logic that an FPGA implements is far less complicated than the FPGA itself. All of the look up tables, routing matrix components, etc. consume far more silicon area and power than the equivalent implementations in hard logic. This means that FPGAs are worse in all performance metrics - active and idle power consumption, density, clock speed, etc - than building the same functionality directly in silicon as is done with microcontrollers, general purpose CPUs, and the FPGA itself. – alex.forencich Sep 14 '15 at 8:17

One distinction that I haven't seen elaborated upon here is that FPGAs are used, and behave, in a completely different way to processors.

An FPGA is really good at doing the exact same task, over and over again. For example, processing video, audio, or RF signals. Or routing Ethernet packets. Or simulating fluid flow. Any situation where you have a lot of the same kind of data being thrown at you really fast and you want to deal with it all in the same way. Or you want to run the same algorithm repeatedly. The FPGA doesn't really have 'tasks' that start and stop[1], its entire job is to do the same thing to whatever data it gets, for as long as it is on. It does not change gears, it doesn't do anything else. It is the ultimate production-line worker. It will do the same thing repeatedly, as fast as it can, forever.

CPUs, on the other hand, are the epitome of flexibility. They can be programmed to do anything at all, and they can be programmed to do multiple different things at the same time. They have tasks that start and stop, they change gears, multitask, are constantly switching and changing functions.

The FPGA and CPU are complete opposites. The CPU's commodity is time - it must get stuff done faster. The quicker your application runs, the better.

The FPGA's commodity is space. Your FPGA is only so big, and there are only so many available gates to perform the task you want. The majority of the time, the issue is more size than speed[2].

It is possible to make an FPGA act like a CPU. You can put a CPU IP core into an FPGA, however it is very difficult to justify because of the reasons others have described[3]. The FPGA and CPU are opposites, both having their own strengths and weaknesses, and both having their own place as a result.

Notes:

1) An FPGA could be designed to perform different tasks, but even then it would be a specific number it was pre-designed for.

2) Speed is also a FPGA design specification. It's really a trade off between speed and size.

3) Putting a CPU into an FPGA is done relatively often, however it's done on a case-by-case basis, depending on the specific applications. For example, if you need a really tiny microcontroller and have extra FPGA space.

And finally: This answer is a big simplifcation - FPGAs are used in enormously varied and complex ways and this is a very brief overview on the way they are used in general.

• "Or routing ethernet packets. Or simulating fluid flow." Although, as far as I know, ASIC is usually used for the former (in mass production, at least) and GPUs are faster, cheaper, lower power, and more easily programmable for the latter. – reirab Sep 16 '15 at 14:48
• @reirab Those were examples of the kind of operations that FPGAs can do well, they came to mind because they're both applications that I've personally coded FPGAs for. There is more than one way to skin a cat. The choice of device depends on many design factors. – stanri Sep 16 '15 at 15:02
• @reirab anything an FPGA can do an ASIC can do for lower power and a lower marginal production cost. FPGA's advantages are in prototyping and low volume production because the upfront costs for an ASIC are far larger; meaning the latter only make sense when the design is finalized and you're making a lot of them. – Dan is Fiddling by Firelight Sep 16 '15 at 17:08
• It's weird to claim that a CPU is more flexible than a FPGA, considering that you can implement a CPU easily within an FPGA (any serious CS student should do that at least once). A FPGA is a much lower concept than a CPU so it just doesn't make much sense to compare them directly imho. – Voo Nov 9 '18 at 15:23
• This answer really bothers me. "The CPU's commodity is time", "The FPGAs commodity is space." Huh? ASICs and CPUs are polar opposites, and FPGAs sit in the middle getting both the best and worst of both worlds. – Jotorious Mar 18 '19 at 12:44

As Olin says, something like a micro is more efficient for many tasks, and you'll almost always find a micro used wherever an FPGA appears. The acreage of silicon used (which translates into cost in a nonlinear fashion) and the power consumption are much less. For that reason, it's not uncommon to implement a 'soft' MCU on an FPGA- but the cost and performance of such a micro is underwhelming.

Some modern FPGAs contain one or more 'hard' cores such as the ubiquitous ARM series. Also, they may contain dedicated memory blocks since it's really inefficient to make memory out of gates. A 32-bit micro core takes up a tiny bit of the silicon area in a typical FPGA, which gives you an idea of the relative costs.

Development is significantly more difficult, and IP tends to not be as freely available as for micros and dedicated SOC solutions- for example LCD controllers, PCI interfaces, Ethernet MACs. The reason is partly that by disclosing the HDL logic descriptions they are transferring the design not just the instantiation of the design. Another reason is that performance is dependent on layout of logic in the FPGA, which requires a lot of effort during development.

A further complication is that most complex FPGAs are RAM-based for configuration and the process costs are such that external nonvolatile memory is required to store the configuration and program memory for any MCU on board. This memory has to be loaded into RAM at power-up.

FPGAs are extremely useful tools in the toolbox, but they're not going to be replacing MCUs or ASICs universally any time soon.

The best use of silicon for a job is an ASIC, nothing wasted, but they have huge learning curve, NRE, and inflexibility.

There are two ways to build flexibility into a chip. a) Have a space-optimised ALU, and use it over and over again on stored data. This is called an MCU, and requires a vast area of silicon that 'isn't doing anything', the program memory, wide busses running from unit to unit, and bus access switches. b) Have fine-grained logic, with a few optional space-optimised parts like multipliers, small RAMs, and simple CPUs. This is called an FPGA, and requires a vast area of silicon that 'isn't doing anything', programmable switches and connection lines.

Obviously with those structures, MCUs work best for tasks that can be broken down into serial chunks, and FPGAs work best for tasks needing high speed parallel operation. When the application is heavy, and the cost is dominated by the silicon cost, that is how the two types will naturally be used.

When the application is light but high volume, the cost is dominated by packaging rather than silicon, and either type is viable. Altera have some very small very low power FPGAs to compete with a-dollar-a-handful MCUs.

For low volume apps, the development cost tends to dominate, and there MCUs win, assuming they have the speed

In terms of power consumption and silicon utilization an FPGA is very poor compared with a microprocessor.

An FPGA consumes much of its silicon area in the logic configuration circuitry something that does not apply to a micro. There have to be many more interconnects available than would be needed on a dedicated implementation of a microprocessor.

The FPGA consumes more power than a dedicated ASIC such as a microprocessor as the logic is not implemented as efficiently.

Any function that can be implemented in an FPGA can be done more efficiently, cheaper, with lower power consumption, smaller board space etc in a dedicated ASIC. This is assuming volumes are large enough to offset the NRE.

• If the goal is to implement the entire feature set of the microprocessor, sure. Once you get down to a specific task, you can identify a lot of wasted silicon in the microcontroller also -- maybe that encryption engine is wasted space in your project. Or the CAN peripheral? Or the floating-point unit? FPGA best utilization is lower, but you also don't suffer 0% utilization in large areas the way a microcontroller does. (On the other hand, with clock gating, having 0% usage of large circuits is very desirable from a power perspective) – Ben Voigt Sep 14 '15 at 16:16

Microprocessor-based dsystems, and later Microcontrollers, have been able to achieve an enormous degree of functionality by their ability to use many of the individual pieces of circuitry therein to accomplish many different tasks at different times. I think it's instructive to compare the arcade machine Tank, designed in 1976, with the game Combat which runs on the world's second microprocessor-controlled game machine, the Atari 2600. While there are some differences in gameplay, the Atari 2600 hardware was essentially designed to implement games like Tank at minimal cost; the fact that it could be made to play different games by inserting different ROM cartridges was a nice bonus.

The game Tank allows two players to drive tanks around the screen and fire shots at each other. It has "slip" counters for each tank's X and Y position, each players's shots' X and Y position, up/down counter for each player's angle and each player's shot's angle, a counter for each player's score, X and Y raster-beam-position counters, and lots of control circuitry on top of those things. It has hardware to fetch playfield data from ROM and display it, as well has hardware to fetch shapes for the two player's tanks and scores from ROM and display those.

The Atari 2600 has a slip counter for the horizontal positions of each of two player objects, each of two missile objects, and one additional object called the "ball" which isn't used in Combat but is used in some other games. For each of the player objects, it has hardware to output a pattern stored in an 8-bit latch, as well as a "delayed" eight-bit latch for each player that gets copied to the primary 8-bit latch whenever the other player's shape is updated. It also has a horizontal beam position counter, and a 20-bit playfield-shape latch which is output to the screen twice per scan line, with the right-side copy appearing as either a repeat or a reflection of the left. It has hardware to detect collisions, but not to do anything as a consequence of them. It does not have any hardware for any objects' vertical positions, nor the raster beam's vertical position(!), nor does it have any hardware associated with score keeping, score display, game duration, etc.

All of the functions for which the 2600 omits hardware are handled by software in the cartridge. It's only necessary to check each object's vertical position against the raster-beam position once per scan line, it's only necessary to update the player's score and remaining game time at most one per frame, the players' scores are stored on scan lines above the playfield and thus may share the same hardware that's used for the playfield, etc.

The normal approach to implementing a game like "Tank" in an FPGA would be to use separate circuits for different functions in much the same way as the 1976 arcade machine did. Such an approach would work, but use a substantial amount of hardware. A microprocessor-based approach could eliminate more than half of that hardware in exchange for adding a microprocessor, which would likely contain less circuitry than the hardware it replaced (the 2600 could implement games far more sophisticated than Tank, which would require a lot more hardware if they didn't use a microprocessor).

FPGAs are excellent in cases where one needs a device that can perform many simple tasks simultaneously. Microprocessor-based (or microcontroller-based) systems are generally better, however, in cases where there are many tasks that need to be performed, but they don't need to be processed simultaneously, because they make it easy to use a small amount of circuitry to accomplish a large number of distinct purposes.

• Couldn't you lay mines, too?? ;-) – Scott Seidman Sep 15 '15 at 22:40
• @ScottSeidman: The arcade machine had a few mines at hardwired positions, which were drawn as X's. It would have been very difficult for the 2600 to show the mines as X's while showing both players and both missiles. If one didn't mind having the mines flicker at 60Hz it would have been possible using some tricks that were discovered later, but would have required more code (COMBAT is a 2K cartridge that's pretty much full--even the two bytes in the unused BRK/IRQ vector at $FFFE/FFFF are used to hold a two-byte table!). – supercat Sep 16 '15 at 15:27 • It would probably have been possible for Combat to implement the mines as flashing squares if it had been willing to forego some of its other options like bouncing shots, etc. but I think Joe Decuir (programmer) did a good job of choosing playable options. My one qualm is that the biplane-vs-bomber might have been more fun if the bomber were a 2x rather than 4x sprite. – supercat Sep 16 '15 at 15:29 It's entirely the cost. When a micro can be as low as 30 cents, a cheap FPGA is in the$5 territory. The cost may not seem that high, but when you make a million of a farting novelty toy to sell at \$10 then the price of the FPGA kills your bottom line.

• Cost is certainly one issue, but to say the difference is entirely the cost is as naive as thinking all micros can be replaced by FPGAs. – Olin Lathrop Sep 13 '15 at 15:11
• @OlinLathrop if cost was not an issue then anything a micro can do, can be done by an FPGA. This has been shown with the ability of an FPGA to hold a soft microcontroller core. The problem is that an FPGA that can hold such a core is at least and order of magnitude more expensive then micro who's core is being emulated. – vini_i Sep 13 '15 at 15:38
• Cost can mean much more than price per unit, but that's all you want to throw into this analysis. – Scott Seidman Sep 13 '15 at 15:48
• I can't tell if you're deliberately pretending to miss the point, or just dense. Either way, you're responding to something nobody said. All agree that FPGAs cost more, and that cost is a issue. But again, to claim it is the only issue is just wrong. If I gave you a bunch of free micros and FPGAs, there are still significant reasons why you'd use the micros over the FPGAs in many designs. – Olin Lathrop Sep 13 '15 at 19:51
• @sleb: No, the cost difference is not just due to volume. The silicon area required per delivered gate is significantly larger in a FPGA than in a custom chip like a microcontroller. All that configurability at the gate interconnect level takes silicon area to implement. In high volumes, the cost of a chip is all about its silicon area. – Olin Lathrop Sep 14 '15 at 12:32

Just to add to the other very good answers, I think the adoption of FPGA is also a matter of domain: for instance, for neuromorphic devices, FPGA boards are becoming quite ubiquitous because there is a huge need for parallelism, which is a strong point of FPGA.

If you extrapolate the trend we see for neuromorphic devices, one can imagine that other fields that are based, or critically require, parallelism will probably adopt FPGAs a lot more. So maybe FPGA won't become ubiquitous for consumer grade products, but it can be for specific domains as it seems it's currently happening for neuromorphic devices.

• While this may be true, this doesn't look like enough for a complete answer. Perhaps it would be better as a comment, or you could expand on it. – Null Sep 13 '15 at 17:27
• This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. – Funkyguy Sep 13 '15 at 20:13
• @Funkyguy, this does answer the question. They're essentially saying that FPGAs are not ubiquitous because common consumer applications do not require the parallelism that is the FPGAs strong suit. – stanri Sep 13 '15 at 21:04