FPGA Development Flow: From HDL to Working Hardware

Detailed Explanation

The FPGA development flow is a software toolchain pipeline that transforms HDL source code into a binary configuration file (bitstream) that programs the FPGA's internal SRAM. Unlike compiling software for a CPU — which produces machine instructions to execute — the FPGA toolchain physically constructs a digital circuit inside the chip: assigning logic to specific hardware cells, routing wires through a programmable interconnect fabric, and verifying that every signal propagates within its timing budget.

This page follows the flow from simulation through to programming a device. For HDL writing — Verilog modules, always blocks, blocking vs non-blocking assignments, and latch avoidance — see How Do You Write Verilog and VHDL for an FPGA? first. For background on what FPGAs contain (LUTs, BRAM, DSP blocks) and when to choose one over a microcontroller or ASIC, see What Is an FPGA and How Does It Work?.

Step 1: Simulate Before Synthesising

Before running synthesis, simulate the design to verify its logical behaviour. Synthesis cannot catch logic bugs — it only catches structural issues (undeclared wires, syntax errors). A combinational error that produces the wrong output will synthesise cleanly, route cleanly, and fail silently in hardware.

Common HDL simulators include Vivado Simulator (XSIM, bundled with Vivado and free), Icarus Verilog (free and open-source, good for quick verification), Verilator (converts Verilog to fast C++ simulation), and ModelSim/Questa (industry standard for large projects). Test bench structure and simulation workflow are covered in How Do You Write Verilog and VHDL for an FPGA?.

Step 2: Synthesis

Synthesis reads your Verilog or VHDL source and produces a technology-mapped netlist — a list of connected FPGA primitives (LUTs, flip-flops, BRAM, DSP blocks) with no physical location assigned yet.

What the synthesis tool infers from your HDL:

Running synthesis in Vivado:

1. Set the top module in Project Settings → General → Top.
2. Optionally select a synthesis strategy: Vivado Synthesis Defaults for most designs; Flow_PerfOptimized_high to allow more aggressive optimisation on timing-critical paths.
3. Run Synthesis (Flow Navigator → Run Synthesis, or F11).
4. After completion, open the Utilisation Report: review LUT%, FF%, BRAM%, and DSP%. Designs projecting above roughly 80% LUT utilisation frequently encounter routing congestion and timing closure difficulties — consider a larger device before proceeding.
5. Open the Schematic view (Open Elaborated Design → Schematic, or search "Schematic" in the Flow Navigator) to verify that BRAM and DSP inference is happening as expected.

Running Analysis & Synthesis in Quartus Prime:

1. Set the top-level entity (Project → Set as Top-Level Entity).
2. Run Analysis & Synthesis (Processing → Start → Start Analysis & Synthesis, or Ctrl+K).
3. Review the Compilation Report → Resource Usage summary and any synthesis warnings.

Critical synthesis warnings to address before proceeding:

• [Synth 8-327] inferring latch for variable 'x' — an unintentional latch from a signal not assigned in all branches of a combinational block. Fix with a default assignment at the top of the always block before any if/case statement.
• [Synth 8-3332] Sequential element has no clock — a register-like construct without a clock connection; usually a structural error in the HDL.
• [Synth 8-3936] Found unconnected internal register — dead logic that is optimised away; may indicate a missing connection or incorrect sensitivity list.

Do not proceed to implementation if synthesis produces latch inference warnings — unintentional latches behave incorrectly in silicon even when they simulate correctly.

Step 3: Implementation — Place and Route

Implementation takes the synthesised netlist and performs two sequential operations: placement and routing.

Placement assigns each LUT, flip-flop, BRAM, and DSP block to a specific physical location in the FPGA's array of logic cells. The placer uses a cost function that balances wire length (shorter wires reduce routing delay), timing criticality (timing-critical paths get priority placement to minimise delay), and routing congestion (densely packed regions are avoided). Timing-driven placement is the default in both Vivado and Quartus: paths with tight timing constraints drive the placer to co-locate their logic.

