Skip to content
STIMSMITH

Constrained Random Verification (CRV)

Concept

Constrained Random Verification (CRV) is a hardware verification approach that generates randomized stimuli under constraints so that tests remain legal while pushing the design under test toward coverage-relevant corner cases. In SoC verification, CRV is used with self-checking testbenches, randomized traffic, weight-based controls, monitors, scoreboards, and coverage feedback to uncover bugs that directed tests may miss.

First seen 5/28/2026
Last seen 7/1/2026
Evidence 14 chunks
Wiki v3

WIKI

Overview

Constrained Random Verification (CRV) is a verification approach in which random stimulus is shaped by constraints. The goal is to reach coverage targets by driving the design under test into interesting corner cases while avoiding invalid or illegal scenarios. In SoC verification, CRV is commonly used alongside directed verification: directed tests exercise known features explicitly, while constrained-random tests explore combinations that may be difficult to enumerate manually.

A public SoC verification article describes random traffic as transactions initiated from randomly selected masters to randomly selected slaves, with randomized transaction type, data size, and latency. This kind of traffic can stress buses, gaskets, masters, slaves, and system-level interactions.

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

14 connections
riscv-dv ← implements 100% 2e
RISC-V DV is a CRV framework implementing constrained random verification for RISC-V.
Constraint-Based Randomization uses → 97% 2e
CRV leverages constraint-based randomization as its core technique for generating test stimuli.
Freescale Semiconductor ← uses 90% 2e
Freescale Semiconductor employs CRV in its SoC design verification flow.
The paper is centered on constrained random verification for RISC-V.
Constrained Random Generation (CRG) uses → 100% 1e
CRG is a central building block of a CRV framework.
Stimulus Generation uses → 97% 1e
CRV uses stimulus generation infrastructure to produce useful test stimuli for processor verification.
simulation-based verification ← uses 85% 1e
Simulation-based verification uses CRV as a core test generation approach.
The paper describes using constrained random verification to verify SoC designs.
Constraint-Based Stimulus Generation ← implements 100% 1e
Constraint-based stimulus generation is the core technique that implements CRV.
random stimulus generation uses → 100% 1e
CRV uses random stimulus generation shaped by constraints.
System-on-Chip (SoC) uses → 95% 1e
CRV is applied to SoC designs for system-level verification.
Functional Coverage uses → 95% 1e
CRV tracks and utilizes coverage information to measure verification progress.
Instruction Scenario uses → 93% 1e
CRV uses instruction scenarios as structured building blocks for test stimulus.
Program Trace uses → 93% 1e
CRV uses the program trace as the main stimulus for the DUT.

CITATIONS

15 sources
15 citations — click to expand
[1] CRV uses constraints to shape random stimulus toward coverage goals, interesting corner cases, and legal scenarios. Bug hunting SoC designs to achieve full functional coverage closure
[2] In SoC CRV, random traffic can mean transactions from random masters to random slaves with randomized transaction type, data size, and latency. Bug hunting SoC designs to achieve full functional coverage closure
[3] Directed verification becomes harder to scale as design complexity increases, while CRV automatically generates stimuli from a constrained solution space. Bug hunting SoC designs to achieve full functional coverage closure
[4] A CRV environment requires a self-checking testbench with stimulus generation, drivers, monitoring, scoreboarding, and checking. Bug hunting SoC designs to achieve full functional coverage closure
[5] SoC CRV setup can use weight-based controls for slaves, transaction count, transaction size, and transaction type, plus randomized inter-transaction delays and coverage-oriented monitors. Bug hunting SoC designs to achieve full functional coverage closure
[6] Protocol-specific randomized stimuli, such as AXI stimuli, can be derived from a generic stimulus base class and controlled with runtime parameters such as slave weightage and read/write weightage. Bug hunting SoC designs to achieve full functional coverage closure
[7] Example CRV SoC scenarios include multiple masters accessing one slave, AXI ID-based out-of-order transactions, boundary or unaligned memory accesses, back-to-back transactions with randomized delays, and cache coherency or stashing cases. Bug hunting SoC designs to achieve full functional coverage closure
[8] Randomized SoC verification procedures caught bugs such as swapped control signals and latency mismatches, with latency issues leading to possible FIFO or jitter-buffer overrun and underrun problems. Bug hunting SoC designs to achieve full functional coverage closure
[9] Functional coverage closure practice can use scenario and seed grading so higher-contributing runs are executed more often after the random environment is frozen. Bug hunting SoC designs to achieve full functional coverage closure
[10] RISC-V DV leverages SystemVerilog/UVM constraints for test generation, and coverage-guided generation would require dynamically evolving constraints at runtime. Constrained Random Verification for RISC-V: Overview, Evaluation and Discussion
[11] The RISC-V CRV evaluation reports immediate-field coverage values including 100% SHAMT, 87.77% I-Imm, 47.07% S-Imm, 5.18% B-Imm, 0.01% J-Imm, and 0.16% U-Imm. Constrained Random Verification for RISC-V: Overview, Evaluation and Discussion
[12] The RISC-V CRV evaluation found RISC-V DV effective at finding common implementation bugs using mutation testing and identified future work including RTL and ISS/RTL evaluation, instruction-set extension support, and extra-functional use cases. Constrained Random Verification for RISC-V: Overview, Evaluation and Discussion
[13] A public trace-sampling paper states that a key CRV problem is generating stimuli that cover targeted behavior-space corners and that existing CRV solutions provide no formal guarantees on the distribution of system runs. On Uniformly Sampling Traces of a Transition System (Extended Version)
[14] TraceSampler uses Algebraic Decision Diagrams to sample bounded traces with provable uniformity or bias guarantees while satisfying constraints. On Uniformly Sampling Traces of a Transition System (Extended Version)
[15] A public coverage-driven verification study states that CRV and coverage-driven methodologies can involve time-consuming redundant regressions and manual constraint adjustment, and reports at least 99% coverage regain with reduced simulation cycles using supervised ML and PyUVM. Optimizing Coverage-Driven Verification Using Machine Learning and PyUVM: A Novel Approach