Hybrid Verification Methodology Wiki

Overview

Hybrid Verification Methodology is a RISC-V processor verification approach that combines constrained-random stimulus with directed test suites. The evidence describes the need for this combination because random testing can explore broad state spaces but may leave coverage gaps, while directed tests provide structure but may miss unexpected interactions. The combined strategy uses constrained-random stimulus for breadth and directed suites for precision and closure. (Citation: Hybrid approach rationale)

Verification Problem Addressed

RISC-V verification is complicated by the ISA's modular design and optional extensions. The evidence states that comprehensive coverage usually requires more than one verification or comparison methodology and more than one stimulus technique. Random stimulus is useful for uncovering unanticipated behavior, but features such as privilege-mode transitions, page-table walks, and memory protection may not be fully exercised by random generation alone. Directed tests can systematically validate those features but cannot anticipate all corner cases. (Citation: RISC-V verification complexity and random/direct limitations)

Core Components

Constrained-random testing with STING

STING is described as a bare-metal, software-driven RISC-V generator. It produces C++-based random streams and ASM-style directed tests using a lightweight kernel, libraries, and device drivers. The evidence also states that STING includes a programming framework for directed tests and uses stimulus graphs to let users control scheduling of both random and directed tests. (Citation: STING generation model)

STING-generated programs are portable across simulation, ZeBu emulation, HAPS FPGA prototyping, and silicon, and are architecturally self-checking. The evidence identifies STING as useful for stressing privilege levels, memory protection, CSRs, and hypervisor extensions. Reported issue classes found with STING include page-table-walk deadlocks, mishandling of the RISC-V fence.i instruction, floating-point NaN quirks, and cache-coherence conflicts. (Citation: STING portability and bug-finding use cases)

Directed suites with ImperasTS

ImperasTS is presented as the directed-test component used to address gaps revealed by coverage analysis. The evidence describes a complementary flow in which STING supports discovery and ImperasTS supports targeted closure. (Citation: ImperasTS role in targeted closure)

The ImperasTS family described in the evidence includes:

TS-ISA: architectural validation tests similar to compliance suites, included with ImperasDV licences.
TS-VECT: targeted suites for vector extensions.
TS-MMU / PMP / ePMP: directed suites for virtual memory and protection features.

The evidence states that these directed suites are configured to match the user's RISC-V processor and efficiently target areas where random stimulus often leaves gaps. One example cited in the evidence is adding TS-MMU tests after coverage analysis found weak points in Sv39 and Sv48 page-table walks; those tests exposed a subtle ordering issue in TLB flush logic. (Citation: ImperasTS family and coverage-gap targeting)

Typical Flow

A typical hybrid flow begins with constrained-random sweeps using STING, followed by functional coverage analysis with ImperasFC. The evidence states that ImperasFC generates SystemVerilog coverage models directly from the ISA specification and that the resulting functional coverage can be viewed in standard coverage reporting tools such as Verdi. Users can extend ImperasFC coverage models for custom features and cross-coverage points. (Citation: Coverage analysis with ImperasFC)

Coverage analysis can begin before RTL using ImperasSC, enabling a shift-left verification approach. Once RTL is available, coverage gaps are highlighted and closed. The evidence describes results being merged in Verdi and failing cases replayed deterministically in VCS, creating an iterative loop that combines broad random exploration with targeted closure. (Citation: Shift-left and iterative closure loop)

Integration

The methodology is described as part of a broader RISC-V verification environment that integrates test generation with simulation, reference models, debug tools, and hardware-assisted platforms. Constrained-random programs can run in simulators such as VCS, with Verdi used for centralized debug. ImperasDV provides lock-step comparison against a reference model, catching errors at instruction retirement. The same stimulus can be reused in ZeBu emulation or HAPS prototyping, extending validation to system-level workloads. (Citation: Tool and platform integration)

Benefits

The evidence identifies several benefits for RISC-V verification teams:

Faster coverage closure: STING random stimulus uncovers unexpected behavior, while ImperasTS directed suites provide precise tests for comprehensive closure.
Improved debug efficiency: Architecturally self-checking tests combined with ImperasDV lock-step compare identify mismatches immediately and simplify root-cause analysis.
Scalability and reproducibility: The flow scales from embedded cores to multi-hart systems, and logged seeds plus directed reruns support reproducibility across regressions.
Portability and shift-left enablement: Tests can move across simulation, emulation, FPGA prototyping, and silicon, while ImperasSC enables pre-RTL coverage analysis.
Future-ready compliance: The flow is described as supporting RISC-V profiles RVA22 and RVA23 and covering privilege-related areas including MMU, PMP, hypervisor, and vector extensions. (Citation: Hybrid methodology benefits)

Summary

Hybrid Verification Methodology uses constrained-random generation to expose unexpected RISC-V behavior and directed suites to close known feature and coverage gaps. In the evidence, STING provides portable, self-checking random and directed programs, ImperasTS provides targeted suites for ISA and extension-specific validation, ImperasFC and ImperasSC support coverage analysis and shift-left verification, and ImperasDV, Verdi, VCS, ZeBu, and HAPS support debug, simulation, emulation, prototyping, and reuse across the validation lifecycle.