Directed Testing

Directed testing is a structured stimulus technique used in RISC-V processor verification to exercise specific architectural features, compliance scenarios, and coverage gaps. In the cited verification flow, directed tests are contrasted with random stimulus: random testing explores broad state spaces and can uncover unanticipated behaviors, while directed testing provides structure and systematic feature validation. The evidence also notes a limitation: directed tests may miss unexpected interactions, so they are most effective when combined with constrained-random stimulus. [Directed testing role]

Purpose in RISC-V verification

RISC-V verification is complicated by the ISA's modular structure 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 stimuli are useful for broad exploration, but some areas—such as privilege-mode transitions, page table walks, and memory protection—may not be fully exercised by random generation alone. Directed suites are used to systematically validate such features and help close gaps exposed by coverage analysis. [Need for directed tests]

Directed testing versus constrained-random testing

Directed testing and constrained-random testing serve complementary roles:

• Constrained-random stimulus is used for breadth and for discovering unexpected behaviors.
• Directed tests or directed suites are used for precision, compliance-oriented validation, and targeted closure of known coverage gaps.

The evidence explicitly describes the most effective strategy as combining constrained-random and directed tests: random stimulus is used to discover unexpected behavior, while directed suites are used to guarantee compliance with the specification. It also notes that compliance is necessary but not sufficient for verification. [Random-directed complementarity]

Generation and execution

Directed tests can be generated or supported by tools in the RISC-V verification flow. STING is described as a bare-metal, software-driven generator for RISC-V that produces C++-based random streams and ASM-style directed tests. It also includes a programming framework for developing directed tests and uses stimulus graphs to control scheduling of both random and directed tests. [STING directed stimulus]

The generated programs are described as portable across simulation, emulation, FPGA prototypes, and silicon, and as architecturally self-checking. This portability allows tests created during RTL bring-up to remain useful in later validation stages and even in silicon. [Portable directed stimulus]

Directed suites

The evidence identifies ImperasTS as a family of directed suites used for targeted validation. It lists:

• TS-ISA for architectural validation tests similar to compliance suites.
• TS-VECT for vector extensions.
• TS-MMU / PMP / ePMP for virtual memory and protection features.

These suites are described as targeting areas where random stimulus often leaves gaps. One example in the evidence states that after 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. [Directed suite scope]

Role in coverage closure

Directed testing is part of an iterative coverage-closure flow. A typical workflow begins with constrained-random sweeps using STING, followed by functional coverage analysis. Coverage gaps are then highlighted and closed with targeted tests. The evidence describes this as a hybrid approach in which random stimulus provides breadth and directed tests provide targeted closure. [Coverage closure flow]

Integration in a hybrid verification methodology

Directed testing is most effective when integrated with simulation, reference models, debug tools, and hardware-assisted platforms. The evidence describes a flow where constrained-random and directed tests run in simulation, coverage results are viewed in tools such as Verdi, failing cases are replayed deterministically in VCS, and the same stimulus can be reused in ZeBu emulation or HAPS prototyping. This supports a shift-left methodology because tests developed during RTL bring-up can continue to be reused through later validation stages. [Hybrid integration]

Practical limitations

Directed tests provide structure and targeted validation, but the evidence states that they cannot anticipate all subtle corner cases. For that reason, directed testing should not be treated as a replacement for random or constrained-random stimulus. Instead, the cited methodology treats directed testing as one part of a combined strategy for coverage closure and bug prevention. [Directed testing limitation]