SoC teams tell the same story again and again: a chip team has to rewrite a dozen block-level agents because none of them can run passive, since each one assumed it owned its bus, and the rewrite costs more than the original block verification. Foundations exists so your benches never need that rewrite. It builds the mental model of UVM, then one complete, running testbench for the course's DMA, and shows why its structure survives the move from block to chip.
Explain why UVM exists, what it standardizes and what your project must still build.
Pick uvm_component or uvm_object for any class, and write an item's copy, compare and print methods.
Turn a spec feature into a testplan row with stimulus, a check and coverage.
Build, run and break a complete UVM bench, and explain every part of it.
Draw the four layers, reuse an agent active or passive, wire an env, coordinate agents, and debug a composed bench in a fixed order.
Topic | Lessons | What it covers | Time |
|---|---|---|---|
7 | Why UVM exists and where its edges are, the component-object fork, item utilities, the testplan triangle, and the complete DMA bench. | about 3 h | |
5 | The four layers, active and passive agents, env wiring, coordinating agents, and composition debug. | about 2 h |
uvm_object rather than a uvm_component?Items are transient data, created per transfer by the thousand, with no fixed place in the tree and no phases. Components are the persistent tree that items flow through. Components vs objects covers the fork and what follows from it.