Routing connects placed primitives through the FPGA's hierarchical programmable interconnect — local routing within a small region, regional routing across a clock region, and global routing across the full device. Routing resources are finite: at high LUT utilisation (commonly above roughly 80%), routing becomes congested. Congestion forces signals onto longer detour paths, which increases delay and causes timing failures that are very difficult to resolve without reducing logic density.

Implementation strategies in Vivado:

Run implementation via Flow Navigator → Run Implementation (this runs placement, routing, and optionally physical optimisation in sequence).

After implementation, the Placed Design and Routed Design views in Vivado show each primitive's physical location on the die — useful for verifying that related logic is co-located and for diagnosing where routing congestion is occurring.

Step 4: Timing Analysis and Timing Closure

This is the most important and most challenging step. A design with unresolved timing violations will fail unpredictably in hardware — wrong outputs, intermittent resets, or data corruption that only appear under specific conditions or after a device warms up. Timing closure is the process of ensuring that every signal in the design propagates correctly within its allocated time budget.

Writing Timing Constraints

Timing constraints tell the toolchain what clock frequencies and I/O timing requirements must be met. They are expressed in a Xilinx Design Constraints (.xdc) file for Vivado, or a Synopsys Design Constraints (.sdc) file for Quartus.

The primary constraint is the clock definition — this example defines a 100 MHz clock (10 ns period) on the clk input port:

create_clock -period 10.000 -name sys_clk [get_ports clk]

Additional common constraints:

set_input_delay  -clock sys_clk 2.000 [get_ports data_in]
set_output_delay -clock sys_clk 3.000 [get_ports data_out]

set_clock_groups -asynchronous \
    -group [get_clocks clk_A] \
    -group [get_clocks clk_B]

set_multicycle_path 2 -setup \
    -from [get_cells reg_source] \
    -to   [get_cells reg_dest]

These four constraints handle the most common timing situations: set_input_delay declares that source data arrives 2 ns after the clock edge at the source; set_output_delay requires data to be stable 3 ns before the next clock edge at the destination; set_clock_groups -asynchronous disables timing analysis between two unrelated clock domains; set_multicycle_path 2 -setup tells the analyser that a path legitimately takes two clock cycles to complete.

Timing constraints must be defined and applied before running implementation — they drive placement and routing decisions. A design placed and routed without constraints is optimised for area, not timing. Adding constraints afterwards produces poor results because the physical placement is already fixed.

Every clock in the design must be explicitly constrained. Unconstrained clocks are treated as having infinite period — paths through them are not optimised for timing and will fail at real frequencies.

Reading the Timing Report

After implementation, the Timing Summary report (Reports → Timing → Timing Summary in Vivado) contains the key metrics:

A typical failing path entry in the Timing Report looks like:

Slack:               -0.800ns  (timing constraint NOT met)
Source:              reg_a/C   (rising edge of sys_clk)
Destination:         reg_b/D   (rising edge of sys_clk)
Data Path Delay:     10.950ns  (logic 3.412ns + routing 7.538ns)
Clock Period:        10.000ns
Clock Uncertainty:   0.150ns
Required Time:       9.850ns   (10.000 - 0.150)
Arrival Time:        10.650ns
Slack = 9.850 - 10.650 = -0.800ns

The path fails because the data takes 10.650 ns to propagate (including clock jitter adjustments), but only 9.850 ns is available. The fix must either reduce the data path delay or increase the clock period budget.

To find the critical path, click on the WNS value to open the path details. The routing delay column identifies whether the violation is dominated by logic depth (too many LUT stages in series) or routing delay (long wires forced by placement).

Timing Closure Strategies

1. Pipeline the critical path. Inserting a register stage breaks a long combinational chain into shorter segments, each of which fits within the clock period:

// Before: 8-input combinational tree — may not meet a 100 MHz constraint
always @(posedge clk)
    result <= (a & b) ^ (c | d) ^ (e & f) ^ (g | h);

// After: two-stage pipeline — each stage fits easily at 100 MHz
always @(posedge clk) begin
    pipe1 <= (a & b) ^ (c | d);
    pipe2 <= (e & f) ^ (g | h);
end
always @(posedge clk)
    result <= pipe1 ^ pipe2;

Pipelining adds one clock cycle of latency but allows a substantially higher clock frequency. It is the most reliable long-term timing closure strategy.

