UVM testbench
ConceptA UVM testbench is a Universal Verification Methodology-based verification environment. In the cited RISC-V vector accelerator work, it provided a reusable and extendable infrastructure with per-interface agents, virtual sequences, synchronization events, a scoreboard connected to a Spike reference model, assertions, functional coverage, and regression/CI support.
First seen 5/27/2026
Last seen 6/8/2026
Evidence 10 chunks
Wiki v2
WIKI
Overview
In the cited RISC-V vector accelerator verification project, the UVM testbench was the central verification environment built around the Universal Verification Methodology. The authors selected UVM because it supports modular, scalable, and reusable verification environments, and they describe the resulting infrastructure as an industrial-grade approach combining a UVM testbench, a reference model, assertions, and coverage. [C1]
The environment targeted a decoupled RISC-V vector accelerator connected to a scalar core through the Open Vector Interface (OVI). It performed step-by-step co-simulation of vector instructions using Spike as the instruction-set simulator and reference model. [C2]
NEIGHBORHOOD
No graph connections found for this entity yet. It may appear in future ingestion runs.
explore full graph →RELATIONSHIPS
20 connectionsThe UVM testbench contains a scoreboard component for result comparison.
The paper introduces an industrial-grade UVM testbench for the RISC-V vector accelerator.
The UVM testbench includes a scoreboard for result comparison.
The UVM testbench uses one agent per OVI sub-interface.
Virtual sequences manage stimulus generation across sub-interfaces in the UVM testbench.
The UVM testbench contains agents for each OVI sub-interface.
The UVM testbench uses virtual sequences to coordinate multi-interface transactions.
The UVM testbench collects functional coverage metrics.
The UVM testbench is complemented with SystemVerilog Assertions for protocol checking.
The Ibex core verification uses a UVM testbench framework as indicated by the UVM directory structure.
core_ibex_base_test.sv is part of the UVM testbench for the Ibex core.
core_ibex_test_lib.sv is part of the UVM testbench for the Ibex core.
EAVS uses a RISC-V Core UVM Testbench as a core component.
The UVM Testbench contains a Memory Agent as a sub-component.
The UVM Testbench contains an RVFI Agent as a sub-component.
The UVM Testbench contains a Scoreboard as a sub-component.
The UVM Testbench contains Virtual Sequencers as sub-components.
The UVM Testbench contains Coverage as a sub-component.
The UVM Testbench contains the Design Under Test (DUT) as a sub-component.
The UVM testbench performs co-simulation of vector instructions against Spike.
LINKED ENTITIES
6 linksFunctional Verification of a RISC-V Vector Accelerator INTRODUCES Extracted graph relationship
Co-simulation USES Extracted graph relationship
UVM scoreboard USES Extracted graph relationship
UVM agent USES Extracted graph relationship
virtual sequence USES Extracted graph relationship
Functional Coverage USES Extracted graph relationship
CITATIONS
14 sources14 citations — click to expand
[1] C1: The project used UVM because it supports modular, scalable, reusable verification environments and presented an industrial-grade verification approach with a UVM testbench, reference model, assertions, and coverage. Functional Verification of a RISC-V Vector Accelerator
[2] C2: The environment verified a decoupled RISC-V vector accelerator connected through OVI and used Spike for step-by-step co-simulation/reference modeling. Functional Verification of a RISC-V Vector Accelerator
[3] C3: The UVM top module instantiated the environment, and the environment used one agent per semi-independent sub-interface; the issue agent included a sequencer, driver, and monitor connected to a virtual interface. Functional Verification of a RISC-V Vector Accelerator
[4] C4: Virtual sequences created interface-specific transactions, drivers stimulated sub-interfaces, and monitors returned captured interface state through sequencers so sequences could react. Functional Verification of a RISC-V Vector Accelerator
[5] C5: UVM events synchronized the interdependent sub-interfaces and could transmit data with the trigger. Functional Verification of a RISC-V Vector Accelerator
[6] C6: Because constrained-random stimulus generation was complicated by sub-interface dependence, only the issue-sub-interface instructions were randomized and other sub-interfaces reacted to the driven instructions. Functional Verification of a RISC-V Vector Accelerator
[7] C7: After issue-agent stimulus, the UVM environment followed the VPU execution flow through DISPATCH confirmation/discard and COMPLETED transaction creation. Functional Verification of a RISC-V Vector Accelerator
[8] C8: The UVM scoreboard compared VPU results against a reference model, and Spike was used for co-simulation in the UVM environment. Functional Verification of a RISC-V Vector Accelerator
[9] C9: Spike acted both as a scalar core providing vector instructions to UVM in program order and as a golden/reference model. Functional Verification of a RISC-V Vector Accelerator
[10] C10: The scoreboard connected to the completed monitor, executed a comparison when an instruction finished, and included destination vector-register values from Spike for checking. Functional Verification of a RISC-V Vector Accelerator
[11] C11: The environment implemented more than 50 SystemVerilog Assertions for OVI/interface behavior, and they helped identify VPU bugs and UVM stimulation problems. Functional Verification of a RISC-V Vector Accelerator
[12] C12: The team defined a functional coverage plan focused on directly observable VPU-interface items such as instructions and execution parameters. Functional Verification of a RISC-V Vector Accelerator
[13] C13: The infrastructure included automated constrained-random test generation, simulation, error reporting, and CI/CD, found 3005 errors, and reached 95.79% functional coverage. Functional Verification of a RISC-V Vector Accelerator
[14] C14: The authors found that distributing communication across several agents complicated maintenance, extension, and performance, and proposed considering a single-agent approach in future work. Functional Verification of a RISC-V Vector Accelerator