FPGA or microcontroller: how to decide on an embedded project

A microcontroller executes instructions one after another. An FPGA does not: it becomes the circuit you describe. The whole difficulty of the choice sits in that sentence, because it changes what "faster" means.

What an FPGA actually is

An FPGA is a fabric of configurable logic blocks, flip-flops, memory blocks and, on recent families, hardwired arithmetic blocks known as DSP slices. You are not programming a processor: you describe a circuit in VHDL or Verilog, a synthesis tool turns it into gates, then a place-and-route tool decides where each element lands on the die and which paths the signals take.

The most important consequence is not clock speed, which is in fact modest. An FPGA typically runs between 100 and 400 MHz, while a Cortex-M7 reaches 600 MHz and an application-class Cortex-A goes past a gigahertz. The FPGA never wins on frequency.

It wins because thirty operations can genuinely run at the same time, each in its own patch of silicon, with no contention for a core, a bus or an interrupt controller.

Four cases where the FPGA really wins

Wide parallelism on a continuous stream. Filtering eight channels of a sensor at 50 Msps, running a convolution over a video stream line by line, correlating in real time: these are workloads where the same computation repeats across a lot of data. An FPGA instantiates eight filters and runs them together. A microcontroller, even with DSP and SIMD extensions, runs them in sequence.

Nanosecond determinism. On an FPGA, a response in three clock cycles is a response in three clock cycles, always, with no jitter. No interrupt, no cache, no bus arbitration disturbs that path. On a microcontroller, a cache miss or a higher-priority interrupt introduces a few microseconds of variability. For a fast switching motor control loop, or for a trigger synchronised across several channels, that difference is structural.

Interfaces that no integrated peripheral provides. An image sensor with a proprietary protocol, a legacy industrial bus, a serial link with an unusual framing: rather than paying for expensive software bit-banging, you describe the protocol in logic. This is often the real reason an FPGA is in a product, far more than raw computation.

I/O aggregation. Fifty lines to sample, timestamp and aggregate before transmission. The FPGA does that work upstream and only sends the processor what it needs.

Four cases where the microcontroller wins

Sequential control. A state machine that reads sensors, applies business logic and drives actuators at a few kilohertz is written in C in a fraction of the time, debugged with a breakpoint, and changed without re-synthesis.

Any existing software stack. TCP/IP, USB, TLS, a filesystem, an RTOS, a signal processing library: all of it exists, is tested, and works. Reimplementing it in logic would make no sense.

Unit cost. A Cortex-M4 sits around 2 to 5 euros. An entry-level FPGA starts closer to 15 to 30 euros, and usually needs an external configuration memory plus several sequenced power rails. On a product shipping 10,000 units a year, the bill-of-materials gap dwarfs any development time saved.

Standby power. A microcontroller drops to a few microamps in deep sleep and wakes in microseconds. An SRAM-based FPGA draws current continuously, if only to hold its configuration, and reloads it at power-up. On a battery product, that rules it out.

The cost nobody counts

The real gap between the two worlds is not the component, it is the development cycle.

Changing one line of C and reflashing a microcontroller takes seconds. Changing one line of VHDL requires a full re-synthesis and place-and-route: ten minutes on a small design, several hours on a large one. A design that misses its timing constraints does not give you a clear error, it gives you a timing report you have to know how to read, and the fix is usually architectural rather than syntactic.

Debugging changes nature too. There is no printf. You simulate first, with a testbench somebody has to write, or you instrument the circuit with an embedded logic analyser that consumes resources and forces a new synthesis every time you move a probe.

That is why an FPGA project should be judged first on the skills available. A team that has never written VHDL does not close that gap in a quarter.

A decision table

The figures in this section are observed orders of magnitude, not specifications. They depend on silicon, compiler and configuration. Measure your own before sizing a product on them.

| Software stacks | complete | describe them yourself |

The answer is usually "both"

In practice, the architectures that work split the roles rather than pick a side. The FPGA takes acquisition, preprocessing and demanding protocols; the processor takes application logic, networking and the user interface.

That is exactly what SoCs combining both on one die offer, such as AMD's Zynq or the STM32MP family. This architecture avoids the worst of both worlds: describing in logic what C expresses perfectly well, or attempting in software a workload that demands genuine parallelism.

So the useful question is not "FPGA or microcontroller", but: which part of my processing demands real parallelism or cycle-accurate determinism, and which part will be simpler, cheaper and more maintainable in software.

References

• Arm, Cortex-M7 Technical Reference Manual
• AMD, Zynq 7000 SoC Technical Reference Manual
• STMicroelectronics, STM32MP1 documentation
• IEEE, 1076 VHDL

Going further

These trade-offs become concrete once you have written a first synthesisable design, read a timing report, and understood why one over-long combinational path limits the whole clock. That is what our two VHDL courses cover, one on the language itself, the other on design for FPGA.