Interview Question · Concept

What a Monitor Samples

L0 FresherL1 Junioruvmmonitoranalysis

The interviewer asks

What does a UVM monitor do? At which moment should it turn pin activity into a transaction?

Reveal the Model Answer

A monitor only watches the pins; it never drives them. It builds a transaction at the edge where the DUT accepts the data, for example where valid and ready are both 1. It then publishes the transaction through an analysis port to the scoreboard and coverage. It creates a new object for every transaction, because write() passes a handle, not a copy.

Seven edges with valid high, three transfers

Columns are rising edges. A monitor that looks only at valid reports 32 and 48 three times each. The design took each value once, at an edge where ready was also 1.

Observe the Accepted Input and the Actual OutputThe monitor reads both sides of the design. It does not use the driver’s item as evidence that a transfer happened.

Offer10 ns (illustrative)
The driver presents 16 at a falling edge and holds valid high. An offer alone creates no input transaction.
Follow the calls, values and waits
1. Waiting: Input pins — waiting for acceptance
Accept and record15 ns (illustrative)
Both handshake signals are high. The design accepts 16, and the input monitor publishes the value sampled on that same edge.
Follow the calls, values and waits
1. data x = 16: Input pins → Incrementer
2. data x = 16: Input pins → Input observation
3. data x = 16: Input observation → Checking path
4. Released: Input pins
Drive the resultJust after 25 ns (illustrative)
The design’s nonblocking updates put 17 and out_valid = 1 on the pins. At the 25 ns sampling edge, the monitor still saw the old out_valid = 0.
Follow the calls, values and waits
1. data y = 17: Incrementer → Output pins
2. Waiting: Output observation — next sampling edge
Record the output35 ns (illustrative)
The output monitor now samples out_valid = 1 and y = 17. It publishes the observed result for comparison with the independent prediction.
Follow the calls, values and waits
1. data y = 17: Output pins → Output observation
2. data y = 17: Output observation → Checking path
3. Released: Output observation

Read the diagram as text

Input pins: valid, ready and x at the edge
Incrementer: Accepts 16; later produces 17
Output pins: out_valid and y at the edge
Input observation: A fresh item with x = 16
Checking path: Predict from input; compare output
Output observation: A fresh result with y = 17

Input pins → Incrementer: accepted x
Incrementer → Output pins: result pins
Input pins → Input observation: sample input
Input observation → Checking path: input item
Output pins → Output observation: sample output
Output observation → Checking path: result item

Arrows carry sampled values or transaction data, not connection calls. The two monitor boxes are the two sides of one monitor component.

Self-Check

Tick each key point you covered in your answer.

Key point 1 A monitor only watches the pins; it never drives them. Key point 2 It builds a transaction at the edge where the DUT accepts the data, for example where valid and ready are both 1. Key point 3 It then publishes the transaction through an analysis port to the scoreboard and coverage. Key point 4 It creates a new object for every transaction, because write() passes a handle, not a copy.

What Interviewers Listen For (Fresher)

A good fresher answer says the monitor only watches the signals and never drives them. It also says, without being asked, that the monitor records a transaction when valid and ready are both 1.

Cross-Questions

Where the interviewer goes next. Open a node to practise that follow-up.

WhyWhat IfProve ItCompareScale It

What a Monitor Samples
WhyWhy a Reused Object Breaks the ScoreboardL1 Junior
Why does a reused object break the scoreboard, while a coverage collector on the same port looks fine?
2:30

You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.

Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
Reveal the Model Answer

A coverage collector samples the fields inside write() and keeps nothing afterwards. A scoreboard stores the handle so it can compare later. When the monitor refills the same object, the stored item changes under the scoreboard. A new object per beat gives each stored item its own data.

Three References Can Still Mean One ObjectWith reuse enabled, this is the state at 45 ns: refilling object A changes what every holder can read.

