Monitor-to-Scoreboard Connection

UVM
1

Hi everyone,

I’m trying to understand the architectural reason behind the recommended Monitor-to-Scoreboard connection in UVM.

Case 1 (Directly from Monitor to Scoreboard)

// env::connect_phase()
agt.mon.ap.connect(scb.analysis_export);

Case 2 (Through Agent)

The Agent exposes its own analysis port, and the Environment connects the Agent to the Scoreboard.

class agent extends uvm_agent;
  uvm_analysis_port #(seq_item) ap;

  function void build_phase(uvm_phase phase);
    super.build_phase(phase);
    ap = new("ap", this);
  endfunction

  function void connect_phase(uvm_phase phase);
    super.connect_phase(phase);
    // Monitor forwards transactions to the agent's analysis port
    // (implementation omitted for simplicity)
  endfunction
endclass

// env::connect_phase()
agt.ap.connect(scb.analysis_export);

So the transaction flow becomes:

  1. Monitor → Agent → Scoreboard

  2. instead of Monitor → Scoreboard

My questions are:

  1. Why is the Agent-level connection considered the recommended UVM architecture?

  2. What are the architectural advantages over connecting the Monitor directly to the Scoreboard?

  3. Is the main reason encapsulation, loose coupling, reusability, or protocol abstraction?

2

A scoreboard is typically design specific, not agent specific. This is why it is integrated at the environment level and not the agent level.

There may be an agent-specific scoreboard, but if that is the case, then it will be created and connected by the agent and not the monitor.

3

A monitor is a sub-component of the agent (along with other sub-components such as driver, sequencer, etc)

So it’s typical that the monitor has an analysis port which transactions get sent out on.

Then there is usually code within the agent (in the connect phase) to connect the monitor analysis port up to an agent level analysis port.

Within your environment you will instantiate the agent (not the monitor) plus other TLM components such as scoreboards, predictors, etc. So then you will see in the environment connect phase that you make a connection from the agent analysis port to an analysis export on either a predictor or scoreboard.

4

Thanks for the replies — that explains how it works, but I’m still trying to understand why it’s better, not just “cleaner.”

I get that env only has an agent handle, not a monitor handle. But SystemVerilog still lets me write agt.mon.ap.connect(...) and it works fine — so what actually breaks if I do that?

My best guess: if the same agent is reused in multiple environments, connecting through agt.ap means monitor-wiring logic lives in one place (inside the agent). Connecting agt.mon.ap directly means that wiring gets copy-pasted into every environment, so any internal change to the monitor means fixing it in N places instead of one.

Is that the real reason, or is there something else (active/passive agent, factory override, elaboration order) that actually breaks even in a single environment?