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 Sequencer

The arbitration and control layer between sequences and drivers.

Overview

The UVM Sequencer is responsible for controlling the flow of transactions from sequences to the driver.

It acts as an arbitration and synchronization layer between multiple sequences and the driver.

Why the Sequencer Exists

  • Arbitrates between multiple active sequences
  • Controls transaction flow
  • Synchronizes driver access
  • Provides handshake mechanism

Without the sequencer, multiple sequences could conflict when sending transactions to the driver.

Position in UVM Architecture

Sequence → Sequencer → Driver → DUT

The sequencer sits between sequences and the driver, managing which transaction is executed next.

Base Class: uvm_sequencer

class my_sequencer extends uvm_sequencer #(packet);

The sequencer is parameterized with the transaction type. It connects to the driver using TLM ports.

Basic Sequencer Example

class my_sequencer extends uvm_sequencer #(packet);

  `uvm_component_utils(my_sequencer)

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

endclass

In many cases, the sequencer contains minimal logic because arbitration is already built into uvm_sequencer.

Driver–Sequencer Handshake

// Inside driver
seq_item_port.get_next_item(pkt);

// Drive signals to DUT

seq_item_port.item_done();

The driver requests the next transaction from the sequencer. The sequencer grants access based on arbitration rules.

Arbitration Mechanism

When multiple sequences are running simultaneously, the sequencer decides which one gets access to the driver.

  • FIFO arbitration
  • Priority-based arbitration
  • User-defined arbitration

Sequencer vs Sequence

Feature Sequencer Sequence
Purpose Arbitrate and control transactions Generate transactions
Base Class uvm_sequencer uvm_sequence
Structural Component Yes No
Participates in Phases Yes No

Virtual Sequencer

A virtual sequencer coordinates multiple sequencers across different agents. It enables system-level stimulus synchronization.

Interview Focus

  • Difference between sequencer and driver
  • How arbitration works
  • What happens during get_next_item()
  • Why sequencer is a component but sequence is not

Key Takeaways

  • The sequencer controls transaction flow.
  • It arbitrates between multiple sequences.
  • It connects sequences to the driver.
  • It is a structural UVM component.
  • It participates in UVM phases.