Overview

CV32E40P is a RISC-V CPU core from the OpenHW Group. The public OpenHW GitHub repository describes it as an in-order, 4-stage RISC-V RV32IMFCXpulp CPU based on RI5CY from PULP-Platform. The repository is written primarily in SystemVerilog.

A 2024 UVM verification study describes CV32E40P as a power-efficient 32-bit RISC-V core using in-order execution with a 4-stage pipeline. The same study notes that the core was already present in several commercial SoC designs, including IoT devices and a general-purpose 32-bit microcontroller.

ISA and implementation context

CV32E40P is part of the OpenHW CORE-V family of RISC-V-based open-source cores. In the Core-V-Verif context, the CV32E40P RTL core is described as being based on the RISC-V specification and implementing the RV32IMCZifencei ISA extensions. The public GitHub summary separately characterizes the repository as RV32IMFCXpulp; these descriptions should be read in their respective source contexts.

Verification with Core-V-Verif

Core-V-Verif is an OpenHW functional verification project intended to verify RISC-V cores in the CORE-V family. Its initial focus was the CV32E40P core. The project provides a simulation environment for the CV32E40P RTL core and is built using UVM and SystemVerilog class libraries, making the verification environment not specific to a single EDA vendor.

The Core-V-Verif testbench includes memory-model support for virtual peripherals, implemented by responding to reads or writes at specific addresses on the data bus. It also uses Board Support Package files to align test-program resources with the resources supported by the DUT; these can include linker scripts, CSR configuration files, and assembly files needed to run C programs.

Test-program model

The Core-V-Verif UVM environment can run test programs as long as they are compatible with the BSP. It distinguishes whether a program is pre-existing or generated at run time, and whether it is self-checking. The documented program categories are:

1. Pre-existing, self-checking programs.
2. Pre-existing, non-self-checking programs.
3. Generated, self-checking programs.
4. Generated, non-self-checking programs.
5. No test program, for cases such as debug-mode CSR access through the debug module interface.

The environment incorporates a random instruction stream generator and supports pass/fail reporting through a status-flags virtual peripheral for self-checking programs. Other checker-monitors can independently fail a simulation by signaling uvm_error.

UVM test flow

The CV32E UVM environment defines a base test class, uvmt_cv32_base_test_c, derived from uvm_test. Tests are expected to extend this base class to preserve the intended test flow. A typical run flow raises an objection, asserts the core fetch_en input, waits for the core and/or environment to signal completion, and then drops the objection.