Formal Verification · All levels
Formal Applications (Apps): Tricky Q&A
Senior interview and review questions for Formal Applications (Apps).
Section Q&A bank
Use these drills after completing all topics in Formal Applications (Apps). Answer with requirement context, mechanism proof, artifact, owner, and signoff decision.
Why can a connectivity app pass while silicon still routes the wrong source in one mode?
[INT][FORMAL][FORMAL-APPS]
Q: Why can a connectivity app pass while silicon still routes the wrong source in one mode?
A:
Because the formal model may not constrain configuration CSR legality or power/clock enables correctly, allowing the proof to avoid the problematic mode or treat it as unreachable. Connectivity closure needs both structural route assertions and explicit assumptions/covers that exercise every architecturally legal mode and mux selection.
FOLLOW-UP TRAP: Assuming endpoint equivalence assertions alone guarantee pin-mux correctness across all configuration states.What subtle CSR bug class is commonly missed without temporal assertions?
[INT][FORMAL][FORMAL-APPS]
Q: What subtle CSR bug class is commonly missed without temporal assertions?
A:
Priority and race bugs between software writes and hardware side effects (for example, interrupt status set and W1C clear in the same cycle). Bit-level access checks are not enough; you must assert cycle-accurate precedence rules and ordering so control software sees deterministic semantics.
FOLLOW-UP TRAP: Treating CSR verification as only address-decoder and permission checking.Why do deadlock checks often require fairness assumptions, and what is the risk?
[INT][FORMAL][FORMAL-APPS]
Q: Why do deadlock checks often require fairness assumptions, and what is the risk?
A:
Liveness proofs need environment progress guarantees (like downstream ready eventually asserting); without them, the solver can construct starvation traces that are legal but non-physical. The risk is over-constraining fairness so heavily that real starvation bugs are hidden, so assumptions must be minimal, reviewable, and traceable to architecture contracts.
FOLLOW-UP TRAP: Adding strong fairness assumptions just to make liveness proofs converge quickly.How does formal X-propagation verification differ from simulation-based X checks?
[INT][FORMAL][FORMAL-APPS]
Q: How does formal X-propagation verification differ from simulation-based X checks?
A:
Simulation reveals X behavior only in sampled traces and depends on simulator optimism/pessimism settings, while formal can prove whether unknown-sensitive control can ever escape reset/initialization envelopes under all legal interleavings. Formal is strongest when paired with explicit convergence properties and reset sequencing assumptions that match hardware bring-up.
FOLLOW-UP TRAP: Believing clean simulation waveforms imply no X-related silicon risk.Q&A drill guide
REQUIREMENT -> PROPERTY -> EVIDENCE -> OWNER ACTION -> RESIDUAL RISKSketch while answering
FORMAL APPS MAP
connectivity + csr + progress + reset/x checks -> integrated SoC confidenceCommon traps
Validate mode and configuration constraints for each app.
Pair safety and liveness checks for progress-sensitive logic.
Add first-transaction covers for reset-sensitive interfaces.
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.