Skip to content
STIMSMITH

Virtual Sequence

Concept WIKI v2 · 5/28/2026

A virtual sequence is a verification stimulus construct used to coordinate multiple interface-level test sequences. In the cited UVM environments, it either creates interface-specific transactions for agents or groups one sequence per DUT interface; in a Multi-Armed Bandit flow, virtual sequences are treated as selectable arms whose coverage reward guides UCB1-based test selection.

Definition

A virtual sequence is a verification construct that coordinates stimulus across multiple DUT interfaces. In one cited UVM environment, each virtual sequence creates interface-specific transactions and sends them to the corresponding interface agent; the agent driver then stimulates the matching DUT sub-interface with the transaction values. Because the virtual sequence does not know exactly when a transaction is driven, a monitor captures the interface state and sends it back through the sequencer, allowing the virtual sequence to react and produce new stimulus. [C1]

In the cited Multi-Armed Bandit (MAB) verification formulation, a virtual sequence is defined more compactly as a collection of test sequences that drive each interface of the DUT. For the Instruction Fetch (IF) unit example, one virtual sequence contains four sequences in total: one sequence per IF-unit interface. [C2]

Role in a UVM verification environment

The cited VPU verification environment uses UVM to build a modular, scalable, and reusable verification environment. Each semi-independent sub-interface has its own agent, and each agent contains a sequencer, driver, and monitor connected to a virtual interface. Virtual sequences interact with those agents by creating transactions, receiving monitored interface state through the sequencer, and generating reactive stimulus. [C1]

Because the VPU environment includes seven unique sub-interfaces that communicate with one another, the implementation uses UVM events to keep virtual sequences synchronized. The evidence notes that UVM events can transmit data along with an event trigger, which eased intercommunication among virtual sequences. [C3]

Virtual sequences in MAB-driven coverage closure

In the MAB-based verification flow, virtual sequences are pre-selected and used as the "slot machines" available to the MAB policy. Each sequence is applied to the DUT for a number of cycles, and a reward is recorded from its coverage performance against selected functional properties. The MAB policy then recommends which sequence to select next, balancing exploitation of sequences that have increased coverage in the past with exploration of other sequences that may perform better. [C4]

The framework fixes both the set of virtual sequences and the sequences inside each virtual sequence before simulation. Their parameters are pre-selected using representative random parameter sampling, and the framework does not allow a selected sequence to change its parameters or constraints during simulation. This fixed behavior lets the MAB policy learn the performance of repeatedly played sequences and penalize poorly performing ones. [C5]

UCB1 selection behavior

The cited framework applies the selected virtual sequences using the UCB1 algorithm. In each trial, UCB1 selects a virtual sequence based on rewards observed in previous trials. The method first plays each of the K virtual sequences once for M cycles to initialize the mean payoff of each sequence. In later trials, it selects the sequence with the highest upper-confidence estimate, observes the trial reward, and updates the sequence's mean reward. [C6]

Only one virtual sequence is allowed to operate in each round; a non-selected virtual sequence remains frozen and contributes no reward during idle periods. The evidence also states that the selected virtual sequence operates without reseeding or parameter tuning. [C6]

Coverage reward

The reward used by the MAB framework is based on coverage progress. For active coverage bins, a sequence receives credit for bins it triggers at least once during a trial; for example, if four bins remain active and the sequence hits three of them, the reward is 3/4. The reward is kept in the range [0,1], and the cited work renormalizes it with a logarithmic function to boost small rewards and compress large ones, which is useful near the end of simulation when hard-to-cover bins remain. [C7]

Example: Instruction Fetch unit

In the IF-unit case study, the DUT subsystem is connected to the rest of the processor through four separate interfaces. During simulation, each interface is fed by a distinct test sequence that mimics the behavior of the corresponding connection when the processor executes real programs. The individual interface sequences are generated by constrained-random generators customized with interface-specific parameters. [C8]

