Why aren't FPGAs ubiquitous?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.