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. If you go this way, how to pick a RISC-V soft core walks the shortlist.

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.