2. Run phys_opt_design after routing (Vivado). This physical optimisation pass relocates cells, inserts buffers, and remaps logic after routing to resolve small timing violations — typically closing paths that are within roughly a few hundred picoseconds of the constraint. Enable in Implementation Settings → phys_opt_design, or run manually in the Tcl console: phys_opt_design.

3. Change the implementation strategy. Performance_ExplorePostRoutePhysOpt enables more aggressive post-route optimisation. Performance_ExploreWithRemap allows logic remapping during routing. Try different strategies before making HDL changes.

4. Enable retiming during synthesis. Synthesis can automatically move registers across combinational logic to balance pipeline stage depths (RETIMING in Vivado synthesis settings). This can resolve imbalanced pipeline stages without manual HDL changes, but requires simulation verification to confirm that the register movement preserves intended latency behaviour.

5. Add placement constraints (PBLOCKs). Forcing related logic into the same physical clock region reduces routing delay on critical paths:

create_pblock pblock_dsp_core
add_cells_to_pblock [get_pblocks pblock_dsp_core] [get_cells dsp_inst]
resize_pblock [get_pblocks pblock_dsp_core] \
    -add {CLOCKREGION_X0Y1:CLOCKREGION_X1Y1}

PBLOCK constraints are most effective when routing delay dominates (shown as high routing delay in the path report), not when logic depth dominates.

6. Reduce the clock frequency. If the application can tolerate a lower frequency, reduce the clock period constraint. A design targeting 200 MHz that closes at 160 MHz is often fully usable — confirm the frequency requirement before spending time on aggressive optimisation.

Step 5: Bitstream Generation

After achieving full timing closure (WNS ≥ 0 ns, TNS = 0 ns, WHS ≥ 0 ns), generate the bitstream:

• Vivado: Flow Navigator → Generate Bitstream. Tcl equivalent: write_bitstream -force design.bit
• Quartus: Processing → Start → Start Assembler. Generates a .sof file for JTAG or a .jic/.pof file for flash programming.

The bitstream encodes the complete SRAM configuration of the FPGA: which truth table each LUT implements, which routing switch connections are made, what I/O standard and drive strength each pin uses, and the initial values of flip-flops and BRAM. For AMD/Xilinx devices the output is a .bit file with header information or a headerless .bin file suitable for direct SPI flash programming.

SRAM volatility: FPGA configuration is held in SRAM and is immediately lost when the device powers down. The bitstream must be reloaded on every power cycle — from external SPI flash in a production design, or from JTAG during development.

Step 6: Programming the Device

JTAG programming (development):

Connect a compatible programmer — Xilinx Platform Cable USB II, Digilent JTAG-HS3, or a compatible adapter — to the JTAG port (TDI, TDO, TCK, TMS) of the target board. In Vivado: Flow Navigator → Open Hardware Manager → Open Target → Auto Connect → Program Device. Select the .bit file and click Program. This is volatile — the FPGA loses its configuration when powered off.

SPI configuration flash (production):

An external SPI or Quad-SPI flash stores the bitstream permanently. On power-up, the FPGA loads its configuration from the flash automatically in Master SPI boot mode. In Vivado Hardware Manager, after programming via JTAG:

1. Right-click the device → Add Configuration Memory Device.
2. Select the SPI flash part matching your board (e.g., s25fl128sxxxxxx0 for a 128 Mb Spansion part).
3. Right-click the flash device → Program Configuration Memory Device → select the bitstream .bit file and program.

On the next power cycle, the FPGA configures from the flash without JTAG. The DONE LED (if present on the board) goes high when configuration completes successfully.

MCU-hosted programming (field update):

A host MCU with SPI access to the FPGA's configuration flash can overwrite the bitstream programmatically — enabling field-updatable firmware without physical JTAG access. AMD/Xilinx MultiBoot divides the flash into a golden (factory) partition and an update partition, with automatic failback to the golden image if the update fails to configure. Always implement a golden fallback for any field-updatable FPGA design.

The Open-Source Toolchain (Lattice and Others)

For Lattice iCE40 and ECP5 FPGAs, an open-source toolchain exists as an alternative to vendor tools:

