I recently put together a high power voltage converter for a client, and throughout the design I was trying to avoid the use of an MCU. Once the client wanted to add dimming to the board, I was forced to add a small component with a 100,000 cycle EEPROM. For me, this wasn’t such a huge deal as it was a simple matter to spend $0.33 per board to add this function, while also allowing the system to be reconfigured later. This got me thinking about an interesting question: when should you choose an FPGA over an MCU?

The designers I work with live and breath Arm, STM, TI, and Nordic MCU modules/SoCs, thanks primarily to manufacturer support through SDKs. What about FPGAs? Can you expect the same level of support, and should you choose to use an FPGA for an embedded component? The answer to this type of question isn’t always simple. Here’s what you should consider when selecting an FPGA vs. MCU and where you can find new components for your boards.

FPGA vs. MCU Capabilities

I remember when I first started working seriously in electronics design and started reading through the alphabet soup of acronyms for different components. At first it was difficult to see the differences between some digital processors, but understanding the limits of each component for different applications has served me well. The limits of what you can program into these processors has also been critical for understanding when to choose each type of component.

I’ll get into these aspects momentarily, but I still sometimes get the occasional question from a younger designer: what are FPGAs and MCUs? They both provide computing power, so they must be perfect replacements, right? It depends on what application you need to perform.

To get a sense of the differences between FPGA vs. MCU components, it helps to compare them with ASICs. The “A” in ASIC tells you the component is designed for a specific application within a larger system. Examples include:

• Chips for digital signal processing
• VCO integrated circuits
• RF transceivers
• Ethernet controllers

The list only goes on from there. Any ASIC will provide very specific, sometimes programmable functions for a narrow range of tasks. The level of integration in an ASIC also varies by chip. A microcontroller is also programmable to some extent, although the tasks that can be performed are broader than what is built into the firmware of an ASIC. MCUs are built to be adaptable and perform any task you can program into the device with the manufacturer’s SDK.

The fun and complication comes with FPGAs. I like to think of FPGAs as customizable ASICs. If the oxymoron bothers you, just know that you could use an FPGA as part of prototyping when designing an ASIC. This is because all the logic blocks on an FPGA are configurable (they are basically SRAM cells). You’re building up the firmware from scratch, and you can define how tasks are executed on the device at the hardware level. This is something you can’t do with an MCU or ASIC.

FPGA vs. MCU vs. ASICs: the specific vs. generic spectrum.

What About SoCs/SiPs/SoMs?

The funny thing about SoCs is that they can be anywhere from specific to generic in terms of computational capabilities. Component manufacturers will attach the term “SoC,” “SoM,” or “SiP” to a new integrated circuit that performs a range of tasks, as long as those tasks used to require multiple separated integrated circuits. These components are highly integrated, and they can fall anywhere on the specific vs. generic spectrum.

MPUs: Even More Generic

Somewhere to the right of the FPGA in the above graphic would be MPUs. These devices run an operating system, interface with multiple peripherals, and are the workhorses of general purpose computing. Some might argue that the MCU and FPGA should trade places in terms of generic-ness (see why below), but neither an FPGA or MCU are designed for the same type of general computing as an MPU.

Choosing an FPGA vs. MCU

The table below shows a brief comparison of some of the most important aspects of MCUs and FPGAs. Each type of component has its advantages, and it’s up to the designer to determine which is best for their system. Personally, I prefer MCUs because I have some experience working in C and I’ve never learned HDL. However, FPGAs can be programmed to have some of the same functions as specialty ASICs, as long as you know how to code them.

| | FPGA | MCU | | ---------- | ---------- | ---------- | | Reprogramming| Fully reprogrammable at the hardware level | Varies: relies on embedded operating system, dynamic | | Programming time | Longer: requires recoding and recompiling everything to machine code | Shorter: aided by manufacturer SDKs and libraries | | Ease of programming | Seen as having a steeper learning curve | Easy: anyone familiar with common languages can code | | Power consumption | Higher | Lower | | Parallelization | Can be configured during programming | Limited by hardware architecture | | Fixed vs. floating point | Configured for fixed point, but floating point can be implemented during programming | Both are accessible | | Languages | Hardware description language (HDL) | C/Assembly language, others if supported by RTOS (e.g. Python) |

Because FPGAs are often seen as difficult to program by newer developers, an MCU is typically seen as the best processor for an embedded device. This has largely been aided by the open source community, and some open source projects can be used as the basic architecture or proof-of-concept for a new product. Add to this the support from manufacturers, and you have plenty of tools available for programming MCUs.

Despite the learning curve in programming FPGAs, they are much more configurable in terms of the firmware architecture. Parallelization can be programmed into the device, depending on the number of LUTs and ALUs available. This makes FPGAs a great choice when your firmware needs to be designed for very specific applications. Examples include inference in AI, image processing, hardware control algorithms, and other tasks that require repetitive (or parallel) computation.

Your next embedded system won’t get anywhere without the right components, and you can find the components you need with when you use an electronic parts search engine like Octopart. The advanced filtration functions help you narrow down to the components you need and can help you quickly choose between an FPGA vs. MCU for your next system. You can find FPGAs and MCUs on Octopart.

Stay up-to-date with our latest articles by signing up for our newsletter.