Formal Verification · All levels
Methodology & Debug: Tricky Q&A
Senior interview and review questions for Methodology & Debug.
Section Q&A bank
Use these drills after completing all topics in Methodology & Debug. Answer with requirement context, mechanism proof, artifact, owner, and signoff decision.
Why can a complete requirement matrix still produce weak formal closure?
diagram
[INT][FORMAL][METHODOLOGY-AND-DEBUG]
Q: Why can a complete requirement matrix still produce weak formal closure?
A:
Because traceability alone does not guarantee sound modeling. A matrix can look complete while assumptions over-constrain legal traffic, liveness is encoded as shallow safety checks, or trigger conditions are vacuous. Closure is credible only when requirement mapping is paired with assumption audits, reachability covers, and non-vacuous proof evidence.
FOLLOW-UP TRAP: Assuming requirement-to-property coverage percentages are sufficient proof of formal signoff quality.What is the most reliable signal that runtime tuning is solving the right problem?
diagram
[INT][FORMAL][METHODOLOGY-AND-DEBUG]
Q: What is the most reliable signal that runtime tuning is solving the right problem?
A:
Evidence that state-space quality improved, not just that jobs ended faster. Useful signals include cleaner proof cores, reduced inconclusive recurrence, stable depth growth where expected, and successful closure of previously hard properties without new over-constraint warnings.
FOLLOW-UP TRAP: Judging convergence improvements only by wall-clock runtime or timeout count reduction.During counterexample debug, when should you modify assumptions first versus RTL first?
diagram
[INT][FORMAL][METHODOLOGY-AND-DEBUG]
Q: During counterexample debug, when should you modify assumptions first versus RTL first?
A:
Modify assumptions first only after proving the trace violates the intended environment contract and that the contract itself is architecturally valid. If the trace is legal under the real protocol or software interaction, RTL or property intent is wrong and should be fixed before tightening assumptions.
FOLLOW-UP TRAP: Tightening assumptions immediately to make failures disappear without validating environment legality.How should formal be represented in CI dashboards to support release decisions?
diagram
[INT][FORMAL][METHODOLOGY-AND-DEBUG]
Q: How should formal be represented in CI dashboards to support release decisions?
A:
Expose risk-weighted evidence: requirement coverage by criticality, non-vacuous proof status, inconclusive aging, waiver rationale, and trend of reopened properties after RTL changes. This ties formal outcomes to release risk, unlike a single aggregate pass rate.
FOLLOW-UP TRAP: Publishing only total pass counts and hiding vacuity, waiver debt, and inconclusive backlog.Q&A drill guide
diagram
REQUIREMENT -> PROPERTY -> EVIDENCE -> OWNER ACTION -> RESIDUAL RISKSketch while answering
diagram
METHODOLOGY LOOP
plan -> run in CI -> triage -> fix -> revalidate -> signoff dashboardCommon traps
Start debug at first semantic divergence cycle.
Tag every failure with owner and risk tier immediately.
Automate stale inconclusive and vacuity alerts.
Key takeaways
Tie each proof claim to assumption boundaries and reachability evidence.
Prefer minimal reversible fixes and preserve legal behavior visibility.
Common pitfalls
Treating runtime reduction as proof-quality improvement without audits.
Declaring closure while critical covers remain unreachable.
Using broad waivers instead of first-divergence root-cause ownership.