Constrained Random Stimulus

Concept

Constrained random stimulus is a design-verification technique in which pseudo-random input generation is steered through constraints and coverage feedback so that hard-to-hit corner cases of a digital design are exercised. It sits between pure random stimulus (theoretically complete but practically too slow for complex designs) and fully directed stimulus, and is the dominant stimulus-generation paradigm in modern SystemVerilog/UVM testbenches. The technique is widely used across processor and SoC IP verification, but its effectiveness depends on extensive human expertise to craft constraints and coverage models, and it has been a target for machine-learning-driven improvements (including LLM/LLM-agent-assisted testbench synthesis tools such as HAVEN, which trigger predefined constrained-random sequence patterns and then layer LLM-generated targeted sequences on top to close remaining coverage gaps).

First seen 6/2/2026

Last seen 7/12/2026

Evidence 6 chunks

Wiki v3

WIKI

Overview

Constrained random stimulus is a ubiquitous method for stimulating a design's functionality and ensuring it meets expectations. It extends pure random stimulus by steering the Design Verification (DV) environment so that hard-to-hit combinations can be generated when needed, rather than relying on the (impractical) hope that a fully random sweep will hit every interesting state. [C1][C2]

Motivation and role in design verification

In theory, random stimulus can exercise all possible input combinations given enough simulation time. In practice, as integrated circuits grow more complex, a purely random approach has difficulty exercising all possible combinations in a timely fashion, so the DV environment must be steered toward hard-to-hit combinations. This steerability is what gives the constrained-random approach its power. [C1][C2]

The same approach is used to generate the very large numbers of pseudo-random tests that CPU and SoC verification flows depend on. The RISC-V processor verification survey describes a typical CPU hardware DV flow in which, after reusable sub-circuit tests are obtained, a huge number of pseudo-random tests are generated and run until functional and code coverage metrics are reached. Coverage models and covergroups are paired with constrained random stimulus to demonstrate that the test intent has been adequately met. [C3][C4]

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

5 connections

Optimizing Design Verification using Machine Learning: Doing better than Random ← uses 100% 2e

The paper describes an approach that leverages constrained-random stimulus as a baseline DV technique.

HAVEN ← uses 93% 1e

HAVEN uses predefined constrained random DSL patterns to achieve coverage without LLM involvement.

design verification part of → 95% 1e

Constrained random stimulus is a widely used technique in design verification.

Coverage-Driven Verification ← uses 90% 1e

Coverage-driven verification typically uses constrained random stimulus to drive test generation.

SV/UVM Testbench ← uses 90% 1e

The testbench uses constrained random stimulus for verification.

LINKED ENTITIES

1 links

HAVEN USES Extracted graph relationship

CITATIONS

9 sources

9 citations — click to expand

[1] Constrained random stimulus has become ubiquitous as a means of stimulating a design's functionality and ensuring it meets expectations. Design Verification - OpenTitan Documentation

[2] Random stimulus theoretically exercises all combinations given enough time, but in practice purely random approaches cannot exercise all combinations in a timely fashion for complex designs, so the DV environment must be steered to generate hard-to-hit combinations; the constrained-random approach is powerful but relies on extensive human expertise, and as designs grow more complex the time to hit all design coverage points can become the dominant schedule limitation. Optimizing Design Verification using Machine Learning: Doing better than Random

[3] A typical CPU hardware DV flow generates a huge number of pseudo-random tests after reusable sub-circuit tests are obtained and verifies them until functional and code coverage metrics are reached; UVM standardization lowers verification costs and improves design quality through reuse and portability. Survey of Verification of RISC-V Processors

[4] The OpenTitan pwrmgr DV uses constrained random sequences (e.g., pwrmgr_wakeup_vseq randomizing wakeup inputs, wakeup enables, wake-info capture enable, and interrupt enable) together with covergroups (wakeup_ctrl_cg, wakeup_intr_cg, control_cg, hw_reset_0_cg, hw_reset_1_cg, rstmgr_sw_reset_cg, main_power_reset_cg, esc_reset_cg, reset_wakeup_distance_cg) to prove test intent is adequately met. Design Verification - OpenTitan Documentation

[5] Torture Test, AAPG, and COREV-DV/risc-dv are concrete RISC-V random-instruction generators used in coverage-driven verification of RISC-V processors, with COREV-DV implemented as SystemVerilog classes extending from uvm_object. Survey of Verification of RISC-V Processors

[6] Google's risc-dv (COREV-DV) is implemented as a collection of SystemVerilog classes extending from uvm_object and is used in coverage-driven verification of RISC-V processors. Survey of Verification of RISC-V Processors

[7] DUTs with complex control flows or multi-step bus protocols (e.g., Wishbone transactions) cause the stimulus exploration space to grow significantly while the set of stimuli that reach uncovered states remains small, so pure random or even constrained random methods struggle to converge and reduce the IC verification coverage rate. HAVEN: Hybrid Automated Verification ENgine for UVM Testbench Synthesis with LLMs

[8] HAVEN lists constrained random as one of its predefined Protocol-Aware Sequence DSL sequence patterns (alongside field value sweeps, toggle patterns, and FIFO stress tests) that are triggered by signal characteristics and protocol structure without any LLM involvement, and these predefined sequences alone have achieved a sufficient coverage rate. HAVEN: Hybrid Automated Verification ENgine for UVM Testbench Synthesis with LLMs

[9] Across 19 open-source IP designs spanning three interface protocols, HAVEN's DSL sequences achieve 90.6% average code coverage and 87.9% average functional coverage through iterative refinement. HAVEN: Hybrid Automated Verification ENgine for UVM Testbench Synthesis with LLMs