FPGA vs CPU vs GPU: three ways to compute
Every digital problem can run on a CPU, a GPU, or an FPGA, but the three chips go about it in completely different ways, and the differences are easiest to see if you just look at the silicon. A useful cartoon: a CPU is a few big, chunky blocks, a GPU is thousands of thin, long rectangles, and an FPGA is a sea of tiny blocks with wires running between all of them.
Those pictures aren't just decoration; they are the architectures. A CPU spends its die on a handful of large, powerful cores (plus a lot of cache). A GPU fills its die with row upon row of narrow arithmetic lanes. An FPGA is a uniform fabric of tiny configurable cells (look-up tables) stitched together by a programmable interconnect. Everything else follows from that.
The core split: computing in time vs in space
The deepest difference isn't speed, it's when the work happens.
A CPU or GPU is a temporal machine. It has a fixed, small set of arithmetic units, and it feeds a stream of instructions through them one after another: load, multiply, add, store. The program is a recipe played out over time on hardware that never changes shape.
An FPGA is a spatial machine. You don't feed it instructions; you become the hardware. The multiply, the add, and the store each get their own dedicated logic, wired directly to each other, and data flows through that custom circuit. The program is the wiring diagram.
That single idea explains almost everything below. Spend the die on a few clever units and you get a CPU. Spend it on thousands of copies of one simple unit and you get a GPU. Hand the die to the user as raw, wireable logic and you get an FPGA.
The CPU: a few brilliant generalists
A modern CPU core is a marvel of doing one thing quickly. It predicts branches, reorders instructions, speculates, and keeps big caches close so it rarely waits on memory. There are only a handful of cores, but each is fast, latency-obsessed, and utterly general: it will run an operating system, a web browser, a compiler, and your control logic without complaint.
That generality is the point and the price. A CPU is unbeatable at irregular, branchy work and latency-sensitive single tasks, the code where "what do I do next?" depends on the last answer. It is comparatively poor at brute-force parallel arithmetic: with only a few cores, it simply can't do thousands of multiplies at once.
The GPU: thousands of narrow specialists
A GPU throws generality away in exchange for sheer numbers. It packs thousands of small lanes that all execute the same instruction on different data at the same time (SIMT/SIMD). Give it a big, regular batch, every pixel in a frame, every element of a matrix, every weight in a neural network, and it chews through it with enormous throughput and memory bandwidth.
The catch is that all those lanes want to march in lock-step. Branchy, irregular code makes lanes sit idle, latency on any one item is high, and the power bill is real. A GPU is a throughput monster for uniform math, and awkward at almost everything else.
The FPGA: build the machine you actually need
An FPGA gives you the die as a blank fabric and lets you wire up exactly the circuit your problem wants: a deep custom pipeline, a hundred parallel filters, a bit-exact protocol decoder, whatever fits. Because the datapath is dedicated silicon, results come out at a fixed, deterministic latency, cycle after cycle, with no instruction overhead and no cache surprises.
That makes FPGAs shine where the others struggle: line-rate streaming, hard real-time and ultra-low latency, odd data widths (a 3-bit field, a 47-bit accumulator, no problem), and custom I/O and protocols wired straight to pins. And unlike an ASIC, you can reflash the whole thing next week when the spec changes. The costs are real too: you design in Verilog or VHDL (or HLS), builds take minutes to hours, and clock speeds are lower than a CPU's, so the FPGA wins by doing far more per clock, not by clocking fast.
The tradeoff, in one plot
Line the four options up (with a fixed-function ASIC as the extreme) and a clean pattern appears: the more you specialize the silicon, the more efficient it gets at its task, and the less flexible it is to reprogram.
The FPGA sits in the interesting middle: nearly ASIC-level efficiency for a task, but reprogrammable in minutes instead of a multi-million-dollar tape-out.
Side by side
| CPU | GPU | FPGA | |
|---|---|---|---|
| Building block | a few big cores | thousands of lanes | a sea of LUTs + routing |
| Computes by | instructions over time | one instruction, many data | a custom circuit in space |
| Best at | latency, branchy control, "run anything" | throughput on regular math | custom pipelines, low deterministic latency, bit/IO work |
| Parallelism | a few threads | thousands of threads | as much as fits on the die |
| Latency | low | high | very low, deterministic |
| Perf / watt (fixed task) | low | medium | high |
| Data widths | fixed (8–64-bit, float) | fixed (float/int, tensor) | any width you like |
| Change the design | recompile (seconds) | recompile (seconds) | resynthesize (minutes–hours) |
| You write | C / C++ / Python | CUDA / kernels | Verilog / VHDL / HLS |
So which should you reach for?
- CPU for control, orchestration, and anything branchy or single-threaded: operating systems, protocol stacks, business logic, and the glue that ties a system together.
- GPU for big, regular, data-parallel math: training and serving neural networks, graphics, dense linear algebra, scientific batches, anywhere you can express the work as "the same thing, a million times."
- FPGA for custom, streaming, latency-critical, or I/O-heavy work: line-rate packet processing, software-defined radio and real-time DSP, low-latency trading, sensor fusion and machine vision at the edge, bespoke interfaces, and prototyping an ASIC before you commit the silicon.
A good rule of thumb: if the bottleneck is decisions, use a CPU; if it's the same math repeated, use a GPU; if it's moving and transforming a stream with tight, predictable timing, an FPGA is often the only thing that fits.
The lines are blurring
None of these live in a pure box any more. CPUs grew wide vector units (AVX) to steal some data-parallel work; GPUs added tensor cores for dense AI math; FPGAs gained hard DSP slices, floating-point, and even dedicated AI engines so they don't have to build multipliers out of raw logic. And the interesting chips are hybrids: FPGA fabric with hardened ARM cores on the same die, and devices that fuse CPUs, vector engines, and programmable logic into one package. In practice a real system uses all three, each doing the part it's best at.
See the spatial machine for yourself
The fastest way to feel the difference is to build a circuit rather than write a program for one. Open the Verilog, VHDL, or MyHDL playground and describe a bit of hardware: it isn't a list of steps, it's a shape that all runs at once. From there the hands-on course starts at logic gates, and the core registry is full of real designs that do exactly the streaming, custom-pipeline work FPGAs are made for.