Introduction
Introduction Get started Hello UVM example UVM Phases Part 1 UVM Phases Part 2 UVM Base Classes UVM Object and Core Methods UVM Components
Building a Testbench
UVM Transaction UVM Sequence UVM Sequencer UVM Driver UVM Monitor UVM Scoreboard UVM Agent UVM Environment UVM Test
Other Components
Coverage Collector
Execution Model
UVM Phases Objections
Communication
TLM Basics TLM Blocking Put Port TLM Non-Blocking Put Port TLM Blocking Peek Port Analysis Ports TLM FIFO
Configuration
UVM Factory UVM Config DB
Runtime Control
UVM Plusargs Seeds & Reproducibility Verbosity Control Debug Runtime Controls
Advanced
Virtual Sequences Virtual Sequencer
UVM RAL
Intro Abstraction Flexibility Comparison Coverage Minimum Requirements Learning Path Register Types First Implementation Register with 2 Fields Register with Reserved Bits Access Policies Part 1 Access Policies Part 2 Access Policies Part 3 Access Policies Part 4 Memory Modeling Register Block Adapter Introduction Adapter Methods Adapter Example Predictor Types Desired and Mirror Values Register Methods Desired Value Mirror Value

UVM Monitor

The passive component responsible for observing DUT activity and converting signals into transactions.

Overview

The UVM Monitor observes signal-level activity on the DUT interface and reconstructs high-level transaction objects.

Unlike the driver, the monitor is passive. It does not drive signals — it only observes and reports activity.

Why the Monitor Exists

  • Convert signal-level behavior into transactions
  • Send transactions to scoreboards
  • Collect functional coverage
  • Enable passive verification

The monitor defines what happened on the DUT interface.

Position in UVM Architecture

Sequence → Sequencer → Driver → DUT
                           ↑
                        Monitor

The monitor observes DUT signals and sends reconstructed transactions to analysis components like scoreboards.

Base Class: uvm_monitor

class my_monitor extends uvm_monitor;

The monitor extends uvm_monitor and is a structural UVM component that participates in simulation phases.

Basic Monitor Example

class my_monitor extends uvm_monitor;

  `uvm_component_utils(my_monitor)

  virtual interface my_if vif;
  uvm_analysis_port #(packet) analysis_port;

  function new(string name, uvm_component parent);
    super.new(name, parent);
    analysis_port = new("analysis_port", this);
  endfunction

  virtual task run_phase(uvm_phase phase);
    packet pkt;

    forever begin
      @(posedge vif.clk);

      if (vif.valid) begin
        pkt = packet::type_id::create("pkt");
        pkt.addr  = vif.addr;
        pkt.data  = vif.data;
        pkt.write = vif.write;

        analysis_port.write(pkt);
      end
    end
  endtask

endclass

Analysis Port

The monitor uses an uvm_analysis_port to send transactions to other components such as:

  • Scoreboards
  • Coverage collectors
  • Reference models

Analysis ports are non-blocking and support multiple subscribers.

Monitor Responsibilities

  • Observe interface signals
  • Reconstruct protocol transactions
  • Detect protocol violations
  • Send transactions to analysis components
  • Collect functional coverage

Driver vs Monitor

Feature Driver Monitor
Purpose Drive stimulus Observe activity
Signal Direction Testbench → DUT DUT → Testbench
Uses Sequencer Yes No
Passive No Yes

Interview Focus

  • Why monitor should be passive
  • Difference between analysis port and TLM port
  • How monitor reconstructs transactions
  • Where to implement protocol checks
  • How to connect monitor to scoreboard

Key Takeaways

  • The monitor observes DUT signals.
  • It reconstructs transactions from signal-level activity.
  • It uses analysis ports to communicate.
  • It is passive and does not drive signals.
  • It is essential for checking and coverage collection.