Skip to content
STIMSMITH

STING

Tool WIKI v1 · 5/25/2026

STING is a Synopsys bare-metal functional verification tool for RISC-V processor and SoC implementations. It generates portable, self-checking constrained-random and directed stimulus, including C++-based random streams and ASM-style directed tests, and is used as part of hybrid RISC-V verification flows spanning simulation, emulation, FPGA prototyping, and silicon.

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]

CITATIONS

11 sources
11 citations
[1] C1: STING is a bare-metal functional verification tool for RISC-V that generates constrained-random and directed tests, with portable self-checking stimulus across simulation, emulation, FPGA prototypes, and silicon. source
[2] C2: RISC-V verification complexity is increased by the ISA's modular design and optional extensions, and comprehensive coverage typically requires more than one stimulus technique. source
[3] C3: STING produces C++-based random streams and ASM-style directed tests, and includes a framework for directed test development. source
[4] C4: STING uses stimulus graphs to control scheduling of generated random and directed tests. source
[5] C5: A combined strategy uses constrained-random stimulus for breadth and directed tests for precision in RISC-V verification. source
[6] C6: STING is effective at stressing privilege levels, memory protection, CSRs, and hypervisor extensions, and has exposed issues including page-table-walk deadlocks, fence.i mishandling, floating-point NaN quirks, and cache-coherence conflicts. source
[7] C7: STING stimulus can be reused across VCS simulation, ZeBu emulation, HAPS FPGA prototyping, and silicon. source
[8] C8: Portability of tests across verification platforms supports shift-left verification because tests from RTL bring-up remain useful later in validation and silicon. source
[9] C9: A hybrid flow begins with constrained-random sweeps using STING, then uses coverage analysis and targeted directed tests to close gaps. source
[10] C10: Random stimulus with STING helps uncover unexpected behavior and can contribute to faster coverage closure in a hybrid verification approach. source
[11] C11: Self-checking tests, lock-step comparison, logged seeds, and directed reruns improve debug efficiency and reproducibility across regression cycles. source