Every component in a UVM testbench is written by someone who never sees the whole tree. The phaser, the part of the UVM library that schedules phases, is what lets those pieces agree on when to be created, when to be wired, when to run and when to stop. This topic explains that agreement from the outside in: first the rules you rely on every day, then the machinery underneath them.
Draw the full phase schedule from memory, including run_phase running in parallel with the twelve runtime phases.
Predict the order in which the phaser visits every component of the DMA bench, and say which orders you must never depend on.
Explain why a driver's forever loop needs no exit, and why code placed after it never runs.
Spot a phase method the phaser will never call, by its signature alone.
Explain phase nodes, imps and states well enough to debug a phase_ready_to_end that never fires.
Lesson | What it answers |
|---|---|
Why components cannot simply build and wire themselves, shown on the DMA env. | |
The nine common phases, the twelve runtime phases beside run_phase, and the course's key phase picture. | |
Top-down and bottom-up walks, the name-order surprise, and why connect really goes bottom-up. | |
Zero-time walks versus forked threads, and how the phaser kills run_phase threads at the end. | |
Exact phase signatures, the old no-argument hooks, and how to prove a phase method runs. | |
Phase nodes versus imp singletons, phase states, callbacks, and how run_test drives the graph. |