Why Objections Exist

Objections · Module 17 · Page 17.1

The Engineering Problem

A UVM test runs — the run_phase advances simulation time, driving stimulus, processing it through the DUT, observing and checking the results. But when should it stop? This is not a trivial question. The phase must keep going while there's work in flight — stimulus still being driven, transactions still in the DUT's pipeline, responses still arriving — and stop when the work is done. There is no fixed end time: how long a test takes depends on what it does (a short directed test vs a long random soak). And the work is distributed — many components run concurrently (drivers, monitors, sequences, scoreboards), so no single component knows when everything is finished. The naive answers all fail: a fixed timeout either cuts off work or wastes time; waiting for run_phase tasks to return doesn't work because many fork forever (monitors run perpetually). The problem this chapter solves is how UVM knows when to end a run-time phase — when all the distributed work is truly done.

The answer is the objection. An objection is a vote that says "work is still in progress — don't end the phase yet." A component raises an objection when it starts work and drops it when it finishes. The framework keeps a count of outstanding objections, and the phase stays alive while that count is greater than zero and ends when it returns to zero — i.e., when no component is objecting to ending. This lets components collectively decide when the phase may end: it ends when everyone agrees there is no more work. Typically the test (or a sequence) raises an objection before starting stimulus and drops it after — holding the phase open exactly as long as the work is in flight. This chapter is why objections exist: the problem of knowing when a test is done, why the naive approaches fail, and how the raise/drop/count-to-zero mechanism solves it.

How does UVM know when to end a run-time phase — when all the distributed, variable-duration work is truly done — and why do objections (raise while working, drop when finished, end when the count reaches zero) solve this where a fixed timeout or waiting for tasks to return both fail?

Motivation — why ending a phase is hard

Ending a run-time phase correctly is hard because the duration is unknown and the work is distributed. The reasons:

• The duration is test-dependent. A directed test might finish in microseconds; a random soak might run for milliseconds. There's no fixed number of cycles that's right for all tests — the phase must end based on whether work remains, not a preset time.
• A fixed timeout is wrong both ways. Set it too short and you cut off work mid-flight (a transaction still in the pipeline, a response not yet checked) — false results. Set it too long and you waste simulation time idling after the work is done. No fixed value is correct.
• Tasks that fork forever never return. You can't end the phase when run_phase tasks return, because many don't — monitors forever loops, drivers forever loops; they run perpetually. Waiting for them is waiting forever.
• The work is distributed across concurrent components. Drivers, monitors, sequences, scoreboards all run at once. No single component knows when everything is done — the driver finishing doesn't mean the DUT's pipeline is drained or the scoreboard has checked everything.
• Ending needs a collective decision. Since no one component knows, the decision must be collective — each component contributes "I still have work" / "I'm done," and the phase ends when all say done. This is a distributed consensus problem.

The motivation, in one line: a run-time phase has no fixed end time (duration depends on the test) and its work is distributed across concurrent components (no single one knows when all is done), so neither a fixed timeout (cuts off or wastes) nor waiting for tasks to return (they fork forever) can end it correctly — ending requires a collective, work-driven decision, which is exactly what objections provide.

Mental Model

Hold objections as a meeting that can't adjourn while anyone still has business:

Objections are like a meeting that can't adjourn while anyone still has business: each participant raises a hand to say 'I still have something to do,' and lowers it when done; the chair may adjourn only when every hand is down. No one participant knows when the whole meeting is finished — but collectively, when all hands drop, it is. Picture a meeting (the run-time phase) with many participants (the components — drivers, sequences, scoreboards). The meeting can't end while anyone still has business — a participant with work to do raises a hand (raises an objection: "I have business — don't adjourn") and lowers it when finished (drops the objection). The chair (the phase) watches the hands: while any hand is up, the meeting continues; only when every hand is down does the chair adjourn. The crucial property is that no single participant knows when the whole meeting is done — the sequence finishing its stimulus doesn't know whether the DUT's responses have all arrived, or the scoreboard has checked everything. But collectively, the hands encode it: while a participant has business, their hand is up; when all business is done, all hands are down — and that's the signal to adjourn. The chair doesn't guess (a fixed timeout — "adjourn after an hour regardless") and doesn't wait for everyone to leave (some participants — the monitors — never leave; they'd stay forever). The chair waits for the hands: raise while you have business, lower when done, adjourn when all are down. The count of raised hands is the single number that tells the chair whether to continue or adjourn — greater than zero: continue; zero: adjourn.

