RISC-V Test Generation: Using Random and Directed Stimulus to Achieve Coverage Closure

Introduction
Design verification of RISC-V processors presents unique challenges. The RISC-V ISA’s modular design and wide range of optional extensions enable flexibility but also introduce significant verification complexity [1]. Achieving comprehensive coverage typically requires more than one verification/comparison methodology, and always requires more than one stimulus technique.

Random testing can explore broad state spaces but often leaves gaps. Directed tests provide structure but risk missing unexpected interactions. The most effective approach combines the two: constrained-random stimulus for breadth and directed suites for precision [2].

The Challenge: Random Alone Is Not Enough
In practice, random stimuli are excellent for uncovering unanticipated behaviours. However, relying only on randomness risks incomplete verification. Some ISA features, such as privilege-mode transitions, page table walks, or memory protection, may never be fully exercised by random generation [4].

Directed suites can systematically validate those features, but cannot anticipate subtle corner cases. Together, these limitations highlight the need for a combined strategy. Random stimulus is used to discover the unexpected, while directed suites guarantee compliance with the specification [3]. Note that compliance is a necessary but not sufficient measure for verification.

Constrained-Random Testing with STING
Constrained-random test generation is often the starting point for RISC-V design verification. STING is a bare-metal, software-driven generator developed for RISC-V [2]. It produces C++-based random streams and ASM-style directed tests, built on a lightweight kernel, libraries, and device drivers [2]. STING includes a programming framework to enable the development of directed tests. It uses stimulus graphs to enable user control of the scheduling of both the random and directed tests generated.

Figure 1: STING test generator architecture showing portable stimulus (C++ and ASM-style tests) executing across simulation, emulation, prototyping, and silicon.

The generated programs are portable across simulation, emulation (ZeBu®), FPGA prototypes (HAPS®), and silicon and are architecturally self-checking [2]. Because of this, STING is particularly effective at stressing privilege levels, memory protection, CSRs, and hypervisor extensions, where traditional flows may miss bugs [4].

In practice, STING has exposed issues such as deadlocks in page-table walks and mishandling the fence.i instruction (used in RISC-V to synchronise instruction and data streams), floating-point NaN quirks, and cache coherence conflicts [4]. These cases illustrate why constrained-random stimulus is essential for preventing bug escapes in RISC-V verification [1].

Directed Test Suites with ImperasTS
While constrained-random stimulus from STING uncovers unexpected behaviours, gaps revealed in coverage analysis can be systematically addressed with both directed stimulus generated by STING and the ImperasTS directed suites. Together, they form a complementary flow: STING for discovery, ImperasTS for targeted closure.

The ImperasTS family includes:

• ImperasTS-ISA: Architectural validation tests, similar to compliance suites, are included with ImperasDV licences.
• ImperasTS-VECT: Targeted suites for vector extensions.
• ImperasTS-MMU / PMP / ePMP: Directed suites for virtual memory and protection features. These directed suites efficiently target areas where random stimulus often leaves gaps. For example, after coverage analysis revealed weak points in Sv39 and Sv48 page table walks, adding TS-MMU tests quickly exposed a subtle ordering issue in TLB flush logic [4]. The test suites for vector, MMU, PMP, and ePMP are configured to match the user’s RISC-V processor.

A Hybrid Flow for Coverage Closure
The most effective strategy combines constrained-random and directed tests. A typical workflow begins with constrained-random sweeps using STING, followed by functional coverage analysis with ImperasFC, which generates SystemVerilog coverage models directly from the ISA specification [3].

Figure 2: RISC-V verification flow showing ImperasFC functional coverage and ImperasDV reference model integrated with Verdi for unified coverage analysis in VCS.

Since functional coverage is just conventional SystemVerilog, functional coverage results can be viewed in a standard coverage reporting tool such as Verdi. Note that the ImperasFC functional coverage models can be extended by users to add coverage for custom features, cross-coverage points, etc.

Figure 3: Imperas functional and stimulus coverage, integrated with a SystemVerilog testbench.

Coverage analysis can begin before RTL using ImperasSC, enabling a shift-left verification approach. Once RTL is available, coverage gaps are highlighted and closed. Results are merged in Verdi, and failing cases are replayed deterministically in VCS, creating an iterative loop combining breadth with targeted closure.

Integration into RISC-V Verification Flows
Test generation is part of a broader toolbox in a complete verification environment. Constrained-random and directed tests are most effective when integrated with simulation, reference models, debug tools, and hardware-assisted platforms.

For example, constrained-random programs can be executed in simulators such as VCS, with Verdi providing centralised debug. ImperasDV enables lock-step comparison against a reference model, catching errors at instruction retirement [3]. The same stimulus can be reused in ZeBu emulation or HAPS prototyping, extending validation to system-level workloads [2].

This portability enables a “shift-left” methodology. Tests developed during RTL bring-up remain valuable throughout later stages of validation and even in silicon.

Benefits for RISC-V Verification Teams
A hybrid approach to test generation delivers measurable benefits across the full verification lifecycle:

1. Faster coverage closure: Random stimulus with STING uncovers unexpected behaviours, while ImperasTS suites ensure comprehensive closure through precise, directed tests that accelerate convergence.
2. Improved debug efficiency: Combining architecturally self-checking tests with lock-step compare in ImperasDV enables engineers to identify mismatches immediately, thus simplifying root-cause analysis.
3. Scalability and reproducibility: The methodology scales from simple embedded cores to complex multi-hart systems. Logged seeds and directed reruns ensure reproducibility across regression cycles.
4. Portability and shift-left enablement: Tests are portable across simulation, emulation (ZeBu®), FPGA prototyping (HAPS®), and silicon. ImperasSC enables pre-RTL coverage analysis, moving validation earlier in the flow.
5. Future-ready compliance: The flow supports new RISC-V profiles (RVA22, RVA23) and covers critical privilege specifications, including MMU, PMP, hypervisor, and vector extensions.

