Skip to content
STIMSMITH

Memory Operation Stimulus

Concept WIKI v1 · 5/28/2026

Memory operation stimulus is the generation, initialization, and constraint of vector memory-operation test cases used to verify a RISC-V vector accelerator. In the cited verification environment, RISCV-DV was extended to vary vector length and element width, initialize data pages, constrain memory addresses, and stress load/store behavior including masks, indexed accesses, retries, and vstart handling.

Overview

Memory operation stimulus refers to the test stimulus used to exercise vector load, store, mask, and indexed memory-operation behavior in a RISC-V vector accelerator verification environment. In the cited work, memory operations were treated as a delicate verification area because the Vector Processing Unit (VPU) did not access memory directly; instead, it read and wrote data through a scalar core using the memop, load, store, and mask interfaces, requiring substantial inter-sub-interface communication. [C1]

Generation in RISCV-DV

The verification flow used RISCV-DV to generate random RISC-V assembly tests that provided vector instructions to the VPU. The authors extended RISCV-DV with memory-operation-related capabilities, including:

  • generation of vsetvli instructions and modification of memory-operation generation so tests could change element width and vector length;
  • an option to select the initialization pattern of data pages;
  • constraints on memory addresses accessed by generated tests to avoid memory exceptions, especially for vector indexed memory instructions;
  • adaptation of the generated stimulus to the RISC-V Vector 0.7.1 specification used by the design. [C2]

These additions made the memory-operation stimulus configurable enough to test different vector-length and element-width combinations while avoiding unintended exception scenarios that would obscure functional checking. [C2]

Load stimulus and memory-model setup

For vector load operations, the verification environment needed the expected data to be present in memory before the instruction executed. Along with instruction information from Spike, the environment retrieved the data that should be read, wrote that data into a memory model based on the OpenTitan memory model, and then sent the Spike data through the VPU load sub-interface at the corresponding addresses. [C3]

Store stimulus and masked-operation checking

For vector store operations, the environment also needed pre-existing memory contents before instruction execution. This was required to check masked stores and detect undesired writes. During a store, the VPU sent data to the memory model; later, the stored values were read back and compared with Spike’s expected values. [C4]

Masked memory operations produced additional outgoing transactions from the VPU, including masks or indexes. The environment used these transactions to execute the instruction-side memory behavior and compare it against Spike, which helped identify mask-related errors in memory instructions. [C5]

Retry-oriented stimulus

The environment also randomized memory-exception and retry scenarios. In the Open Vector Interface behavior described by the authors, retries occurred when the VPU could not handle all loaded cache lines sent by the scalar core. The instruction then completed with a vstart value identifying the first element that could not be written to the vector registers, meaning the instruction had to be re-executed from that element. [C6]

The verification environment randomized retries using UVM configuration objects to increase the chance of provoking these cases. This was important because retries required killing instructions after the retried instruction, reissuing from the stored vstart, and correctly calculating vstart from the lowest received index, mask, or data chunk. The authors reported that retries were a primary source of VPU errors. [C6]

Coverage role

Memory operation stimulus was also tied to functional coverage. The cited verification effort implemented coverage for diverse load and store scenarios, considering not only vector length but also the organization of the register file. Loads and possible retries with different vstart values were covered by directed tests that were added to the regression suite. [C7]

LINKED ENTITIES

2 links
Functional Verification of a RISC-V Vector Accelerator USES
riscv-dv INTRODUCES

CITATIONS

7 sources
7 citations
[1] Memory operations were a delicate verification area because the VPU accessed memory through scalar-core memop, load, store, and mask interfaces rather than directly. Functional Verification of a RISC-V Vector Accelerator
[2] RISCV-DV was used to generate random RISC-V assembly tests and was extended with vsetvli generation, memory-operation generation changes for element width and vector length, data-page initialization selection, address constraints, and RVV 0.7.1 adaptation. Functional Verification of a RISC-V Vector Accelerator
[3] For load operations, expected data from Spike was written into a memory model and sent through the VPU load sub-interface at corresponding addresses. Functional Verification of a RISC-V Vector Accelerator
[4] For store operations, pre-existing memory data was needed to check masked operations and detect undesired writes; VPU store data was later read and compared with Spike values. Functional Verification of a RISC-V Vector Accelerator
[5] Masked memory operations produced outgoing VPU transactions carrying masks or indexes, and comparing them with Spike helped identify mask-related memory-instruction errors. Functional Verification of a RISC-V Vector Accelerator
[6] Retries occurred when the VPU could not handle all loaded cache lines, completed with a vstart value, required re-execution from that element, and were randomized using UVM configuration objects because they were a major source of VPU errors. Functional Verification of a RISC-V Vector Accelerator
[7] Functional coverage included diverse load and store scenarios, register-file organization considerations, and directed tests for loads and retries with different vstart values. Functional Verification of a RISC-V Vector Accelerator