So objections are a meeting adjourning by consensus of raised hands: each component raises an objection while it has work and drops it when done; the phase (chair) continues while any objection is raised and ends when all are dropped (the count hits zero). No one component decides; the collective of raised/lowered hands encodes "are we done?", and the phase ends when the consensus is yes. Raise while you have work, drop when done, and the phase ends when no hand is up.

Visual Explanation — the objection count gates the phase

The defining picture is the gate: components raise and drop objections, the framework keeps a count, and the phase stays alive while the count > 0, ending at zero.

The figure shows the objection count as the gate on the phase. Components (A, B, C) raise objections when they start work and drop them when they finish — each contributing to the objection count (the total outstanding). The phase stays alive while the count is greater than zero and ends when the count returns to zero. The crucial reading is that the warning-colored count is the single signal that gates the phase: greater than zero means keep running (someone has work), zero means end (no one is objecting). The components don't coordinate with each other — each simply raises and drops its own objection, and the framework aggregates them into the count. This is the distributed nature made concrete: Component A doesn't know about B or C; it just raises while it's busy and drops when done. The framework sums all their objections, and the phase watches the sum. So the collective decision — "is all the work done?" — is encoded in the count: it's non-zero while any component has work, and zero only when every component is done. The success-colored phase ends at exactly the moment the count hits zero — the instant the last component drops its last objection. The diagram is the mechanism in one picture: raise/drop (components) → count (framework) → alive-while-positive/end-at-zero (phase) — a distributed, work-driven gate that ends the phase precisely when no work remains, without any component needing to know the global state.

RTL / Simulation Perspective — raise before work, drop after

In code, a component raises an objection before starting time-consuming work and drops it after — holding the phase open for exactly that work. The code shows the canonical pattern.

// === TEST: raise an objection before stimulus, drop it after — keeps run_phase alive ===
class my_test extends uvm_test;
  task run_phase(uvm_phase phase);
    my_seq seq = my_seq::type_id::create("seq");
    phase.raise_objection(this);        // "I have work — don't end the phase yet" (count: 0 → 1)
    seq.start(env.agt.seqr);            // the time-consuming work: drive stimulus, wait for it
    phase.drop_objection(this);         // "my work is done" (count: 1 → 0 → phase may end)
  endtask
endclass
// the phase stays alive from raise to drop — exactly as long as the stimulus is in flight.
 
// === Without the objection, the phase ends IMMEDIATELY (the DebugLab) ===
class broken_test extends uvm_test;
  task run_phase(uvm_phase phase);
    fork seq.start(env.agt.seqr); join_none;   // forked stimulus
    // ✗ NO raise_objection → count is 0 → phase ends NOW → stimulus never runs
  endtask
endclass
 
// === A monitor that forks forever does NOT keep the phase alive — it has no objection ===
class monitor ...;
  task run_phase(uvm_phase phase);
    forever begin @(posedge vif.clk); ... end   // runs forever, but raises NO objection
  endtask                                        // so it does NOT prevent the phase from ending
endclass

