Skip to content
STIMSMITH

Core-V-Verif

Tool WIKI v1 · 5/27/2026

Core-V-Verif is OpenHW Group’s functional verification project for the CORE-V family of RISC-V cores. It provides a UVM/SystemVerilog-based simulation environment initially focused on CV32E40P, supports pre-existing and generated test programs, and uses Board Support Package files to align software tests with testbench resources.

Overview

Core-V-Verif is a functional verification project developed by the OpenHW Group to verify RISC-V cores in the CORE-V family. The public repository describes it as a functional verification project for the CORE-V family of RISC-V cores.

The project’s verification environment was initially focused on CV32E40P, a 32-bit RISC-V core with in-order execution and a 4-stage pipeline. The cited thesis describes Core-V-Verif as providing a simulation environment for the CV32E40P RTL core, and notes that the environment was intended to be adapted for additional CORE-V cores such as CV32E40X, CV32E40S, CVA6, and future OpenHW roadmap cores.

Verification approach

Core-V-Verif uses UVM to make its verification environment transferable and easier for the wider SoC community to adopt. The environment is described as not being specific to a single EDA vendor because it uses class libraries based on SystemVerilog.

The CORE-V UVM environment centers on test programs executed by the core. These programs run in a simple execution environment defined by the ISA, the memory map supported by the testbench memory model, and memory-mapped virtual peripherals. The UVM environment is therefore aware of the test program and responds as part of the run flow.

Test programs

The Core-V-Verif UVM environment can support test programs regardless of how they are created, provided they are compatible with the relevant Board Support Package. The environment distinguishes whether a program is pre-existing or generated at run time, and whether it is self-checking.

Supported modes described in the evidence include:

  1. Pre-existing, self-checking: a memory image exists in the expected location, and the environment checks the status-flags virtual peripheral for pass/fail information.
  2. Pre-existing, not self-checking: a memory image exists in the expected location, but the environment does not check the status-flags virtual peripheral for pass/fail information.
  3. Generated, self-checking: the environment uses its random instruction generator to create a test program and checks the status-flags virtual peripheral.
  4. Generated, not self-checking: the environment uses its random instruction generator to create a test program and does not check the status-flags virtual peripheral.
  5. None: a UVM test can run without a test program, for example to access CSRs via the debug module interface in debug mode.

The evidence notes that pre-existing self-checking programs and generated non-self-checking programs are expected to predominate. It also states that checker-monitors can independently fail a simulation by signaling uvm_error, regardless of what a test program writes to the status-flags virtual peripheral.

Board Support Package and virtual peripherals

The core testbench memory module implements virtual peripherals by responding to read or write cycles at specific data-bus addresses. To keep software tests aligned with resources supported by the device under test and testbench, Core-V-Verif uses Board Support Package files. These can include linker scripts defining program sections and memory regions, control/status-register configuration files, and assembly files that provide the minimum startup support required to run a C program.

UVM test structure

In the CV32E environment described by the evidence, all UVM tests should extend the base test class uvmt_cv32_base_test_c, which directly extends uvm_test. The base test preserves the intended test flow and reduces duplicated boilerplate for test writers.

A typical CORE-V UVM test extends work in three phases:

  • Reset phase: often calls super.reset_phase() to invoke the default reset sequence, though a test-specific reset virtual sequence may also be used.
  • Configure phase: can load pre-compiled programs into instruction memory when required.
  • Run phase: usually contains the procedural code for the test.

The cited run-flow example raises an objection, asserts the core fetch_en input, waits for the core and/or environments to signal completion, and then drops the objection.

Repository

The public GitHub repository is openhwgroup/core-v-verif. Public repository metadata identifies the project language as Assembly and describes the repository as the functional verification project for the CORE-V family of RISC-V cores.

LINKED ENTITIES

6 links
Random Instruction Generator USES
UVM Based Design Verification of a RISC-V CPU Core MENTIONS
CV32E40P EVALUATES
UVM USES
SystemVerilog USES
Board Support Package USES

CITATIONS

9 sources
9 citations
[1] Core-V-Verif is a functional verification project for the CORE-V family of RISC-V cores, developed by OpenHW Group. openhwgroup/core-v-verif
[2] Core-V-Verif initially focused on CV32E40P and provides a simulation environment for the CV32E40P RTL core, with adaptation planned for other CORE-V cores. [PDF] UVM based design verification of a RISC-V CPU core - POLITesi
[3] Core-V-Verif uses UVM and SystemVerilog-based class libraries, and is described as not specific to a single EDA vendor. [PDF] UVM based design verification of a RISC-V CPU core - POLITesi
[4] The Core-V-Verif UVM environment supports pre-existing and generated test programs, self-checking and non-self-checking modes, and a no-program mode. [PDF] UVM based design verification of a RISC-V CPU core - POLITesi
[5] Core-V-Verif incorporates a random instruction stream generator to generate many test programs. [PDF] UVM based design verification of a RISC-V CPU core - POLITesi
[6] Checker-monitors can fail a simulation by signaling uvm_error independently of status written by a test program. [PDF] UVM based design verification of a RISC-V CPU core - POLITesi
[7] The core testbench implements virtual peripherals at specific data-bus addresses and uses Board Support Package files such as linker scripts, CSR configuration files, and startup assembly files to align tests with supported resources. [PDF] UVM based design verification of a RISC-V CPU core - POLITesi
[8] In the CV32E environment, UVM tests should extend uvmt_cv32_base_test_c, and a typical run flow raises an objection, asserts fetch_en, waits for completion, and drops the objection. [PDF] UVM based design verification of a RISC-V CPU core - POLITesi
[9] The public GitHub repository is openhwgroup/core-v-verif and its public metadata describes it as a functional verification project for CORE-V RISC-V cores. openhwgroup/core-v-verif