Condition Coverage

Definition

Condition coverage is a coverage metric that measures the fraction of conditional expressions exercised by a test-generation process. In hardware fuzzing, condition coverage specifically requires that every input combination in a condition block produce the correct output value; it is reported alongside related metrics such as statement, branch, expression, toggle, FSM, and line coverage [evidence: 7d1ca475-9c0c-4b68-bc24-db339ffa3987, fedd43f9-88d9-4388-a2c7-805a2eea51f4]. In configurable-systems testing, condition coverage generalizes to "presence conditions" — boolean expressions extracted from the code that determine whether an implementation artifact is included in a given configuration.

Use in Hardware Fuzzing

TheHuzz

TheHuzz (USENIX Security 2022) is an instruction fuzzer for processors that relies on Golden Reference Models (GRMs). It extracts coverage metrics — including condition coverage — from Register-Transfer-Level (RTL) simulation logs produced by Synopsys VCS using custom Python scripts [evidence: 401f59d6-8bcf-4b91-b70f-90125d8d19e0]. Condition coverage is used in two distinct ways inside TheHuzz:

• Bug-detection criterion. Condition coverage is the criterion chosen to check that every input combination in a condition block produces the correct output value, complementing branch coverage (which tests "when" / "otherwise" constructs) [evidence: 7d1ca475-9c0c-4b68-bc24-db339ffa3987].
• Feedback signal for the optimizer. TheHuzz's optimizer formulates a set-cover problem in which the universe C is the union of coverage metrics — statement, branch, expression, toggle, FSM, and condition — and the goal is to find the smallest subset Q of instruction-mutation (IM) pairs that covers all of the coverage points C_d identified during a profiling phase. The resulting optimal weights w_I, w_M steer both seed generation and stimulus mutation toward IM pairs that maximize observed coverage, including condition coverage [evidence: fedd43f9-88d9-4388-a2c7-805a2eea51f4].

TheHuzz was evaluated on four open-source processors — Ariane (a.k.a. cva6), mor1kx, or1200, and Rocket Core — using spike (RISC-V) and or1ksim (OpenRISC) as GRMs, and compared against DifuzzRTL, random regression testing, and formal verification on a 32-core Intel Xeon 2.6 GHz machine with 512 GB RAM running CentOS 7.3 [evidence: 401f59d6-8bcf-4b91-b70f-90125d8d19e0].

ChatFuzz

ChatFuzz (arXiv 2404.06856) is an ML-based hardware fuzzer that uses reinforcement learning with code-coverage metrics — including condition coverage — to reward generated inputs. On the RISC-V RocketCore processor, ChatFuzz achieves 75% condition coverage in 52 minutes, compared with a state-of-the-art fuzzer that requires a 30-hour window to reach a similar level. Given a limited pool of 10 simulation instances/licenses over 130 hours, ChatFuzz attains 80% condition coverage, executes 199K test cases, finds 6K discrepancies with the golden model, and surfaces more than 10 unique mismatches including two new bugs in RocketCore [evidence: arxiv 2404.06856].

GenHuzz

GenHuzz (USENIX Security 2025) is a coverage-based white-box generative hardware fuzzer that uses a GPT-based language model (~12 million parameters) with word-level encoding of RISC-V opcodes, operands, and immediates as both fuzzer and scorer [evidence: 454e9ebc-5856-4202-9eef-b12166bbd72c]. GenHuzz is evaluated against four state-of-the-art fuzzers — Cascade, DifuzzRTL, TheHuzz, and ChatFuzz — with a comprehensive coverage analysis using condition, line, and FSM metrics across three RISC-V cores: RocketChip, Boom, and CVA6; for the other fuzzers, benchmarking focuses on RocketChip with condition-coverage metrics [evidence: 402334cf-a4f2-4c32-bee1-6f69d1f92c0c].

• FSM coverage measures how well the states and transitions of finite state machines within the design are tested. Condition coverage assesses the evaluation of all possible logical conditions, while line coverage determines the extent to which the lines of code in the RTL have been executed during simulation. Together, these metrics provide a comprehensive view of the effectiveness of the test cases in validating the hardware design [evidence: 454e9ebc-5856-4202-9eef-b12166bbd72c].
• GenHuzz consistently outperforms Cascade across all cores and evaluation metrics, except for the FSM metric on RocketChip where GenHuzz and Cascade perform identically [evidence: 402334cf-a4f2-4c32-bee1-6f69d1f92c0c].
• GenHuzz's condition-coverage continues to increase with the number of test cases (e.g., on Boom), whereas Cascade's coverage plateaus after a relatively small number of test cases, highlighting the role of the HGRL scheme that integrates reinforcement learning and a language model [evidence: 454e9ebc-5856-4202-9eef-b12166bbd72c].
• The reward function blends hardware coverage with a bonus for valid instructions, with weight α = 0.2 on hardware coverage and Rbonus = 0.4, normalized to balance exploration and exploitation [evidence: 454e9ebc-5856-4202-9eef-b12166bbd72c].

GenHuzz uses Synopsys VCS for RTL simulation and the Spike simulator as the RISC-V ISA reference model to detect mismatches between the DUT and the reference [evidence: 454e9ebc-5856-4202-9eef-b12166bbd72c].

LiFU

