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

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Path
  • STA Glossary
  • STA Metrics Reference
  • STA Mastery Cheatsheet
  • Timing Paths and Checks16
  • Constraints & SDC Fundamentals20
    • Clock Definition & Uncertainty
    • Generated Clocks & Dividers
    • I/O Timing & Boundary Contracts
    • Exceptions & Audit Policy
      • False Paths
      • Multicycle Paths
      • Min and Max Delay Exceptions
      • Exception Audit
    • Environment and Design Rules
  • Delay Graph & Path Analysis16
  • Beyond Setup and Hold16
  • Multi-Corner Multi-Mode Signoff16
  • OCV, AOCV, POCV and Variation16
  • Crosstalk and Noise16
  • ECO and Closure16
  • STA Debug Playbook16
  • STA Interview Prep26
  • Capstone Timing Signoff Lab4
Loading lesson

‹Exceptions & Audit Policy
  1. Topics
  2. Static Timing Analysis
  3. Constraints & SDC Fundamentals
  4. Exceptions & Audit Policy
  5. Exception Audit

Part 2 · Constraints and SDC · All levels

Exception Audit

An exception audit lists what every exception covers, flags overbroad or stale ones, and ties each to a reason and an owner.

On this page

    Why it matters

    Exceptions accumulate over a project: each fix adds one, few are removed, and the constraint file ends up silencing paths nobody remembers. An audit makes the effect of each exception visible: how many paths it covers, whether it overlaps another, whether its objects still exist.

    The audit table

    Check

    What it finds

    Paths covered per exception

    A count far larger than intended signals overbreadth

    Exceptions covering no paths

    Stale exceptions: objects renamed or logic removed

    Exceptions covering the same paths

    Overlap: precedence decides, and the loser is dead text

    Exceptions with no reason or owner

    Unreviewed claims

    Exceptions that only mask failing paths

    Suspicious: a violation hidden, not explained

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    exceptions = [
        {"id": "FP1", "reason": "static mode", "paths": 12, "intended": 12},
        {"id": "FP2", "reason": "", "paths": 4300, "intended": 40},
        {"id": "MC1", "reason": "enable gated", "paths": 0, "intended": 30},
    ]
    def audit(e):
        notes = []
        if not e["reason"]: notes.append("no reason")
        if e["paths"] == 0: notes.append("stale")
        if e["paths"] > 10 * e["intended"]: notes.append("overbroad")
        return notes
    result = {e["id"]: audit(e) for e in exceptions}
    assert result == {"FP1": [], "FP2": ["no reason", "overbroad"], "MC1": ["stale"]}
    print("PASS:", result)

    Three exceptions, three outcomes: one clean, one with no reason that covers a hundred times the intended paths, and one that covers no paths at all. The audit output is a work list: fix, narrow, or remove. It is rerun with every constraint change.

    Policy

    • No exception is merged without a reason, an owner and the evidence reference.

    • Exceptions are expired or re-justified at each milestone, not kept forever.

    • The number of exceptions and the number of paths they cover are tracked as a metric; an exception count that only grows is a warning.

    Common pitfall

    Auditing only the exceptions you wrote. Constraints inherited from earlier projects, IP, or a block's top-level wrapper carry exceptions nobody on the team owns. Audit the whole effective constraint set.

    Interview

    Describe how you would keep an exception list honest: reasons, owners, coverage counts, and periodic expiry.

    Check yourself An exception covers zero paths after an RTL change. What do you do?

    Remove it (or fix its object names if the intent still applies). A stale exception can start covering unintended paths if names are reused later.

    Related topics

    • Min and Max Delay Exceptions

    Previous

    37 / 183

    Next: Environment and Design Rules

    Up next

    Up nextEnvironment and Design Rules

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • False Paths
    • Multicycle Paths