Orchestrating traffic across multiple agents (e.g., CPU + DMA) without having a physical driver of its own.
A Virtual Sequence is the top-level orchestrator of a UVM testbench. While a normal sequence drives a single interface, a virtual sequence coordinates multiple independent agents (e.g., triggering a DMA transfer on one agent while monitoring an interrupt on another).
REQ type.
To coordinate agents, a virtual sequence needs handles to the agents'
sequencers. UVM provides m_sequencer (the base handle) and
the `uvm_declare_p_sequencer macro to create a
type-safe (typed) handle called p_sequencer.
Without it, you have to manually cast m_sequencer every
time you want to access a specific sub-sequencer handle.
p_sequencer automates this casting, making your
coordination code clean and readable.
class top_vseq extends uvm_sequence;
// 1. Declare the typed handle
`uvm_declare_p_sequencer(my_virtual_sequencer)
task body();
cpu_write_seq cpu_s;
dma_move_seq dma_s;
// 2. Start child sequences on their specific sequencers
fork
cpu_s.start(p_sequencer.cpu_sqr);
dma_s.start(p_sequencer.dma_sqr);
join
endtask
endclass
For scalable testbenches, never hardcode sequencer paths inside sequences. Always use a Virtual Sequencer as a central hub for handles. This maintains strict separation between "What to drive" (Sequence) and "Where to drive" (Environment).
Virtual sequences are the only place where objection
handling (raise/drop) should typically occur. This ensures stimulus
and test longevity are controlled from a single, high-level source.