Should you use an FPGA or a microcontroller?

Many people turn to me for advice regarding their FPGA projects. Often, my answer is not what they expected: have you considered using a microcontroller instead of an FPGA?

I’m running VHDLwhiz, the website dedicated to FPGA design using VHDL. My life revolves around FPGAs, and I’m the biggest proponent of VHDL there is. Why would I say such a thing?

It’s because, for some tasks, an FPGA is overkill.

When you are learning FPGA design using VHDL, of course, you have to start with simple projects. Also, if you are creating something just for fun, then you may very well use an FPGA, even if it doesn’t make sense.

Those are not the kind of projects I’m talking about. But if your goal is to create something, and you are looking at an FPGA because you think it’s the best solution. Then, you should put that theory to the test.

Microcontrollers are easier to use

You should use a microcontroller if you can because it’s easier to develop software than hardware.

A computer program works on a higher abstraction level than a digital circuit. Just like a high-level language, like Python, is easier to work with than C, you may be able to program C faster than you can create logic using VHDL.

On a microcontroller, you can perform inline debugging through JTAG. That makes it a lot easier to test and debug. You can attach a debugger and step through the code while it’s running on the microcontroller. Therefore, you can get away with creating little or no software tests.

We can look inside some FPGAs with JTAG as well, but it’s a more complicated process. And it’s not a computer program, so we can’t use any breakpoints. We can only read the instantaneous signal values and capture short waveforms.

Even if you don’t have access to a JTAG in-circuit emulator (ICE), you can rely on printf for embedded software development. If you are working with Arduino, it’s as simple as throwing in a call to Serial.println()  whenever you want to print something to the console.

Why use an FPGA?

The main reasons why engineers turn to FPGAs are performance or connectivity related. Another reason to use FPGAs is that you can make them more reliable than a microcontroller or microprocessor.

Interface timing

FPGAs have almost perfect timing of input and output signals. You can create logic for handling every kind of digital interface up to a few hundred Megahertz. If you are lucky, someone has already created a module that you can import into your project. For example, from OpenCores, Xilinx IP Cores, or the Intel IP and Reference Designs library.

Microcontrollers usually come with dedicated hardware interfaces like UART, SPI, or I²C. These special pins on the microcontroller are capable of sending and receiving data at high speeds while maintaining signal integrity.

If you can’t find a microcontroller that matches your external interfaces, you may need to use an FPGA.

Connectivity

If you are working with exotic interfaces, or if you can’t find a microcontroller that offers the quantity or combination of IO controllers that you need, then you are out of luck.

You can use general-purpose IO pins to emulate any IO interface using a method called bit-banging. But the speed is going to be low, and the signal integrity is going to be awful. That’s because you are emulating physical, digital signals by using software running on a processor.

FPGAs, on the other hand, can handle as many IO interfaces as you have IO pins for. Need to attach another high-speed sensor using I²C? No problem! Just create another instance of the I²C module, and you’re ready to go. On the FPGA, all general-purpose pins are potential high-speed interfaces.

Parallelism

As I said earlier, you can implement custom interfaces in microcontrollers by using bit-banging. There’s also the option to use external IO expander chips. These are ICs that allow you to control multiple digital wires by using less pins on the microcontroller.

Therefore, in theory, you can read from a large number of data sources in parallel by using a microcontroller. The problem is that the processor in the microcontroller can only read from one source at the time. It’s software, so it can never sample all inputs simultaneously. It can only do it one at the time.

That can be a problem if you need to sample a consistent dataset. For example, if you are reading multiple voltages and currents in a high-speed analog circuit. You would want to sample the voltage and current values in parallel. Any skew on one data series may ruin the dataset.

An FPGA is capable of initializing reads in parallel, at pretty much the exact same time. If your application is required to read, write, or process data in parallel, then you may want to use an FPGA.

Hard real-time requirements

In real-time computing, the application has strict deadlines for how long the processing time of each dataset can be. The device must read the inputs at fixed intervals, and churn out the results with a fixed delay, no matter what.

It’s hard to make such guarantees with a computer program running on a processor. Software is inherently non-real-time. That’s especially true when you introduce an operating system. Even adaptations like RTLinux (“real-time Linux”) are really just working at best-effort. They don’t offer any guarantees for how long each processing step takes.

Most microcontrollers don’t have operating systems. They run bare-metal programs that, in theory, can be used for hard real-time requirements. But you must analyze the critical parts of your program on an Assembler level to verify that it always completes in time. You must also have an intricate knowledge of the microcontroller architecture to make sure that the processing is 100% deterministic.

These extra steps make it more difficult to develop microcontrollers, which kind of defeats the purpose of using them in the first place. It’s easy to guarantee that the data processing pipeline of an FPGA is deterministic. Depending on how strict your real-time requirements are, you may want to choose an FPGA for these tasks.

High data volumes

If you have high data volumes that need processing, a microcontroller may be too slow. Microcontrollers are generally low-cost devices running on clock speeds up to 20 MHz. It’s not fair to compare them to FPGAs with clock speeds in the hundreds of Mhz. You could even implement a microcontroller in an FPGA.

If a microcontroller is too slow, the next logical step is to use a microprocessor. Unlike microcontrollers that are mostly self-sufficient, processors require external components like RAM and non-volatile memory.

A well-known embedded computer is the Raspberry Pi. The high-end versions are inexpensive and have the full connectivity of a desktop computer. Its 1.5 GHz ARM Cortex processor certainly has a higher throughput than a microcontroller.

It’s going to be more complicated to create a custom PCB with a microprocessor. It would probably be just as challenging as using an FPGA because you have to accommodate the other digital components that the processor relies on.

Other factors than throughput usually determine if you want to use a microprocessor or an FPGA, although there are specialized computing tasks where an FPGA implementation is superior.

Power consumption

Microcontrollers are very power conservative. Many of them have sleep modes that reduce the current to only a few µA. FPGAs generally can’t compete with the idle current of a microcontroller. But it all depends on the use case.

FPGAs can be more power conservative than microcontrollers or microprocessors. If your application performs continuous calculations, the FPGA may use less power than the processors. That’s why cryptocurrency farms use FPGAs; they use less power for this specialized task than CPUs do.

Reliability

FPGAs are considered to be less error-prone than microcontrollers. It’s easier to verify hardware than software. You know this intuitively already. How many bugs have you not seen in well-known computer programs? Does your car malfunction at an equal rate?

That’s the main reason why the aviation industry uses loads of FPGAs. The exact numbers are hard to find, but this article states that each Airbus A380 contains more than 700 FPGAs from one vendor alone. Numbers are probably similar for other aircraft.

For aerospace companies, it’s cheaper to develop FPGAs than to use microcontrollers and microprocessors. Electronics and software used in aircraft must be proven error-free. FPGAs fall under the hardware category, and therefore must comply with the DO-254 Design Assurance Guidance for Airborne Electronic Hardware. Software, on the other hand, is subject to verification under the stricter DO-178C certification standard.

Even if you’re not developing aerospace applications, reliability is something that many FPGA engineers have to keep in mind. If failure of your device means that someone is going to get hurt, you may want to go for an FPGA instead of using a software approach.

Summary

There’s no golden rule for when to use an FPGA and when to use a microcontroller. It depends on the requirements of your project. One isn’t better than the other. They have different qualities that you need to assess the importance of on a case-by-case basis.

I’m a fan of using the simplest possible tools for the job. If I can get away with using a microcontroller, I will do it. If you want to use FPGAs, that’s fine, but don’t make it more complicated for yourself when it really matters. For example, when selecting which device to use for your master’s thesis.