FPGA vs microcontroller: how to actually choose

It's the most common question from newcomers and the most practical question in embedded design reviews: should this be an FPGA or a microcontroller? Both are wrong answers half the time, and the decision gets easy once you see what each one fundamentally is.

Two completely different machines

A microcontroller is a processor executing instructions one after another (fast, but sequentially), surrounded by fixed-function peripherals. Its superpower is software: change behavior in seconds, enormous ecosystems, a dollar buys a lot of capability.

An FPGA is a blank sheet of digital hardware — LUTs, flip-flops, block RAM, DSP slices — that becomes whatever circuit you describe. Its superpower is parallelism with deterministic timing: a thousand things per clock cycle, every cycle, with latency you can put in a datasheet.

The metaphor that sticks: an MCU is a brilliant chef following a recipe line by line. An FPGA is a purpose-built factory floor where every station works simultaneously — and you designed the floor.

Pick the microcontroller when…

• The work is sequential and event-driven. Read sensor, decide, log, sleep. A state machine in C, essentially — the MCU's home game.
• Sub-microsecond timing doesn't matter. Interrupt latency in the microseconds and occasional jitter are fine for most control loops.
• The peripherals already exist. UART, I2C, SPI, CAN, USB, ADC on one die, driven by vendor libraries.
• Cost/power floors matter. MCUs start under a dollar and sleep in microamps; small FPGAs start around a few dollars (Tang Nano class) and rarely nap as deeply.
• Iteration speed is the priority. Compile in seconds, printf everywhere, step through with a debugger.

Pick the FPGA when…

• Many things must happen at once. Sixteen channels sampled, filtered and compared simultaneously — an MCU time-slices; fabric just wires up sixteen pipelines.
• Timing must be exact, every time. Generating precise waveforms, reacting in fixed nanoseconds (HFT is the extreme case), keeping deterministic latency through a signal chain.
• The interface doesn't exist as a peripheral. Custom LVDS protocol, a camera's exotic lane format, a 1980s arcade bus, 32 quadrature encoders — fabric speaks anything you can describe.
• Throughput is the product. Line-rate packet processing, video pipelines, software-defined radio: data flows through an FPGA rather than being fetched and processed.
• You need hardware certainty. No interrupt storms, no scheduler, no cache misses — the waveform you simulate is the behavior you get.

The secret third option (which usually wins)

Most interesting products use both — and the industry has productized the combination:

• MCU + small FPGA: the MCU runs logic and comms; the FPGA handles the one hard-real-time or many-channel task. Talk over SPI or a register map.
• SoC FPGAs (Zynq, Cyclone V SoC — see the board picker): hard ARM cores and fabric on one die, Linux on one side, your custom hardware on the other.
• Soft cores: drop a small RISC-V into the fabric for housekeeping next to your fast logic.

The design question then becomes cleaner: which parts of this problem are software, and which parts are circuits? Software: anything sequential, complicated, or likely to change weekly. Circuits: anything parallel, fast, or timing-critical.

If you're choosing what to learn

Learn both, in either order — but know that FPGA skills are rarer, better paid, and teach you what computers are actually made of. The on-ramp is gentler than its reputation: our free course takes you from logic gates to a working ALU with live simulated waveforms, the playground runs your first Verilog today with zero installs, and a first board costs less than a nice lunch (Tang Nano 9K). The moment a design of yours blinks its first LED because you described the circuit, you'll understand why FPGA people never stop talking about it.