Ask ten experienced engineers what UVM is and you get ten lists of class names. Senior interviews want something different: why the library exists, where its edges are, and how its two kinds of class (the persistent tree and the data flowing through it) shape every testbench. This topic builds that mental model, then has you build, run and break a complete testbench for the course's DMA.
Tell the story of why UVM exists in two minutes, and say when you would not use it.
Draw the line between what UVM gives you and what your project must supply.
Choose between uvm_component and uvm_object for any class, and explain what follows from the choice.
Write an item's copy, compare and print methods by hand, and defend that choice against field macros.
Map a testplan row to stimulus, a check and coverage, and build, run and break a complete UVM bench.
Lesson | What it covers |
|---|---|
The OVM and VMM split, how UVM ended it, the three problems it solves, and when it is overkill. | |
Mechanism versus policy: what the library gives you, what you own, what the tool owns, and random stability. | |
The one fork in the class tree, the constructor tell-tale, lifetimes, and the errors you get when you cross it. | |
Field macros versus hand-written | |
Testplan rows, the three legs every feature needs, and the coverage hole hiding in a green regression. | |
Build, run and break the complete DMA bench used throughout the course. | |
Both files of the running example, ready to paste into EDA Playground. The testbench is listed in three parts. |