Writing a testbench is a small part of a DV engineer's week. Most of it goes into the runs that fail, the runs that hang, and the runs that pass when they should not. This section is about that work: the instruments UVM ships for looking inside a running bench, a playbook for each class of failure, and the regression practice (seeds, triage, infrastructure, metrics) that keeps a bench honest at the scale of thousands of runs a night. Every example is a deliberately broken version of the course's DMA bench, with the log it really prints.
Classify a failing run from its last lines and pick the playbook for it: hang, mismatch, false pass or early end.
Use UVM's built-in instruments (topology, factory, config, objection and phase tracing, verbosity, recording) from the command line or from code.
Reproduce any regression failure from its seed and shrink it to a minimal case that a designer can act on.
Triage a night's failures by signature, and run a regression that shows when the bench itself stops catching bugs.
The first topic works through the loop on single failures. The second scales it to a regression: the same loop, run on the hundred failures of a night, where reproducing means a recorded seed and narrowing means grouping failures by signature.
Topic | What it covers |
|---|---|
The UVM debug instruments, and playbooks for hangs, scoreboard mismatches, false passes and early ends. | |
Seeds and replay, regression triage, regression infrastructure and CI, waveforms at scale, metrics and dashboards. |