Skip to content
STIMSMITH

RISC-V Vector Extension (RVV)

Concept WIKI v2 · 5/27/2026

The RISC-V Vector Extension (RVV) is a vector extension of the open-source RISC-V ISA. The provided evidence describes RVV as vector-length agnostic, configurable for different element widths, and including vectorized arithmetic, logical, and memory instructions plus vector-specific operations such as reductions and scatter/gather. It also documents practical verification concerns for an RVV 0.7.1 vector accelerator, including RISCV-DV test generation, Spike co-simulation, vsetvli configuration, memory-operation testing, vstart retry behavior, and unordered floating-point reduction handling.

Overview

The RISC-V Vector Extension (RVV) is a vector extension of the open-source RISC-V Instruction Set Architecture (ISA). A 2022 verification paper describes RISC-V as an open-source ISA with a vector extension, notes that RVV version 1.0 existed at that time, and studies a vector accelerator implementing RVV 0.7.1. [RVV ISA role and version context]

RVV includes vectorized versions of many arithmetic, logical, and memory instructions. It also includes vector-specific instructions such as reductions and scatter/gather operations. [RVV instruction categories]

A key property described in the evidence is that RVV is vector-length agnostic and supports different element widths. In the verification work, vector length and element width were exercised through generation of vsetvli instructions and memory-operation generation adapted to allow changes in element width and vector length. [RVV vector-length agnostic behavior and vsetvli configuration]

Architectural and ISA characteristics

The public research context states that the standard RISC-V V extension requires 32 vector registers. A 2024 paper explored reducing the vector register file to 16 or 8 registers for small processors while keeping other RVV features, noting that such reduced-register designs would not be binary-compatible with standard RVV but could be supported by compiler parameterization. [Standard RVV vector register count and reduced-register proposals]

A 2025 paper comparing long-vector ISA approaches characterizes existing long-vector extensions such as RVV and Arm SVE as providing one-dimensional strided and random memory accesses. [RVV memory-access characterization in in-cache-computing research]

Example implementation context: RVV 0.7.1 vector accelerator

The cited verification paper describes a RISC-V-based decoupled vector accelerator implemented against RVV 0.7.1 and connected to a scalar processor core through the Open Vector Interface (OVI). [RVV 0.7.1 accelerator implementation]

The Vector Processing Unit (VPU) in that work was based on ISA Vector extension 0.7.1v and had eight vector lanes. It supported vectors up to 256 elements of 64 bits each, had 32 logical and 40 physical vector registers, and supported 64- and 32-bit floating-point vector operations as well as 64-, 32-, 16-, and 8-bit integer vector operations. [Example VPU capabilities]

In that implementation, the scalar core executed scalar instructions and sent vector instructions to the VPU. Vector memory accesses were also performed by the scalar core through OVI. [Scalar core and VPU interaction]

Verification considerations

The evidence describes an RVV verification infrastructure using a UVM environment with step-by-step co-simulation of vector instructions. Spike was used as an instruction set simulator and reference model, while constrained-random binaries and C programs were used for testing. [RVV verification infrastructure]

RISCV-DV adaptation

RISCV-DV is described as a tool that generates random RISC-V assembly tests. In the cited work, it was used to provide vector instructions for VPU testing, but it implemented a later RVV version than 0.7.1, requiring adaptation. [RISCV-DV use for RVV testing]

The cited adaptations included generation of vsetvli instructions, modifications to memory-operation generation to allow changes in element width and vector length, options for data-page initialization patterns, constraints on memory addresses to avoid memory exceptions, and adaptation to RVV 0.7.1. [RISCV-DV RVV adaptations]

Spike as scalar core and reference model

Spike had two roles in the verification environment: it executed scalar instructions while providing vector instructions to the UVM environment in program order, and it served as the golden/reference model for checking device-under-test results. [Spike roles]

