Definition

Hybrid Verification Methodology is a verification strategy that combines multiple stimulus and comparison techniques rather than relying on any single approach. The evidence frames this as necessary for RISC-V: achieving comprehensive coverage typically requires more than one verification or comparison methodology and always requires more than one stimulus technique. [C1]

For RISC-V processor verification, the hybrid methodology combines constrained-random stimulus for breadth with directed suites for precision, because random testing can explore broad state spaces but may leave gaps, while directed tests provide structure but may miss unexpected interactions. [C2]

Rationale

RISC-V verification is challenging because the ISA is modular and includes many optional extensions, increasing verification complexity. Random stimulus is useful for uncovering unanticipated behaviors, but it may not fully exercise features such as privilege-mode transitions, page table walks, or memory protection. Directed suites can systematically validate such features, but they cannot anticipate every subtle corner case. The hybrid methodology addresses these complementary weaknesses by using random stimulus to discover unexpected behavior and directed suites to guarantee specification-oriented coverage and compliance. [C3]

The evidence also identifies alternative hybrid combinations that combine trace-based comparison with verification IP. One such hybrid methodology pairs post-simulation trace file compare with verification IP, using trace compare for ISA and unprivileged tests, and using VIP for complex scenarios including synchronous and asynchronous exceptions and corner cases, while combining the functional coverage results from both environments. [C4]

Choosing a hybrid methodology

The evidence describes two categories of considerations that influence which hybrid methodology is most appropriate for a given project: DUT considerations and technology considerations. [C5]

DUT considerations

DUT considerations include whether the design is new, whether it started from a commercial IP core and the magnitude of the change, whether it is based on an open-source core, the availability of prior verification infrastructure that can be reused, the verification goal (research project, IP product, or tape-out), and reuse requirements across teams and future projects. [C5]

Technology considerations

Technology considerations include the verification language, because some methodologies are only available in certain languages (e.g., functional coverage in SystemVerilog, UVM in SystemVerilog or Python, OSVVM in VHDL), and the choice between UVM, a home-grown flow, open-source tooling, or commercial VIP. [C6] UVM is widely adopted and industry-proven, with strengths in virtual sequences, configuration database, and messaging, but weaknesses in limited RTL simulation tool choice and its heavy-weight nature. [C6] The decision between building, using open-source, or using VIP involves a trade-off between VIP license cost and the time/effort cost of building an in-house solution. [C6]

Hybrid methodology patterns

Pattern: Constrained-random plus directed tests

A typical flow begins with constrained-random sweeps using STING, followed by functional coverage analysis. Coverage gaps are then highlighted and closed using targeted directed tests. The evidence describes an iterative loop in which results are merged in Verdi and failing cases are replayed deterministically in VCS, combining broad random exploration with targeted closure. [C7]

Pattern: Trace file compare plus VIP

The evidence describes a hybrid methodology that combines post-simulation trace file compare with verification IP: trace file compare is used for ISA / unprivileged tests, and verification IP is used for complex scenarios such as synchronous and asynchronous exceptions and corner cases, with functional coverage results combined across the two environments. The stated pros are potential savings on license costs, and the stated cons are the effort required to build, maintain, and coordinate two separate verification environments. [C4]

Methodology flow for the STING-based pattern

Constrained-random phase

STING is described as a bare-metal, software-driven RISC-V generator that produces C++-based random streams and ASM-style directed tests. It uses a lightweight kernel, libraries, device drivers, and stimulus graphs to give users control over scheduling of generated random and directed tests. The generated programs are portable across simulation, emulation, FPGA prototypes, and silicon, and are architecturally self-checking. [C8]

In practice, STING has exposed issues such as deadlocks in page-table walks, mishandling of the fence.i instruction, floating-point NaN quirks, and cache-coherence conflicts. These examples support its role in the broad-exploration portion of the hybrid methodology. [C9]

Directed-test phase

Directed stimulus is used to address gaps found by coverage analysis. The evidence identifies ImperasTS directed suites such as TS-ISA for architectural validation, TS-VECT for vector extensions, and TS-MMU/PMP/ePMP for virtual memory and protection features. These suites are described as efficiently targeting areas where random stimulus often leaves gaps. [C10]

The evidence gives an example in which coverage analysis revealed weak points in Sv39 and Sv48 page-table walks; adding TS-MMU tests exposed a subtle ordering issue in TLB flush logic. [C11]

Assertions as part of the hybrid flow

The evidence describes assertions as rules that check behavior over time, that can be used to verify micro-architectural details, can be written by RTL designers, and can be reused in formal verification. "Cover" properties contribute to functional coverage. Assertions support the hybrid methodology by providing fine-grained checks that complement higher-level functional coverage and reference-model comparison. [C12]

Coverage closure and debug

The hybrid approach is explicitly associated with faster coverage closure: random stimulus with STING uncovers unexpected behaviors, while directed suites provide precise tests that accelerate convergence. [C13]

Debug efficiency is improved by combining architecturally self-checking tests with lock-step comparison in ImperasDV, allowing mismatches to be identified immediately and simplifying root-cause analysis. The evidence also states that failing cases can be replayed deterministically in VCS, supporting reproducibility across regression cycles. [C14]

Portability and shift-left use

The methodology supports reuse of tests across simulation, ZeBu emulation, HAPS FPGA prototyping, and silicon. The evidence states that this portability enables a shift-left methodology because tests developed during RTL bring-up remain valuable in later validation stages and even in silicon. Coverage analysis can also begin before RTL using ImperasSC, allowing coverage growth before RTL maturity. [C15]

Benefits

According to the evidence, a hybrid approach provides several benefits for RISC-V verification teams:

• Faster coverage closure through STING random stimulus and precise directed tests.
• Improved debug efficiency through self-checking tests and lock-step comparison.
• Scalability and reproducibility across simple embedded cores and complex multi-hart systems, with logged seeds and directed reruns.
• Portability and shift-left enablement across simulation, emulation, FPGA prototyping, and silicon.
• Future-ready compliance for RISC-V profiles and privilege-related specifications, including MMU, PMP, hypervisor, and vector extensions. [C16]

Position in a verification environment

The evidence frames test generation as part of a broader RISC-V verification toolbox that includes simulation, reference models, debug tools, and hardware-assisted platforms. In that environment, constrained-random and directed tests are most effective when integrated with coverage, debug, and comparison infrastructure. [C17]