Coverage closure
Find out why coverage has stalled, with a test, proof, or supported waiver for each resolved item.
How the check works
A coverage gap can have different explanations.
Investigate the uncovered logic
Reach it
A directed test exercises the missing scenario.
Prove it unreachable
A formal check establishes the limit under stated assumptions.
Support a waiver
An explicit usage rule explains why the scenario is excluded.
Concept illustration. These are possible outcomes; closure is not guaranteed. Unresolved gaps stay open with the evidence gathered.
What you receive
- A table of the agreed coverage gaps, outcomes, and unresolved items.
- Directed tests and recorded hits for gaps reached during the investigation.
- Proof logs for gaps established as unreachable under stated assumptions.
- A waiver note and the solver script behind it for each waived hole.
- Scripts to repeat the agreed checks on a later revision.
When this is useful
- Coverage has stalled short of the target and more random runs do not move it.
- A sign off review is coming and the waiver list has no evidence behind it.
- Nobody is sure whether some holes can be reached at all.
Problem, approach, and required inputs
The problem
Your coverage report shows parts of the design your tests never reached. These are coverage holes. Sign off waits until each one is explained. More random tests often do not reach them, and a waiver with nothing behind it will not survive review.
What we do
We investigate each agreed coverage gap. A resolved item has a directed test, a proof under stated assumptions, or a supported waiver based on an explicit usage rule. If the available checks cannot establish an outcome, we keep the item open and record the evidence, limits, and next steps.
Inputs agreed after scoping and NDA
- The uncovered lines or conditions from your coverage report.
- The RTL revision the report was measured on.
- Any known limits on how the design is used, such as settings the firmware never writes.
Related public demonstration
Public demonstration, not a client result
From a missed timer interrupt to a verified fix
A RISC-V machine timer with a seeded bug, taken from failing test to counterexample, root cause, proven fix, and closed coverage holes.
Technical details
How the result is checked
Each outcome comes with a file a reviewer can check: the test and its hit count, the proof log, or the solver result. Nothing is marked closed without one. Unresolved items retain their limits and next steps.
Tools used for this kind of work
- SymbiYosys
- Yosys
- z3
- Verilator
- cocotb
- SystemVerilog Assertions
Scripts are handed over as agreed in the scope. Properties are standard SystemVerilog Assertions and can be adapted to a commercial tool. If we have not tested your simulator or flow, the scope says so.
Discuss this problem.
Tell us what you are trying to verify and what is blocking you. A person replies, and the scope comes back in writing after a call.
Discuss a verification problem