Verification and Design Review

Verification asks whether the hardware behaves as required. Design review asks whether the RTL, constraints, timing, reset strategy, CDC handling, implementation reports, and board evidence are strong enough to trust. A design is not ready because it compiles. It is ready when the evidence is coherent and the remaining risks are known.

Learning Objectives

You will learn to:

• separate functional verification from implementation signoff;
• convert requirements into checks, assertions, and review questions;
• use simulation, lint, synthesis reports, timing analysis, and CDC review together;
• recognize weak signoff statements such as "tested on board";
• prepare a concise FPGA release note with traceable evidence.

Prerequisites

• Basic RTL design in Verilog or VHDL.
• Familiarity with testbenches and waveform inspection.
• Basic constraints and static timing analysis.
• Awareness of resets, clock domains, and board-level pin planning.

The Verification Stack

Each layer catches a different class of problem. Simulation can prove behavior for tested scenarios, but it does not prove pin constraints, timing closure, or CDC safety. A blinking LED can prove some hardware activity, but it does not prove boundary conditions or register-map correctness.

Requirements First

Good verification starts with requirements that are specific enough to test:

• clock frequencies and tolerated jitter or drift;
• reset state and reset release behavior;
• input ranges, invalid values, and error flags;
• output timing, latency, and throughput;
• register map, write behavior, readback behavior, and reserved bits;
• clock-domain crossings and external asynchronous inputs;
• board pins, I/O standards, voltage banks, and safety limits.

If a requirement cannot be simulated, measured, reviewed, or inspected, rewrite it until it can.

Minimum Review Checklist

Assertions

Assertions turn design assumptions into executable checks. Even simple assertions catch bugs earlier than manual waveform browsing.

// A FIFO user must not read when no data is available.
always @(posedge clk) begin
    if (!rst) begin
        assert (!(rd_en && empty));
    end
end

Other useful checks:

• request remains stable until acknowledged;
• a one-hot FSM has exactly one active state;
• duty <= period for a PWM core after configuration is accepted;
• no write occurs outside the implemented register map;
• reset eventually leads to the documented idle state.

Lint, Warnings, And Report Hygiene

Warnings are review inputs. Do not normalize noisy builds. A warning that everyone ignores is no longer a warning.

Timing And Constraints Review

For every signoff build, record:

• requested clock period, for example 10 ns for 100 MHz;
• worst negative slack or worst positive slack;
• total number of failing setup and hold paths;
• critical path startpoint and endpoint;
• whether the path is logic-dominated, routing-dominated, or constraint-related;
• every timing exception and why it is valid.

Use the basic relationship:

Tclk = 1 / fclk
setup slack = required arrival time - actual arrival time

Positive setup slack means the path meets the requested period in the analyzed corner. Negative slack means the implemented circuit may sample late data.

CDC And Reset Review

CDC review should identify each crossing by name, source clock, destination clock, structure, and verification evidence.

Never justify a CDC by saying clocks are "almost the same." If timing does not define their phase relationship, the crossing is asynchronous.

Worked Example: PWM Signoff Note

A concise review note for a PWM peripheral might say:

• simulation covers reset, enable, period update, duty update, invalid duty, status clear, and period-boundary shadow load;
• assertions prove no invalid duty reaches the active comparator;
• lint warnings are zero after review;
• clock constrained at 100 MHz, so Tclk = 10 ns;
• implementation passes with 2.1 ns worst setup slack and 0.4 ns worst hold slack;
• no CDC exists except one synchronized button input;
• pin constraints match the board schematic and selected I/O bank voltage;
• hardware evidence includes an ILA capture at 25%, 50%, and 75% duty plus a scope measurement of the LED pin;
• known limitation: configuration changes take effect only at the next PWM period boundary.

That is stronger than "tested on board" because another engineer can inspect the claim.

Common Mistakes

• Treating hardware observation as the only verification.
• Reviewing HDL but not constraints.
• Accepting unconstrained paths without written explanation.
• Ignoring CDC because the clocks have related nominal frequencies.
• Letting the testbench print "passed" without checking outputs.
• Failing to document what was tested and what was not tested.
• Waiving warnings in bulk instead of explaining each relevant warning.

Practical Review Flow

1. Read the requirement list before reading RTL.
2. Run simulation and confirm the testbench is self-checking.
3. Run lint and classify warnings.
4. Review reset values, state machines, counters, and arithmetic widths.
5. Review constraints before trusting timing.
6. Read worst setup and hold paths.
7. Review every CDC and reset crossing.
8. Inspect resource use for unexpected DSP, BRAM, LUT, or register changes.
9. Collect board evidence with instrument settings and test conditions.
10. Write a short signoff note with remaining risks.

Summary

FPGA verification is layered. Requirements, simulation, assertions, lint, synthesis reports, timing, CDC review, and hardware validation all answer different questions. A design is release-ready when the evidence covers the requirements, the warnings and exceptions are understood, and the remaining limitations are documented.

Next: Capstone Exercise: FPGA Peripheral System.

Further Reading

• Verilator lint and simulation documentation
• SymbiYosys documentation for formal checks
• AMD and Intel timing closure methodology guides
• Vendor CDC verification and reset synchronization application notes

Mind Map