The FPGA Flow: RTL to Bitstream

You press one button — the tools call it "Generate Bitstream" — and somewhere between twenty minutes and a long lunch later, your RTL is a working chip. In that window, software solves a chain of genuinely hard problems: rewriting your logic into LUTs, deciding which of a hundred thousand tiles each one lives in, threading millions of wire segments between them, and then proving the result can keep up with your clock. Understanding this pipeline — what each stage does, what it produces, and which report to read when it finishes — is what separates an engineer from a button-presser. It is also a rehearsal: modules 4 and 5 walk the ASIC version of the same pipeline, where each stage gets deeper, slower and vastly more expensive to get wrong.

What you feed in: design plus constraints

The flow takes two kinds of input. The first is your RTL. The second — every bit as important — is the constraints file, which tells the tools two things the RTL cannot:

# constraints.xdc — the two essential declarations create_clock -period 10.000 [get_ports clk] # "clk runs at 100 MHz — make it work at that speed" set_property PACKAGE_PIN E3 [get_ports clk] # "the clk signal enters on physical pin E3" set_property PACKAGE_PIN H5 [get_ports led] # "led leaves on pin H5"

The pin assignments anchor your ports to the physical package (get one wrong and your LED design flashes a motor driver instead). The clock definition is the contract the whole flow works to satisfy: every register-to-register path must settle within one period. Without it the tools have no target — and no way to tell you they missed.

The six stages

Step through the pipeline — and notice that every stage hands a concrete artefact to the next, each one a little closer to physical:

Two of these stages are combinatorial optimisation problems of monstrous size. Placement must position hundreds of thousands of cells so that connected ones sit near each other — shorter wires mean less delay. Routing must then realise every net using the finite wire segments that actually exist, fighting congestion where too many nets want the same channel. Both are NP-hard; the tools attack them with heuristics, randomness and sheer iteration, which is why the same design can take different times (and reach different clock speeds!) on different runs.

Be the placer for a minute

Here is placement in miniature: six blocks, seven nets, a 4×4 grid. Scatter the blocks randomly, measure the total wire length (Manhattan distance per net), then greedily swap pairs whenever a swap helps — which is, in spirit, exactly what the real tools do at nation-state scale (Module 5 returns to this problem for ASICs):

// Nets: which pairs of blocks are connected. const nets: [number, number][] = [[0, 1], [1, 2], [2, 3], [3, 4], [4, 5], [0, 5], [1, 4]]; // A tiny seeded RNG so every run tells the same story. let seed = 20260728; function rand(n: number): number { seed = (seed * 1103515245 + 12345) % 2147483648; return seed % n; } // Random initial placement: 6 blocks dropped on distinct cells of a 4x4 grid. let cells: number[] = []; while (cells.length < 6) { const c = rand(16); if (!cells.includes(c)) cells.push(c); } const pos = (c: number) => [c % 4, Math.floor(c / 4)]; function wirelength(cs: number[]): number { let total = 0; for (const [a, b] of nets) { const [ax, ay] = pos(cs[a]), [bx, by] = pos(cs[b]); total += Math.abs(ax - bx) + Math.abs(ay - by); // Manhattan distance } return total; } function show(label: string, cs: number[]) { console.log(`${label} total wirelength = ${wirelength(cs)}`); for (let y = 3; y >= 0; y--) { let row = " "; for (let x = 0; x < 4; x++) { const i = cs.indexOf(y * 4 + x); row += i >= 0 ? ` B${i}` : " ."; } console.log(row); } } show("Before:", cells); // Greedy improvement: keep any pairwise swap that shortens the wires. let improved = true; while (improved) { improved = false; for (let i = 0; i < 6; i++) for (let j = i + 1; j < 6; j++) { const trial = cells.slice(); const t = trial[i]; trial[i] = trial[j]; trial[j] = t; if (wirelength(trial) < wirelength(cells)) { cells = trial; improved = true; } } } console.log(""); show("After greedy swaps:", cells); console.log("\nShorter wires = less delay = a faster clock. Now imagine 500,000 blocks.");

Watch the wirelength drop. Real placers add cleverness on top — simulated annealing to escape local minima, analytic solvers, timing-driven weighting so the critical nets get shortest — but the objective you just optimised is the genuine article.

The report culture

A flow run does not end with "done"; it ends with reports, and professionals read them the way pilots read instruments. The utilization report you met last lesson; the new one is the timing summary. Its centrepiece: the critical path — the slowest register-to-register path in your design — and the slack, the margin between that path's delay and the clock period. Positive slack on every path: the design meets timing, and the report quotes your achievable f_{max}. The arithmetic is worth having in your bones:

f_{max} = \frac{1}{T_{crit}} \quad\text{e.g.}\quad T_{crit} = 8\,\text{ns} \implies f_{max} = 125\,\text{MHz}

Negative slack — the dreaded red — means the critical path is too slow for the requested clock, and the loop begins: read the path listing (it names every LUT and wire on the offending path), then fix it — restructure the RTL (fewer logic levels, add a pipeline register), help the placer with a floorplan hint, or, honestly, lower the clock. Rerun. Read again. This edit–compile–report loop is minutes to hours on an FPGA. Hold that thought for the ASIC modules, where a full physical iteration takes weeks and the final "rerun" — a mask set — costs millions: the FPGA is the rehearsal stage where iteration is nearly free, which is precisely why industry prototypes ASIC designs on FPGAs first.

synthesis → generic netlist; technology mapping → LUT/FF netlist; placement → cells assigned tiles; routing → nets assigned wires; timing analysis → fmax and critical path; bitstream generation → the configuration file;
inputs are RTL plus constraints: pin assignments and clock definitions — the clock is the contract timing analysis checks;
the critical path is the slowest register-to-register path; f_{max} = 1/T_{crit}; negative slack = timing failed;
the flow is judged by its reports (utilization, timing summary, critical path) — and the whole loop takes minutes to hours, making the FPGA the cheap rehearsal for the ASIC flow.

For most of FPGA history the answer was a flat no: bitstream formats were trade secrets, so only Xilinx's or Altera's tools could target their chips. Then, in the mid-2010s, came one of open source's great reverse-engineering feats: the IceStorm project documented the bitstream of Lattice's little iCE40 parts bit by bit, and a complete free flow snapped into existence around it — Yosys for synthesis, nextpnr for place and route. The whole loop, RTL to configured silicon, runs in seconds for small designs, which transformed FPGA tinkering: continuous-integration servers now build hardware on every git push, exactly like software. The community has since opened up several larger families, and the vendors — who once sent lawyers after bitstream researchers — now sponsor some of the work. If you want to see a placer sweat, nextpnr even ships a GUI that animates the placement converging.

The most seductive line in any log file is "Bitstream generation completed successfully." It means only that the tools produced a circuit — not that the circuit keeps up with your clock. A design can sail through every stage and still carry negative slack: the flow will happily emit a bitstream for a design that fails timing (some tools print a warning; none refuse). Load it and you get the cruellest kind of bug — hardware that mostly works, then corrupts a value when the temperature rises or one particular data pattern exercises the critical path, because a register is being clocked before its input has settled. The discipline is absolute: read the timing summary after every run, and treat "met timing, worst slack +0.3 ns" — not "bitstream generated" — as the definition of success. Where that number comes from is the subject of static timing analysis, coming in the next module.