To create virtual sequences for this case study, the authors selected parameter values for the constituent interface sequences and randomly selected K = 40 virtual sequences from the available choices. This number was chosen empirically to ensure that each possible parameter level was used at least once, while still allowing the verification engineer to choose specific parameter sets for targeted corner cases. [C9]

Reported effect in the cited MAB experiment

Using the same 40 virtual sequences, the cited experiment compared random application of sequences for 5000 trials against the MAB framework using UCB1 and the proposed reward function. Across five random seeds, random selection achieved 82.9% to 90.6% coverage after 5000 trials, while the MAB framework reached the same coverage goals in 1507 to 2590 trials, averaging 1988 trials and a reported 60% saving. The authors summarize this as about a 2× reduction in the number of trials needed to reach the same coverage goal. [C10]

The same evidence emphasizes that UCB1 does not improve the intrinsic quality of the selected sequence set; rather, it identifies the sequence set's potential more quickly by playing consistently higher-reward sequences more often while still exploring all sequences. [C11]

LINKED ENTITIES

2 links
UCB1 Algorithm USES
Multi-Armed Bandit USES

CITATIONS

12 sources
12 citations
[1] In the UVM VPU environment, virtual sequences create interface-specific transactions, drivers stimulate the corresponding DUT sub-interface, monitors capture interface state, and the virtual sequence reacts by producing new stimulus. source
[2] In the MAB formulation, a virtual sequence is a collection of test sequences that drive each DUT interface; in the IF-unit example, a virtual sequence includes four sequences, one per interface. [PDF] UVM-based verification of RISC-V superscalar processors
[3] The VPU verification environment uses UVM agents per semi-independent sub-interface and synchronizes communicating virtual sequences with UVM events that can carry data with the trigger. source
[4] The MAB verification analogy maps slot machines to test sequences, records coverage-based reward for each sequence, and selects future sequences with an exploration-exploitation policy. [PDF] UVM-based verification of RISC-V superscalar processors
[5] The MAB framework fixes the set of virtual sequences, their constituent sequences, and their parameters before simulation, avoiding runtime parameter or constraint changes so sequence performance can be learned. [PDF] UVM-based verification of RISC-V superscalar processors
[6] The UCB1-based flow initializes each of K virtual sequences by playing it once for M cycles, then selects later sequences using an upper-confidence estimate based on prior rewards and updates the mean reward after each trial. [PDF] UVM-based verification of RISC-V superscalar processors
[7] In each UCB1 round, only one virtual sequence operates; non-selected sequences remain frozen, contribute no reward, and the selected sequence is not reseeded or tuned. [PDF] UVM-based verification of RISC-V superscalar processors
[8] The reward function gives credit for active coverage bins hit during a trial, remains in the range [0,1], and is renormalized logarithmically to make small rewards more distinguishable near coverage closure. [PDF] UVM-based verification of RISC-V superscalar processors
[9] The IF-unit case study uses four separate interfaces, each fed by a distinct constrained-random test sequence customized by interface-specific parameters. [PDF] UVM-based verification of RISC-V superscalar processors
[10] The IF-unit study selected K=40 virtual sequences from available parameterized choices, with the number chosen empirically to cover possible parameter levels at least once. [PDF] UVM-based verification of RISC-V superscalar processors
[11] In the reported experiment, UCB1 over the same 40 virtual sequences reached the random-selection coverage goals in 1507 to 2590 trials versus 5000 random trials, averaging 1988 trials and about a 2× trial reduction. [PDF] UVM-based verification of RISC-V superscalar processors
[12] The cited authors state that the MAB approach does not improve the quality of the selected sequence set, but identifies its potential more quickly by exploiting high-reward sequences while exploring all sequences. [PDF] UVM-based verification of RISC-V superscalar processors

VERSION HISTORY

v2 · 5/28/2026 · gpt-5.5 (current)
v1 · 5/27/2026 · gpt-5.5