RISCV-DV

Overview

RISCV-DV is the CHIPS Alliance-hosted chipsalliance/riscv-dv project, described in public repository metadata as a "Random instruction generator for RISC-V processor verification." Repository metadata reports Python as the project language, with 1,358 stars, 400 forks, and an update timestamp of 2026-09-30T12:52:50Z.^[1]

CHIPS Alliance describes RISCV-DV as an SV/UVM-based framework originally contributed by Google for rigorous CPU verification. In that description, it is an instruction generator for RISC-V processors and is used to verify features such as privileged modes (machine, supervisor, and user) and trap/interrupt handling.^[2]

The original public location for the project was https://github.com/google/riscv-dv, as cited by the 2020 OpenHW/Imperas announcement, the DVCon Europe paper "Rolling the Dice with Random Instructions is the Safe Bet on RISC-V Verification" (acknowledged by the Ibex development team at LowRISC), and the NaxRiscv lockstep-verification paper from RISC-V Summit Europe 2025.^[3][4][5] The repository subsequently moved to the CHIPS Alliance organization as chipsalliance/riscv-dv.^[2]

The Bruns et al. extended abstract "RISC-V Processor Verification with Coverage-guided Aging" (MBMV 2022) likewise characterizes Google's RISC-V DV as a particularly promising open-source approach in the constrained-random processor-verification landscape.^[6]

Industry reporting on UVM functional coverage for RISC-V cores likewise characterizes RISCV-DV as an open-source project enabling coverage-driven simulation "based on UVM constrained random methods and compliant with the Universal Verification Methodology (UVM) standard."^[7]

RISCV-DV also appears as a teaching topic in industry training courses on CPU verification. Alpinum Consulting's "Introduction to CPU and CPU Verification" training series covers instruction stream generation and open-source tools such as riscv-dv in its Part 1 module, alongside CPU architectures, microarchitecture, hierarchical verification strategies at the unit, CPU, and system levels, functional coverage modeling, and practical verification exercises that extend coverage models and constraints.^[8][9]

The same training program's broader scope is described in the Alpinum "RISC-V Software Ecosystem" announcement, which covers architectures and microarchitectures, ISA and toolchains, riscv-dv instruction stream generation, CPU integration, SoC feature verification, debug, coverage, and sign-off as topics of the live-online 2026 program.^[10]

Verification flow

The supported evidence describes RISCV-DV as a constrained-random instruction-stream or random-binary generator for RISC-V verification. The GLSVLSI 2021 EPEX paper characterizes Google's RISC-V DV as a test-generation approach that uses SystemVerilog together with UVM to continuously generate RISC-V instruction streams from constrained-random specifications.^[11]

The MBMV 2022 paper describes RISCV-DV as leveraging a co-simulation method in which an Instruction Set Simulator (ISS) serves as a functional reference model for the RTL processor under test. As a backbone, it applies constraint-based specification techniques in SystemVerilog to generate RISC-V assembly tests one after another. Arbitrary combinations of load/store and Control and Status Registers (CSRs) instructions, as well as infinite loops, are supported, enabling a very comprehensive test approach.^[6]

In the CHIPS Alliance flow description, instructions generated by RISCV-DV are executed both by the core under test and by a reference RISC-V instruction set simulator (ISS), with Spike and Renode named as examples. After execution, the core states are compared after each executed instruction in terms of register writebacks.^[2]

The 2020 OpenHW Group / Imperas announcement describes a typical configuration in which the SystemVerilog test environment runs the tests in a side-by-side configuration, with the DUT and reference model enabling a step-and-compare methodology, avoiding the inefficiencies of logfile-based methods and supporting direct analysis of any issues found. This side-by-side approach also supports advanced techniques with dynamic testbenches using UVM (Universal Verification Methodology) and SystemVerilog stimulus/response features.^[3]

The Imperas 2020 RISC-V Global Forum talk describes the OpenHW RISC-V DV flow for CV32/64 cores in detail: a UVM run-flow loads the generated test program into the Instruction Memory from a hexfile, invokes the toolchain (GCC compiling an assembly program produced by the random instruction generator, with elf2hex then converting the ELF into hex), and exercises the CORE-V CV32/64 RTL against a UVM RISC-V reference model in step-and-compare fashion. The talk notes that most test-programs are generated from Google's random instruction generator, and that the flow's Makefile target is make SIMULATOR=<sim> +UVM_TEST=riscv-dv-test. The Imperas talk further lists the Imperas model as the RISC-V golden reference and adds that Imperas has extended that flow with Vector and Bitmanip extension instructions (described at the time of the talk as not yet publicly released).^[12]

