Skip to content
STIMSMITH

Coverage-driven test generation

Technique

Coverage-driven test generation is a hardware/system verification methodology that uses structured feedback over pre-defined coverage bins to constrain stimulus generation, drive the simulation campaign toward un-hit bins, and pair each generated transaction with an explicit oracle (reference model, monitors, scoreboards, and assertions). The technique iteratively samples, executes, observes, and scores until a total campaign budget is exhausted, with engineers manually inspecting coverage gaps to refine constraints, illegal bins, and sequences. In contrast, prior academic results show that purely coverage-driven software test generation can leave behaviors untested when those behaviors are not captured by structural coverage signals, motivating documentation-driven or LLM-guided alternatives; however, these do not directly define hardware-style coverage-driven campaigns.

First seen 9/29/2026
Last seen 9/29/2026
Evidence 1 chunks
Wiki v1

WIKI

Overview

Coverage-driven test generation is a verification technique in which the verification engineer defines an explicit set of coverage bins describing functional, structural, or configuration-relevant states of the design under test (DUT), then uses feedback from sampling these bins to constrain and steer stimulus generation. The goal is to ensure that meaningful subsets of the DUT's operational state space are exercised, with each generated stimulus paired to an explicit oracle that determines whether observed behavior is correct.

This technique is widely used in hardware and system-on-chip (SoC) verification flows, where it typically appears alongside constrained-random verification (CRV) and reference-model-based or scoreboard-based oracles. It is distinct from pure random testing because the stimulus distribution is biased by coverage feedback, and distinct from directed testing because the bias is updated automatically as bins are hit.

READ FULL ARTICLE →

NEIGHBORHOOD

4 nodes · 5 edges
graph · Coverage-driven test generation · depth=1

RELATIONSHIPS

3 connections
InputGen_TLUL uses → 76% 1e
Coverage sampling is performed over TL-UL requests produced by the input generator, indicating the generator is used within a coverage-driven loop.
ConfigGen_AccessControl uses → 74% 1e
Coverage is defined over the access-control generator's ranges, permissions, and decisions, showing it is used in a coverage-driven process.
Constrained-Random Verification (CRV) uses → 67% 1e
Coverage gaps trigger updates to constraints and tests, showing coverage-driven generation operating together with constrained-random methods.

CITATIONS

7 sources
7 citations — click to expand
[1] A coverage-driven campaign defines constraints on legal address ranges, permissions, and decisions via a configuration generator such as ConfigGen_AccessControl. SoK: You Find What You Seek Rethinking Oracles, Guidance, and ...
[2] Stimulus is generated by a transactional generator such as InputGen_TLUL with weighted constraints, e.g. higher weights around a selected address range. SoK: You Find What You Seek Rethinking Oracles, Guidance, and ...
[3] Coverage bins are defined as a cross product of ranges, permissions, and decisions, with illegal bins explicitly excluded. SoK: You Find What You Seek Rethinking Oracles, Guidance, and ...
[4] Each transaction is checked by an oracle combining a reference model (GRM), monitors, a scoreboard, and assertions such as 'completes without timeout' and 'denied read ⇒ data = 0'. SoK: You Find What You Seek Rethinking Oracles, Guidance, and ...
[5] Engineers manually inspect coverage results for gaps and update constraints, tests, and illegal bins as part of the campaign. SoK: You Find What You Seek Rethinking Oracles, Guidance, and ...
[6] Coverage-driven test generation approaches in software leave many behaviors untested when those behaviors are not captured as coverage targets. Automated Test Generation from Program Documentation Encoded in Code Comments
[7] A state-of-the-art software coverage-driven test generation tool (CoverUp) achieved a 76.2% bug validity rate on the IssueSpecter benchmark, versus 81.0% for IssueSpecter's coverage-plus-LLM approach. LLM-Guided Issue Generation from Uncovered Code Segments