Overview

Constrained random test generation is a widely adopted method for generating stimuli in simulation-based verification. In the cited description, randomness provides test diversity, while constraints bias generated tests toward interesting, hard-to-reach, and yet-untested logic; those constraints are typically written manually. The same source notes that unconstrained diversity alone is not enough, because tests often repeatedly exercise the same design logic. [C1]

In the broader verification ecosystem, the term refers to any pipeline in which random stimulus production is narrowed by an explicit specification of what should be tested — a constraint expressed as code, a coverage group, or an external generator — before the stimulus is fed to the design under test (DUT). Several cited works frame constrained random generation as the dominant practical alternative to purely directed testing, which is limited in design-space coverage, and to formal verification, which is limited by state-space explosion. [C7][C4]

Mechanism in practice: coverage-point–driven constraint solving

The cited documentation of RISCV-CTG (RISC-V Compatibility Test Generator) describes one concrete realization of constrained random test generation. In that tool, the test-generation constraints are not authored as ad-hoc random seeds, but are supplied via a Coverage Group Format (CGF) file that lists cover-points for different instructions. The CTG treats each cover-point as a constraint and uses a constraint satisfaction problem (CSP) solver — specifically the solvers from the python-constraint Python package — to find concrete solutions that satisfy the cover-points, yielding a test that exercises a targeted corner case rather than an undirected random input. [C2]

The same documentation describes the internal data flow of CTG. Each instruction has a structured instruction attribute entry, stored as YAML, that fixes the XLEN values, the RISC-V ISA extension, a Python-evaluated operation string describing the instruction's function, the instruction format type, and lists of legal operand registers and operand values (rs1_op_data, rs2_op_data, rd_op_data, rs1_val_data, rs2_val_data), together with an assembly template that is instantiated to emit the test. The document also notes that the strength of CTG is bounded by the completeness of the CGF: a more elaborate CGF that covers all corner cases of an instruction can be supplied to produce a near-verification test for that instruction, and conversely the generator cannot exceed the corner cases encoded in the cover-points. [C2]

Mechanism in practice: Python-driven constrained random generation paired with UVM

A different realization is described in the ConfigDrivenV paper, which integrates Python-based constrained random test generation with a UVM testbench for processor and communication-protocol RTL. The paper describes a two-layer architecture in which the Python layer generates the test program and computes the expected register state, while the UVM layer drives the DUT and performs automated comparison. [C7]

According to that source, the Python generator produces N random CPU instructions by selecting from a defined instruction set, assigning random destination registers (rd ∈ {0,1,2,3}), and generating signed 8-bit immediate values (imm ∈ [−128, +127]). Instruction encoding follows a 16-bit format in which bits [15:12] hold the opcode, bits [9:8] hold rd, and bits [7:0] hold the immediate value. Concurrently with generation, a software register file models the processor's expected behavior. The two layers communicate via three text files written by Python and read by the UVM test sequence. The framework is validated on a 16-bit RISC-style processor and a UART controller, with the cited experimental results reporting 100% verification accuracy on correct RTL (PASS=100, FAIL=0) and 100% bug detection effectiveness on deliberately corrupted RTL (PASS=0, FAIL=100). [C7]

The ConfigDrivenV paper motivates this Python-fronted approach against two practical barriers: the cost of commercial EDA licenses, and the absence of SystemVerilog constraint-randomization features in some free simulators. It observes that industry-grade verification typically employs Cadence Xcelium or Synopsys VCS with full constraint solver support, while academic environments are often constrained to free tools such as ModelSim Starter Edition, which lacks SystemVerilog randomization. ConfigDrivenV is specifically designed to operate within these constraints, replacing SystemVerilog randomization with Python-generated test files. [C7]

The same source also cites a 2024 IEEE paper on UVM verification of RISC-V instruction sets as evidence that a UVM testbench with constrained random stimulus and functional coverage groups achieves significantly higher design-space coverage than directed testing, validating the random-generation approach adopted by ConfigDrivenV. [C7]

Mechanism in practice: SystemVerilog/UVM constrained-random frameworks

In the SystemVerilog/UVM ecosystem, the cited processor-verification survey describes several constrained-random generators used for RISC-V. RISC-V DV (Google) uses SystemVerilog together with UVM to continuously generate RISC-V instruction streams from constrained-random descriptions, with each instruction stream representing a test case. The same source states that RISC-V DV provides a high-level co-simulation interface based on execution-log comparison and supports several RISC-V instruction set extensions as well as CSR testing. It also reports two disadvantages: restrictions are added to avoid infinite loops and platform-dependent memory accesses, and there is significant performance overhead because the framework is generic and fully decouples test generation from co-simulation. [C4]

