2026-06-15 · FPGA · MCU · hardware · RTL · embedded

FPGA or MCU? Choosing by parallelism, timing and cost

“Should this be an FPGA or a microcontroller?” is one of the highest-leverage early decisions in a hardware project, and it’s usually made on vibes — FPGAs feel intimidating, MCUs feel familiar, so the MCU wins by default. That’s often right, but sometimes it ships a product that can’t meet timing or burns a CPU at 100% doing something an FPGA would do in one clock. The decision isn’t about which is “more powerful”; it’s about a single structural difference in how they compute, and the trade-offs that fall out of it.

One ALU over time vs a fabric over space

A microcontroller has a CPU: a small number of execution units that run instructions one after another, reusing the same ALU every cycle. An FPGA is the opposite — a sea of configurable logic cells you wire into dedicated hardware, where many operations happen at the same instant, each in its own piece of silicon.

A dark silicon-themed diagram split in two. Left, MCU, in cyan: a single CPU core with one ALU, and a Gantt-style grid showing four operations spread across four clock cycles on a diagonal — op1 in cycle 1, op2 in cycle 2, and so on, labeled 4 ops to 4 cycles, one after another. Right, FPGA, in magenta: six logic blocks (multiply, add, FIR, FSM, CRC, PWM) arranged in two parallel lanes wired by gold dataflow traces, all firing on one clock edge, labeled 6 ops to the same cycle, side by side. A caption reads: a CPU reuses one unit over time; an FPGA spreads the work over space. Figure 1 — The whole difference in one picture. A CPU time-shares one unit across operations; an FPGA gives each operation its own hardware and runs them simultaneously.

That’s the entire mental model. A CPU spends time to do many things; an FPGA spends space. Everything else — why FPGAs crush high-rate signal processing, why they’re cycle-deterministic, why they cost more and take longer to develop — follows from it. A CPU doing four operations needs four cycles; an FPGA does four (or four hundred) operations in the same cycle, as long as you have the fabric to lay them out.

The trade-offs that fall out

Because the CPU is sequential and the FPGA is spatial, each is dramatically better at opposite kinds of work:

A dark comparison table titled where each wins, with two columns: MCU in cyan and FPGA in magenta, across seven dimensions. Execution: MCU is sequential with one or few cores, FPGA is parallel across thousands of cells. Sweet spot: MCU for control, protocols, UIs and ecosystems, FPGA for line-rate DSP and custom parallel I/O. Timing: MCU is fast but has ISR jitter, FPGA is cycle-exact and hard-deterministic. Throughput: MCU is clock times number of cores, FPGA is the size of the fabric. Development: MCU is C or C++ in days with huge tooling, FPGA is HDL plus timing closure over weeks. Cost and power: MCU is cheap with low power for control, FPGA is pricier with higher power. Field update: MCU flashes a firmware image, FPGA loads a new bitstream. Figure 2 — The same structural difference, applied. The MCU wins on cost, ecosystem and ease; the FPGA wins on parallel throughput and hard-deterministic timing.

The points that decide most projects:

  • Throughput and latency. An FPGA processes data at the rate it arrives, with a fixed, cycle-exact latency — no operating system, no interrupt jitter, no cache surprises. For a CPU, throughput is capped by clock × cores, and worst-case latency depends on whatever ISR happens to be running. If you need to react to an edge in a handful of nanoseconds, or sustain a data rate a CPU + DMA can’t keep up with, that’s FPGA territory.
  • Determinism. Because the logic is physical, an FPGA’s timing is the same every time. An MCU is fast on average but has jitter — fine for most control, fatal for some signal paths.
  • Development effort. This is the real cost of an FPGA. You write HDL (Verilog/ VHDL), think in clock domains, and fight timing closure — getting the design to meet its clock across the chip. An MCU is C, a vendor HAL, and a debugger you already know; you’re running in an afternoon.
  • Cost and power. MCUs are cheap and sip power for control workloads; FPGAs cost more per unit and generally draw more. (Per-operation at high rates an FPGA can be more efficient — but for a thermostat it’s absurd overkill.)

So which one?

The honest default is MCU until something forces your hand — cost, ecosystem and time-to-market almost always favour it. Reach for an FPGA when the problem is parallel or the timing is too tight for software:

A dark decision diagram with two cards and a bottom strip. The cyan MCU card, titled reach for an MCU when, lists: the work is sequential control and decision logic; you want rich peripherals and driver ecosystems; microsecond-scale latency or soft real-time is enough; lowest cost, power and time-to-market win; C firmware with simple OTA updates — examples STM32, PIC, ESP32, nRF, RP2040. The magenta FPGA card, titled reach for an FPGA when, lists: many operations must run truly in parallel; you need nanosecond-deterministic, cycle-exact timing; data rates exceed what a CPU plus DMA can sustain; custom or massive I/O like high-speed serial or video; protocol bridges or glue logic in hardware — examples Lattice, Artix, Cyclone, Agilex. A gold bottom strip reads: need both? An SoC FPGA such as Zynq, Agilex SoC or PolarFire SoC puts ARM cores plus fabric on one die — run control or Linux on the CPU and the hot path in the fabric, at the most power and complexity. Figure 3 — A practical guide. Sequential control and ecosystems → MCU; parallel, line-rate, cycle-deterministic work → FPGA; both at once → an SoC FPGA.

And you don’t always have to choose. SoC FPGAs (Xilinx Zynq, Intel Agilex SoC, Microchip PolarFire SoC) put hard ARM cores and programmable fabric on one die — you run Linux or your control loop on the CPU and offload only the hot, parallel path to the fabric, talking over an on-chip bus. It’s the best of both worlds at the cost of the most complexity, and it’s why so many high-end radios, cameras and motor drives look like “a processor with an FPGA bolted on” — because that’s exactly what they are.

Field notes

  • Default to an MCU; justify the FPGA. The question isn’t “could an FPGA do this?” (it can) — it’s “does the problem need parallelism or timing a CPU can’t give?” If not, you’ll ship faster and cheaper in C.
  • The classic FPGA wins are line-rate and parallel I/O: high-speed serial, multi-channel ADC capture, video pipelines, many independent PWM/encoder channels, and protocol bridges — things that are “one clock” in hardware but a CPU-melting loop in software.
  • Budget for timing closure, not just coding. The HDL is the easy part; getting a big design to meet timing across clock domains is the schedule risk. (Clock-domain crossing is its own deep topic — and its own bug class.)
  • Consider an SoC FPGA before splitting into two chips. One die with ARM + fabric is often simpler than an MCU plus a separate FPGA wired together.
  • Match the tool to the bottleneck. If the CPU is at 100% shuffling a fast data stream, that’s the signal to move that stream into fabric — not necessarily the whole design.
← All posts