A regression farm runs the same compiled bench thousands of times. What changes between runs is a test name, a seed, a handful of plusargs and, now and then, a fault hooked into a driver. This topic is about those levers: how each one really works inside the library, how it fails quietly, and how a senior engineer keeps it under control.
Add, order, switch off and debug callbacks, and choose between a callback, a factory override and a virtual hook for a given change.
Use every built-in UVM plusarg with its exact syntax, and build a project plusarg registry that turns typos into errors.
Explain why adding a component does not change stimulus but adding one random call does, and replay a failing seed exactly.
Port code between UVM 1.2 and IEEE 1800.2 from a concrete delta table, including the deltas that change behaviour silently.
Find where a bench spends its time, with measured costs for field macros, config_db, reports, objections and callbacks.
# | Lesson | The question it answers |
|---|---|---|
1 | In which order do two callbacks run, what does an empty callback site cost, and why did a fault never fire? | |
2 | What does each built-in plusarg do exactly, and which typos are silent? | |
3 | Why did a one-line debug edit move every random job, and how do you replay a seed? | |
4 | Which differences break the compile, and which change behaviour without a word? | |
5 | Where does a UVM bench spend its time and memory, and what do the fixes buy? |
Start with: Callbacks done right.