Typical FPV Tool Flow: Setup, Constraints, Run, Debug, and Closure: Inputs and Outputs

Inputs and outputs contract

Inputs and Outputs for Typical FPV Tool Flow: Setup, Constraints, Run, Debug, and Closure is anchored on non-vacuous closure rate, counterexample turnaround, and residual-risk trend by requirement class. Convert outcomes into assumption-aware, evidence-backed actions.

INPUTS
  - requirement intent and risk tier
  - property scope and temporal contract
  - assumption model and reset policy
  - tool/engine metadata and reproducibility tags

OUTPUTS
  - evidence-backed root-cause classification
  - owner-signed mitigation proposal
  - validation matrix and rollback triggers
  - signoff recommendation

Ownership split

OWNERSHIP LAYERS - Typical FPV Tool Flow: Setup, Constraints, Run, Debug, and Closure

+----------------------+--------------------------------+--------------------------------+
| Team                 | Primary responsibility         | Closure artifact               |
+----------------------+--------------------------------+--------------------------------+
| formal verification owner | property and model integrity      | assumptions and proof packet   |
| rtl owner | implementation root-cause closure | RTL fix and replay evidence    |
| Formal Verification Foundations owner | signoff governance and rollout    | risk memo + acceptance gates   |
+----------------------+--------------------------------+--------------------------------+

Formal deep dive

FPV foundations are reliable only when assumptions, reset semantics, and requirement intent are explicitly modeled and audited.

Concept diagram

FPV FOUNDATION LOOP

requirements -> property set -> assumptions and reset model -> prove/fail traces -> closure audit

Metric graph

FOUNDATION HEALTH

vacuous passes         ████
reachable proofs       ███████
inconclusive backlog   █████
reopened properties    ███

Metrics and artifacts to collect

• assumption traceability matrix

• vacuity and reachability status

• proof core relevance summary

• counterexample classification trend

Mini case study

A green-looking run was invalidated after legal-mode covers failed, exposing assumptions that removed realistic traffic.

Debug branches

• Validate requirement-to-property mapping before tuning runtime.

• Check legal scenario reachability after every assumption change.

• Classify first divergence as model issue or RTL bug.

Senior review question

Ask: which requirement intent is proven, under which assumptions, and what residual risk remains?

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.

Handoff explanation

Inputs should include assumptions, reset semantics, and property intent classes.

Outputs should include counterexample classification, closure confidence, and residual-risk labeling.