A UVM bench stimulates with classes and judges with classes, but some rules are about cycles and internal state that no monitor sees. Those rules are assertions, and a senior engineer is expected to answer the integration questions around them: which rules go in a checker and which in the scoreboard, how a test switches one rule off without silencing the rest, how cover hits reach the closure report, how the same file serves a formal tool, and how a failure ends up in the verdict.
Place each DMA rule in its right home (bound checker, interface, monitor or scoreboard) and defend the choice.
Switch one rule off for one test and one instance, from class code, and know where $assertoff stops working.
Bring cover-property hits into the UVM report and the plan, and catch vacuous passes.
Keep one property file usable by both the UVM bench and a formal tool, and replay a counterexample as a UVM test.
Route assertion failures into the UVM verdict, waivers and quit count, and keep one root cause from flooding the log.
# | Lesson | The question it answers |
|---|---|---|
1 | The fault campaign missed DONE stuck at 1 and TLAST stuck at 0. Where does each missing check belong? | |
2 | A test breaks one rule on purpose. What is the narrowest switch, and why does | |
3 | How do cover hits reach the plan, and when is a passing assertion vacuous? | |
4 | What changes when the same file goes to a formal tool, and what comes back? | |
5 | One stuck flag gave 57 errors. How should assertion failures enter the verdict? |
Start with: Where Assertions Live.