Design Flow: Synthesis, Place-and-Route, and Bitstream
The FPGA build flow turns a hardware description into a configured chip. The important stages are requirements, RTL design, simulation, synthesis, constraints, place-and-route, static timing analysis, bitstream generation, and board validation. Skipping one stage often moves the bug later, where it is harder to diagnose.
Learning Objectives
After this lesson, you should be able to:
- explain where HDL fits in the FPGA build flow;
- distinguish simulation, synthesis, place-and-route, and bitstream generation;
- describe why constraints are part of the design;
- identify what static timing analysis proves and what it does not prove;
- follow a small design from source files to board validation.
HDL Is a Hardware Description
This Verilog assignment:
assign y = (a & b) | c;
describes combinational hardware whose output is continuously driven by the expression. It does not ask a CPU to compute a & b, then compute an OR, then store a result.
The same idea in VHDL:
y <= (a and b) or c;
Both styles describe a circuit. The language differs, but the implementation goal is hardware.
The Full FPGA Flow
Simulation appears before hardware because functional bugs are cheaper to catch early. Static timing appears after implementation because real path delay depends on placement, routing, fanout, clocking, and selected FPGA resources.
What Each Stage Produces
| Stage | Main input | Main output | What to inspect |
|---|---|---|---|
| Requirements | behavior, rates, pins, interfaces | design checklist | missing timing or I/O facts |
| RTL design | Verilog or VHDL | modules and registers | unintended latches, clocking style |
| Simulation | RTL plus testbench | pass/fail and waveforms | edge cases, reset behavior |
| Synthesis | RTL | logic netlist | warnings, inferred resources |
| Constraints | pins, clocks, I/O standards | implementation rules | wrong pin, missing clock |
| Place-and-route | netlist plus constraints | physical implementation | utilization, route quality |
| Static timing | routed design | slack report | setup/hold failures |
| Bitstream | routed design | configuration file | correct target part |
| Board validation | programmed board | observed behavior | pinout, clocks, real inputs |
RTL: Register Transfer Level
Most beginner FPGA work is RTL. You describe:
- registers that update on clock edges;
- combinational logic between registers;
- finite-state machines;
- counters, timers, FIFOs, and memories;
- handshakes between blocks;
- interfaces to pins and board peripherals.
Good RTL makes the register boundaries clear. If a combinational path becomes too long, you add a pipeline register or restructure the logic. If an input crosses from another clock domain, you synchronize it or use a CDC-safe structure.
Constraints Are Design Inputs
An FPGA tool cannot guess every board and timing requirement. You must tell it:
- which top-level signal connects to which physical pin;
- what I/O voltage standard and drive strength are valid;
- what clock frequency each clock must meet;
- which paths are false, multicycle, asynchronous, or generated, if that is truly justified;
- what external setup/hold relationship applies for interfaces when relevant.
For a basic clock, the timing requirement is often written as a period:
Fclk = 1 / Tclk
Tclk = 1 / Fclk
For example, a 50 MHz clock has:
Tclk = 1 / 50,000,000 Hz = 20 ns
If the routed register-to-register path cannot settle within the available period after uncertainty and setup requirements, timing fails.
Static Timing Analysis
Static timing analysis checks timing paths without running a functional simulation. For setup timing:
setup slack = required time - arrival time
Positive setup slack means the path meets the requirement. Negative setup slack means the path is too slow for the declared clock or constraint.
For hold timing, the concern is different: data must not arrive too soon after the capturing clock edge. A design can pass setup and fail hold, especially when clocking or constraints are wrong.
Timing analysis does not prove your algorithm is correct. It proves that the implemented paths meet the declared timing constraints.
Worked Example: Button Toggles an LED
Requirement: each clean pushbutton event toggles an LED.
A reliable flow is:
- define button polarity, LED polarity, board clock frequency, and debounce requirement;
- write RTL for a button synchronizer, debounce counter, edge detector, and LED register;
- simulate reset, no press, one press, bounce-like transitions, and repeated presses;
- constrain clock, button pin, LED pin, and I/O standards;
- synthesize and check that registers, counters, and synchronizer stages were inferred;
- place-and-route and confirm timing passes;
- program the board and test the real button;
- if the LED behaves oddly, compare board schematic, active levels, constraints, and waveform assumptions.
If you skip the synchronizer, a real asynchronous button input can create metastability risk. If you skip debounce, one press may look like many transitions. If you skip constraints, you may drive the wrong pin or miss a timing failure.
Common Mistakes
- Writing HDL like sequential C code.
- Believing successful synthesis means correct behavior.
- Forgetting pin constraints, clock constraints, or I/O standards.
- Ignoring warnings because the bitstream was generated.
- Testing only on hardware and never writing a testbench.
- Adding false-path or multicycle constraints to hide a real timing problem.
- Treating static timing as a substitute for functional verification.
Summary
The FPGA flow transforms RTL into configured hardware through simulation, synthesis, constraints, place-and-route, timing analysis, bitstream generation, and board validation. Simulation checks behavior against test cases. Static timing checks implemented paths against declared timing. Constraints are part of the design, and a bitstream is not evidence by itself.
Next: Pin Planning and Constraints.
Further Reading
- Verilator documentation for linting and simulation.
- GHDL documentation for VHDL analysis and simulation.
- Vendor timing constraint and static timing analyzer user guides.
- Yosys and nextpnr documentation for synthesis and place-and-route stages.