LiFU ("Beyond Fuzzer Islands: CPU Fuzzing via Smart Coordination") is a CPU testing framework that coordinates multiple fuzzers and formal tools via runtime analysis and seed selection, using condition coverage as one of the coverage signals collected from VCS coverage reports and differential checking against Spike [evidence: 3227df4c-29cf-4d2b-8897-ec5807c06284, 8bb71cd9-8af7-438f-bdb5-79987971280a, 1d29d1d3-1c16-40fc-ad3a-844bea924191]. On RocketChip, LiFU achieves 90.1% line, 75.0% FSM, and 78.3% condition coverage, exceeding Cascade's 89.2%, 60.0%, and 77.5% respectively, while reaching 89.0% line coverage in fewer than 1,000 tests (versus Cascade's ~5,000) [evidence: 8bb71cd9-8af7-438f-bdb5-79987971280a]. On the out-of-order BOOM core, LiFU reaches 93.4% line, 43.6% FSM, and 95.7% condition coverage (vs. Cascade's 83.2%, 11.6%, 90.8%), obtaining roughly 3.76× more micro-architectural controller states and sustaining coverage gains beyond 50,000 tests while matching state-of-the-art results using 25–33% of the test budget [evidence: f166c7f3-e5cc-44ba-8331-25437cde3e58, 3227df4c-29cf-4d2b-8897-ec5807c06284]. Across both cores LiFU uncovers six new bugs and cuts time-to-90% coverage by more than 50% [evidence: 3227df4c-29cf-4d2b-8897-ec5807c06284]. All experiments ran on an AMD EPYC 7763 2.45 GHz machine, comparing LiFU against DifuzzRTL, ProcessorFuzz, ChatFuzz, Cascade, and GenHuzz [evidence: f166c7f3-e5cc-44ba-8331-25437cde3e58].

GoldenFuzz and Comparative Context

GoldenFuzz (NDSS 2026) is evaluated on the RocketChip core using condition-coverage metrics. GoldenFuzz surpasses the prior state of the art (Cascade, DifuzzRTL, TheHuzz, ChatFuzz) by +3.7% condition coverage on RocketChip and matches FSM coverage; on BOOM/CVA6 the advantage in condition coverage is +4.2% to +6.5% [evidence: f3a9a6cc-156a-4e3e-9801-f08bdc600e31]. GoldenFuzz maintains superior coverage as the number of test cases grows, reaching coverage comparable to that of other fuzzers using test cases of only 30 instructions and fewer than 1% of the test cases generated by competitors [evidence: 263c1ec5-969e-4f80-af1b-51a17cc24a87]. In a CPU setting, TheHuzz generates each test case in 2.47 seconds (versus 0.34 s for GoldenFuzz on the same CPU) [evidence: 263c1ec5-969e-4f80-af1b-51a17cc24a87].

State-of-the-art fuzzers frequently struggle to exceed a 70% condition-coverage threshold on intricate hardware designs within a practical timeframe, which has motivated the adoption of stronger feedback signals and ML-based guidance [evidence: arxiv 2404.06856].

Use in Configurable-Systems Testing

In the configurable-systems literature, condition coverage is generalized to t-wise presence condition coverage (Henkler et al., arXiv 2205.15180). Whereas classical t-wise interaction sampling only considers combinations of configuration options drawn from a variability model, t-wise presence condition coverage uses presence conditions extracted from the code as the basis for covering t-wise interactions. The motivation is that options from a variability model do not capture how those options map onto implementation artifacts, so critical code may remain untested. Building on Tartler et al., who considered presence conditions but not their interactions, t-wise presence condition coverage extends the criterion to all t-wise interactions of implementation artifacts, increasing the chance of detecting combinations of faulty configuration options. The authors show that t-wise presence condition sampling produces mostly smaller samples than t-wise interaction sampling while guaranteeing 100% t-wise presence condition coverage [evidence: arxiv 2205.15180].

Relationship to Coverage-Guided Fuzzing

Condition coverage is a specific instance of the broader feedback metrics employed by coverage-guided fuzzing. Within that paradigm, the fuzzer steers input generation toward inputs that increase the observed coverage signal; condition coverage has been adopted as both a bug-detection criterion and a reward signal in reinforcement-learning-guided hardware fuzzers such as ChatFuzz and GenHuzz [evidence: arxiv 2404.06856, fedd43f9-88d9-4388-a2c7-805a2eea51f4, 454e9ebc-5856-4202-9eef-b12166bbd72c]. Coordinated frameworks such as LiFU combine line, FSM, and condition coverage with bug-detection impact, novelty, and efficiency into a multi-factor priority weight w(t) = α·Δcov(t) + β·bugsc(t) + γ·nov(t) + δ·eff(t) (with α+β+γ+δ = 1) that drives seed selection and reseeding across an ensemble of fuzzers and formal tools [evidence: f166c7f3-e5cc-44ba-8331-25437cde3e58, 8bb71cd9-8af7-438f-bdb5-79987971280a].

Tools and Methods Evaluated with Condition Coverage

Related Concepts

• Coverage-guided fuzzing — the broader paradigm in which condition coverage serves as one of several feedback signals.
• Branch coverage — a closely related metric used by TheHuzz that tests "when" / "otherwise" branching constructs, distinct from condition coverage, which tests the condition block itself.
• T-wise presence condition coverage — a configurable-systems analogue of condition coverage, covering t-wise interactions of presence conditions extracted from code.
• LiFU — a coordinated CPU fuzzing framework that uses condition coverage (with line and FSM coverage) as a feedback signal to prioritize seeds across an ensemble of fuzzers and formal tools.
• GenHuzz — a coverage-based white-box generative hardware fuzzer that uses condition (alongside line and FSM) coverage as a reward signal for reinforcement-learning-guided instruction generation.