Lesson 23/2592%

MODULE 23 OF 25 20 MIN FPGA FUNDAMENTALS

FPGA Development Flow Overview

The complete journey from design specification to running hardware — RTL coding, simulation, synthesis, place and route, timing closure, bitstream generation, and in-system debug with ILA.

Why the FPGA Design Flow is Different

In software development, compiling translates source code into machine instructions that run on a fixed processor. In FPGA development, the equivalent process physically places hardware — it assigns each logic primitive to a real location on silicon and routes actual interconnects between them. This is why FPGA compilation (called implementation) takes minutes to hours rather than seconds, and why understanding the flow is essential before writing a single line of RTL.

Key Insight Unlike an MCU where you flash firmware onto fixed hardware, an FPGA design becomes the hardware. Each synthesis and implementation run produces a unique physical circuit tailored to your design and device.

The Complete FPGA Design Flow

graph TD A[Design Specification] --> B[RTL Coding Verilog VHDL SystemVerilog] B --> C[Functional Simulation Vivado xSim ModelSim] C --> D{Sim Pass?} D -->|No fix bugs| B D -->|Yes| E[Synthesis synth_design] E --> F[Check Utilization and Synthesis Warnings] F --> G[Implementation Place and Route] G --> H[Static Timing Analysis report_timing_summary] H --> I{WNS >= 0?} I -->|No timing fail| J[Timing Closure Pipeline Floorplan Strategy] J --> G I -->|Yes| K[Bitstream Generation write_bitstream] K --> L[Program FPGA Vivado Hardware Manager] L --> M[Hardware Debug ILA VIO JTAG] M --> N{Design OK?} N -->|No RTL bug| B N -->|Yes| O[Design Complete]

Step-by-Step Walkthrough

Design Specification

Define clock frequencies, interfaces, latency requirements, and resource budgets before writing code. Create a block diagram identifying major functional modules — which go in PL fabric vs PS (for Zynq) and which will use Xilinx IP Catalog cores. Poorly specified requirements are the number one cause of FPGA project overruns.

RTL Coding — Verilog / VHDL / SystemVerilog

Write synthesizable Register Transfer Level (RTL) code describing how data flows between registers on each clock edge. Verilog is dominant in industry. High-Level Synthesis (HLS via Vitis HLS) lets you describe behaviour in C/C++ and the tool generates RTL automatically.

