Safety vs Liveness, Strong vs Weak: Mechanism

Mechanism to understand

Mechanism for Safety vs Liveness, Strong vs Weak is anchored on non-vacuous closure rate, counterexample turnaround, and residual-risk trend by requirement class. Convert outcomes into assumption-aware, evidence-backed actions.

Safety properties state that something bad never happens (for example mutual exclusion: `assert property (@(posedge clk) !(wr && rd));`), while liveness properties state that something good eventually happens (for example progress: `req |->

• Name the first boundary where requirement intent diverges.

• Prove mechanism with one high-confidence evidence packet.

• Assign owner for smallest reversible mitigation.

Execution flow

FORMAL EXECUTION FLOW - Safety vs Liveness, Strong vs Weak

requirement intent and risk class
      |
      v
property and assumption modeling
      |
      v
proof engine exploration and trace extraction
      |
      v
counterexample classification and fix hypothesis
      |
      v
re-proof, coverage audit, and signoff decision

Formal deep dive

SVA scales when temporal intent, clock sampling, and reset gating are precise enough to be replayed and reviewed.

Concept diagram

SVA INTENT CHAIN

timing contract -> sequence composition -> property implication -> sampled failure trace

Metric graph

ASSERTION QUALITY SIGNALS

non-vacuous hit rate    ████████
clock/reset mismatches  ████
false-positive churn    ███

Metrics and artifacts to collect

• assertion trigger hit-rate

• implication timing mismatch bucket

• reset-window noise ratio

• assertion decomposition quality score

Mini case study

A protocol failure vanished after correcting `|->` vs `|=>` semantics and reset masking boundaries.

Debug branches

• Confirm antecedent trigger at sampled clock edges.

• Verify implication operator matches protocol timing contract.

• Split monolithic properties into stage-local checks.

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.

Mechanism deep dive

Mechanism detail: Safety properties state that something bad never happens (for example mutual exclusion: `assert property (@(posedge clk) !(wr && rd));`), while liveness properties state that something good eventually happens (for example progress: `req |-> s_eventually gnt`). In formal, weak eventuality can pass vacuously when the trace terminates before progress is forced, so use strong intent where required: `req |-> strong(##[1:$] gnt)` requires grant to occur on every satisfying path, not just non-failing finite prefixes. Pair liveness with fairness/environment assumptions (like downstream can accept responses) or proofs may report unrealizable counterexamples dominated by hostile environments rather than design bugs.

Prefer requirement decomposition over monolithic assertions for debug clarity.