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 Driver

The component responsible for converting transactions into signal-level activity on the DUT.

Overview

The UVM Driver receives transactions from the sequencer and drives them onto the DUT interface at the signal level.

It translates high-level transaction objects into low-level pin toggling.

Why the Driver Exists

  • Implements protocol timing
  • Controls signal-level behavior
  • Executes transactions from sequences
  • Maintains synchronization with DUT clock/reset

The driver defines how transactions are executed.

Position in UVM Architecture

Sequence → Sequencer → Driver → DUT

The driver sits between the sequencer and the DUT, implementing protocol-specific signal behavior.

Base Class: uvm_driver

class my_driver extends uvm_driver #(packet);

The driver is parameterized with the transaction type and extends uvm_driver.

Basic Driver Example

class my_driver extends uvm_driver #(packet);

  `uvm_component_utils(my_driver)

  virtual interface my_if vif;

  function new(string name, uvm_component parent);
    super.new(name, parent);
  endfunction

  virtual task run_phase(uvm_phase phase);
    packet pkt;

    forever begin
      seq_item_port.get_next_item(pkt);

      drive_transaction(pkt);

      seq_item_port.item_done();
    end
  endtask

  task drive_transaction(packet pkt);
    // Example driving logic
    vif.addr  <= pkt.addr;
    vif.data  <= pkt.data;
    vif.write <= pkt.write;
  endtask

endclass

Driver–Sequencer Handshake

  • get_next_item() → Driver requests next transaction
  • item_done() → Driver signals completion

This handshake ensures controlled and synchronized transaction flow.

Driver Responsibilities

  • Wait for reset deassertion
  • Align stimulus with clock
  • Handle protocol timing
  • Drive interface signals
  • Report errors if necessary

Driver vs Monitor

Feature Driver Monitor
Purpose Drive stimulus Observe DUT signals
Direction Testbench → DUT DUT → Testbench
Uses Sequencer Yes No
Transaction Source From Sequencer Reconstructed from signals

Interview Focus

  • Explain get_next_item() and item_done()
  • Difference between driver and monitor
  • How to handle backpressure
  • How to synchronize with clock and reset
  • Blocking vs non-blocking transport

Key Takeaways

  • The driver converts transactions into signal-level activity.
  • It extends uvm_driver.
  • It communicates with the sequencer using TLM ports.
  • It handles protocol timing and synchronization.
  • It is a structural UVM component and participates in phases.