Alpinum Consulting likewise describes riscv-dv as a SystemVerilog/UVM-based RISC-V random instruction generator, documenting capabilities that include constrained instruction generation, privilege modes, exceptions, interrupt handling, illegal instructions, debug-related generation, directed-instruction mixing, and co-simulation hooks for several ISSs.^[13]

This makes RISCV-DV part of a co-simulation-oriented processor-verification workflow: randomized RISC-V programs provide stimulus, while an ISS supplies a reference execution for comparison against the device under test.^[2] In academic comparisons, RISCV-DV experiments are described as run "using the UVM framework with a commercial simulator," with Spike acting as the golden reference model.^[14]

The MBMV 2022 paper notes a key limitation of the RISCV-DV-style approach: it does not collect or employ runtime coverage information to assess and guide the test-generation process. Instead, the instruction-stream generators are based on a simple randomized test strategy, making it very difficult to continuously achieve a broad and deep test coverage in endless instruction streams. The authors' own follow-up work proposes a coverage-guided "aging" approach to address this limitation.^[6]

Supported ISA targets and generated stimuli

A 2025 RISC-V Summit Europe paper on lockstep verification of the NaxRiscv SoC describes RISCV-DV as a robust, open-source framework developed by Google and coded in SystemVerilog/UVM. It is characterized there as a generator of randomized instruction sequences and exhaustive test programs for the RV32/64IMAFDC ISAs across multiple privilege modes (M, S, and U), deliberately targeting critical edge cases to maximize functional coverage.^[15]

The same paper reports that RISCV-DV's generated test programs deliberately target edge cases such as misaligned instructions, register dependencies (RD/RS), pipeline hazards, memory access violations, and unhandled interrupts, thereby probing complex execution paths.^[16]

The paper also notes that RISCV-DV embeds a functional coverage model based on Universal Verification Methodology (UVM), covering various opcodes, extensions (such as F, D, and C), and the proper interactions with control and status registers (CSRs), ensuring exhaustive validation of all ISA features.^[17]

The Imperas 2020 case study identifies the LowRISC Ibex core as a "small 32 bit RISC-V CPU core (RV32IMC/EMC) with a two stage pipeline, previously known as zero-risky (PULP)" and links to https://github.com/lowRISC/ibex.^[18]

The FLAME paper (TCAD 2026) characterizes RISCV-DV as a constrained-random-verification (CRV) baseline that requires configuration to use and generates constrained random test cases based on the constraints of its internal implementation. The FLAME authors used RISCV-DV's default configuration in their experiments, following prior work. The FLAME paper also classifies RISCV-DV as a traditional CRV technique, "the most widely used in industry and academia," and selects it as their CRV baseline implementation.^[19]

A CVA6 verification-flow Makefile (Centralesupélec / cva6-zicfiss-2025) illustrates a concrete instantiation of the generator against the RV32IMC ISA target. The Makefile defines comp_riscv-dv and gen_riscv-dv rules that compile and elaborate RISCV-DV against RISCVDV_PKG/target/rv32imc together with user_extension and tests include paths and a COREVDV_PKG/manifest.f file list, then run corev_instr_base_test with xceligen rand_struct to emit a randomized assembly stream into google-riscv-dv. The example invocation sets num_of_tests=2, start_idx=0, asm_file_name=$(CORE_TEST_DIR)/google-riscv-dv, instr_cnt=10000, num_of_sub_program=0, directed_instr_0=riscv_int_numeric_corner_stream,4, boot_mode=m, and disables fences (no_fence=1), data pages (no_data_page=1), branch/jumps (no_branch_jump=1), and CSR instructions (no_csr_instr=1). The generated *.S files are then moved into $(CORE_TEST_DIR)/custom for downstream simulation. The corev-dv make target composes clean_riscv-dv clone_riscv-dv comp_riscv-dv gen_riscv-dv.^[20]

Multi-hart test generation

The ETH Zurich "HARTBREAKER" paper (ISCA 2026) characterizes RISCV-DV as "a widely-used random instruction generator for RISC-V verification" and, to the authors' knowledge, "the only tool capable of automated generation of multi-hart test" cases.^[21] That work used RISCV-DV's "default multi-hart target, configured for 64-bit designs with three harts," evaluating coverage on a triple-hart BOOM configuration.^[22]

