Verification code review has a different failure cost than design review. A sloppy RTL block fails in simulation, but a sloppy testbench fails by passing: it stops checking, and nobody notices until silicon.
Three questions carry every review in this topic. Can this constraint set hide a legal-but-nasty case. Can this scoreboard compare nothing and report green. Can this assertion pass without ever firing.
REVIEW PASSES — order matters: architecture before syntax
pull request arrives
|
v
PASS 1 — INTENT
what is this change for, and does the approach fit the env
(wrong approach: stop and talk, not forty nits)
|
v
PASS 2 — CHECKING INTEGRITY
transactions: reachability, checked randomize, copy and compare
components: timing, reset, item_done, drain, fork hygiene
assertions: vacuity, reset gating, bounds, bin intent
|
v
PASS 3 — MAINTAINABILITY
naming, duplication, magic numbers, comments that lie
|
v
verdict: approve, approve with notes, or request changes
(block only on correctness and architecture; note the rest)Lesson | What you review | Path |
|---|---|---|
Reachability of the stimulus space, checked randomize calls, complete copy and compare. | Recommended | |
Driver timing and reset, monitor source of truth, scoreboard drain, fork hygiene. | Recommended | |
Vacuous passes, reset gating, liveness bounds, bins with plan intent. | Recommended | |
The three-pass method, comments that land, and the master checklist by artifact. | Required |
Path: Required is the core first pass for this topic, Recommended is what most learners should read, and Optional is reference, specialist or revision material you can skip at first.
The compare count and the leftover expected-queue depth. Zero compares, or a nonempty queue, means the green result checked nothing.