• Yosys — open-source synthesis (reads Verilog; produces a technology-mapped netlist for Lattice or other supported devices)
• nextpnr — open-source place-and-route supporting iCE40, ECP5, and Nexus families
• Project IceStorm / Project Trellis — the device databases that nextpnr uses for physical mapping
• iceprog / ecpprog — open-source programmers for Lattice iCE40 and ECP5 devices

The open-source flow is practical for learning, for designs that fit within Lattice device capabilities, and for projects with an open-source licensing requirement. It lacks hard IP support (high-speed transceivers, PCIe, DDR controllers), has less mature timing closure optimisation than Vivado or Quartus, and is limited to devices with published bitstream documentation.

Design Considerations

Size the device for roughly 60–70% utilisation, not 100%. Run synthesis early — even on a partial design — to get a utilisation projection. High LUT utilisation causes routing congestion, which causes timing failures that are difficult to resolve without moving to a larger device. Reserve headroom: a design at 70% utilisation has room for debugging logic, future features, and routing slack.

Set timing constraints before implementation, not after. Constraints drive the placer and router to make timing-aware decisions. Routing a design without constraints and then applying them to an already-placed netlist consistently produces worse timing than constraining from the start. Establish clock constraints and I/O delays as early as the first complete implementation run.

Use vendor IP cores for standard functions. PLLs/MMCMs, FIFO generators, DDR memory controllers, and PCIe cores are available from the IP catalog and are timing-verified for the target device family. Reimplementing these from HDL is rarely justified and typically produces a worse result in terms of timing, area, and reliability.

Constrain all clock domain crossings explicitly. Any signal crossing between two asynchronous clock domains must be declared to the timing tool. Without set_clock_groups -asynchronous, the tool may attempt timing analysis across the boundary and produce false violations — or worse, optimise paths that rely on asynchronous synchronisation. For real-world clock domain crossing failures, see the FPGA clock domain crossing forum discussion.

Keep simulation and synthesis source files separate. Testbench files use non-synthesisable constructs (#delay, initial, $readmemh, file I/O). In Vivado, simulation sources are managed in a separate simulation fileset. In Quartus, exclude testbench files from the synthesis file list. Accidentally including testbench constructs in synthesis produces errors or incorrect logic.

If your design requires professional FPGA implementation, HDL development, or integration with a custom PCB, Zeus Design provides electronics engineering consultancy across the full hardware and firmware stack.

Common Mistakes

Not simulating before synthesis. Synthesis cannot catch logic bugs. A combinational mistake synthesises cleanly, routes cleanly, and produces wrong outputs in hardware. Hardware debugging of a logic error — without a simulation that already demonstrates the failure — is extremely time-consuming. Simulate all non-trivial logic before running the toolchain.

Missing or incomplete timing constraints. A design without clock constraints synthesises and routes without timing awareness. It may appear to work at low frequencies and fail intermittently at the target frequency, across temperature, or across production units. Always constrain every clock, and add input/output delays to constrain I/O paths. Unconstrained paths are never timing-safe.

Proceeding past high LUT utilisation. When synthesis projects LUT utilisation above roughly 80%, routing congestion will cause timing violations during implementation that cannot be resolved by strategy changes alone. The correct response is to move to a larger device or reduce logic density — not to fight placement constraints in an undersized part.

Declaring timing met on marginally positive WNS. A WNS of +0.050 ns satisfies the hard constraint, but leaves almost no margin for temperature variation, voltage droop, or silicon spread across production units. Many designs target at least several hundred picoseconds of positive WNS for production reliability — the appropriate margin depends on the clock frequency, environmental operating range, and device speed grade. Check the device datasheet's speed grade derating guidelines.

Omitting configuration flash from the PCB. SRAM-based FPGAs require a configuration flash for production use. A design without one requires JTAG to program on every power-up — an impractical manufacturing and field support requirement. Plan the bitstream delivery mechanism during PCB design, including configuration flash footprint, decoupling, and JTAG access header. For integration of FPGA configuration flash into the PCB layout, the PCB design cluster covers high-speed routing and decoupling placement principles that apply to configuration memory interfaces.