virtual sequence

Concept

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.

First seen 5/27/2026

Last seen 6/1/2026

Evidence 6 chunks

Wiki v2

WIKI

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]

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

7 connections

UVM ← implements 93% 1e

Virtual sequences are used in the UVM environment to coordinate stimulus across sub-interfaces.

UVM testbench ← uses 93% 1e

Virtual sequences manage stimulus generation across sub-interfaces in the UVM testbench.

Functional Verification of a RISC-V Vector Accelerator ← uses 95% 1e

The paper uses virtual sequences to coordinate transactions across multiple OVI sub-interfaces.

UVM testbench part of → 93% 1e

The UVM testbench uses virtual sequences to coordinate multi-interface transactions.

UCB1 Algorithm ← uses 90% 1e

UCB1 orchestrates the execution of virtual sequences to maximize coverage.

Multi-Armed Bandit ← uses 95% 1e

The MAB framework treats virtual sequences as the arms of the bandit.

UVM environment ← uses 97% 1e

The UVM environment uses virtual sequences to create interface-specific transactions.

LINKED ENTITIES

2 links

UCB1 Algorithm USES Extracted graph relationship

Multi-Armed Bandit USES Extracted graph relationship

CITATIONS

12 sources

12 citations — click to expand

[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