UVM Sequence Item | Transaction Object

The Atomic Transaction

A UVM Sequence Item (or Transaction) is the smallest unit of data that can be moved through your testbench. It encapsulates all the information required for a single operationbe it a memory write, an Ethernet frame, or a CPU instruction.

Core Requirements:

Factory Registration: Enables polymorphism and transaction overrides.
Randomization: Uses SystemVerilog rand properties for stimulus.
Data Services: Must support common operations like Copy, Compare, Pack, and Print.

Transactional Modeling

Design your items to be Lightweight. They should only contain data and constraintsnever simulation time or component-like logic.

Implementation: Protocol-Aware Transaction


typedef enum {READ, WRITE} cmd_t;
class apb_item extends uvm_sequence_item;
    // 1. Data Fields
    rand bit [31:0] addr;
    rand bit [31:0] data;
    rand cmd_t      cmd;
    rand int        delay;
    // 2. Factory Registration
    `uvm_object_utils_begin(apb_item)
        `uvm_field_int(addr,  UVM_ALL_ON)
        `uvm_field_int(data,  UVM_ALL_ON)
        `uvm_field_enum(cmd_t, cmd, UVM_ALL_ON)
    `uvm_object_utils_end
    // 3. Constraints
    constraint c_alignment { addr[1:0] == 0; } // Word aligned
    constraint c_delay     { delay inside {[1:10]}; }
    function new(string name = "apb_item");
        super.new(name);
    endfunction
endclass

Field Macros vs Manual Methods

The `uvm_field_* macros automatically implement copy(), compare(), and print(). While convenient, they are computationally heavy due to their use of introspection.

Performance Tip:

In ultra-high-performance environments (like networking), many teams manually override do_copy, do_compare, and do_print to avoid the overhead of field macros. This can speed up simulation by several percentage points in large regressions.

Best Practices

Soft Constraints: Use soft for default constraints so sequences can easily override them.
Meaningful Names: Ensure your transaction names reflect the physical protocol (e.g., axi_burst_item).
Avoid Complexity: If a transaction needs to track state, move that logic to the Sequence or a separate State Object.

Polymorphism Power

Because items are registered in the factory, you can create a corrupt_apb_item (with illegal parity) and override the base apb_item type in the test without changing any driver or monitor code.

UVM Class Hierarchy (Interview Essential)

A very common interview question: "What's the difference between uvm_object, uvm_component, uvm_sequence_item, and uvm_transaction?"

Class	Hierarchy?	Phases?	Use Case
`uvm_object`	No	No	Base for data objects (configs, transactions)
`uvm_component`	Yes	Yes	Testbench components (driver, monitor, etc.)
`uvm_sequence_item`	No	No	Transactions for driver/sequencer handshake
`uvm_transaction`	No	No	Deprecated - alias for uvm_sequence_item

Key Insight:

uvm_sequence_item extends uvm_object, adding sequencer/driver communication hooks (set_sequencer, set_item_context). Use uvm_sequence_item for anything going through the handshake, and uvm_object for pure data objects like configuration classes.

Interview Answer

"Should I use uvm_transaction or uvm_sequence_item?"
Always use uvm_sequence_item. The uvm_transaction class exists only for backward compatibility with OVM and adds no functionality.