Memory Operations Stimulus

Concept

Memory Operations Stimulus refers to the generation and environment setup needed to exercise RISC-V vector memory operations in a VPU verification flow. In the cited flow, RISCV-DV was extended to vary vector configuration, initialize data pages, and constrain accessed addresses, while Spike and a UVM memory model supplied and checked load, store, masked, indexed, and retry scenarios.

First seen 5/27/2026

Last seen 5/27/2026

Evidence 3 chunks

Wiki v1

WIKI

Overview

Memory Operations Stimulus is the test-generation and verification-environment stimulus used to exercise vector memory operations in a RISC-V Vector Processing Unit (VPU) verification flow. The cited environment used RISCV-DV to generate random RISC-V assembly tests, including vector instructions, and modified its memory-operation generation so tests could change element width and vector length through generated vsetvli instructions. The flow also added selectable data-page initialization patterns and constrained test memory addresses to avoid memory exceptions, especially for vector indexed memory instructions.

Role in the verification environment

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

1 connections

riscv-dv ← uses 93% 1e

RISCV-DV was adapted to generate memory operations stimulus

LINKED ENTITIES

1 links

riscv-dv USES Extracted graph relationship

CITATIONS

7 sources

7 citations — click to expand

[1] RISCV-DV was used to generate random RISC-V assembly tests for the VPU, and it was extended to generate vsetvli instructions, modify memory-operation generation for element width and vector length changes, select data-page initialization patterns, constrain memory addresses, and adapt to RVV 0.7.1. source

[2] The VPU did not directly access memory; it used scalar-core-mediated memop, load, store, and mask interfaces that required inter-sub-interface communication. source

[3] For load operations, the environment obtained expected read data from Spike, wrote it into a memory model based on OpenTitan, accessed corresponding addresses, and sent the Spike data through the VPU load sub-interface. source

[4] For store operations, memory needed to be initialized before execution to check masked operations and detect undesired writes; VPU store data was saved in the memory model and later compared with Spike values. source

[5] Masked memory operations sent masks or indexes from the VPU, and those transactions were needed by the environment to execute the instruction and compare against Spike; this comparison helped identify mask-related memory-instruction errors. source

[6] Retry scenarios occurred when the VPU could not handle all loaded cache lines; retry completion reported a vstart value, required killing later instructions and reissuing from that element, and was randomized with UVM configuration objects to increase retry occurrence. source

[7] Spike was used as both scalar core and golden/reference model, and was modified with methods to resume until vector instructions, return reference results, and read Spike memory. source