Bounded model checking is widely used in formal verification to explore design behaviour over a finite number of clock cycles.
The selected depth determines how far the engine explores possible execution traces.
However, the absence of a counterexample within a selected depth does not automatically establish that a property is true for all possible executions.
What does a bounded proof check?
Suppose a formal engine checks a property up to depth K.
The engine explores legal behaviours within that bound and searches for a counterexample.
If no counterexample is found, the result establishes that no violating trace was identified within the explored bound, subject to the model and assumptions.
It does not necessarily establish an unbounded proof.
Why depth matters
Consider a counter that uses 10 bits.
A complete counter cycle can require up to 1,024 count states, depending on its starting value and transition behaviour.
If a property concerns behaviour that can occur only after a complete wraparound, a much smaller depth may not expose the relevant scenario.
Similarly, a FIFO, arbitration controller or DMA controller may require several transactions before reaching a particular state.
The required depth depends on the property and the design architecture.
When is a bounded result useful?
Bounded analysis is useful for:
- Finding short counterexamples
- Checking reset and initialization sequences
- Exploring transaction-level behaviour
- Detecting protocol violations
- Debugging control logic
- Establishing confidence over selected finite scenarios
It can provide valuable evidence even when an unbounded proof is not yet available.
What should engineers consider when selecting depth?
Depth should be selected based on the design behaviour being checked.
Important considerations include:
- Maximum expected transaction latency.
- Counter rollover and state-transition behaviour.
- FIFO occupancy and boundary conditions.
- Reset and initialization sequences.
- Reachability of important control states.
- Whether the property requires a deeper sequence to expose a violation.
Can induction help?
For suitable properties, induction-based methods can establish correctness beyond a finite exploration depth.
However, induction may require additional invariants or strengthening properties.
A property that is difficult to prove by induction may need better decomposition, stronger invariants or a more suitable abstraction.
The appropriate proof strategy depends on the design and property.
How should results be reported?
A verification report should distinguish clearly between:
- Unbounded proven results
- Bounded results and their explored depth
- Counterexamples
- Inconclusive results
- Properties not reached or not evaluated
A statement such as "no counterexample found up to depth K" is more accurate than describing the property as fully proven.
Conclusion
Selecting a formal verification depth is not simply a matter of increasing a tool setting.
It requires understanding the design's state space, expected transaction behaviour and the property being checked.
A bounded result is valuable when its scope is clearly understood and reported. It should not be confused with an unbounded proof.
