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]

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]

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]

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 describes several concrete constrained-random generators used in the RISC-V ecosystem. 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]

The same 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]

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]

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]