First transfer15 ns (illustrative)
The monitor fills object A with x = 16 and writes it. The recorder saves the handle; the checker’s get returns the same handle and reads x = 16 to start its 50 ns of work.
Follow the calls, values and waits
data handle to A: Object A → Recorder entry
data handle to A: Object A → Checker variable
data x = 16: Object A → Checker variable
Waiting: Checker variable — working for 50 ns
Refill and write again45 ns (illustrative)
With reuse enabled, the monitor refills the same object A with x = 32 and writes it again. The FIFO queues a handle to A, the object the recorder and the busy checker still hold.
Follow the calls, values and waits
data handle to A: Object A → FIFO entry
The checker reads x again65 ns (illustrative)
The checker finishes its first item and reads x through its handle: 32, not the 16 the pins carried at 15 ns.
Follow the calls, values and waits
data x = 32: Object A → Checker variable
Released: Checker variable

Read the diagram as text
Recorder entry: Saved during the first transfer
FIFO entry: Queued by the second transfer
Checker variable: Still processing the first transfer
Object A: x = 32; previously x = 16
Recorder entry → Object A: handle
FIFO entry → Object A: handle
Checker variable → Object A: handle

These arrows are references, not copies or calls. When the checker reads x at 65 ns, the same object now holds 32.

Self-Check
Tick each key point you covered in your answer.
Key point 1 A coverage collector samples the fields inside write() and keeps nothing afterwards. Key point 2 A scoreboard stores the handle so it can compare later. Key point 3 When the monitor refills the same object, the stored item changes under the scoreboard. Key point 4 A new object per beat gives each stored item its own data.
Misconception

"Each subscriber gets its own copy, so subscribers are isolated."

The analysis port loops over its connections and passes one handle to all of them. Nothing is copied unless someone calls clone().

Source uvm-core 2020.3.1 (IEEE 1800.2 library) source, tlm1/uvm_analysis_port.svh
- Lesson U7.2Who Owns an Analysis Transaction
CompareNew Object in the Monitor vs Clone in the SubscriberL1 JuniorL2 Mid-Level
Compare creating a new object per beat in the monitor with cloning the item inside each subscriber.
2:30

You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.

Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
Reveal the Model Answer

A new object in the monitor costs one allocation per beat and protects every subscriber at once. Cloning in subscribers puts the duty on every listener, and one careless listener can corrupt the others. The usual rule: the monitor creates, subscribers treat the item as read-only, and a subscriber that must change it clones it first.

One Subscriber Keeps Handles, the Other Keeps ClonesA monitor that reuses one item, and two subscribers. Arrows show handles moving: write passes the monitor's handle on, and push_back stores a handle in a queue. Only clone() makes a new object.

The first observation10 ns (illustrative)
The monitor writes x=16, y=17 into seen and calls ap.write(seen). Both subscribers receive the same handle.
Follow the calls, values and waits
data x=16 y=17: Monitor → seen
data handle to seen: Monitor → keeper
data handle to seen: Monitor → snapshot
A handle, or a clone10 ns (illustrative)
keeper stores the handle it received. snapshot calls t.clone(), which makes a new object holding x=16, y=17, and stores that.
Follow the calls, values and waits
data handle to seen: keeper → keeper.kept
data clone: x=16 y=17: snapshot → snapshot.kept
The same object, refilled20 ns (illustrative)
The monitor writes x=127, y=128 into seen and publishes it again. keeper stores a second handle to the one object; snapshot stores a second clone.
Follow the calls, values and waits
data x=127 y=128: Monitor → seen
data handle to seen: Monitor → keeper
data handle to seen: keeper → keeper.kept
data handle to seen: Monitor → snapshot
data clone: x=127 y=128: snapshot → snapshot.kept
And once more30 ns (illustrative)
x=255 and y=0, since y has 8 bits and 256 wraps to 0. keeper now holds three handles to seen, and snapshot three separate clones.
Follow the calls, values and waits
data x=255 y=0: Monitor → seen
data handle to seen: Monitor → keeper
data handle to seen: keeper → keeper.kept
data handle to seen: Monitor → snapshot
data clone: x=255 y=0: snapshot → snapshot.kept
What each queue printsreport phase (illustrative)
Every keeper entry reads the object as it is now: x=255 y=0 three times. snapshot prints x=16 y=17 | x=127 y=128 | x=255 y=0.

Read the diagram as text
Monitor: reuse_monitor
seen: the one item object
keeper: keeps the handle t
snapshot: keeps t.clone()
keeper.kept: handles
snapshot.kept: one clone per write
Monitor → seen: refills x, y
Monitor → keeper: write(seen)
Monitor → snapshot: write(seen)
keeper → keeper.kept: push_back(t)
snapshot → snapshot.kept: push_back(c)

Assignment and write share an object; clone() makes a second one.

Self-Check
Tick each key point you covered in your answer.
Key point 1 A new object in the monitor costs one allocation per beat and protects every subscriber at once. Key point 2 Cloning in subscribers puts the duty on every listener, and one careless listener can corrupt the others. Key point 3 The usual rule: the monitor creates, subscribers treat the item as read-only, and a subscriber that must change it clones it first.
Half-Truth

"Cloning in every subscriber is the safest choice."

It is safe only if every subscriber, including ones added later by other teams, remembers to clone. A rule enforced in one place, the monitor, is easier to keep.
- Lesson U7.2Who Owns an Analysis Transaction
- Problem U7.2.1A Scoreboard Among Careless Listeners
What IfA Monitor Under Back-PressureL1 Junior
Asked if they say "sample when valid is high"

What if ready stays low for three cycles while valid is high?

Reveal the Model Answer

A monitor that samples on valid alone reports that one beat four times. The scoreboard then sees four inputs for one transfer and fails later, far from the cause. Coverage also counts stall cycles as transfers. Sample only at an edge where valid && ready is true.

Self-Check
Tick each key point you covered in your answer.
Key point 1 A monitor that samples on valid alone reports that one beat four times. Key point 2 The scoreboard then sees four inputs for one transfer and fails later, far from the cause. Key point 3 Coverage also counts stall cycles as transfers. Key point 4 Sample only at an edge where valid && ready is true.
- Lesson U7.1Monitor the Event the DUT Accepts
- Problem 6.1.1Count the Real Transfers
CompareProtocol Checks in the Monitor or the InterfaceL2 Mid-LevelL3 Senior
Should protocol checks live in the monitor, or as assertions in the interface?

Reveal the Model Answer

Cycle rules, such as "valid holds until ready", fit best as SVA in the interface or in a bound checker. They fire at the exact cycle, and formal tools can reuse them. Transaction rules, such as a length that matches its payload, fit in the monitor or a checker class. Many teams keep both, with a switch such as checks_enable per agent.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Cycle rules, such as "valid holds until ready", fit best as SVA in the interface or in a bound checker. Key point 2 They fire at the exact cycle, and formal tools can reuse them. Key point 3 Transaction rules, such as a length that matches its payload, fit in the monitor or a checker class. Key point 4 Many teams keep both, with a switch such as checks_enable per agent.

What Interviewers Listen For (Senior)
A good senior answer puts cycle rules in bound assertions that formal tools can reuse. It keeps transaction rules in classes, and gives each agent a switch to turn its checks off.

Wrong Altitude

"Put every check in the scoreboard."

The scoreboard sees transactions after the fact. A handshake rule broken for one cycle may never become a transaction it can see.
Prove ItSolve U7.4.1: The Checker That Fails NothingSimulator-graded

Show it, don't just say it: this Silicon Lab problem is graded by the simulator.
Open Problem U7.4.1
Prove ItSolve 6.3.1: The Monitor That Read the Next BeatSimulator-graded

Show it, don't just say it: this Silicon Lab problem is graded by the simulator.
Open Problem 6.3.1
Scale ItA Monitor That Survives SoC ReuseL2 Mid-LevelL3 Senior
At SoC level, the same agent watches an internal bus that nothing in the bench drives. What must the monitor already do right?

Reveal the Model Answer

It must work with no driver and no sequencer, using only the pins. It must not read the driver's variables or rely on its timing. Its analysis port must carry complete transactions that a system scoreboard can use. A monitor that peeks into the driver breaks the first time its agent is made passive.

Self-Check
Tick each key point you covered in your answer.
Key point 1 It must work with no driver and no sequencer, using only the pins. Key point 2 It must not read the driver's variables or rely on its timing. Key point 3 Its analysis port must carry complete transactions that a system scoreboard can use. Key point 4 A monitor that peeks into the driver breaks the first time its agent is made passive.

Missed Corner

"The monitor can copy fields it cannot see on the pins from the driver's current item."

A passive agent has no driver. The fields go missing at exactly the level where reuse matters.

Source Verification Academy, UVM Cookbook, Agents: is_active builds the sequencer and driver only when active (PDF p549)
- Lesson U11.1Build an Active or Passive Agent
- Lesson U12.2Vertical Reuse: A Block Environment Inside a Subsystem

What People Get Wrong

Common wrong answers and why they fail. Run It shows the wrong belief failing on a real simulator.

Misconception

"The monitor can create one transaction object and refill it for each beat."

Every subscriber gets the same handle. A scoreboard that stores handles ends up holding one object, refilled with the last beat. The twin keeps three beats and prints 30 three times.

Run It

A monitor that creates its transaction once and reuses it; a subscriber keeps what it receives.

RUNVerilator + UVM 2020.3.1 · simulator service

Edit the code, then run it

Expected among the UVM messages: scoreboard kept 30 30 30 FAIL: write() passed one handle three times, so every kept beat shows the last data

`timescale 1ns/1ns
`include "uvm_macros.svh"
import uvm_pkg::*;

class beat extends uvm_sequence_item;
  `uvm_object_utils(beat)
  bit [7:0] data;
  function new(string name = "beat"); super.new(name); endfunction
endclass

// The belief: one transaction object is enough; write() hands the data over.
class beat_monitor extends uvm_monitor;
  `uvm_component_utils(beat_monitor)
  uvm_analysis_port #(beat) ap;
  beat t;
  function new(string name, uvm_component parent); super.new(name, parent); ap = new("ap", this); endfunction
  task run_phase(uvm_phase phase);
    bit [7:0] seen[3] = '{8'h10, 8'h20, 8'h30};   // three beats the DUT accepted
    t = beat::type_id::create("t");               // created once, reused for every beat
    foreach (seen[i]) begin
      #10 t.data = seen[i];
      ap.write(t);
    end
  endtask
endclass

// Keeps each observed beat to compare later, as an in-order scoreboard does.
class keeper extends uvm_subscriber #(beat);
  `uvm_component_utils(keeper)
  beat kept[$];
  function new(string name, uvm_component parent); super.new(name, parent); endfunction
  function void write(beat t);
    kept.push_back(t);
  endfunction
endclass

class mon_test extends uvm_test;
  `uvm_component_utils(mon_test)
  beat_monitor mon;
  keeper       sb;
  function new(string name, uvm_component parent); super.new(name, parent); endfunction
  function void build_phase(uvm_phase phase);
    mon = beat_monitor::type_id::create("mon", this);
    sb  = keeper::type_id::create("sb", this);
  endfunction
  function void connect_phase(uvm_phase phase);
    mon.ap.connect(sb.analysis_export);
  endfunction
  task run_phase(uvm_phase phase);
    phase.raise_objection(this);
    #40;
    phase.drop_objection(this);
  endtask
  function void report_phase(uvm_phase phase);
    $display("scoreboard kept %0h %0h %0h", sb.kept[0].data, sb.kept[1].data, sb.kept[2].data);
    if (sb.kept[0] == sb.kept[2])
      $display("FAIL: write() passed one handle three times, so every kept beat shows the last data");
  endfunction
endclass

module tb;
  initial run_test("mon_test");
endmodule

Missed Corner

"Sample whenever valid is high."

Under back-pressure, valid stays high for several edges while one beat waits. The monitor then reports that beat several times. Only an edge where ready is also 1 is a transfer.

Source Lesson U7.1 example: 7 edges with valid high but 3 real transfers (uvm-core 2020.3.1 on Verilator 5.052)

Half-Truth

"The driver knows what it sent, so the scoreboard can take its items from the driver."

The driver reports what it meant to send. The monitor reports what the DUT accepted. Only the monitor still works when the agent is passive and has no driver.

Find Your Next Track

Put Your Skills to Work

Prepare to Explain Your Thinking

An Idea to Try? Pick a Tool.

What a Monitor Samples

Your Answer

Self-Check

What Interviewers Listen For (Fresher)

What Interviewers Listen For (Junior)

Cross-Questions

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

What Interviewers Listen For (Senior)

Your Answer

Self-Check

What People Get Wrong

Learn It, Then Prove It

The Question

Your Answer

Self-Check

What Interviewers Listen For (Fresher)

What Interviewers Listen For (Junior)

Cross-Questions

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

What Interviewers Listen For (Senior)

Your Answer

Self-Check

What People Get Wrong

Learn It, Then Prove It