Verification and Design Review

Verification asks: did we build the right hardware, and can we prove it? Design review asks whether the implementation, constraints, timing, CDC, reset strategy, and validation evidence are good enough to trust.

Learning Objectives

You will learn to:

separate functional verification from implementation signoff;
create a practical FPGA review checklist;
use lint, simulation, assertions, timing, and CDC checks;
document evidence before deploying hardware.

Verification Layers

flowchart TB A["Requirements\nwhat must happen"] --> B["RTL simulation\nfunctional behavior"] B --> C["Assertions/lint\nlocal correctness and style"] C --> D["Synthesis reports\nresources, inferred blocks, warnings"] D --> E["Timing analysis\nsetup/hold with constraints"] E --> F["CDC/reset review\nsafe crossings and release"] F --> G["Hardware validation\nboard evidence"]

No single layer proves everything.

Minimum Review Checklist

Area	Questions
Requirements	Are inputs, outputs, rates, errors, and reset behavior defined?
RTL	Are combinational and sequential blocks cleanly separated?
Testbench	Does it self-check normal, boundary, and error cases?
Constraints	Are clocks, pins, I/O standards, and generated clocks constrained?
Timing	Is worst slack positive? Are exceptions justified?
CDC	Is every crossing identified and handled?
Reports	Are warnings reviewed, not ignored?
Hardware	Is board validation documented with captures or logs?

Assertions

Assertions turn assumptions into executable checks. Example SystemVerilog idea:

// Never read from an empty FIFO.
always @(posedge clk) begin
    if (!rst) begin
        assert (!(rd_en && empty));
    end
end

Even simple assertions catch bugs earlier than manual waveform inspection.

Lint and Warnings

Treat warnings as design review input:

inferred latch;
width truncation;
unused signal;
unconnected port;
multiple drivers;
incomplete case;
unconstrained clock;
timing exception not applied.

Do not normalize noisy builds. A warning that everyone ignores is no longer a warning.

Worked Example: Signoff Note

For a PWM peripheral, a concise signoff record might say:

simulation covers reset, enable, duty changes, invalid duty, and period update boundary;
register map reviewed;
clock constrained at 100 MHz;
timing passes with 2.1 ns worst slack;
no CDC exists except synchronized button input;
hardware capture confirms PWM period and duty at 25%, 50%, and 75%;
known limitation: duty update takes effect at next period boundary.

That is far stronger than “tested on board.”

Common Mistakes

Treating hardware observation as the only verification.
Allowing unconstrained paths without explanation.
Ignoring CDC because “the clocks are almost the same.”
Reviewing HDL but not constraints.
Failing to document what was tested.

Summary

FPGA verification is layered. Use self-checking simulation, assertions, lint, synthesis reports, timing analysis, CDC review, and board validation together. A design is not ready because it builds; it is ready when the evidence is coherent.

Next: Capstone Exercise: FPGA Peripheral System.

Mind Map

mindmap root((Design Review)) Core concept Requirements trace Simulation coverage CDC review Timing review Applications Applications Release gate Team handoff Design checks Checks Warnings zero Constraints valid Common mistakes Common mistakes Reviewing code only Skipping reports