FPGA vs ASIC vs GPU

You now command two ways to get custom hardware — configure an FPGA, or (as modules 4–5 will teach) tape out an ASIC — and the world offers a third that involves designing no hardware at all: buy a domain-specific accelerator off the shelf, which today usually means a GPU. Choosing among them is one of the most consequential decisions a hardware team makes: get it right and the product ships; get it wrong and you have either burned twenty million dollars on silicon a cheaper chip could have matched, or doomed a high-volume product to paying FPGA prices forever. The good news: the decision has real structure. Four axes — money, speed-per-watt, flexibility, time — and on each axis the technologies line up in a knowable order.

Axis 1: money — NRE versus unit cost

Chip economics splits every cost into two bins. NRE (non-recurring engineering) is what you pay once, before the first unit exists; unit cost is what each additional device costs forever after. The two technologies sit at opposite corners:

ASIC: brutal NRE — tools, a large team, and a photomask set that alone runs from hundreds of thousands of dollars (mature nodes) to tens of millions (cutting edge) — but then each chip is a few dollars of etched sand.
FPGA: essentially zero NRE (a laptop and a dev board) — but every unit ships with the silicon overhead of all that programmable routing, so each one might cost tens to hundreds of dollars, forever.

With NRE N, ASIC unit cost a and FPGA unit cost f, the total costs cross at the crossover volume:

V^* = \frac{N}{f - a}

Worked example with real-ish numbers: N = \$2\,\text{M}, f = \$300, a = \$30. Then V^* = 2\,000\,000 / 270 \approx 7\,400 units. Selling a few hundred radar units? FPGA, no contest. Selling a million set-top boxes? The ASIC's NRE amortises to two dollars a box. Selling ten thousand — right at the crossover? Now the other axes decide.

Watch the crossover move

The FPGA line starts at zero and climbs steeply ($300/unit); the ASIC line starts at the NRE and climbs gently ($30/unit). Their crossing point is the whole business case — drag the NRE slider and watch cheap masks (mature process node) pull the crossover left, while a bleeding-edge node pushes it right:

Axes 2 and 3: performance per watt, and flexibility

For a fixed, known function, efficiency follows how specialised the silicon is:

\text{perf/watt:}\quad \text{ASIC} \;>\; \text{FPGA} \;>\; \text{GPU} \;>\; \text{CPU}

Every layer of generality — programmable routing on the FPGA, instruction fetch and schedulers on the GPU and CPU — spends energy on being general rather than on the work. But note the fine print "fixed function": for floating-point-heavy, batch-parallel throughput (dense matrix multiplies above all), a GPU's thousands of hardened FPUs and mature software stack routinely beat an FPGA implementation in raw throughput and in engineering time. The ordering flips with the workload — remember this for the Watch out below.

Flexibility runs exactly the other way:

\text{flexibility:}\quad \text{CPU} \;>\; \text{GPU} \;>\; \text{FPGA} \;>\; \text{ASIC}

A CPU changes behaviour by loading a program (seconds); a GPU by loading kernels (seconds, but only for parallel-shaped work); an FPGA by re-running a flow and reconfiguring (hours); an ASIC by taping out a new chip (a year and a fortune). The same ranking is roughly time-to-market: software this afternoon, a working bitstream this month, silicon in 12–18 months if nothing goes wrong.

	NRE	Unit cost	Perf/watt (fixed fn)	Change the behaviour	Time to market
CPU	~0	low	worst	recompile — seconds	days
GPU	~0	moderate	good for parallel float	new kernels — seconds	weeks
FPGA	~0	high	very good	new bitstream — hours	months
ASIC	$0.5M–$50M+	lowest	best	new tape-out — ~a year	12–18 months

A serviceable decision procedure falls out: volume huge and function frozen → ASIC; volume modest, latency-critical, streaming or exotic-I/O → FPGA; workload is batched parallel float with good library support → GPU; none of the above → the CPU you already have.

Where the course goes next — and why

This lesson closes the FPGA module, and the syllabus now turns deliberately down the ASIC road: Module 4 teaches static timing analysis and Module 5 the physical-design flow — synthesis to GDSII, the ASIC big siblings of the flow you just learned. Why ASIC before returning to accelerators and the GPU capstone? Because of a delicious circularity: a GPU is an ASIC. The exact flow of modules 4–5 — run at heroic scale, with the FPGA emulation farms of last lesson standing in as the rehearsal stage — is how every GPU in every datacenter came to exist. The three technologies of this lesson are not rivals so much as stages of one supply chain: prototype on the FPGA, commit to the ASIC, and sell the result to everyone whose workload fits — as a GPU.

money: ASIC = huge NRE + tiny unit cost; FPGA = zero NRE + high unit cost; crossover volume V^* = N/(f-a);
perf/watt for a fixed function: ASIC > FPGA > GPU > CPU — but GPU > FPGA for batched floating-point throughput with mature toolchains;
flexibility / time-to-market: CPU > GPU > FPGA > ASIC;
no comparison means anything until the workload is named;
the boundaries blur: FPGAs ship hard AI engines, structured ASICs split the difference, and GPUs are the default accelerator purchase.

The tidy three-way split is dissolving at every edge, and the hard-block logic of this module explains how. FPGA vendors, watching machine-learning workloads leak to GPUs, began hardening whole AI engine arrays — grids of little vector processors — beside the fabric: an FPGA wearing a GPU costume. Structured ASICs attack from the other side: dies with most mask layers prefabricated, customised by just the final metal layers — a fraction of the NRE for most of the efficiency, an ASIC wearing an FPGA costume. Meanwhile GPU vendors harden function-specific units (tensor cores, video encoders) into their "general" chips, making the GPU itself a bag of small ASICs. Even the crossover arithmetic blurs: cloud providers rent FPGAs and GPUs by the hour, converting your NRE-vs-unit-cost decision into an operating expense. The four axes still govern — you just have to score real products on them, not the textbook archetypes.

Both versions of this sentence appear in vendor slides, and both are meaningless as stated, because each is true for some workloads and false for others. Fixed-point streaming with microsecond deadlines — a radio front-end processing samples as they arrive, a market-data feed handler — plays to the FPGA: a custom pipeline computes at wire speed with no batching, and latency is deterministic to the nanosecond. Batched dense floating-point — training a neural network on ten thousand images — plays to the GPU: thousands of hardened FPUs, memory bandwidth an FPGA can only envy, and a decade of tuned libraries. Run each contender on the other's home turf and it loses embarrassingly, in both directions. So the professional reflex when anyone claims "X is faster than Y": ask "on what workload, at what batch size, at what latency bound, with how many engineer-months of tuning?" A performance claim without a named workload is an advertisement, not a measurement.