HomeFPGA from ScratchDay 4
DAY 4 · FPGA FOUNDATIONS

The FPGA Design Flow — RTL to Bitstream

By EcrioniX · Updated Jun 7, 2026

You write some Verilog. A few steps later, a chip physically becomes that circuit. What happens in between? That journey — from your code to a configured FPGA — is the design flow, and every FPGA project follows it. Today we'll walk each stage in plain English so the tools never feel like a black box again.

1. The big picture

In Day 1 we said an FPGA "becomes" your circuit when you load a bitstream. The design flow is the assembly line that produces that bitstream from your code. It's a pipeline of well-defined stages — and the tools run most of it for you:

1 · Design entry (RTL)Verilog / VHDL 2 · Simulationdoes it behave correctly? 3 · SynthesisRTL → netlist (LUTs/FFs) 4 · Implementationmap + place & route 5 · Timing analysisdoes it meet the clock? 6 · Bitstream genthe .bit file 7 · Configure FPGAload onto the chip ⚡ Constraintspins + clocks
Figure — The FPGA design flow: your RTL becomes a bitstream, guided by a constraints file.

2. Step 1 — Design entry (RTL)

You describe the circuit's behaviour in a hardware description language, usually Verilog or VHDL. This is RTL (Register-Transfer Level) — you say what happens to data between registers on each clock. This is the part you write; everything after is mostly automated.

3. Step 2 — Simulation (verify before hardware)

Before spending time building hardware, you check that the design does the right thing. A testbench feeds inputs and checks outputs in a simulator — exactly what our online Verilog simulator does. Catching a bug here takes seconds; catching it on a board takes hours. (Always simulate first!)

4. Step 3 — Synthesis (RTL → netlist)

Synthesis reads your RTL and converts it into a netlist — a description built from the FPGA's real building blocks (the LUTs and flip-flops from Day 2, plus hard blocks like BRAM/DSP). It figures out what hardware your code means and how to build it from available resources — but not yet where on the chip.

5. Step 4 — Implementation (map, place & route)

This is where the design is fitted onto the physical fabric:

This "place & route" (PnR) is the heaviest computation in the flow, and it's where most of your speed is won or lost.

6. Step 5 — Static timing analysis

Now the tools check: can the signals get where they need to go within one clock period? Static timing analysis (STA) examines every path against your clock constraint and reports timing met or violations. If a path is too slow, you fix the design or relax the clock. (We dive deep in Day 16; see also our STA guides.)

7. Steps 6–7 — Bitstream & configuration

Once timing passes, the tools generate the bitstream — the binary that sets every LUT, flip-flop and routing switch. Finally you configure the FPGA by loading that bitstream over USB/JTAG, and the blank chip instantly becomes your circuit. Power-cycle (on volatile FPGAs) and you re-load it — that's the "reprogrammable" magic.

8. The one file you write besides RTL: constraints

Tucked beside the flow is a small but essential file: constraints. It tells the tools two things they can't guess:

Xilinx/AMD calls these XDC files; the timing syntax derives from SDC. Forget the constraints and your LEDs won't light and timing can't be checked — beginners hit this constantly.

9. The toolchains

Vendor / toolRuns the whole flow for…
AMD VivadoXilinx FPGAs (Artix, Kintex, Versal…)
Intel QuartusIntel/Altera FPGAs (Cyclone, Arria…)
Yosys + nextpnropen-source flow (great for Lattice iCE40 / ECP5)

Here's a real open-source flow (Yosys synthesis → nextpnr place & route → bitstream) for a Lattice iCE40 board — copy or download it:

build.sh — open-source iCE40 flow
# RTL -> bitstream with the open-source toolchain (Lattice iCE40 example)
# 1) Synthesis: RTL (blink.v) -> netlist (.json)
yosys -p "synth_ice40 -top blink -json blink.json" blink.v

# 2) Place & route: netlist + constraints (.pcf = pins) -> .asc
nextpnr-ice40 --hx1k --json blink.json --pcf blink.pcf --asc blink.asc

# 3) Bitstream generation: .asc -> .bin
icepack blink.asc blink.bin

# 4) Configure the FPGA: load the bitstream onto the board
iceprog blink.bin

Four commands = the entire RTL-to-chip journey. Vivado/Quartus do the same stages behind a GUI (or Tcl scripts). We'll use simulation throughout the course and put a real design on an FPGA in Day 24.

💡 Like publishing a book

RTL is your manuscript. Simulation is proofreading. Synthesis typesets it into printable form. Place & route decides which words go on which page. Timing analysis checks it reads smoothly. The bitstream is the final print file, and configuration is printing the copy. You write the manuscript; the tools handle the press.

✅ Day 4 in one line

The FPGA flow turns your RTL into a bitstream through fixed stages: design entry → simulate → synthesize (→ netlist) → implement (map, place & route) → timing analysis → bitstream → configure the chip, guided by a constraints file (pins + clocks). Tools like Vivado, Quartus or Yosys+nextpnr automate it — you mainly write the RTL and the constraints.

🎯 Day 4 takeaways

Quick check

  1. What does synthesis produce, and what does place & route decide?
  2. Why should you simulate before building hardware?
  3. What two things does a constraints file specify?
  4. What is a bitstream and what does loading it do?

FAQ

What is the FPGA design flow?

The steps from RTL to a configured chip: design entry, simulation, synthesis, implementation (place & route), timing analysis, bitstream, configuration.

What is synthesis?

Converting RTL into a netlist of the FPGA's logic elements (LUTs, flip-flops, hard blocks).

What are constraints (XDC/SDC)?

A file specifying physical pin assignments and clock timing so the tools can place I/O and verify timing.

What is a bitstream?

The final binary that configures every LUT/flip-flop/routing switch, turning the blank FPGA into your circuit.

Previous
← Day 3: Hard blocks

← Back to the full roadmap  ·  Open the Verilog simulator →