Overview

Directed tests are verification stimuli that target specific scenarios, instructions, interfaces, or corner cases rather than producing broad random exploration. In simulation-based functional verification of processors they are typically written (or auto-generated) to exercise a known behavior end-to-end and are checked against a reference model, an assertion set, or expected outputs. Functional verification surveys of RISC-V processors explicitly identify stimulus as "either directed tests or random tests," with directed tests favoring targeted, hand-checked scenarios and random tests favoring broader coverage of input combinations.

Use in the CHIA RISC-V ISA extension case study

In the CHIA riscv_extensions case study, directed tests are a formal stage of the per-extension pipeline. run_vext_loop() drives one extension from a clean tree to a converged, synthesized result. Implementing and testing are coupled into a single step — a regression failure feeds straight back to the LLM — and the stress phase only runs once both the directed tests and the base-ISA regression suite pass:

1. Reset BOOM and build the per-instruction directed tests from specs/<ext>/instructions.json.
2. The implement-LLM edits BOOM Chisel, builds the cospike simulator, and runs the directed tests against Spike; iteration continues until all pass.
3. Run the full base-ISA riscv-test regression.
4. Stress test with riscv-dv-generated random programs, co-simulated lockstep against Spike.
5. Synthesize the BoomTile with and without the extension for PPA comparison.

"Every instruction, once"

The directed tests are built from specs/<ext>/instructions.json, the extension's closed instruction set (generated from riscv-opcodes). isa_tests emits one minimal program per instruction — a handful of executions over random operands — and cross-compiles each to an ELF. Coverage is 100% by construction: the table is the instruction set, so every instruction is exercised and checked against Spike.

Differential verification against Spike

Every test — directed or random — is judged the same way: run it on the DUT with Spike riding inside the simulator, and fail at the first architectural disagreement. CosimNode runs one ELF in lockstep; the embedded Spike's ISA string comes from the DUT's own config, so the oracle always decodes exactly what the core claims to implement. No expected output is ever hand-encoded — the golden model is the check.

Relationship to the stress phase

Directed tests prove each instruction in isolation; the stress phase proves it in context. riscv-dv generates large random programs that weave the extension's instructions through ordinary code — hazards, loops, memory traffic — and streams them through parallel lockstep cosims. A single divergence resets the pool, so after the debug LLM fixes the RTL the whole batch re-runs and must pass clean. In this flow directed tests act as a deterministic gate before random stimulus is admitted.

Use in broader RISC-V verification practice

A multi-core RISC-V system verification project (RISC-V Summit Europe 2025, Genovese et al.) reports combining riscv-isa-tests, riscv-arch-tests (formerly compliance), internal RVV ISA tests, and UVM-directed tests for JTAG and DMA interfaces. The authors state that an initial regression of riscv-tests plus a few other directed tests "proved to be necessary but not sufficient" to detect buggy updates; the team then added random tests to complement the regression and later improved that batch by selecting random tests that had uncovered difficult bugs. Directed tests here serve to keep specific subsystems (debug, DMA) and ISA corners pinned across changes, while random tests carry the bulk of coverage work.

Relationship to functional verification

The 2025 Survey of Verification of RISC-V Processors places directed and random tests as the two stimulus categories of functional verification. Functional verification applies stimuli to the DUT and observes outputs to confirm the design meets its specification. Its advantages include being time-saving, less complex, and more flexible than formal verification; its main disadvantages are incomplete coverage (not all possible inputs are explored) and heavy reliance on the quality and completeness of the testbench. Directed tests address the quality concern by deliberately checking known scenarios, at the cost of leaving input-space exploration to complementary random or constrained-random stimulus.

See also

• CHIA (Tool)
• run_vext_loop (CodeArtifact)
• isa_tests (CodeArtifact)
• Functional Verification of a RISC-V Vector Accelerator

References

• CHIA documentation — RISC-V ISA Extension Implementation case study (ebee694a-b6b7-4680-b000-0220f294ab94, de5c2b06-f7d3-4e0f-97c2-2239c335856f).
• Survey of Verification of RISC-V Processors, Journal of Electronic Testing (2025) 41:111–138 (cafbd16c-77ae-4bac-aa26-e0ec655db473).
• Genovese et al., "Verification of a RISC-V system with multiple cores," RISC-V Summit Europe 2025 proceedings (39195577-779e-4fda-8abf-487946858ea7).