Example Walkthrough: Verifying the FIFO
Every mechanism, methodology, and process across this curriculum's 20 pages now exists. This capstone doesn't introduce anything new — it applies all of it to the same synchronous FIFO Testbench and UVM already built full environments for, showing what a real verification effort around that testbench actually looks like end to end.
The verification plan, excerpted
Per The Verification Plan's format, a real plan for this FIFO would include rows like:
| Feature | Requirement | Coverage goal | Checking mechanism | Status |
|---|---|---|---|---|
| Full boundary | Writing while full is asserted must not corrupt existing data | Cross: wr_en asserted, full asserted | Scoreboard compares queue contents before/after | Closed |
| Empty boundary | Reading while empty is asserted must not return stale data as valid | Cross: rd_en asserted, empty asserted | Scoreboard checks no read transaction recorded | Closed |
| Data integrity | Bytes read out must match bytes written, in order | Functional coverage: full data range on wr_data | Scoreboard reference-model comparison, every read | Closed |
| Full/empty mutual exclusion | full and empty never asserted simultaneously | N/A — protocol invariant, not a data scenario | Concurrent assertion (SVA), checked every cycle | Closed |
The last row is worth noting specifically: not every requirement in a real plan maps to a functional coverage bin — the full/empty mutual-exclusion property is exactly the kind of thing Assertion-Based Checking already built for this FIFO, and a verification plan should name which mechanism closes each row, not assume every row needs the same kind of check.
These four rows are deliberately an excerpt, not the complete plan — a genuinely complete one for this FIFO would add rows for scenarios the excerpt doesn't show: back-to-back writes that hit full on consecutive cycles (not just a single write-while-full attempt), a simultaneous read and write occurring in the exact same cycle the FIFO is full (does the read draining one entry correctly allow that cycle's write through, or does the boundary logic get this ordering wrong), and reset asserted while full is already asserted (does the FIFO correctly return to empty, or does stale full-state logic survive the reset). Each is a real, distinct corner beyond what the four excerpted rows already cover — exactly the kind of additional row a thorough plan keeps adding as more of the design's actual edge cases get identified.
Applying the CDV loop
The CDV Loop applied concretely: the generator built in Testbench randomizes write/read transactions across multiple seeds; the scoreboard measures both functional coverage (per the plan above) and code coverage on the FIFO's own RTL; analysis of an early coverage report might reveal the full+write-attempt cross bin rarely fills, since random stimulus alone rarely produces a write attempt at exactly the moment the FIFO is full — the refine step tightens the generator's constraints to bias toward that boundary specifically, rather than writing one brittle directed test for it.
The signoff checklist
Every domain from Section D gets an explicit entry — including the ones that turn out not to meaningfully apply, marked so deliberately rather than silently skipped:
| Check | Applicable to this FIFO? | Status |
|---|---|---|
| Functional coverage | Yes | 98%, remaining bins under formal review |
| Code coverage | Yes | 100% statement/branch, toggle clean |
| Formal (assertion) | Yes — full/empty mutual exclusion | Proven, non-vacuous |
| CDC | Only if instantiated across a clock boundary | N/A for a single-clock-domain instance |
| RDC | Yes — reset synchronization on rst_n | Clean |
| Lint | Yes | Clean, zero violations |
| GLS / X-propagation | Yes | Clean against synthesized netlist |
| Power-aware | Only if instantiated inside a switchable power domain | N/A for this standalone example |
| Timing (SDC review) | Yes | Constraints reviewed, no front-end-visible issues |
Two rows are explicitly N/A, not silently omitted — CDC only applies once this FIFO is instantiated somewhere that actually crosses a clock boundary, and power-aware verification only applies once it sits inside a domain that's actually switched. A real checklist names every category and marks non-applicability deliberately, exactly so a reviewer can tell "considered and doesn't apply" apart from "forgotten."
The signoff decision
Per Verification Signoff & Metrics: 98% functional coverage with the remaining 2% under formal review (not just left open), 100% code coverage, a non-vacuous proven assertion, every applicable specialized check clean, and — the signal a percentage alone can't provide — a bug-discovery curve that flattened three regression cycles ago. That combination, not any single number in it, is what a real signoff decision is actually made of.
What's next
This closes the Verification curriculum — 20 pages across 6 sections, from why verification is worth its cost, through coverage-driven and formal verification, six specialized front-end domains researched specifically for this site, and the process that turns all of it into an actual signoff decision. UPF remains the one topic still a stub on this site; every other verification-adjacent topic — SystemVerilog, Testbench, UVM, and now Verification itself — is complete.