Mentor Questa Formal Verification: Exhaustive Property Checking with SystemVerilog Assertions
Simulation-based verification can exercise millions of clock cycles, yet it remains fundamentally incomplete: a single untested corner case can escape to silicon. Mentor Questa Formal Verification (part of the Siemens EDA portfolio) addresses this gap by mathematically proving — or disproving — that a design satisfies every SystemVerilog Assertion (SVA) property across all possible input sequences, without writing a single testbench stimulus.
Why Formal Verification Belongs in Your Verification Plan
Traditional simulation finds bugs by running specific scenarios. Formal verification inverts the problem: given a property, the tool exhaustively searches the entire reachable state space for a counterexample. If none exists, the property is proven correct. This makes formal especially powerful for:
- Control logic and arbiters — priority encoders, bus arbiters, and handshake protocols where rare interleavings cause deadlocks
- Reset and clock-domain crossing (CDC) logic — conditions that are nearly impossible to hit in directed simulation
- Security-critical paths — information-flow properties and access-control invariants
- Datapath correctness — overflow, saturation, and rounding guarantees in fixed-point arithmetic
Questa Formal Architecture
Questa Formal uses a Bounded Model Checking (BMC) engine for bug hunting and a k-induction / IC3/PDR engine for full proofs. The two engines run in parallel:
- BMC unrolls the design state machine up to a configurable depth (bound) and checks whether any reachable state violates the property. It is fast and finds shallow bugs quickly.
- IC3/PDR (Property Directed Reachability) constructs an inductive invariant that holds for all reachable states, enabling unbounded proofs on designs with large but finite state spaces.
The tool reads standard RTL (SystemVerilog, VHDL, or mixed) and SVA property files, compiles them into an internal model, and dispatches proof tasks to a multi-core solver farm.
Writing Effective SVA Properties for Questa Formal
The quality of formal results depends directly on the quality of the properties. A minimal but complete SVA property set for a FIFO controller illustrates the key patterns:
// Assume: valid input protocol
property no_push_when_full;
@(posedge clk) disable iff (!rst_n)
full |-> !push;
endproperty
assume_no_push_when_full: assume property (no_push_when_full);
// Assert: count never exceeds depth
property count_bounded;
@(posedge clk) disable iff (!rst_n)
count <= DEPTH;
endproperty
assert_count_bounded: assert property (count_bounded);
// Cover: both full and empty states are reachable
cover_full: cover property (@(posedge clk) full);
cover_empty: cover property (@(posedge clk) empty);
Key authoring guidelines:
- Separate assumes from asserts. Assumes constrain the environment (legal inputs); asserts state what the design must guarantee. Mixing them produces vacuous proofs.
- Use
disable ifffor reset. Without it, the tool may find spurious counterexamples during reset de-assertion. - Add cover properties. Cover directives verify that the property's antecedent is reachable — a proof with an unreachable antecedent is vacuously true and meaningless.
- Bound complex sequences. For liveness properties (e.g., "a request is eventually granted"), add a cycle-count bound to keep the proof tractable:
##[1:MAX_LATENCY] grant.
Running a Questa Formal Session
A typical command-line flow compiles the design and launches the proof engines:
# Compile RTL and properties
qverilog -f rtl.f -f props.f -work work
# Launch Questa Formal
qformal -work work -init {
set_compile_option -sv
formal compile -d top -work work
formal verify -init {
set_engine_mode {Ht Hp} ;# BMC + PDR in parallel
set_max_trace_length 200 ;# BMC bound
}
}
The GUI presents each property with one of four outcomes: Proven, Falsified (with a waveform counterexample), Bounded Proof (proven up to the BMC depth), or Inconclusive. Falsified properties generate a .vcd or .fsdb waveform that can be loaded directly into Questa Sim or Synopsys Verdi for root-cause analysis.
Interpreting Results and Managing Complexity
State-space explosion is the primary challenge in formal verification. Questa Formal provides several mitigation strategies:
| Technique | When to Use | Effect |
|---|---|---|
Abstraction (abstract -port) |
Large memories, FIFOs | Replaces concrete storage with unconstrained model |
| Case splitting | Designs with many independent sub-blocks | Decomposes proof into smaller sub-problems |
| Assume-guarantee | Multi-block hierarchies | Proves each block independently using interface contracts |
| Witness coverage | After proof | Confirms that cover properties are reachable, validating assume set |
For SoC-scale designs, the recommended approach is block-level formal — isolate individual IPs (arbiters, protocol bridges, CSR blocks) and prove them independently before integrating into simulation-based regression.
Integration with CI/CD Regression
Questa Formal integrates cleanly into Jenkins or GitLab CI pipelines. A nightly formal regression run can:
- Compile all RTL blocks and their associated SVA property files
- Run BMC to depth 150 on all asserts (fast bug-hunting pass, ~30 min)
- Escalate any new failures to the on-call verification engineer via email/Slack
- Run full PDR proofs on proven-stable blocks overnight
This layered approach catches regressions within hours of a code commit, long before simulation regression completes.



Conclusion
Mentor Questa Formal Verification transforms SVA properties from passive documentation into active, exhaustive proof obligations. By combining BMC for rapid bug hunting with IC3/PDR for unbounded proofs, it closes the coverage gaps that simulation cannot reach. Teams that integrate block-level formal into their CI pipeline consistently report 20–40% reductions in late-stage bug escapes and faster sign-off on control-intensive IP blocks.
Further Reading: