Analysis Port Lifetime Reuse

Puzzle

Difficulty: Medium · Puzzle 3 of 6 · Topic: Handle and Copy Puzzles

A monitor reuses one transaction object every cycle and sends it over analysis port. Why does scoreboard history show all entries with the final sample value?

Code

class mon extends uvm_component;
  `uvm_component_utils(mon)
  uvm_analysis_port #(tr) ap;
  tr t;
  function new(string name, uvm_component parent);
    super.new(name, parent);
    ap = new("ap", this);
  endfunction
  task run_phase(uvm_phase phase);
    t = tr::type_id::create("t");
    forever begin
      @(posedge vif.clk);
      t.addr = vif.addr;
      ap.write(t);
    end
  endtask
endclass

function void sb::write(tr t);
  exp_q.push_back(t);
endfunction

Hint

Ask whether `write()` transfers a new object or the same handle.

Step-by-step solution

1) `ap.write(t)` passes a handle, not a deep-copied object.
2) Scoreboard stores that same handle each cycle, so queue entries alias one object.
3) Next cycle updates `t.addr`, and all previously stored handles appear to change.
4) Clone in monitor before write, or clone in subscriber on receipt.

Answer

Answer: All entries alias the same reused object handle; the scoreboard never captured immutable snapshots.

Why candidates get it wrong

Assuming TLM analysis behaves like pass-by-value instead of pass-by-handle.

Interviewer follow-up

Where should cloning happen for best performance and ownership clarity: monitor, analysis FIFO, or scoreboard?

Related topics

• Back to Handle and Copy Puzzles

• OOP & Testbench Puzzles section