Constrained Random Verification (CRV)
TechniqueConstrained Random Verification (CRV) is a simulation-based hardware verification technique that generates large numbers of random inputs under engineer-specified constraints. It is used to explore complex design behavior more broadly than directed testing alone, but it can require substantial manual constraint tuning and may leave difficult functional points uncovered.
First seen 5/31/2026
Last seen 9/29/2026
Evidence 16 chunks
Wiki v2
WIKI
Constrained Random Verification (CRV)
Overview
Constrained Random Verification (CRV) is a dynamic, simulation-based verification technique in which random test inputs are generated under specific constraints. In processor-verification literature, random or constraint-random testing is described as filling the gap left by directed testing: as designs become more complex, manually crafted directed tests become costly and insufficient to cover peripheral or unexpected scenarios, while CRV generates large numbers of constrained random inputs to explore a broader functionality space.
NEIGHBORHOOD
5 nodes · 7 edgesgraph · Constrained-Random Verification (CRV) · depth=1
RELATIONSHIPS
20 connectionsThe CRV approach is supplemented by directed stimulus for specific functionalities.
CRV generates program traces as the main stimulus for the processor design under test.
CRV requires top-down stimulus planning to build the stimulus-generation infrastructure.
The SystemVerilog random sequence generator can create instruction sequences randomly but is procedural and does not fully exploit object-based randomization.
CRV employs a scenario generator to select and randomize scenarios during stimulus generation.
CRV provides the ability to create useful stimulus through a stimulus-generation infrastructure.
The scenario generator applies constrained-random techniques to select and randomize scenarios.
CRV is proposed as an alternative to traditional directed tests whose creation time has become unreasonable.
CRV using object-based randomization is contrasted with procedural random sequence generation.
CRV requires intelligence about the processor ISA to generate useful stimulus.
The CRV approach is paired with top-down planning to create the stimulus-generation infrastructure.
The article proposes an object-oriented solution as the implementation approach for CRV.
Suresh Chips and Semiconductor applies constrained random verification to generate billions of instruction streams.
RISCV-DV generates constrained random RISC-V instruction tests.
CRV represents the traditional random testing baseline in their evaluation.
The access-control config generator applies constraints and randomizes DUT configuration as part of a constrained-random flow.
The TL-UL input generator uses constraints and randomize() to create request sequences.
Within the CRV flow, weighted constraints bias generation toward selected address ranges.
CRV uses instruction scenarios as the main stimulus building blocks for processor verification.
Coverage gaps trigger updates to constraints and tests, showing coverage-driven generation operating together with constrained-random methods.
CITATIONS
12 sources12 citations — click to expand
[1] CRV is random or constraint-random testing that generates many random inputs guided by constraints to explore design functionality more broadly than directed testing alone. FLAME: Enhancing Functional Coverage in Processor Verification via Large Language Models
[2] CRV is widely used in industry and academia, and RISCV-DV is used as an open-source RISC-V CRV instruction generator that emits constrained-random tests from internal constraints. FLAME: Enhancing Functional Coverage in Processor Verification via Large Language Models
[3] A CRV campaign can use constrained configuration and input generators, weighted address constraints, cross coverage bins, illegal bins, a golden reference model, monitor, scoreboard, and assertions. SoK: You Find What You Seek Rethinking Oracles, Guidance, and Input Generation in Hardware Fuzzing
[4] The access-control CRV loop randomizes DUT configuration and TL-UL input sequences from a seed, executes and observes requests, computes expected behavior, samples coverage, and runs scoreboard/assertion checks, followed by manual inspection and constraint/test updates. SoK: You Find What You Seek Rethinking Oracles, Guidance, and Input Generation in Hardware Fuzzing
[5] Processor functional coverage models can be structured into fine-grained functional points and higher-level functional groups, with examples including branch instruction execution and CSR write protection checks. FLAME: Enhancing Functional Coverage in Processor Verification via Large Language Models
[6] A RISC-V verification methodology may use constrained-random instruction and interrupt streams, ISS-based scoreboard comparison, and coverage dimensions such as ISA, pipeline, exception, and security/PMP coverage. Inside RISC-V: Navigating the RTL Design & Verification Landscape
[7] CRV can leave some functional points inefficiently covered, motivating coverage-guided fuzzing and other advanced approaches. FLAME: Enhancing Functional Coverage in Processor Verification via Large Language Models
[8] Simulation-based techniques such as CRV and CGF can struggle with high functional coverage because of vast instruction spaces and complex triggering conditions, and often require experienced engineers to write constraints. FLAME: Enhancing Functional Coverage in Processor Verification via Large Language Models
[9] Existing CRV solutions have been reported to lack formal guarantees on the distribution of system runs, motivating TraceSampler's constrained trace-sampling algorithm with provable uniformity or bias guarantees. On Uniformly Sampling Traces of a Transition System (Extended Version)
[10] Coverage-guided fuzzing adaptively generates random inputs and mutates seed inputs guided by coverage metrics, and one adapted DifuzzRTL baseline mutates instruction sequences generated by CRV using desired functional coverage as guidance. FLAME: Enhancing Functional Coverage in Processor Verification via Large Language Models
[11] A hardware-fuzzing survey distinguishes hardware fuzzing roles including augmenting CRV via feedback-guided coverage. SoK: You Find What You Seek: Rethinking Oracles, Guidance, and Input Generation in Hardware Fuzzing
[12] FLAME reports outperforming CRV and other baselines on four open-source RISC-V designs, with 34.25% to 220% average functional-coverage improvement and up to 86.13% reduction in time to reach the same functional coverage. FLAME: Enhancing Functional Coverage in Processor Verification via Large Language Models