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 Sequence

Understanding how stimulus is generated and controlled in UVM.

Overview

A UVM Sequence is responsible for generating transactions and sending them to the sequencer. It defines the stimulus behavior of a test.

Sequences extend uvm_sequence and create transaction objects that are later executed by the driver.

Why Sequences Exist

  • Encapsulate stimulus generation logic
  • Separate stimulus from driver implementation
  • Support constrained random testing
  • Allow reusable stimulus scenarios

Sequences describe what to send, while drivers describe how to send it.

Sequence Flow in UVM

Sequence → Sequencer → Driver → DUT

The sequence generates transactions, the sequencer arbitrates them, and the driver converts them into signal-level activity.

Base Class: uvm_sequence

class my_sequence extends uvm_sequence #(packet);

The sequence is parameterized with the transaction type. It controls how transactions are created and randomized.

Basic Sequence Example

class simple_sequence extends uvm_sequence #(packet);

  `uvm_object_utils(simple_sequence)

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

  virtual task body();
    packet pkt;

    pkt = packet::type_id::create("pkt");
    start_item(pkt);
    assert(pkt.randomize());
    finish_item(pkt);
  endtask

endclass

Important Sequence Methods

body()

Main execution task of the sequence. All stimulus logic is implemented here.

start_item()

Requests permission from the sequencer to send a transaction.

finish_item()

Sends the transaction to the driver after randomization.

Types of Sequences

  • Simple Sequence – Sends one or more transactions
  • Virtual Sequence – Coordinates multiple sequencers
  • Layered Sequence – Builds complex stimulus from smaller sequences

Sequence vs Transaction

Feature Sequence Transaction
Purpose Generate stimulus Carry data
Base Class uvm_sequence uvm_sequence_item
Contains Randomization Yes Yes
Structural Component No No

Interview Focus

  • Difference between sequence and sequencer
  • What happens inside start_item() and finish_item()
  • How arbitration works in sequencer
  • Difference between virtual and regular sequences

Key Takeaways

  • Sequences generate transactions.
  • They extend uvm_sequence.
  • They implement stimulus logic inside body().
  • They communicate with drivers through the sequencer.
  • They enable reusable and scalable stimulus generation.