Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Paths
  • Glossary
  • Metrics Reference
  • Formal Cheat Sheet
  • Formal Foundations19
  • Properties and SVA16
  • Property Development and Constraints19
  • Proof Engines and Convergence23
  • Formal Applications20
  • Equivalence Checking14
  • Formal Coverage and Signoff15
    • Cover Properties, Vacuity and Reachability
    • Formal Coverage Metrics
    • Bounded Proof Signoff
      • Justifying a Bound
      • The Proof Status Ledger
      • Inconclusive Results and Waivers
      • Stale Proofs and Source Hashes
    • The Formal Signoff Package
  • Methodology and Debug13
  • Interview Prep15
  • Capstone: A Chip-Block Verification Lab24
Loading lesson

←Bounded Proof Signoff
  1. Topics
  2. Formal Verification
  3. Formal Coverage and Signoff
  4. Bounded Proof Signoff
  5. Stale Proofs and Source Hashes
On this page

    Part 7 of 10, lesson 12 of 15Part 7 of 10/Formal Coverage and Signoff/Lesson 12 of 15All levels

    Stale Proofs and Source Hashes

    Tie every result to its source revision and rerun the suite on every change.

    Why it matters

    A proof belongs to one revision. The day after sign-off, a one-line fix lands, the proof is rerun by nobody, and the package still quotes the old result. From that moment the sign-off describes a design that no longer exists. Staleness is not a rare accident; in an active project it is the default, and only a mechanical check defeats it.

    The core idea

    Every ledger row records the source hash it was proved against, and the gate compares those hashes with the current sources before any other check. A mismatch marks the row stale, and a stale row is rerun, not argued about. The rerun is cheap because the suite is incremental: proofs whose cone excludes the changed logic can be identified, but the safe default is rerunning everything, since the full FIFO and arbiter suites complete in seconds.

    Worked example: the hash check

    The script below models the gate: a ledger with per-file hashes against current sources. One file moved on, and the gate names exactly the rows that must rerun. The second half shows the rerun making the ledger current, and a source file that has vanished from the tree being flagged instead of skipped.

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    # the staleness gate: ledger hashes versus current sources
    ledger = [
        {"prop": "a_range", "files": {"sync_fifo.sv": "a41f"}, "status": "proven"},
        {"prop": "a_wt1", "files": {"rr_arbiter.sv": "9c02"}, "status": "proven"},
        {"prop": "a_data", "files": {"hs_bridge.sv": "77bd"}, "status": "inconclusive"},
    ]
    current = {"sync_fifo.sv": "a41f", "rr_arbiter.sv": "9c03", "hs_bridge.sv": "77bd"}
    
    def stale_rows(rows, cur):
        stale = []
        for r in rows:
            for f, h in r["files"].items():
                if cur.get(f) != h:
                    stale.append((r["prop"], f, h, cur.get(f)))
        return stale
    
    stale = stale_rows(ledger, current)
    assert stale == [("a_wt1", "rr_arbiter.sv", "9c02", "9c03")], stale
    # only the arbiter row reruns; the other two keep their status
    fresh = [r["prop"] for r in ledger if r["prop"] not in {s[0] for s in stale}]
    assert fresh == ["a_range", "a_data"], fresh
    # once the rerun is recorded with the new hash the ledger is current again
    rerun = [dict(r, files={f: current[f] for f in r["files"]}) for r in ledger]
    assert stale_rows(rerun, current) == []
    # a source file missing from the tree is flagged too, not silently skipped
    assert stale_rows(ledger, {"sync_fifo.sv": "a41f", "hs_bridge.sv": "77bd"}) == [("a_wt1", "rr_arbiter.sv", "9c02", None)]
    print("PASS: gate reruns a_wt1 on rr_arbiter.sv 9c02->9c03; others stand; missing file flagged")

    What the reviewer looks for

    • Every result row carries a source hash, and the gate compares it with the current tree before sign-off.

    • The rerun policy is written down: what reruns on which change, and who owns the rerun.

    • No result is quoted for a revision behind the release candidate, however good the numbers.

    Verify and debug

    Keep the hash fine-grained: per file or per module, not per repository, so one fix reruns one proof family instead of the world. Store the ledger beside the sources so the two cannot drift apart. In continuous integration, the gate runs first and fails fast on staleness; human review starts only after the hashes agree, because reviewing numbers for the wrong revision is worse than useless.

    The stale proof after a source change: symptom is a sign-off quoting a proof run on an older revision. Cause is a manual process where reruns depend on memory. Fix is the hash column with the mechanical gate and rerun-on-change policy. It is found by the gate, which compares hashes before reading any result.

    Expect the probe: the design changed after your proofs passed, what still holds? Answer with the hash gate: rows whose sources moved rerun, the rest stand, and nothing is quoted for an old revision. Then name the rerun owner and the regression step that enforces it.

    Check yourself A fix touches only comments in one file. Must its proofs rerun?

    Yes under the safe default, because the gate cannot tell comments from logic without parsing. With per-module hashing that ignores comments the rerun can be skipped honestly; without it, rerun and keep the result current.

    Related topics

    • The Formal Signoff Package: The Signoff Checklist in Full

    • Formal: Formal in Regression

    Previous

    128 / 183

    Next: The Formal Signoff Package

    Up next

    Up nextThe Formal Signoff Package

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Justifying a Bound
    • The Proof Status Ledger