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 Transaction (Sequence Item)

Understanding the fundamental data object used for communication inside UVM testbenches.

Overview

A UVM Transaction is a class-based object that represents a unit of data exchanged between verification components. Transactions typically extend uvm_sequence_item and are used to model stimulus, observed DUT activity, and scoreboard data.

Transactions are data containers. They are not structural elements of the testbench hierarchy.

Why Transactions Exist

  • Separate data representation from structural components
  • Enable constrained random stimulus
  • Allow reusable protocol modeling
  • Simplify communication between sequencer, driver, monitor, and scoreboard

Transactions are the core communication mechanism inside a UVM agent.

Where Transactions Fit in UVM

Sequence → Sequencer → Driver → DUT
                           ↑
                        Monitor

The sequence creates transactions, the sequencer forwards them, the driver converts them into pin-level activity, and the monitor reconstructs transactions from DUT signals.

Base Class: uvm_sequence_item

class my_transaction extends uvm_sequence_item;

The uvm_sequence_item base class provides:

  • Randomization support
  • Factory integration
  • Copy and compare methods
  • Printing utilities
  • Packing and unpacking methods

Basic Transaction Example

class packet extends uvm_sequence_item;

  rand bit [7:0]  addr;
  rand bit [31:0] data;
  rand bit        write;

  constraint addr_range {
    addr inside {[0:255]};
  }

  `uvm_object_utils(packet)

  function new(string name = "packet");
    super.new(name);
  endfunction

endclass

Key Features

Randomization
packet pkt;
pkt = packet::type_id::create("pkt");
assert(pkt.randomize());
Copy and Compare

Used heavily in scoreboards to compare expected vs actual transactions.

Print Support
pkt.print();
Packing / Unpacking

Enables serialization for TLM communication and recording.

Transaction vs Component

Feature Transaction Component
Base Class uvm_sequence_item uvm_component
Hierarchy No Yes
Phases No Yes
Purpose Data Transfer Testbench Structure

Key Takeaways

  • Transactions are lightweight data objects.
  • They extend uvm_sequence_item.
  • They are randomizable and reusable.
  • They are central to stimulus and checking.
  • They do not participate in UVM phases.