Functional Verification of a RISC-V Vector Accelerator
Paper"Functional Verification of a RISC-V Vector Accelerator" describes an industrial-style verification infrastructure for an academic decoupled RISC-V vector accelerator taped out in the European Processor Initiative context. The work uses a UVM environment around the Open Vector Interface, RISCV-DV random binary generation, Spike co-simulation as a reference model, a UVM scoreboard, SystemVerilog assertions, functional and code coverage, and Jenkins/GitLab-based CI. The reported campaign found 3005 errors and reached 95.79% average functional coverage.
First seen 5/27/2026
Last seen 5/28/2026
Evidence 10 chunks
Wiki v2
WIKI
Overview
"Functional Verification of a RISC-V Vector Accelerator" is a paper on the functional verification of an academic RISC-V-based decoupled vector accelerator. The paper states that the accelerator was successfully taped out in the context of the European Processor Initiative and implemented version 0.7.1 of the RISC-V Vector Extension while connecting to a scalar processor core through the Open Vector Interface (OVI). [C1]
The paper's main reported contributions are an industrial-grade verification approach using a UVM testbench, reference model, assertions, and coverage; a common UVM testbench for a novel interface and large RTL project; co-simulation-based result comparison for completed vector instructions; and automated testing/regression infrastructure that reached 95.79% functional coverage. [C2]
NEIGHBORHOOD
No graph connections found for this entity yet. It may appear in future ingestion runs.
explore full graph →RELATIONSHIPS
39 connectionsThe paper describes using Spike as the reference model for co-simulation.
The paper measures and reports functional coverage as a key verification metric.
The paper presents the functional verification of a RISC-V vector accelerator (VPU).
The paper evaluates the OVI protocol with assertions and scoreboard comparison.
SystemVerilog assertions are used to improve observability and check interface behavior
A UVM scoreboard is used to compare VPU results with reference model results
The paper describes work done in the context of the European Processor Initiative.
The paper describes using RISCV-DV for random test generation.
The paper describes building a UVM environment for verification
The verification performs step-by-step co-simulation of all vector instructions
Constrained-random test generation is used for automated test creation
CI/CD infrastructure is used to automate simulation, test generation, and error reporting.
Code coverage is measured alongside functional coverage.
The paper was produced by the verification team at Barcelona Supercomputing Center.
Random binary generation is used via RISCV-DV to create test programs.
Jenkins is used as the CI server for running verification pipelines.
SemiDynamics is mentioned as the designer of the scalar RISC-V core connected to the VPU.
UVM agents are created for each sub-interface of OVI
A regression suite is maintained and run to ensure design correctness across changes.
The paper describes a CI/CD infrastructure using Jenkins for running regression tests.
GitLab is used for version control and issue tracking in the verification project.
The paper uses a reference model (Spike) to predict expected VPU behavior for comparison.
The paper describes a verification approach built on the UVM methodology.
SystemVerilog Assertions are used to check OVI protocol compliance and detect bugs.
The paper evaluates the RTL design of the vector accelerator through functional verification.
Directed tests are developed to cover specific edge cases and added to the regression suite.
Memory operation stimulus is a key part of verification, requiring special handling in RISCV-DV and OVI.
The paper introduces an industrial-grade UVM testbench for the RISC-V vector accelerator.
The paper uses constrained-random test generation to verify the VPU.
UVM virtual sequences coordinate stimulus generation across sub-interfaces
Vector instruction blacklisting is used to exclude unimplemented instructions during early verification phases.
RISCV-DV was extended to generate vsetvli instructions through the test code.
The paper uses instruction blacklisting to exclude unimplemented instructions from test generation.
The paper develops a custom C reference model for unordered floating-point reductions to avoid false mismatches with Spike.
A custom reference model for unordered floating-point reductions was developed to handle Spike divergence.
The paper uses virtual sequences to coordinate transactions across multiple OVI sub-interfaces.
Some authors are affiliated with SemiDynamics
A C-based reduction reference model is developed to handle unordered floating-point reductions
ISA tests are developed for instruction coverage of the 0.7.1 spec
LINKED ENTITIES
23 linksGitLab USES Extracted graph relationship
Barcelona Supercomputing Center AUTHORED_BY Extracted graph relationship
SemiDynamics AUTHORED_BY Extracted graph relationship
European Processor Initiative MENTIONS Extracted graph relationship
UVM USES Extracted graph relationship
spike USES Extracted graph relationship
riscv-dv USES Extracted graph relationship
Co-Simulation USES Extracted graph relationship
constrained-random test generation USES Extracted graph relationship
Random Binary Generation USES Extracted graph relationship
CI/CD Infrastructure USES Extracted graph relationship
Jenkins USES Extracted graph relationship
SystemVerilog Assertions USES Extracted graph relationship
Functional Coverage USES Extracted graph relationship
Code Coverage USES Extracted graph relationship
UVM scoreboard USES Extracted graph relationship
UVM agent USES Extracted graph relationship
UVM Virtual Sequence USES Extracted graph relationship
Directed Tests USES Extracted graph relationship
ISA Tests USES Extracted graph relationship
Reduction Reference Model in C USES Extracted graph relationship
Vector Processing Unit (VPU) EVALUATES Extracted graph relationship
Open Vector Interface (OVI) EVALUATES Extracted graph relationship
CITATIONS
25 sources25 citations — click to expand
[1] The paper verifies an academic RISC-V decoupled vector accelerator taped out in the European Processor Initiative context, implementing RVV 0.7.1 and connecting through OVI. Functional Verification of a RISC-V Vector Accelerator
[2] The paper's stated contributions include UVM, a reference model, assertions, coverage, co-simulation, and automated testing/regression infrastructure reaching 95.79% coverage. Functional Verification of a RISC-V Vector Accelerator
[3] The verified VPU is RVV 0.7.1-based, has eight lanes, supports vectors up to 256 64-bit elements, has 32 logical and 40 physical registers, supports FP and integer vector operations, and has limited memory-operation out-of-order capability. Functional Verification of a RISC-V Vector Accelerator
[4] BSC developed the vector accelerator, SemiDynamics designed the connected scalar RISC-V core, and the scalar core handles scalar execution, vector issue, and vector memory accesses through OVI. Functional Verification of a RISC-V Vector Accelerator
[5] The team selected UVM for a modular, scalable, reusable verification environment and focused on OVI-level verification rather than individual VPU submodules. Functional Verification of a RISC-V Vector Accelerator
[6] The UVM environment uses agents, sequencers, drivers, monitors, virtual sequences, and UVM events across seven OVI sub-interfaces. Functional Verification of a RISC-V Vector Accelerator
[7] Because OVI sub-interfaces are highly dependent, the environment randomized only issue-interface instructions and made other sub-interfaces react. Functional Verification of a RISC-V Vector Accelerator
[8] RISCV-DV generated random RISC-V assembly tests for VPU testing and required adaptation because it implemented a later RVV version than 0.7.1. Functional Verification of a RISC-V Vector Accelerator
[9] Major RISCV-DV additions included vsetvli generation, memory-operation changes, data-page initialization selection, memory-address constraints, and RVV 0.7.1 adaptation. Functional Verification of a RISC-V Vector Accelerator
[10] Generated-test instructions were initially blacklisted while modules were under development and gradually re-enabled as errors were fixed. Functional Verification of a RISC-V Vector Accelerator
[11] The verification environment used a UVM scoreboard and Spike as the reference model in co-simulation. Functional Verification of a RISC-V Vector Accelerator
[12] Spike acted both as scalar-core instruction source and golden/reference model, with DPI-callable functions, vector-instruction stepping, memory reads, and reduction-result forcing. Functional Verification of a RISC-V Vector Accelerator
[13] The scoreboard compares results when instructions finish and includes destination vector-register values extracted from Spike. Functional Verification of a RISC-V Vector Accelerator
[14] Unordered floating-point reductions used a C reference model matching the DUT algorithm, with matching values injected into Spike. Functional Verification of a RISC-V Vector Accelerator
[15] Memory operations are delicate because the VPU accesses memory through the scalar core using memop, load, store, and mask interfaces. Functional Verification of a RISC-V Vector Accelerator
[16] Load, store, and masked memory-operation checking used Spike data and a memory model based on OpenTitan's memory model. Functional Verification of a RISC-V Vector Accelerator
[17] OVI retries use vstart for re-execution, were randomized with UVM configuration objects, and were a primary source of VPU errors. Functional Verification of a RISC-V Vector Accelerator
[18] The authors implemented more than 50 SystemVerilog Assertions for OVI behavior, mostly targeting memory-related sub-interfaces. Functional Verification of a RISC-V Vector Accelerator
[19] The functional coverage plan focused on observable VPU interface behavior, internal modules, ISA tests, and RISCV-DV random tests. Functional Verification of a RISC-V Vector Accelerator
[20] CI recorded assertion and code coverage, used Jenkins pipelines for test generation/retry/selection/regression, and used GitLab for version control, issue tracking, and documentation. Functional Verification of a RISC-V Vector Accelerator
[21] The environment was used for about one year, and the team provided reproduction/debugging information and ran regressions before merging fixes. Functional Verification of a RISC-V Vector Accelerator
[22] Nightly testing ran 24 tests per night from April to July and 50 from August to November, with about 500 vector instructions each; the campaign found 3005 errors, around 70% from memory, narrowing, and widening instructions. Functional Verification of a RISC-V Vector Accelerator
[23] After nightly runs, additional pipelines ran around 600 tests per day; average functional coverage was 95.79%, average code coverage 72.64%, statement coverage 90.90%, and toggle coverage 49.83%. Functional Verification of a RISC-V Vector Accelerator
[24] The conclusion states that the reusable UVM environment checks OVI/VPU completed-instruction correctness and that CI/CD-enabled constrained-random testing found 3005 errors and reached 95.79% functional coverage. Functional Verification of a RISC-V Vector Accelerator
[25] The authors report that dividing communication among several agents complicated maintenance, extension, and performance, and suggest a single stimulus-producing agent as future work. Functional Verification of a RISC-V Vector Accelerator