Overview
“UVM Based Design Verification of a RISC-V CPU Core” is a technical work available as a POLITesi PDF that discusses verification of RISC-V CPU cores using UVM-oriented design-verification practices. The work frames CPU verification as a demanding problem because processors are complex state machines with many states and corner cases; verification must check instruction correctness, exception handling, memory accesses, timing behavior, and expected functional outcomes. It also notes that the practical number of possible test cases can be far beyond exhaustive exploration, making systematic verification strategy essential. [C1]
Verification planning
The work describes a verification test plan as a specification document that captures what must be verified for a design under test. The plan starts from the design or micro-architecture specification, which the verification engineer treats as a golden reference, and records features, supported configurations, combinations of features/configurations, and selected micro-architectural cases. The evidence also identifies constrained-random and coverage-driven simulation as common functional-verification approaches, with formal verification applicable to selected design areas or special features. [C2]
UVM and SystemVerilog background
The paper’s background material presents UVM as a SystemVerilog class framework for building verification testbenches. It names common UVM testbench elements including drivers, monitors, stimulus generators, and scoreboards, and describes sequence items as dynamic data objects flowing through the testbench. It also explains UVM components as self-contained units of verification logic, the UVM factory as a mechanism for substituting derived types without changing testbench structure, and UVM phases as an organized simulation flow comprising build, run-time, and clean-up phases. [C3]
Open-source RISC-V verification context
The work uses open-source RISC-V cores as a way to examine production-oriented verification practices. It states that large companies often keep CPU verification methods proprietary, while the open-source nature of RISC-V makes verification processes more visible. [C4]
Ibex example
For the Ibex core, the evidence states that Ibex is a production-quality open-source 32-bit RISC-V CPU core written in SystemVerilog and maintained by lowRISC. It is described as heavily parameterizable, suitable for embedded control applications, and verified using a UVM-based testbench. The Ibex verification approach uses co-simulation to cross-check execution against the Spike instruction-set simulator, and the testbench runs binaries generated from RISC-DV random-instruction-generator output. Additional stimulus includes randomized memory timings, memory errors, interrupts, and debug requests, with a comprehensive test plan and coverage plan. [C5]
Core-V-Verif example
The paper also discusses Core-V-Verif, described as an OpenHW Group functional-verification project for the CORE-V family of RISC-V cores. The evidence says the verification strategy initially focused on the CV32E40P, a power-efficient 32-bit RISC-V core with in-order execution and a four-stage pipeline. The Core-V-Verif environment provides a simulation environment for the CV32E40P RTL core, which implements the RV32IMCZifencei ISA extensions, and is intended to be adapted to other CORE-V cores. The evidence further states that using UVM and SystemVerilog class libraries makes the environment transferable, easier for the SoC community to adopt, and not specific to a single EDA vendor. [C6]
Test programs and checking
The evidence describes Core-V-Verif support for test programs that must be compatible with a Board Support Package (BSP). The BSP can include linker scripts, memory-region definitions, CSR configuration files, and assembly files needed to run a C program. The Core-V-Verif UVM environment supports pre-existing and generated test programs, both self-checking and non-self-checking, as well as tests that run without a test program, for example CSR access through a debug-module interface. It can generate tests with a random instruction stream generator, and checker-monitors can independently fail a simulation by raising uvm_error. [C7]
The evidence also identifies Spike and the RISC-V Formal Interface (RVFI) in the co-simulation/checking flow: a particular version of Spike is required for co-simulation, and RVFI provides information about retired instructions and synchronous traps for checking. [C8]