Part 2 · Phases & Lifecycle · Intermediate

Why Phases Summary: Mental Model & Review Checklist

Condensed mental model of the synchronization problem, phase solution, and a practical checklist before merging new env or VIP integration.

Mental model in three sentences

1) Large testbenches are distributed systems that need a shared clock — phases provide it. 2) Structural work is split into build then connect with enforced traversal. 3) Run-time work is task-based and ends via

objections, not integrator delays.

diagram
[UVM][PHASE] one-page map

WHY:
  composable VIPs + multi-team integration

WHAT:
  named callbacks on uvm_component

WHEN:
  scheduler traversal (TD/BU rules)

HOW LONG:
  function phases = 0 time
  task phases = real time

HOW TO STOP:
  objections + drain_time

Key takeaways

  • Phases are the integration API — not optional methodology decoration.

  • If you remember only one diagram, remember build->connect->run->cleanup.

  • Objections are the completion half of the synchronization story.

Common pitfalls

  • Memorizing phase names without understanding dependency direction.

  • Skipping motivation and fighting phases in run_phase later.

  • Treating objections as advanced optional material — they are core.


Pre-merge review checklist

Structural

  1. All children created in build_phase via type_id::create().

  2. All TLM connects in connect_phase only.

  3. print_topology after end_of_elaboration matches expectation.

  4. Factory overrides registered before affected create.

Behavioral

  1. No time control in any function phase.

  2. Reset/wait logic lives in run_phase or runtime sub-phases.

  3. Stimulus starts only after documented reset preconditions.

Completion

  1. Every stimulus path has matching raise/drop objections.

  2. No bare #delay or $finish for test completion.

  3. check_phase guards against zero-activity false passes.

systemverilog
function void check_phase(uvm_phase phase);
  super.check_phase(phase);
  if (scb.get_checked_count() == 0)
    `uvm_error("CHECK", "no transactions checked — false pass?")
endfunction
diagram
[PHASE] debug boot sequence

1) +UVM_PHASE_TRACE
2) end_of_elaboration print_topology
3) +UVM_OBJECTION_TRACE
4) check_phase counters

if still unclear:
  add PHASE build/connect logs on env + one agent

Key takeaways

  • A short checklist catches most integration regressions before wave debug.

  • Phase trace and objection trace are the highest-leverage debug switches.

  • Zero-txn check_phase turns silent false passes into loud failures.

Common pitfalls

  • Reviewing only block diagrams, not phase placement per component.

  • Merging VIP updates without re-running topology print.

  • Disabling check guards to greenwash a broken scenario.