Conclusion
Test generation is a cornerstone of RISC-V processor verification. Constrained-random stimulus from STING uncovers unexpected behaviours, while directed suites such as ImperasTS provide structured compliance and feature coverage. Together, they form a hybrid methodology that accelerates coverage closure, prevents late bug escapes, and builds confidence in design quality.

As RISC-V adoption accelerates across embedded, datacenter, and AI applications, this methodology provides the rigour and flexibility to validate diverse and complex implementations.

Next Steps

• Start broad exploration with STING to uncover subtle interactions and corner cases.
• Apply targeted ImperasTS suites for compliance, MMU, PMP, and vector extensions where coverage gaps remain.
• Integrate coverage and debug by merging ImperasFC/SC results into Verdi and replaying failing cases deterministically in VCS.
• Shift verification earlier with ImperasSC and pre-RTL stimulus coverage, ensuring coverage growth begins before RTL maturity. If your team is building or verifying RISC-V designs, Synopsys provides the most complete verification toolbox to accelerate closure. Explore the Synopsys RISC-V Verification Resources to learn how STING, ImperasTS, and ImperasDV can strengthen your flow from RTL bring-up through silicon.

Appendix A: Key Definitions

• Constrained-Random Test Generation
  A verification approach that generates random stimuli under user-defined constraints. It allows broad exploration of design states while avoiding illegal inputs, often uncovering subtle corner cases missed by directed tests.

• Self-Checking Tests
  Programs that automatically validate their results against expected outcomes or a reference model, flagging mismatches without requiring manual inspection.

• ImperasTS
  A family of directed, self-checking Test Suites (TS) for RISC-V. These suites provide targeted coverage where constrained-random testing may leave gaps. Examples include:

• TS-ISA: Architectural validation tests, similar to compliance suites, are included with ImperasDV licences.

• TS-VECT: Targeted test suites for vector extensions.

• TS-MMU / PMP / ePMP: Directed suites for virtual memory management and memory protection features.

ImperasTS suites self-check and automatically compare results against a reference model, making them effective at uncovering subtle design issues while accelerating coverage closure.

• STING
  A bare-metal functional verification tool designed for RISC-V. It generates portable, self-checking programs running across simulation, emulation, FPGA prototypes, and silicon, supporting constrained-random and directed stimulus.

• Lock-Step Compare
  Runs RTL and a golden reference model in parallel, comparing results at instruction retirement for early bug detection.

• Coverage Closure
  The process of achieving sufficient functional and code coverage to provide confidence that all relevant design behaviours have been tested.

• PMP / ePMP
  Physical Memory Protection (PMP) and Enhanced PMP are RISC-V features that restrict access to memory regions to enforce privilege, isolation, and security policies.

• Floating-Point NaN (Not a Number)
  Represents undefined values in floating-point arithmetic. RISC-V distinguishes between signalling NaNs (raise exceptions) and quiet NaNs (propagate silently).

• Cache Coherence Conflicts
  Issues in multi-core caches where multiple accesses to the same line cause stale data, corruption, or stalls if coherence is not enforced correctly.

• Sv39 / Sv48
  RISC-V virtual memory schemes that use 39-bit and 48-bit virtual addresses, respectively. They define multi-level page table structures for address translation.

• Functional Coverage (FC) / Stimulus Coverage (SC)
  Metrics that measure how thoroughly the stimulus has exercised ISA features and system behaviours. Automatically generated coverage models (e.g., via ImperasFC/SC) provide detailed insights into coverage gaps.

• Shift-Left Verification
  A methodology where test generation and validation are moved earlier in the design cycle. Portable stimulus enables tests to start in simulation and be reused in emulation, prototyping, and silicon, reducing late-stage risk.

• ImperasFC / ImperasSC
  Functional Coverage (FC) and Stimulus Coverage (SC) tools auto-generate SystemVerilog coverage models for RISC-V ISA features. They provide detailed metrics and integrate with Verdi.

Appendix B: Synopsys Tools

STING
A bare-metal functional verification tool for RISC-V that generates constrained-random and directed tests. Stimulus is portable across simulation, emulation (ZeBu®), FPGA prototypes (HAPS®), and silicon, and it is self-checking to simplify debugging.

• ImperasDV™
  Integrates fast reference models for RISC-V into verification flows. Enables lock-step comparison of RTL against a golden reference model at instruction retirement.

• VCS®
  HYPERLINK “https://www.synopsys.com/verification/simulation/vcs.html”A high-performance RTL simulation platform. Executes STING-generated random tests and ImperasTS directed suites to accelerate debug and coverage closure.

• Verdi®
  A debug and analysis platform used for waveforms, mismatch tracking, and functional coverage reporting.

• ZeBu® Emulation
  Hardware-assisted verification for long software-driven tests, OS bring-up, and large-scale workloads.

• HAPS® Prototyping
  FPGA-based prototyping solution for pre-silicon software development, performance validation, and extended regression cycles.

References
[1] L. Lapides, “RISC-V Processor Verification Requires the Full Toolbox,” Verification Futures UK, May 2025.

[2] Synopsys, “STING – Design verification for RISC-V-based CPU and SoC implementations.” Accessed: Sep. 12, 2025. [Online]. Available: https://www.synopsys.com/verification/sting.html

[3] Synopsys, “ImperasDV – RISC-V Processor Verification Made Easy.” Accessed: Aug. 30, 2025. [Online]. Available: https://www.synopsys.com/verification/imperasdv.html

[4] S. Davidmann, “RISC-V Processor Verification Requires the Full Toolbox,” in Verification Futures, UK: Verification Futures, 2025.