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
  • CDC/RDC Glossary
  • CDC/RDC Metrics Reference
  • CDC/RDC Interview Prep
  • CDC/RDC Signoff Cheatsheet
  • Clock Domains and Failure Modes8
  • Metastability and Synchronizers16
  • CDC Protocols and Handshakes16
  • Reconvergence and Gray Coding16
  • Reset Domain Crossing16
  • Architecture and Design Rules16
    • CDC-Aware Partitioning
    • Clock Gating and Muxing
    • Interface and IP Rules
    • Quasi-Static Signals and Configuration
      • Static by Construction
      • Qualification and Stability
      • Constraints and Waiver Hygiene
      • Runtime Reconfiguration
  • CDC Signoff Methodology24
  • RDC Signoff16
  • Debug and Case Studies11
  • CDC and RDC Interview Prep30
  • Capstone: Sign Off a Multi-clock Peripheral4
Loading lesson

‹Quasi-Static Signals and Configuration
  1. Topics
  2. CDC & RDC
  3. Architecture and Design Rules
  4. Quasi-Static Signals and Configuration
  5. Constraints and Waiver Hygiene

Part 6 · Architecture and Design Rules · Intermediate

Constraints and Waiver Hygiene

How quasi-static intent is communicated to the checks and why a blanket waiver is dangerous.

On this page

    Structural analysis cannot see intent. A quasi-static crossing looks exactly like an unsynchronised one unless the intent is written into the setup: which signals are quasi-static, under what window, and where the proof lives. Waivers are that writing, which is why their hygiene decides whether they record engineering or hide bugs.

    Communicating the intent

    Each quasi-static signal needs a constraint entry that names the signal (never a bus wildcard that future signals inherit), states the stability window, and points at the proof: the enforcer plus the assertion from the previous lesson. The sketch below shows the shape in generic form, illustrative rather than tool syntax:

    Diagram
    # Illustrative shape only, not tool syntax:
    # signal cfg_live[15:0] is quasi-static: stable throughout RUN mode.
    # Enforced by: write gating in mode_logic. Proven by: a_cfg_stable.
    # Review with any change to the write path or the mode machine.

    Timing setup treats the path accordingly (no setup chase on a path that cannot change during use), but the entry above is what stops the next engineer from “cleaning up” the exception without understanding it.

    Why a blanket waiver is dangerous

    Blanket waiver

    What goes wrong

    “All crossings on this bus are static”

    A new signal added to the bus inherits the waiver without its own proof.

    “Crossings between these clocks are false paths”

    Every future crossing between the clocks, synchronised or not, is silently excused.

    “Waived: reviewed” with no evidence pointer

    The next reviewer cannot tell what was reviewed, so the waiver is uncheckable and permanent.

    Hygiene rules

    • One waiver per inventory row or row group, naming the exact signals.

    • Every waiver carries the evidence pointer (assertion name, test result) and the stability window it depends on.

    • Every waiver has an owner and an expiry or re-review trigger, such as any change to the write path.

    • Waiver review is part of release signoff: re-confirm each one against the current RTL, because the design moved since it was written.

    Common pitfall

    Copying a waiver file from a previous project “as a starting point”. The signals, windows, and proofs it names belong to a different design; most rows will be wrong, and the wrong rows look exactly like careful work. Start from the generated crossing list every time.

    Check yourself A waiver names CDC-017, points at assertion a_cfg_stable, and expires on any change to the configuration write path. A release changes only the datapath pipeline depth. Does the waiver need re-review?

    Strictly the trigger did not fire, but the release signoff still re-confirms it: the use window or the clocking may have shifted with the pipeline. Expiry triggers catch edits; release review catches side effects.

    Related topics

    • Qualification and Stability

    • Crossing Inventory

    Previous

    93 / 179

    Next: Runtime Reconfiguration

    Up next

    Up nextRuntime Reconfiguration

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Static by Construction