Skip to content
STIMSMITH

STING

Tool WIKI v2 · 9/30/2026

STING is a Synopsys bare-metal, software-driven test generator for RISC-V processor and SoC verification. It produces portable, self-checking constrained-random and directed stimulus that can be reused across simulation, emulation, FPGA prototyping, and silicon, and it is used as part of a hybrid RISC-V verification methodology alongside ImperasDV and ImperasTS.

Overview

STING is a bare-metal functional verification tool for RISC-V designs, developed for processor and SoC implementation verification. It generates constrained-random and directed tests whose stimulus is intended to run across simulation, ZeBu emulation, HAPS FPGA prototyping, and silicon. The generated programs are architecturally self-checking, which simplifies debugging in verification flows. [C1]

STING is positioned for RISC-V verification because the modular RISC-V ISA and its optional extensions increase verification complexity. The source material 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 both constrained-random test generation and directed stimulus generation. It produces C++-based random streams and ASM-style directed tests, built on a lightweight kernel, libraries, and device drivers. STING also includes a programming framework that enables users to develop directed tests. [C3]

STING uses stimulus graphs to give users control over the scheduling of both the 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 particularly effective at stressing privilege levels, memory protection, CSRs, and hypervisor extensions, where traditional flows may miss bugs. Reported issue classes exposed by STING include:

  • Deadlocks in page-table walks [C6]
  • Mishandling of the RISC-V fence.i instruction, which synchronizes instruction and data streams [C6]
  • Floating-point NaN corner cases [C6]
  • 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 a hybrid verification methodology

The evidence recommends a hybrid verification flow that combines constrained-random sweeps using STING with functional coverage analysis and directed tests for closure. In that flow, functional coverage analysis is performed with ImperasFC, which generates SystemVerilog coverage models directly from the ISA specification, and coverage results can be viewed in standard tools such as Verdi. Failing cases are replayed deterministically in VCS, creating an iterative loop combining breadth with targeted closure. [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 such as those in Sv39/Sv48 page table walks, MMU, PMP, and vector extensions. [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 (provided by ImperasDV) 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, together with ImperasFC functional coverage, ImperasDV reference models, and Verdi for debug. [C9]
  • RISC-V ISA: STING is designed for RISC-V processor verification and targets RISC-V implementations. [C1]
  • Shift-left verification: STING's portability across simulation, emulation, FPGA prototyping, and silicon enables a shift-left methodology in which tests from early RTL bring-up are reused later in the flow. [C8]

LINKED ENTITIES

7 links
ImperasDV integrates_with
ImperasTS complements
ImperasFC integrates_with
Verdi integrates_with
VCS executes_on
ZeBu executes_on
HAPS executes_on

CITATIONS

11 sources
11 citations
[1] STING is a bare-metal functional verification tool for RISC-V designs that generates constrained-random and directed tests, with stimulus portable across simulation, emulation, FPGA prototyping, and silicon. RISC-V Test Generation: Random, Directed & Coverage
[2] Comprehensive RISC-V verification typically requires multiple stimulus techniques rather than either random or directed testing alone. RISC-V Test Generation: Random, Directed & Coverage
[3] STING produces C++-based random streams and ASM-style directed tests, built on a lightweight kernel, libraries, and device drivers, and includes a programming framework for developing directed tests. RISC-V Test Generation: Random, Directed & Coverage
[4] STING uses stimulus graphs to enable user control of the scheduling of both random and directed tests generated. RISC-V Test Generation: Random, Directed & Coverage
[5] STING is particularly effective at stressing privilege levels, memory protection, CSRs, and hypervisor extensions. RISC-V Test Generation: Random, Directed & Coverage
[6] STING has exposed issues such as deadlocks in page-table walks, mishandling of the RISC-V fence.i instruction, floating-point NaN quirks, and cache coherence conflicts. RISC-V Test Generation: Random, Directed & Coverage
[7] STING-generated programs are portable across simulation (VCS), emulation (ZeBu), FPGA prototypes (HAPS), and silicon. RISC-V Test Generation: Random, Directed & Coverage
[8] STING's portability enables a shift-left methodology in which tests developed during RTL bring-up remain valuable through later validation stages and silicon. RISC-V Test Generation: Random, Directed & Coverage
[9] A hybrid flow combines constrained-random sweeps using STING with ImperasFC functional coverage analysis and directed ImperasTS suites for coverage closure, with results merged in Verdi and failing cases replayed deterministically in VCS. RISC-V Test Generation: Random, Directed & Coverage
[10] Random stimulus with STING can accelerate coverage closure by uncovering unexpected behaviors, while directed tests improve convergence by targeting known coverage gaps in Sv39/Sv48 page table walks, MMU, PMP, and vector extensions. RISC-V Test Generation: Random, Directed & Coverage
[11] STING-generated tests are self-checking; the methodology pairs them with lock-step comparison against an ImperasDV reference model, and uses logged seeds and directed reruns for reproducibility across regression cycles. RISC-V Test Generation: Random, Directed & Coverage

VERSION HISTORY

v2 · 9/30/2026 · minimax/minimax-m3 (current)
v1 · 5/25/2026 · gpt-5.5