For UART verification, cited prior work reports achieving 100% functional coverage using SystemVerilog-based constrained random verification, with 20 boundary-spanning test vectors described as adequate for UART protocol behavior. The cited ConfigDrivenV paper treats this as evidence that constrained random generation, even with a small number of boundary-targeted vectors, can be sufficient for protocol-level coverage. [C7]

Main limitation

A recurring limitation is diminishing coverage return over time. As verification progresses, most constrained random tests may have little or no effect on functional coverage. The cited abstract further states that simulation-based hardware verification may require several millions of tests to reach coverage goals, while the vast majority of those tests do not contribute to coverage progress and still consume verification resources. [C1][C3]

In the ConfigDrivenV paper, this limitation is reframed as a tooling-access problem: when SystemVerilog randomization is unavailable in the chosen simulator, constrained random generation must be performed outside the UVM environment, which can decouple stimulus generation from the rest of the verification flow. [C7]

Responses in the cited literature

One response is to decouple cheap stimulus generation from expensive simulation. When generating stimuli costs much less than simulating them, the cited work argues that a better strategy is to generate many random tests, predict which ones are most effective, and simulate only that subset. In that context, coverage-directed test selection is presented as a supervised-learning method that learns from coverage feedback, biases selection toward tests likely to increase functional coverage, and aims to reduce manual constraint writing, prioritize effective tests, reduce resource consumption, and accelerate coverage closure on a large, real-life industrial hardware design. [C1]

A second response is Hybrid Intelligent Testing, which combines Coverage-Directed Test Selection with Novelty-Driven Verification. In the cited paper, this hybrid approach is motivated by the observation that constrained random test generation alone can require very large numbers of tests; the hybrid method is described as addressing the limitations of the individual component methods to make testing both efficient and effective. [C3]

Examples in processor verification

The cited processor-verification survey situates constrained-random and constraint-oriented generation among related instruction-stream generation approaches:

• The RISC-V Torture Test is a Scala-based model-based framework that generates tests from randomized instruction sequence templates and supports several RISC-V ISA extensions.
• An alternative model-based approach (cited as [11]) uses a constraint-based specification for test generation, but is described as limited by pre-defined building blocks for instruction sequences and as not supporting illegal instructions or exceptions.
• Coverage-guided fuzzing approaches tailored for ISS-level verification loosen some of the instruction-stream generation restrictions but still have problems with non-terminating test cases and platform-dependent CSR and memory-access operations, and produce comparatively small test-suites of a few thousand cases. [C4]

A more recent effort, cited as [24] and described in a 2026 review, proposes coverage and constraint-based test generation specifically for the RV32F floating-point extension on a single RTL processor. That review notes the flow is not open-source, is limited to 32-bit single precision, and does not address off-the-shelf RISC-V simulators or alternative FP libraries. [C5][C6]

The ConfigDrivenV paper provides additional processor-verification precedents. It cites Chippagi's reusable UVM framework for verification of Power ISA processor cores, which introduced a software predictor model computing expected register states and feeding them to a UVM scoreboard — described as the direct academic precedent for ConfigDrivenV's Python golden reference model — and which demonstrated complete coverage across arithmetic, logical, and memory-access instruction classes. [C7]

Domain-specific limitations

In the RISC-V floating-point context, the cited FP-RVVTS paper observes that the canonical open-source constrained-random generator, RISC-V DV, initializes FP registers only once at the beginning of a test with special values, which the paper describes as a limitation that restricts operand diversity and consequently FP coverage. [C6]

In the ConfigDrivenV paper, a domain-specific constraint is highlighted at the protocol level: UART verification requires only a small number of boundary-spanning test vectors to achieve 100% functional coverage, suggesting that the cost of constrained random generation is highly design-dependent. [C7]

Tooling

The related entity RISCV-CTG implements constrained random test generation for the RISC-V architectural test suite. Its generated tests are compliant with the official Test Format Spec and are used both in the RISC-V Architectural Test Suite and in the RISCOF framework. [C2]

ConfigDrivenV is cited as a two-layer Python-UVM co-verification framework that integrates Python-based constrained random test generation with a UVM testbench and a self-checking scoreboard. According to the paper, the Python layer handles test generation and golden reference computation, while the UVM layer consumes the resulting artifacts, drives the DUT, and performs cycle-accurate comparison. The cited paper validates the framework on a 16-bit RISC-style processor and a UART controller, and presents it as a license-free alternative to commercial SystemVerilog-constrained-random flows. [C7]