Function vs Task Phases Hub: Signatures, Rules, and Discipline

Overview

Every UVM phase callback is either a function (zero simulation time) or a task (may consume time). Getting the type, name, and signature wrong is one of the most common silent UVM bugs.

Eight common phases are functions; run_phase and the 12 runtime sub-phases are tasks. Function phases build the machine; task phases run it.

Sub-lessons in this topic

1. function-phase-rules — zero-time constraints and allowed actions.

2. task-phase-rules — time control, objections, and fork discipline.

3. parallel-vs-serial — what runs in parallel during run-time.

4. phase-callback-signatures — exact names and argument types.

5. super-call-discipline — why super.phase(phase) is mandatory.

6. phase-method-debug — finding silent override failures.

[UVM][PHASE] method type map

FUNCTION (void, zero time):
  build, connect, end_of_elaboration, start_of_simulation
  extract, check, report, final

TASK (may consume time):
  run_phase
  + 12 runtime sub-phase tasks (reset/configure/main/...)

rule of thumb:
  structure/config/check -> function
  pins/events/sequences -> task

function void build_phase(uvm_phase phase);
  super.build_phase(phase);
  // NO #delay, NO @(event), NO wait()
endfunction

task run_phase(uvm_phase phase);
  super.run_phase(phase);
  phase.raise_objection(this);
  @(posedge vif.clk); // legal in tasks
  phase.drop_objection(this);
endtask

Key takeaways

• Function vs task is not stylistic — it is enforced by the scheduler.

• run_phase is the only common task phase; runtime sub-phases are also tasks.

• Exact signatures matter — typos silently disable overrides.

Common pitfalls

• Declaring run_phase as a function — compile error or wrong binding.

• Using #delay in build_phase to wait for reset.

• Skipping super — breaks automation and internal bookkeeping.