Directed Testing

Concept

Directed testing is a stimulus technique in which pre-selected, specific data values or sequences are applied to a design under test, rather than randomized values. It is used in hardware/RISC-V verification, custom processor benchmarks, and module-level testing of autonomous driving systems to target known corner cases, validate compliance, and close coverage gaps—most often in combination with constrained-random stimulus.

First seen 5/25/2026

Last seen 6/10/2026

Evidence 7 chunks

Wiki v2

WIKI

Directed Testing

Directed testing is a stimulus technique in which a testbench implements tests using specific, pre-selected data values and sequences for the design under test (DUT). It is contrasted with random and constrained-random testing, which generate stimuli with varying degrees of freedom. Directed testing is most often used to target known corner cases, validate compliance with specifications, and close specific coverage gaps, and is typically deployed alongside (not in place of) constrained-random stimulus. [Directed testing definition]

The paradigm appears across multiple verification domains, including hardware/SoC verification, RISC-V processor validation, custom processor benchmarks, and module-level testing of autonomous driving systems.

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

2 connections

Custom Benchmark ← uses 93% 2e

The custom benchmark consists of 40 manually directed test programs.

Directed-Random Verification ← extends 95% 1e

Directed-Random Verification extends Directed Testing by adding constraints and randomization to control data values.

LINKED ENTITIES

1 links

Custom Benchmark USES Extracted graph relationship

CITATIONS

13 sources

13 citations — click to expand

[1] Directed testing implements tests using specific, pre-selected data values and sequences, contrasted with random and constrained-random paradigms, and may miss errors at unselected addresses or with unselected data values. Testbench Automation and Constraints Tutorial - Doulos

[2] SystemVerilog supports directed, random, and directed-random testing, and functional coverage models can be used to measure and guide verification so tests adequately exercise the design. Testbench Automation and Constraints Tutorial - Doulos

[3] RISC-V verification requires more than one stimulus technique; random stimuli are useful for breadth, but features such as privilege-mode transitions, page table walks, and memory protection may not be fully exercised by random generation alone, motivating directed suites. RISC-V Test Generation: Random, Directed, and Coverage

[4] The most effective strategy combines constrained-random and directed tests: random stimulus discovers the unexpected while directed suites guarantee compliance, and compliance is necessary but not sufficient for verification. RISC-V Test Generation: Random, Directed, and Coverage

[5] STING is a bare-metal, software-driven generator for RISC-V that produces C++-based random streams and ASM-style directed tests, includes a programming framework for developing directed tests, uses stimulus graphs to schedule random and directed tests, and generates programs portable across simulation, emulation, FPGA prototypes, and silicon that are architecturally self-checking. RISC-V Test Generation: Random, Directed, and Coverage

[6] STING has exposed real bugs including deadlocks in page-table walks, mishandling of fence.i, floating-point NaN quirks, and cache coherence conflicts. RISC-V Test Generation: Random, Directed, and Coverage

[7] The ImperasTS directed suite family includes TS-ISA (architectural validation, similar to compliance), TS-VECT (vector extensions), and TS-MMU/PMP/ePMP (virtual memory and memory protection), configured to match the user's RISC-V processor and targeting areas where random stimulus leaves gaps. RISC-V Test Generation: Random, Directed, and Coverage

[8] 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. RISC-V Test Generation: Random, Directed, and Coverage

[9] A custom benchmark of 40 programs used in large-scale RISC-V verification included manually written (directed) tests for each RV32I instruction and corner cases such as stores followed by loads and instruction combinations triggering forwarding structures; the simulation infrastructure was format-agnostic and accepted both handwritten and randomly generated tests. Large-Scale RISC-V Processor Verification Using Automated ...

[10] Some verification methods rely on directed testing, which is generally less effective than reference model comparison verification methods. Large-Scale RISC-V Processor Verification Using Automated ...

[11] MoDitector introduces a module-directed testing strategy for autonomous driving systems that combines module-specific oracles with module-specific feedback, adaptive seed selection, and mutation to provoke failures in a target module (perception, prediction, planning, or control) and identify the responsible module. MoDitector: Module-Directed Testing for Autonomous Driving Systems

[12] Coverage-directed test selection uses supervised learning from coverage feedback to bias test selection toward stimuli with a high probability of increasing functional coverage, reducing manual constraint writing and accelerating coverage closure on large industrial designs. Supervised Learning for Coverage-Directed Test Selection in Simulation-Based Verification

[13] Directed testing provides structure and targeted validation but cannot anticipate all subtle corner cases, so the cited methodology treats it as one part of a combined strategy rather than a replacement for random or constrained-random stimulus. RISC-V Test Generation: Random, Directed, and Coverage