// Synthesizable 4-bit synchronous counter
module counter #(parameter WIDTH = 4) (
  input  wire             clk,
  input  wire             rst_n,
  input  wire             en,
  output reg  [WIDTH-1:0] count
);
  always @(posedge clk) begin
    if (!rst_n)   count <= {WIDTH{1'b0}};
    else if (en)  count <= count + 1'b1;
  end
endmodule

RTL Best Practices Register all module outputs. Never create combinational loops. Use parameters for data widths. Keep each module to one clock domain. These habits eliminate 90% of common synthesis and timing problems.

Functional Simulation

Simulate RTL behaviorally — no gate delays, pure logic checking. Write a testbench that drives inputs and verifies outputs. Vivado includes xSim (free); ModelSim/QuestaSim are industry standards. Catch all logical bugs here — simulation is 10-100x faster to debug than hardware. Aim for more than 90% statement coverage before synthesis.

Synthesis

Vivado maps your RTL to FPGA primitives: LUT6, FDRE, CARRY4, RAMB36E1, DSP48E1. Run synth_design -top mydesign -part xc7a35tcpg236-1. Check the synthesis report for utilization and warnings. Fix all critical warnings — especially inferred latches and undriven nets — before proceeding.

Synthesis Warning	Cause	Fix
Inferred latch for signal X	Combinational always block missing else clause	Add default assignment or else branch
Net X is undriven	Signal declared but never assigned	Remove or connect the signal
Multiple drivers on net X	Two always blocks drive same signal	Merge into one always block
Timing not met during synthesis	Very long combinational paths	Add pipeline registers
Black box instantiation	Module not found in project	Add missing file to project sources

Implementation — Place and Route

Vivado places each primitive at a physical FPGA location then connects them through the routing fabric. This is timing-driven: the tool uses your XDC clock constraints to optimize for speed. Runtime ranges from 2 minutes (small design) to 8+ hours (large Virtex-7 design). Vivado offers multiple implementation strategies — Default is fastest; Performance_ExplorePostRoutePhysOpt recovers 5-15% timing margin at 3x longer runtime.

Static Timing Analysis (STA)

After routing, Vivado calculates actual signal delays through every path. Run report_timing_summary -file timing.rpt. The key metric is Worst Negative Slack (WNS) — must be 0 or positive for timing to be met. Worst Hold Slack (WHS) must also be non-negative. Total Negative Slack (TNS) shows the total extent of all failing paths.

Critical Rule A design with negative WNS will have random, intermittent failures in hardware — the flip-flop sometimes samples data before it has settled. Never ship a design with timing violations. The failures are non-deterministic and extremely difficult to debug in the field.

Timing Closure Techniques

Problem	Root Cause	Solution
Setup violation on long path	Too much logic between registers	Insert pipeline register to break the path
High routing congestion	Too much logic packed in one area	Create Pblock to spread logic across fabric
Clock skew causing hold violations	BUFG placement issue	Check BUFG placement; add set_clock_groups
False path showing as critical	Missing XDC constraint	Add set_false_path or set_multicycle_path
High fanout net slowing timing	One register drives 10,000+ loads	Use BUFG or replicate the register
Marginal timing across the board	Sub-optimal implementation	Switch to Performance_ExplorePostRoutePhysOpt

Bitstream Generation

Once timing is met, generate the binary configuration file: write_bitstream -force design.bit. The bitstream encodes all LUT INIT values, routing switch settings, IO standards, clock configurations, and BRAM initial contents. Enable compression and AES-256 encryption for production to protect IP and reduce flash size.

Hardware Programming

Open Vivado Hardware Manager, connect to the JTAG cable, right-click the device, and select Program Device. DONE pin goes high on the board. For production, the bitstream is stored in SPI flash so the FPGA loads automatically on every power-up.

Hardware Debug with ILA and VIO

ILA (Integrated Logic Analyzer) is Xilinx's built-in logic analyzer. Add (* mark_debug = "true" *) to any RTL net; Vivado inserts an ILA core and connects it to those signals. After programming, set a trigger condition in Hardware Manager and capture up to 64K samples per channel at full clock speed. VIO (Virtual IO) lets you drive signals and read status in real time from the PC without physical IO pins.

// Mark signals for ILA capture in RTL before synthesis
(* mark_debug = "true" *) wire [15:0] data_bus;
(* mark_debug = "true" *) wire        valid;
(* mark_debug = "true" *) wire        overflow_flag;

// After synthesis: Vivado Set Up Debug wizard connects ILA automatically

Essential XDC Constraints Reference

# Define primary clock at 100 MHz
create_clock -period 10.000 -name sys_clk [get_ports sys_clk_p]

# Clock from MMCM output
create_generated_clock -name clk_250 -source [get_pins mmcm_inst/CLKIN1] \
  -multiply_by 5 -divide_by 2 [get_pins mmcm_inst/CLKOUT0]

# IO timing
set_input_delay  -clock sys_clk -max 3.0 [get_ports {data_in[*]}]
set_output_delay -clock sys_clk -max 2.0 [get_ports {data_out[*]}]

# Ignore paths between unrelated clock domains
set_clock_groups -asynchronous -group {sys_clk} -group {clk_250}

# Pin assignments
set_property PACKAGE_PIN E3       [get_ports sys_clk_p]
set_property IOSTANDARD  LVDS     [get_ports sys_clk_p]
set_property PACKAGE_PIN T22      [get_ports {led[0]}]
set_property IOSTANDARD  LVCMOS33 [get_ports {led[*]}]

Typical Design Flow Time Distribution

Interview Question Q: What is the difference between setup and hold timing violations in FPGA design?

A: A setup violation means data arrives at a flip-flop less than t_setup before the clock edge — fix by reducing logic depth (pipeline stages) or lowering clock frequency. A hold violation means data changes less than t_hold after the clock edge — fix by adding delay buffers on the data path. Setup violations are the common case in FPGA designs; hold violations are typically fixed automatically by Vivado's router inserting delay cells.

Pro Tip Run report_cdc and report_methodology after every implementation. These commands catch CDC hazards (missing synchronizers), unconstrained clocks, and common design rule violations that do not appear as timing failures but cause real, hard-to-diagnose hardware failures.

Knowledge Check

1. What does Worst Negative Slack (WNS) greater than or equal to zero indicate?

The design has unused logic resources
All timing paths meet their constraints — timing is closed
The implementation ran in under one hour
The bitstream file is ready with no further checks needed

WNS ≥ 0 means every flip-flop has adequate setup margin. All paths meet timing. This is required before generating a bitstream for production hardware.

2. What does an "inferred latch" synthesis warning mean?

A RAMB36E1 was automatically used for memory inference
A DSP48E1 replaced a LUT multiplier
A combinational always block has a missing else clause — creating unintended sequential state
The tool inferred a FIFO from the RTL pattern

An inferred latch is almost always a bug. It happens when a combinational always block assigns a signal in some conditions but not all, so the synthesizer creates a latch to hold the last value. Fix: add a default assignment at the top of the always block.

3. What Xilinx debug core captures internal FPGA signals like a logic analyzer?

VIO — Virtual IO core
ILA — Integrated Logic Analyzer
JTAG boundary scan
IBERT — Integrated Bit Error Ratio Tester

ILA captures internal FPGA signals in real time, storing up to 64K samples per channel in BRAM. You trigger it on specific conditions from Vivado Hardware Manager and view waveforms just like an external oscilloscope — no physical probe needed.

4. What is the correct fix for a setup timing violation caused by too many LUTs in series?

Switch to a faster FPGA package
Insert a pipeline register to break the long combinational path
Add a set_false_path constraint to ignore the path
Reduce the clock period in the XDC file

Adding a pipeline register splits the long path into two shorter paths, each meeting the clock period requirement. This adds one cycle of latency but is the correct, sustainable fix. Using set_false_path would hide a real timing issue.

5. What RTL attribute marks a net for automatic ILA connection in Vivado?

(* keep = "true" *)
(* dont_touch = "true" *)
(* mark_debug = "true" *)
(* use_dsp = "yes" *)

The (* mark_debug = "true" *) attribute tells Vivado to preserve this net through optimization and connect it to an ILA probe. After synthesis, use "Set Up Debug" to configure the ILA depth, trigger, and capture settings.

6. What XDC command declares a clock generated by an MMCM output?

create_clock
create_generated_clock
set_clock_groups
set_output_delay

create_generated_clock defines a clock derived from another clock — such as an MMCM output. It specifies the multiply/divide relationship to the source clock, allowing Vivado's timing engine to correctly analyze all paths in both domains.

Practical Exercise

Mini Design Challenge — Complete Flow on Artix-7 Work through these steps targeting XC7A35TCPG236-1 in Vivado:

Step 1 — RTL: Write a Verilog 8-bit up/down counter with synchronous reset and direction control.
Step 2 — Testbench: Verify count increments, decrements, and resets over 100 clock cycles.
Step 3 — Simulate: Run behavioral simulation in xSim. Check the waveform.
Step 4 — XDC: Create constraints: create_clock -period 5.0 [get_ports clk] (200 MHz target).
Step 5 — Synthesize: Check utilization — expect ~8 FFs, ~4 LUTs, 0 BRAM, 0 DSP.
Step 6 — Implement: Run implementation. Check WNS in timing summary.
Step 7 — Timing Report: Run report_timing -max_paths 5. Identify the critical path.
Step 8 — ILA: Add (* mark_debug = "true" *) to the count output. Re-synthesize, set up debug, program, and observe.

Summary

The FPGA design flow transforms RTL source code into a physical circuit through nine distinct stages: specification, RTL coding, functional simulation, synthesis, implementation, static timing analysis, bitstream generation, hardware programming, and in-system debug. Unlike software compilation, each stage has physical significance — timing closure ensures every flip-flop has adequate setup margin, and the ILA debug core lets you observe internal signals without an oscilloscope probe on every pin. Master this flow and you have the foundation for any FPGA project.