Overview
STING is a bare-metal functional verification tool for RISC-V designs. It generates constrained-random and directed tests for RISC-V processor verification, with stimulus intended to run across simulation, ZeBu emulation, HAPS FPGA prototyping, and silicon. The generated programs are described as architecturally self-checking, which helps simplify debug in verification flows. [C1]
STING is positioned for RISC-V verification because the modular RISC-V ISA and its optional extensions increase verification complexity. Evidence from the source emphasizes that comprehensive RISC-V verification typically requires multiple stimulus techniques rather than either random or directed testing alone. [C2]
Test-generation model
STING supports constrained-random test generation and directed stimulus generation. The source describes STING as producing C++-based random streams and ASM-style directed tests, built on a lightweight kernel, libraries, and device drivers. It also includes a programming framework for developing directed tests. [C3]
STING uses stimulus graphs to give users control over scheduling of both random and directed tests generated by the tool. [C4]
Role in RISC-V verification
In RISC-V verification, constrained-random stimulus is used to explore broad state spaces and uncover unexpected behavior, while directed tests provide precision for known architectural features and coverage gaps. STING contributes to both sides of this approach by generating random stimulus and supporting directed test development. [C5]
The evidence identifies STING as especially useful for stressing privilege levels, memory protection, CSRs, and hypervisor extensions. Reported issue classes exposed by STING include deadlocks in page-table walks, mishandling of the RISC-V fence.i instruction, floating-point NaN corner cases, and cache-coherence conflicts. [C6]
Portability and execution environments
STING-generated programs are described as portable across simulation, emulation, FPGA prototypes, and silicon. The referenced RISC-V verification flow specifically names VCS for simulation, ZeBu for emulation, HAPS for FPGA prototyping, and silicon as execution targets for the same stimulus. [C7]
This portability supports a shift-left verification methodology: tests developed during RTL bring-up remain useful in later validation stages and even in silicon. [C8]
Use in hybrid verification methodology
The evidence recommends a hybrid verification flow that combines constrained-random sweeps using STING with coverage analysis and directed tests for closure. In that flow, random stimulus from STING helps uncover unexpected behavior, while targeted directed suites or directed STING stimulus can address gaps found through coverage analysis. [C9]
The same source states that random stimulus with STING can accelerate coverage closure by uncovering unexpected behaviors, while directed tests improve convergence by targeting known coverage gaps. [C10]
Debug and reproducibility considerations
STING-generated tests are described as self-checking. In broader RISC-V verification flows, the evidence pairs self-checking tests with lock-step comparison against a reference model to identify mismatches earlier and simplify root-cause analysis. The source also notes that logged seeds and directed reruns support reproducibility across regression cycles. [C11]
Related concepts
- Constrained-random testing: STING generates constrained-random stimulus for RISC-V verification. [C3]
- Directed testing: STING produces ASM-style directed tests and includes a framework for directed test development. [C3]
- Stimulus graphs: STING uses stimulus graphs to schedule random and directed tests. [C4]
- Hybrid verification methodology: STING is used in flows that combine random and directed tests for coverage closure. [C9]
- RISC-V ISA: STING is designed for RISC-V processor verification and targets RISC-V implementations. [C1]