UVM-SystemC Objections and Phase Drain Time

How to Read This Lesson

Phases are not magic time regions. They are methodology objects coordinated on top of the SystemC scheduler. Objections are the mechanism that tells a phase, "do not finish yet; useful verification work is still active."

Source and LRM Trail

Use Docs/LRMs/uvm-systemc-language-reference-manual.pdf for UVM-SystemC phasing and synchronization behavior. In source, inspect .codex-src/uvm-systemc/src/uvmsc, especially phase, component, report, and objection-related implementation files.

The Problem Objections Solve

In a testbench, many components may start activity during a run phase:

• sequences generate stimulus
• drivers consume items
• monitors observe interfaces
• scoreboards wait for expected responses

If the phase ended as soon as the top-level thread returned, the test could finish while responses are still in flight.

An objection says: this component has active work. Keep the phase alive until the objection is dropped.

Basic Pattern

void run_phase(uvm::uvm_phase& phase) override {
  phase.raise_objection(this);
 
  // start stimulus and wait for expected completion
  wait(100, sc_core::SC_NS);
 
  phase.drop_objection(this);
}

The exact API shape depends on the UVM-SystemC release and class context, but the modeling intent is stable: raise before activity, drop after activity.

Drain Time

Drain time handles a subtle issue: a component may drop its final objection, but other SystemC activity triggered by that work may still need a small amount of simulation time to settle.

Drain time gives the phase a controlled grace period before it concludes. It should be used carefully. If you need a large drain time, the testbench probably lacks a proper completion condition.

How This Interacts with SystemC

UVM-SystemC phasing is implemented in C++ on top of SystemC. The SystemC kernel still controls process execution, waits, events, and time advancement. UVM phases coordinate methodology-level state; they do not replace sc_start() semantics.

That means you debug phase hangs like this:

1. Which component still has an objection?
2. Which SystemC process is that component waiting in?
3. Which event or time delay should wake it?
4. Did a sequence, driver, or scoreboard miss a completion signal?

Review Checklist

• Is every raised objection dropped on all control paths?
• Are exceptions or early returns handled?
• Is drain time small and justified?
• Does the test have a real completion condition?
• Can reports identify the component that holds the final objection?