memory operation stimulus

Memory Operation Stimulus

Concept

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.

First seen 5/28/2026

Last seen 5/28/2026

Evidence 3 chunks

Wiki v1

WIKI

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

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

2 connections

Functional Verification of a RISC-V Vector Accelerator ← uses 90% 2e

Memory operation stimulus is a key part of verification, requiring special handling in RISCV-DV and OVI.

riscv-dv ← introduces 88% 1e

RISCV-DV was extended to generate memory operation stimulus with configurable parameters.

LINKED ENTITIES

2 links

Functional Verification of a RISC-V Vector Accelerator USES Extracted graph relationship

riscv-dv INTRODUCES Extracted graph relationship

CITATIONS

7 sources

7 citations — click to expand

[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