Part 5 · Sequences · Intermediate
UVM Sequences & Stimulus
The complete stimulus stack: sequence items as transaction objects, the sequencer–driver handshake, arbitration and lock/grab, virtual sequences for multi-agent scenarios, layered reuse, sequence libraries, and debugging hangs.
What this section covers
In UVM, stimulus is procedural . Tests do not wiggle pins directly — they start sequences on sequencers, sequences produce uvm_sequence_item transactions, sequencers arbitrate access to a shared driver, and drivers convert items into pin-level activity. This separation is what lets the same agent VIP run in block tests, chip tests, and directed regressions with only the sequence layer changing.
Each major topic below is a hub page with five focused sub-topics. You will learn how to model protocol transactions as randomized items, the exact blocking handshake between sequence, sequencer, and driver, how multiple sequences share one driver, how virtual sequences coordinate traffic across many agents without breaking encapsulation, how to layer stimulus for reuse, and how to debug the hangs that every verification engineer hits at least once.
Topic map
Legend: [STIM] [SEQ] [DRV] [ITEM] [UVM]
┌─────────────────────────────────────────────────────────────────────────┐
│ SEQUENCES SECTION — topic map │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. SEQUENCE ITEMS [ITEM] │
│ item vs driver boundary │ field macros │ constraints │ layering │ copy│
│ │
│ 2. SEQUENCE BODY HANDSHAKE [SEQ] [DRV] │
│ pull model │ start/finish_item │ get_next_item │ test start │ pipeline│
│ │
│ 3. SEQUENCER ARBITRATION [SEQ] [UVM] │
│ FIFO default │ priority │ lock/grab │ arbitration modes │ starvation│
│ │
│ 4. VIRTUAL SEQUENCES [STIM] [SEQ] │
│ coordination problem │ v_sqr structure │ p_sequencer │ fork/join │ placement│
│ │
│ 5. LAYERED SEQUENCES & LIBRARIES [STIM] [SEQ] │
│ why layer │ base inheritance │ start() delegation │ seq_lib │ factory│
│ │
│ 6. SEQUENCE DEBUGGING [UVM] [SEQ] [DRV] │
│ hang symptom │ driver running │ handshake │ p_sequencer │ verbosity │
│ │
└─────────────────────────────────────────────────────────────────────────┘Topics and sub-topics
Sequence Items — 5 sub-topics from item vs driver boundary to clone before scoreboard queue.
Sequence Body Handshake — 5 sub-topics from pull-model overview to pipelined read responses.
Sequencer Arbitration — 5 sub-topics from FIFO default to starvation debug.
Virtual Sequences — 5 sub-topics from multi-agent coordination to env placement rules.
Layered Sequences & Libraries — 5 sub-topics from layering rationale to factory overrides.
Sequence Debugging — 5 sub-topics from hang symptoms to UVM verbosity tracing.
The stimulus stack
Every UVM testbench that drives a DUT follows the same high-level path: a test raises an objection and starts a sequence; the sequence produces transaction items; the sequencer mediates between competing sequences; the driver converts each item into pin activity. The diagram below is the map for this entire section — every lesson expands one box or arrow.
Legend: [STIM] [SEQ] [DRV] [ITEM] [UVM]
[STIM] TEST / ENV
│
│ seq.start(sequencer) virtual seq coordinates many sequencers
▼
┌─────────────┐
│ [SEQ] │ body(): start_item → randomize → finish_item
│ SEQUENCE │
└──────┬──────┘
│ [ITEM] uvm_sequence_item (addr, data, opcode — WHAT not HOW)
▼
┌─────────────┐
│ [SEQ] │ arbitration, lock/grab, FIFO of pending items
│ SEQUENCER │
└──────┬──────┘
│ get_next_item / item_done
▼
┌─────────────┐
│ [DRV] │ drive(req) on virtual interface → DUT pins
│ DRIVER │
└─────────────┘
[UVM] Agent encapsulates sequencer + driver + monitor as one reusable VIPFour roles — one contract
[ITEM] Data — what to send (address, data, length). No pin timing.
[SEQ] Procedure — how to generate a stream of items over time.
[SEQ] Sequencer — arbiter deciding which sequence gets the driver next.
[DRV] Executor — converts items to clock-aligned pin wiggles.
[STIM] Test / virtual sequence — scenario intent that starts sub-sequences.
[STIM] APB write example — one transaction through the stack
TEST run_phase:
apb_wr_seq seq; seq.num_trans = 3;
seq.start(env.apb_agent.sqr);
[SEQ] apb_wr_seq.body():
req = apb_item::type_id::create("req");
start_item(req);
req.randomize() with { write==1; addr==32'h4000; };
finish_item(req); ← blocks until driver item_done
[DRV] apb_driver.run_phase:
get_next_item(req); ← receives item from sequencer
drive_apb(req); ← paddr, pwrite, pwdata on vif
item_done(); ← releases sequence at finish_item
[ITEM] apb_item carries: addr, data, write — NOT pready wait loopsKeep this stack in mind as you drill into each topic. Items are the contract object between sequence and driver — pin timing stays in the driver. Virtual sequences orchestrate scenarios across agents without driving pins directly.
Key takeaways
Sequences generate intent; drivers execute it; sequencers mediate access.
sequence_item is the contract between sequence and driver — keep pin timing out of it.
Virtual sequences orchestrate scenarios across agents without driving pins directly.
Six topic hubs × five sub-topics each — work through in nav_order for a complete stimulus education.