The code shows the canonical objection pattern and why it's needed. The test raises an objection before starting stimulus (phase.raise_objection(this) — count 0 → 1, "I have work"), runs the time-consuming work (seq.start(...) — drives stimulus and waits for it), and drops the objection after (phase.drop_objection(this) — count 1 → 0, "done"). The phase stays alive from raise to drop — exactly as long as the stimulus is in flight. The broken test shows the failure (the DebugLab): with no raise_objection, the count is zero, so the phase ends immediately — the forked stimulus never runs. The monitor shows a subtle point: a forever loop runs perpetually but raises no objection — so it does not keep the phase alive (it doesn't prevent ending). This is deliberate: monitors should not hold the phase open (they'd run forever); the phase end is gated by the stimulus (the test/sequence's objection), and when the stimulus is done, the phase ends — killing the forever monitors (which is fine; their work is done when there's no more stimulus to observe). The shape to carry: raise an objection before time-consuming work that must hold the phase open, drop it after — the phase lives from raise to drop. The test/sequence raises (it defines the work); monitors and drivers (which forever) don't raise (they follow the stimulus). The objection makes the phase wait for the stimulus to complete — not a fixed time, not forever.

Verification Perspective — collective, work-driven termination

Objections give collective, work-driven termination — each component contributes, and the phase ends when all the real work is done. Contrast with the naive approaches shows why this is right.

The figure contrasts objections with the naive approaches, showing why objections are right. A fixed timeout ends at a preset time, regardless of whether work remains — so it cuts off work (too short) or wastes time (too long): wrong both ways. Waiting for tasks to return never ends, because monitors and drivers fork forever — there's nothing to wait for that ever completes. Objections end the phase exactly when the work is done: components raise while working and drop when finished, and the phase ends when the count hits zero — work-driven, self-adjusting, collective. The verification insight is that the right termination is the one tied to the work, not to time (the timeout) nor to tasks returning (which they don't). Objections measure the work directly: the count is non-zero iff some component has work in flight, so the phase ends iff no work remains — precisely the condition you want. It's self-adjusting: a short test drops its objection early (short run); a long test holds it longer (long run) — automatically, without a preset time. And it's collective: each component contributes its own "I have work," and the aggregate decides — so the phase respects all the distributed work (the driver's stimulus, a sequence's completion, a scoreboard's drain), ending only when all of it is done. The figure is the argument for objections: terminate on the work, not the clock — the only model that ends a phase when (and only when) the work is actually finished, across all the distributed, variable-duration components. Objections are work-driven consensus; the alternatives are blind guesses.

Runtime / Execution Flow — the phase lifecycle with objections

At run time, the phase lives from the first raise to the last drop: it starts, components raise objections as they begin work, the phase stays alive while any are outstanding, and ends when the count returns to zero. The flow shows the lifecycle.

The flow shows the phase lifetime as from the first raise to the last drop. Start (step 1): run_phase begins; components are about to do their work. Raise (step 2): a component raises an objection as it begins work — the count goes positive, and the phase is held open. Run (step 3): the phase keeps running as long as any objection is outstanding (the count positive) — work in flight. End (step 4): as components finish, they drop their objections, lowering the count; when the last objection is dropped and the count reaches zero, the phase ends. The runtime insight is that the phase's lifetime is exactly the duration of the work: it lives from the first raise (when work begins) to the last drop (when all work finishes) — no longer, no shorter. This is why objections are self-adjusting: the phase automatically lasts as long as the work does, because its end is defined by the work's end (the count returning to zero). The critical subtlety — and the source of the DebugLab and later bugs — is the boundary conditions: if no objection is ever raised, the count is zero from the start, so the phase ends immediately (Step 4 before any work — the never-raise bug); if an objection is raised but never dropped, the count never returns to zero, so the phase runs forever (the never-drop bug, Module 17.5). The correct lifecycle is raise-when-work-starts, drop-when-work-ends — so the count tracks the work exactly, and the phase ends precisely when work does. The flow is the temporal map of objections: the phase opens with the first raise, stays open while work is in flight, and closes with the last drop — its lifetime is the work's lifetime, which is exactly the behavior a correct termination requires.

Waveform Perspective — the count rises and falls, the phase ends at zero

The objection mechanism is visible on a timeline: the count rises as components raise, the phase stays alive while it's positive, and the phase ends when the count falls to zero. The waveform shows the count gating the phase.

The waveform shows the count gating the phase. The phase is active (phase_active high) while work is in flight. A component raises an objection (raise pulses) and the objection count (obj_count) goes from 0 to 1 — holding the phase open; another raises and it goes to 2 (two components have work). As components finish, they drop (drop pulses) and the count falls — 2 → 1, then 1 → 0. The crucial visual is the instant the count reaches 0: the phase ends — phase_active goes low and phase_end pulses. The picture to carry is that the phase's lifetime is exactly while the count is positive — from the first raise (count 0 → 1) to the last drop (count 1 → 0). The count encodes "how many components have work," and the phase lives while it's positive and dies the moment it's zero. Reading this waveform — does the count track the raises and drops? does the phase end exactly when the count hits zero? — is reading the objection mechanism directly. The count rising, plateauing, and falling to zero, with the phase ending at that instant is the signature of objection-based termination: the phase opens with the first raise, stays open while any objection is outstanding, and closes the instant the count returns to zero — the work's lifetime, made into the phase's lifetime. And the boundary lessons are visible: if obj_count were never raised above 0, phase_active would never go high (end immediately); if it never returned to 0, phase_active would never go low (run forever).

DebugLab — the test that ended before it ran

✗ NO objection raised → count is 0 from the start → phase ends immediately:
  task run_phase(uvm_phase phase);
    fork seq.start(env.agt.seqr); join_none;   // forked stimulus
    // ✗ no raise_objection → objection count = 0 → UVM ends run_phase NOW
    // → the forked seq never gets to run → zero-time test, no stimulus
  endtask
 
✓ RAISE before the work, DROP after → phase held open while stimulus runs:
  task run_phase(uvm_phase phase);
    phase.raise_objection(this);     // count 0 → 1 → phase held open
    seq.start(env.agt.seqr);         // stimulus runs to completion (phase stays alive)
    phase.drop_objection(this);      // count 1 → 0 → phase may now end
  endtask

Common Mistakes

• Not raising an objection. With no objection, the count is zero and the phase ends immediately, before the work runs; raise to hold it open.
• Expecting forked tasks to keep the phase alive. A forever loop runs but raises no objection, so it doesn't prevent the phase from ending; the stimulus's objection gates the end.
• Relying on a fixed timeout to end the phase. A preset time cuts off work or wastes time; objections end the phase when the work is actually done.
• Raising after the work starts. The raise must precede the work; if the phase can end between start and raise, the work may be cut off.
• Thinking one component knows when everything is done. Termination is collective; each component raises and drops its own objection, and the framework aggregates.
• Forgetting the count starts at zero. The phase has nothing holding it open until something raises; never assume it waits on its own.

Senior Design Review Notes

Interview Insights

Exercises

1. State the problem. Explain why ending a run-time phase is hard, and why a fixed timeout and waiting for tasks both fail.
2. Trace the count. For a test with two components raising and dropping, sketch the objection count over time and mark when the phase ends.
3. Diagnose the zero-time test. A test finishes instantly with no stimulus. Name the cause and the fix.
4. Place the raise and drop. Write the run_phase bracketing of a stimulus sequence with raise and drop, and explain the lifetime.

Summary

• An objection is a vote that "work is still in progress — don't end the phase yet." A component raises one when it starts work and drops it when it finishes.
• The framework counts outstanding objections; the phase stays alive while the count is greater than zero and ends when it returns to zero — when no component is objecting — so the many concurrent components collectively decide when the phase may end.
• Objections solve a real problem: a run-time phase has no fixed end time (duration is test-dependent) and its work is distributed (no single component knows when all is done), so a fixed timeout (cuts off or wastes) and waiting for tasks to return (monitors fork forever) both fail.
• The phase's lifetime is exactly from the first raise to the last drop — the duration of the work; no objection raised means the count is zero and the phase ends immediately (before the work runs).
• The durable rule of thumb: a run-time phase ends as soon as the objection count is zero — so raise an objection (raise_objection before the work) to hold the phase open while there's work, and drop it (drop_objection after) when done; termination is work-driven and collective, not a fixed timeout or waiting for forever-tasks, and without an objection the phase ends instantly, before your stimulus runs.

Next — Raising an Objection: the mechanism in detail — how raise_objection works, where and when to call it (the test, the sequence, or a component), the role of the optional description and count, and the patterns for raising objections correctly so the phase is held open for exactly the work that matters.