RISCV-DV is described in the same comparison as using "pre-defined test scenarios, which guide random programs towards specific features of a CPU," and as lacking capabilities that HARTBREAKER adds — specifically IPI support, memory-model checking, and deterministic interrupt injection — while reaching comparable coverage.^[23]

Implementation and extensibility

The OpenHW Group CORE-V verification documentation describes riscv-dv as implemented as a collection of SystemVerilog classes extending uvm_object. That structure is cited as making it straightforward to extend RISCV-DV classes to modify behavior, including implementing specific instruction streams as extensions of existing RISCV-DV classes rather than modifying RISCV-DV itself.^[24]

COREV-DV is documented as a library of extensions to the Google riscv-dv instruction-stream generator. In the CORE-V flow, a specific RISCV-DV hash can be cloned into a core-specific vendor_lib/riscv-dv directory, and compile makefiles build the required extensions for a core-specific generated test program.^[24]

The CVA6 cva6-zicfiss-2025 Makefile also illustrates this extension composition in practice: it combines the upstream RISCVDV_PKG with a COREVDV_PKG/manifest.f file list and additional user_extension and tests include directories to specialize the generated stream for a given core.^[20]

Use in RISC-V verification projects

CHIPS Alliance states that the RISCV-DV co-simulation setup has been used in verification workflows for multiple RISC-V cores, including VeeR EL2 and Ibex.^[2]

The DVCon Europe paper "Rolling the Dice with Random Instructions is the Safe Bet on RISC-V Verification" applies RISCV-DV-style random-instruction methodology specifically to the LowRISC Ibex core, and the paper's acknowledgements thank the Ibex development team at LowRISC for their help and support.^[4]

The OpenHW CORE-V verification documentation says core-v-verif mostly uses RISCV-DV "as is," while allowing each core verified in core-v-verif to use whatever RISCV-DV version suits that core's needs.^[24]

The OpenHW / Imperas 2020 announcement describes the OpenHW Group CORE-V DV testbench using the Imperas RISC-V reference model as the golden reference, and cites the use of random instruction stream generators — specifically the Google open-source RISCV-DV ISG — as a common processor DV technique for testing complex states and extreme corner cases within that testbench.^[3]

The FLAME paper (TCAD 2026) studies processor designs including IBEX CPU, CVA6, and CV32E40P, and uses RISCV-DV as the constrained-random baseline; the targeted RISC-V ISA in that work is RV32IMC by default.^[25]

A PySpike presentation from Open Source @ Siemens 2025 (EsionTech / HuiMt Labs) lists riscv-dv among the RISC-V tools to which the authors' team are veteran contributors, alongside gcc and spike.^[26]

OpenHW CORE-V DV flow (Imperas 2020 case study)

The 2020 Imperas RISC-V Global Forum slides lay out the OpenHW RISC-V DV flow as a UVM environment for CV32/64 cores in which the random instruction generator output is assembled with a manually written crt0.S and link.ld, compiled with GCC, converted with elf2hex, and loaded into Instruction Memory. Memory-mapped virtual peripherals include the vp, Phe/EEE extensions, a debug agent driven by independent-of-UVM sequences, and an interrupt agent. The CORE-V CV32/64 RTL under test is step-and-compared against a UVM RISC-V reference model. The slides also describe the reuse of formal-verification-derived assertions in the testbench, with separate agents covering all CSRs, GPRs, and the PC.^[12]

The Imperas 2020 talk additionally documents an early phase of RISC-V golden-reference work, listing Imperas as the RISC-V golden reference model and noting that Imperas is extending its flow to support a step-and-compare DV methodology for Vector and Bitmanip extension instructions, described in the talk as not yet publicly released at that time.^[12]

NaxRiscv SoC lockstep verification

A 2025 paper from the RISC-V Summit Europe (CEA-LETI) describes a comprehensive lockstep verification framework for the NaxRiscv SoC that integrates RISCV-DV with Verilator-based cycle-accurate RTL simulation, the Spike golden ISS, the RISC-V Lock-Step (RVLS) framework, and Questa/UVM-based coverage analysis. In that flow, RISCV-DV generates constrained-random assembly programs that are executed on SocSim, a Scala-based multi-core SoC simulator built on Verilator, and the results are compared against Spike step-by-step.^[27]

The paper presents the NaxRiscv verification methodology as a multi-layered approach combining directed testing, real-world benchmarking, and constrained-random testing. The constrained-random layer, which leverages RISCV-DV, runs alongside compliance suites such as riscv-tests and riscv-arch-tests and benchmarks such as CoreMark, Dhrystone, FreeRTOS, and the Linux boot stage.^[28]

