Your run_phase objections have all dropped. The objection trace shows the test's last drop at 2 ms. Yet the simulation keeps going, and check_phase does not start until 5 ms. Nothing is hung; something is still busy. The question is where, and the answer is a part of the schedule many engineers have never drawn: a second set of phases running beside run_phase.

The idea: two tracks that meet at extract

UVM has two families of phases. The nine common phases (build through final) run on every component in every testbench. The twelve runtime phases (pre_reset through post_shutdown) are optional, finer steps for the time-consuming middle. They do not come after run_phase, and they are not inside it. They run on a parallel track that starts when run_phase starts.

Picture two railway tracks leaving the same station at the same moment. One train (run_phase) goes straight through. The other stops at twelve small stations on the way. Both must arrive at the next junction, extract_phase, before anything after it can happen. If the stopping train is held at one of its stations, the junction waits, even though the express arrived long ago.

In library terms, these tracks are domains. run_phase and the other common phases belong to the common domain. The twelve runtime phases belong to the uvm domain (or to a user-defined domain), which is joined to the common domain so that it starts with run_phase and must finish before extract. Phase Domains and Sync covers user domains.

The picture: the full UVM phase schedule

Keep this picture. Almost every phase question in an interview, and almost every end-of-test bug, is answered by finding the right box in it.

The nine common phases and what lives in each

Eight of the nine are functions, so they run in zero simulated time: the first four at time 0, the last four at the moment the run phases end. Only run_phase can wait. The walk column is explained in Traversal Order Rules.

The twelve runtime phases

All twelve are tasks and run in order among themselves. Each has its own objection, so a phase ends only when no one objects to it. When nobody raises an objection in them, as in the DMA bench, they all pass through at time 0. Runtime Sub-Phases explains when to use them and why drivers stay in run_phase.

Build it: one component, every common phase

The skeleton below shows each common phase method with its exact signature. A real component overrides only the ones it needs. There is no objection here on purpose: raising and dropping belongs to the test or a sequence, never to a generic component.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

// snippet
class phase_demo extends uvm_component;
  `uvm_component_utils(phase_demo)

  function new(string name, uvm_component parent);
    super.new(name, parent);
  endfunction

  function void build_phase(uvm_phase phase);
    super.build_phase(phase);              // create children, read config
  endfunction
  function void connect_phase(uvm_phase phase);
    super.connect_phase(phase);            // wire ports, forward handles
  endfunction
  function void end_of_elaboration_phase(uvm_phase phase);
    super.end_of_elaboration_phase(phase); // audit the structure
  endfunction
  function void start_of_simulation_phase(uvm_phase phase);
    super.start_of_simulation_phase(phase);// banners
  endfunction
  task run_phase(uvm_phase phase);         // the only common task phase
    super.run_phase(phase);
  endtask
  function void extract_phase(uvm_phase phase);
    super.extract_phase(phase);            // collect numbers
  endfunction
  function void check_phase(uvm_phase phase);
    super.check_phase(phase);              // decide pass or fail
  endfunction
  function void report_phase(uvm_phase phase);
    super.report_phase(phase);             // print summaries
  endfunction
  function void final_phase(uvm_phase phase);
    super.final_phase(phase);              // close files
  endfunction
endclass

Three more callbacks exist on every component and are called for every phase, common and runtime: phase_started, phase_ready_to_end and phase_ended. They are how you hook the schedule itself; Inside the Phaser shows them in use.

Watch it run: both tracks in one log

This log comes from a copy of the smoke test that overrides phase_started and phase_ended to print each phase's full name (the ended line is printed only for run, main and post_shutdown):

UVM_INFO dma_tb.sv(...) @ 0: uvm_test_top [PH] started common.build
UVM_INFO dma_tb.sv(...) @ 0: uvm_test_top [PH] started common.connect
UVM_INFO dma_tb.sv(...) @ 0: uvm_test_top [PH] started common.end_of_elaboration
UVM_INFO dma_tb.sv(...) @ 0: uvm_test_top [PH] started common.start_of_simulation
UVM_INFO dma_tb.sv(...) @ 0: uvm_test_top [PH] started common.run
UVM_INFO dma_tb.sv(...) @ 0: uvm_test_top [PH] started uvm.uvm_sched.pre_reset
   ... reset through pre_main, all @ 0 ...
UVM_INFO dma_tb.sv(...) @ 0: uvm_test_top [PH] started uvm.uvm_sched.main
UVM_INFO dma_tb.sv(...) @ 0: uvm_test_top [PH] ended   uvm.uvm_sched.main
   ... post_main through shutdown, all @ 0 ...
UVM_INFO dma_tb.sv(...) @ 0: uvm_test_top [PH] started uvm.uvm_sched.post_shutdown
UVM_INFO dma_tb.sv(...) @ 655000: uvm_test_top [PH] ended   common.run
UVM_INFO dma_tb.sv(...) @ 655000: uvm_test_top [PH] ended   uvm.uvm_sched.post_shutdown
UVM_INFO dma_tb.sv(...) @ 655000: uvm_test_top [PH] started common.extract
UVM_INFO dma_tb.sv(...) @ 655000: uvm_test_top [PH] started common.check
UVM_INFO dma_tb.sv(...) @ 655000: uvm_test_top [PH] started common.report
UVM_INFO dma_tb.sv(411) @ 655000: uvm_test_top.env.sb [SB] 8 words matched, 0 mismatched
UVM_INFO dma_tb.sv(...) @ 655000: uvm_test_top [PH] started common.final

• common.run and uvm.uvm_sched.pre_reset start at the same time, 0. The prefix is the domain (and schedule) each phase belongs to.

• No one objects in the runtime phases, so main starts and ends at time 0. The DMA traffic all happens in run_phase.

• post_shutdown started at 0 but ended at 655000, together with run. The last runtime phase is held until run_phase is ready to end too, which is how the two tracks meet before extract.

• Extract, check, report and final all run at 655000, the time the run phases ended, not at time 0.

What breaks: the shutdown sequence nobody stopped

Back to the opening. A block team had added a background sequence that polls a status register, started from the test's shutdown_phase with its own objection "so the DUT is idle before we check". The poll loop waited for a FIFO-empty bit that, on one configuration, never set. The run_phase objections dropped on time, so the objection trace for run looked clean, and the team spent a day looking at the wrong phase.

The clue was in the schedule: extract waits for both tracks. A phase trace (+UVM_PHASE_TRACE) showed shutdown started and never ended, and the objection trace for that phase named the polling sequence. The fix was a bounded poll with an error on timeout. The lesson for debugging is to ask "which phase is still executing?" before asking "who holds the run objection?".

Next: the schedule says which phase runs; Traversal Order Rules says in what order the phaser visits the components inside one phase.

Related topics

• Traversal Order Rules

• Runtime Sub-Phases

• Phase Domains and Sync