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 |
|---|---|
Reachability of the stimulus space, checked randomize calls, complete copy and compare. | |
Driver timing and reset, monitor source of truth, scoreboard drain, fork hygiene. | |
Vacuous passes, reset gating, liveness bounds, bins with plan intent. | |
The three-pass method, comments that land, and the master checklist by artifact. |
The compare count and the leftover expected-queue depth. Zero compares, or a nonempty queue, means the green result checked nothing.