Why UVM Has Phases Hub: The Synchronization Problem

Overview

UVM phases exist because large testbenches are distributed systems — dozens of independently authored components must agree on when to build, wire, run, and stop without a central integrator hand-ordering every line.

Phasing replaces fragile ad-hoc ordering with a library-enforced lifecycle contract that every component inherits. Each team writes only its own callbacks; the scheduler guarantees global order.

Sub-lessons in this topic

1. synchronization-problem — why multi-VIP integration needs a temporal contract.

2. without-phases-chaos — manual ordering anti-patterns and failure modes.

3. phased-construction-connection — build/connect guarantees and dependency satisfaction.

4. shared-timeline-contract — the implicit agreement every component signs.

5. motivation-case-studies — AXI+APB, reset, and scoreboard integration stories.

6. why-phases-summary — condensed mental model and review checklist.

[UVM][PHASE] why phases exist

problem:
  N teams, N VIPs, one top module
  who constructs first?
  who connects to whom?
  when does stimulus start?
  when is simulation truly done?

solution:
  standardized phase callbacks
  scheduler enforces traversal order
  objections signal completion

components know WHAT to do in each phase
library knows WHEN everyone does it

// Without phases: integrator owns global order (fragile)
// With phases: each component owns local callbacks (composable)

class my_agent extends uvm_agent;
  function void build_phase(uvm_phase phase);
    super.build_phase(phase);
    // create children — scheduler guarantees parent built first
  endfunction

  function void connect_phase(uvm_phase phase);
    super.connect_phase(phase);
    // wire TLM — scheduler guarantees all build_phase finished
  endfunction
endclass

Key takeaways

• Phases solve distributed coordination without central orchestration code.

• Construction, connection, and run-time start/stop become library guarantees.

• Composable VIPs are only practical when temporal order is standardized.

Common pitfalls

• Treating phases as ceremony — they are the integration contract.

• Bypassing phases with run_phase construction or build_phase TLM connect.

• Assuming sibling order inside one phase is portable across testbenches.