The evidence describes modifications to Spike, including SystemVerilog DPI-callable functions, a method to resume simulation until a vector instruction is executed, functions to read Spike memory, and a function to force reduction results into Spike to avoid divergence in unordered floating-point reductions. [Spike modifications]

Floating-point reductions

A notable RVV-specific verification issue involved floating-point reduction instructions. The VPU used a different reduction algorithm from Spike, and the evidence states that this was allowed by the RVV specification. This could produce mismatches even when the VPU result was correct for its rounding mode and algorithm; additionally, an uncorrected mismatch could leave incorrect values in Spike vector registers and affect later comparisons. [RVV reduction algorithm allowance and verification issue]

To address this, the authors created an independent C reference model for unordered reductions that implemented the same reduction algorithm as the device under test. For these cases, the VPU result was compared against that reduction reference model rather than Spike, and matching values were injected back into Spike registers. [Reduction reference model workaround]

Memory operations and vstart retries

The cited implementation treated memory operations as a delicate verification area because the VPU did not have direct memory access. Instead, it read and wrote data through the scalar core using memory-related interfaces that required inter-interface communication. [VPU memory-operation verification]

For load operations, the verification environment needed expected memory data before instruction execution; data from Spike was written into a memory model and provided through the VPU load interface. For store operations, memory data was needed before execution to check masked operations and detect undesired writes. [Load and store verification behavior]

The OVI-based implementation also exposed retry scenarios. If the VPU could not handle all loaded cache lines sent by the scalar core, the instruction completed with a vstart value representing the first element that could not be written to vector registers; the instruction then had to be re-executed from that element. The paper reports that retries were a primary source of VPU errors and required directed tests covering different vstart values. [vstart retry behavior]

Reported verification outcome

The cited paper reports that the verification process found 3005 errors and reached 95.79% functional coverage for the studied RISC-V vector accelerator. [Verification outcome]

LINKED ENTITIES

5 links
riscv-dv USES
spike USES
RISC-V PART_OF
vstart PART_OF
Unordered Floating-Point Reductions PART_OF

CITATIONS

19 sources
19 citations
[1] RVV ISA role and version context Functional Verification of a RISC-V Vector Accelerator
[2] RVV instruction categories Functional Verification of a RISC-V Vector Accelerator
[3] RVV vector-length agnostic behavior and vsetvli configuration Functional Verification of a RISC-V Vector Accelerator
[4] Standard RVV vector register count and reduced-register proposals RISC-V V Vector Extension (RVV) with reduced number of vector registers
[5] RVV memory-access characterization in in-cache-computing research Multi-Dimensional Vector ISA Extension for Mobile In-Cache Computing
[6] RVV 0.7.1 accelerator implementation Functional Verification of a RISC-V Vector Accelerator
[7] Example VPU capabilities Functional Verification of a RISC-V Vector Accelerator
[8] Scalar core and VPU interaction Functional Verification of a RISC-V Vector Accelerator
[9] RVV verification infrastructure Functional Verification of a RISC-V Vector Accelerator
[10] RISCV-DV use for RVV testing Functional Verification of a RISC-V Vector Accelerator
[11] RISCV-DV RVV adaptations Functional Verification of a RISC-V Vector Accelerator
[12] Spike roles Functional Verification of a RISC-V Vector Accelerator
[13] Spike modifications Functional Verification of a RISC-V Vector Accelerator
[14] RVV reduction algorithm allowance and verification issue Functional Verification of a RISC-V Vector Accelerator
[15] Reduction reference model workaround Functional Verification of a RISC-V Vector Accelerator
[16] VPU memory-operation verification Functional Verification of a RISC-V Vector Accelerator
[17] Load and store verification behavior Functional Verification of a RISC-V Vector Accelerator
[18] vstart retry behavior Functional Verification of a RISC-V Vector Accelerator
[19] Verification outcome Functional Verification of a RISC-V Vector Accelerator

VERSION HISTORY

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