Skip to content
STIMSMITH

Constrained-Random Testing

Concept WIKI v2 · 8/2/2026

Constrained-random testing is a stimulus-generation technique used in RISC-V processor verification to explore broad design state spaces and surface unexpected behaviours that directed tests might miss. Evidence shows it is most effective when combined with directed test suites, functional coverage analysis, reference-model comparison, and portable execution across simulation, emulation, prototyping, and silicon.

Overview

Constrained-random testing is a stimulus-generation technique widely used in functional verification of digital designs. In RISC-V processor verification specifically, it provides breadth: random stimulus can explore broad state spaces and uncover unanticipated behaviours [1]. However, evidence indicates that random testing alone can leave verification gaps, especially for features such as privilege-mode transitions, page-table walks, and memory protection. A stronger strategy combines constrained-random stimulus with directed suites for targeted closure and compliance-oriented validation [b73d6860-3caf-4eb7-811e-eda1693f60f3, e79e3ecb-a829-4ced-b719-7d329fb97e3b].

Role in RISC-V Verification

RISC-V verification is complicated by the ISA's modular design and optional extensions. The evidence states that comprehensive coverage typically requires more than one verification or comparison methodology and more than one stimulus technique [2]. In this setting, constrained-random testing is commonly used as a starting point because it can discover unexpected interactions, while directed testing is applied to cover known architectural and feature-specific requirements [2].

STING-Based Constrained-Random Generation

STING is described as a bare-metal, software-driven RISC-V generator that produces C++-based random streams and ASM-style directed tests. It is built on a lightweight kernel, libraries, and device drivers, and includes a programming framework for directed-test development. STING also uses stimulus graphs to let users control scheduling of generated random and directed tests [2].

Generated STING programs are portable across simulation, ZeBu emulation, HAPS FPGA prototypes, and silicon, and they are architecturally self-checking. The evidence identifies STING-generated constrained-random stimulus as useful for stressing privilege levels, memory protection, CSRs, and hypervisor extensions [2].

Strengths and Limitations

Constrained-random testing is valuable because it can expose behaviours that directed test writers may not anticipate. Reported issue classes found with STING include deadlocks in page-table walks, mishandling of the fence.i instruction, floating-point NaN quirks, and cache-coherence conflicts [2].

Its limitation is that random stimulus may not reliably hit all important architectural cases. Evidence specifically notes that privilege-mode transitions, page-table walks, and memory-protection behaviours may not be fully exercised by random generation alone [2]. For this reason, constrained-random testing is treated as complementary to directed suites rather than as a complete verification strategy by itself [b73d6860-3caf-4eb7-811e-eda1693f60f3, e79e3ecb-a829-4ced-b719-7d329fb97e3b].

Use in a Hybrid Verification Methodology

The evidence supports a hybrid flow in which constrained-random sweeps begin the process, functional coverage analysis identifies gaps, and directed suites close those gaps [1]. In this flow, random stimulus from STING uncovers unexpected behaviours, while directed suites such as ImperasTS target architectural validation, vector extensions, virtual-memory management, PMP, and ePMP features [1].

Coverage and debug infrastructure are part of the same loop. ImperasFC can generate SystemVerilog functional coverage models from the ISA specification, results can be viewed in tools such as Verdi, and failing cases can be replayed deterministically in VCS [1]. ImperasDV can provide lock-step comparison against a reference model at instruction retirement, helping identify mismatches during execution [3].

Portability and Shift-Left Usage

Because STING-generated programs can run across simulation, emulation, prototyping, and silicon, constrained-random tests developed during RTL bring-up can remain useful later in validation [b73d6860-3caf-4eb7-811e-eda1693f60f3, e79e3ecb-a829-4ced-b719-7d329fb97e3b]. The evidence describes this portability as enabling a shift-left methodology, where tests and coverage analysis begin earlier and continue across later implementation stages [1].

SystemVerilog Context

In SystemVerilog-based verification flows, constrained-random stimulus is typically built after establishing safe testbench-to-DUT connectivity. The evidence indicates that verification methodology teaches interfaces, modports, and clocking blocks before introducing constrained-random testing, ensuring race-free and predictable stimulus delivery [4].

LINKED ENTITIES

1 links
Functional Verification USES

CITATIONS

8 sources
8 citations
[1] Constrained-random testing explores broad state spaces and uncovers unanticipated behaviours, but random stimulus alone leaves verification gaps for features such as privilege-mode transitions, page-table walks, and memory protection. RISC-V Test Generation: Random, Directed, Coverage
[2] STING is a bare-metal, software-driven RISC-V generator producing C++-based random streams and ASM-style directed tests, with stimulus graphs for scheduling control. RISC-V Test Generation: Random, Directed, Coverage
[3] STING-generated programs are portable across simulation, ZeBu emulation, HAPS FPGA prototypes, and silicon, and are architecturally self-checking. RISC-V Test Generation: Random, Directed, Coverage
[4] STING-generated constrained-random stimulus has uncovered deadlocks in page-table walks, mishandling of the fence.i instruction, floating-point NaN quirks, and cache-coherence conflicts. RISC-V Test Generation: Random, Directed, Coverage
[5] A hybrid verification flow combines constrained-random sweeps (STING) with functional coverage analysis (ImperasFC) and directed suites (ImperasTS) to close coverage gaps, integrated with Verdi and VCS for debug. RISC-V Test Generation: Random, Directed, Coverage
[6] ImperasDV enables lock-step comparison of RTL against a golden reference model at instruction retirement for early bug detection. RISC-V Test Generation: Random, Directed, Coverage
[7] Portability of STING-generated tests across simulation, emulation, prototyping, and silicon enables a shift-left verification methodology. RISC-V Test Generation: Random, Directed, Coverage
[8] SystemVerilog verification methodology teaches interfaces, modports, and clocking blocks before introducing constrained-random stimulus, to ensure race-free testbench-to-DUT communication. Debugging Intermittent SystemVerilog randomize() Failures

VERSION HISTORY

v2 · 8/2/2026 · minimax/minimax-m3 (current)
v1 · 5/25/2026 · gpt-5.5