The same paper reports that the DUT's tracer.log and Spike's spike.log are converted to CSV and processed by Questa to collect coverage into a binary Unified Coverage Database (UCDB), with metrics reported through the vcover report command, covering instruction, CSR, and branch coverpoints including operand registers, branch outcomes, and memory alignment.^[29]

In the NaxRiscv flow, a Jenkins-based CI pipeline automates regression testing and dynamically scales RISCV-DV test generation until predefined coverage targets are met.^[30]

The NaxRiscv paper also reports concrete bugs uncovered through RISCV-DV-driven testing, including:

• Discrepancies in the IO/memory mapping that triggered trap_store_access_fault events.
• A misaligned instruction generated by RISCV-DV that resulted in a malformed opcode and a DUT/ISS mismatch stemming from a lack of verification of the Rd/Rs registers of certain compressed instructions (e.g., C.LWSP), causing trap_load_page_fault events.
• CSR configuration mismatches between the DUT and the Spike golden reference that led to observable execution anomalies (e.g., the DUT missing a trap).^[31]

Other project usage

A 2025 RISC-V Summit Europe abstract on verification of a multi-core RISC-V system reports heavy use of constrained-random testing and random binary generators, "mostly, riscv-dv," to verify designs and uncover bugs. In that project, generated tests were checked using co-simulation with a modified Spike ISS reference model, and code and functional coverage were analyzed to identify corner cases for generator-configuration changes or directed tests.^[32]

The same 2025 abstract reports project-specific modifications to RISCV-DV for full RVV 1.0.0 support, vector memory instruction generation with changing SEW and vector-length values, and additional options to control the kinds of instructions generated. These are described as adaptations by that project, not as evidence of baseline upstream RISCV-DV behavior.^[33]

What RISCV-DV can and cannot establish

The Alpinum Consulting RISC-V verification IP/sign-off guide explicitly characterizes riscv-dv as a "stimulus-generation component" rather than a complete verification strategy: a team still has to decide what to generate, constrain illegal or irrelevant scenarios correctly, introduce directed stimulus where probability is insufficient, connect generated programmes to checking, and determine whether the generation space actually addresses the verification plan. The same source notes that riscv-dv is "not a complete verification strategy" and that "[r]andom generation without verification intent can create enormous regressions while leaving important scenarios untouched."^[13]

The Alpinum Consulting FAQ describes the CHIPS Alliance project as a SystemVerilog/UVM-based RISC-V random instruction generator that "does not constitute a complete sign-off environment by itself."^[34]

The same source's component-capabilities section lists riscv-dv's primary role as generating RISC-V instruction streams and related stimulus within a broader verification stack; it cannot, on its own, establish complete processor verification or sign-off.^[35]

The same Alpinum Consulting training program reinforces this scoping by dedicating a Part-1 lesson to "Instruction stream generators and riscv-dv overview" alongside CPU verification strategies at the unit, CPU, and system levels, but explicitly covering it as one ingredient in a hierarchical verification methodology rather than as a self-contained verification environment.^[8]

Evidence limitations

The current evidence supports RISCV-DV's role as a RISC-V constrained-random instruction generator integrated with SV/UVM and ISS-based co-simulation flows, using constraint-based specification techniques in SystemVerilog and a simple randomized test strategy. It targets the RV32/64IMAFDC ISA subset across machine, supervisor, and user privilege modes, with documented extension support at least including F, D, and C, and is the only tool, to the best of the HARTBREAKER authors' knowledge, capable of automated generation of multi-hart test cases. A concrete Makefile-based integration against the RV32IMC ISA target demonstrates how the generator is composed with a core-specific extension package (COREVDV_PKG) and directed-instruction streams (e.g., riscv_int_numeric_corner_stream) to produce customized assembly programs. The OpenHW CORE-V DV flow described by Imperas in 2020 documents the specific Makefile target (make SIMULATOR=<sim> +UVM_TEST=riscv-dv-test), the GCC + elf2hex toolchain integration, and the Imperas reference-model-based step-and-compare check used in that flow. RISCV-DV is also used as a teaching topic in industry CPU-verification training programs. It does not provide enough detail to document command-line usage beyond the specific examples seen, repository license, full supported ISA-extension matrix, output file formats beyond .S, simulator compatibility matrix beyond specific named simulators (XRUN, Verilator, Spike, Renode), trace formats, or release history.