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 Signoff Methodology24
    • CDC Tool Flow
    • CDC Constraints and STA
      • How CDC Meets Timing
      • Clock Groups and False Paths
      • Bounded Delay Constraints
      • Constraint Reviews
    • CDC Waiver Policy
    • CDC Review Gate
    • CDC Signoff Dashboard
    • Formal and Simulation CDC Verification
  • RDC Signoff16
  • Debug and Case Studies11
  • CDC and RDC Interview Prep30
  • Capstone: Sign Off a Multi-clock Peripheral4
Loading lesson

‹CDC Constraints and STA
  1. Topics
  2. CDC & RDC
  3. CDC Signoff Methodology
  4. CDC Constraints and STA
  5. Clock Groups and False Paths

Part 7 · CDC Signoff Methodology · Advanced

Clock Groups and False Paths

Declaring asynchronous clock groups and false paths: what they remove from timing and when that is justified.

On this page

    Two constraint concepts release paths from ordinary timing checks: declaring a group of clocks asynchronous to another group, and marking individual paths as false. Both are statements of intent — “do not time this” — and both remove a safety net. This lesson explains what each removes, when the removal is justified, and what evidence the justification needs.

    What each concept removes

    Concept

    What it declares

    What timing stops checking

    Scope

    Asynchronous clock groups

    These clocks have no phase relationship worth checking

    Setup and hold on every path between the groups

    Broad: all paths between the named clocks

    False path

    This particular path is never exercised in a way timing must guarantee

    Setup and hold on that path only

    Narrow: the named path or paths

    The names above are generic constraint concepts, not command spellings: every timing flow offers its own syntax for the same two ideas. What matters for signoff is the meaning — which checks are removed over which paths — not the spelling.

    When each is justified

    Situation

    Justified exception

    Evidence needed

    True asynchronous clocks with synchronisers

    Asynchronous clock groups between the pair

    Structural CDC analysis showing every crossing between the groups is synchronised

    Quasi-static signal with qualification

    False path on the qualified static net

    Proof the signal is stable during operation plus the qualification mechanism

    Timing exception inside one domain

    False path or multicycle on that path

    Designer argument reviewed against the protocol; see multicycle and false paths for the timing side

    A path that merely looks asynchronous

    Neither

    Fix the clocking or add a synchroniser; the exception would only hide the defect

    Why a broad declaration is dangerous

    An asynchronous-group declaration covers every path between two clocks, including crossings added next month by someone who never read the waiver. Each new crossing inherits the silence automatically. That is why the declaration is reviewed against the full crossing inventory, not against the crossings known when it was written — and why narrow false paths are preferred wherever a narrow statement is honest.

    Warning

    A false path never makes a crossing safe. It only stops timing from complaining about it. Every false path on a crossing must be paired with a structural CDC check that confirms the synchroniser, handshake, or FIFO behind it.

    Interview

    “When would you use a false path on a CDC crossing?” Only where the path is genuinely not timing-critical by construction — a qualified quasi-static net, for example — and always paired with structural evidence that the crossing is safe. A false path used to quiet a real asynchronous crossing is a defect, not a fix.

    Check yourself A designer marks two related clocks asynchronous to clear timing violations. What two things are wrong with this?

    First, the clocks are related, so the declaration is false and hides real timing requirements. Second, even a true declaration removes checks without adding safety; without structural evidence for every crossing, the silence proves nothing.

    Check yourself Why is a narrow false path usually preferable to a broad asynchronous-group declaration?

    Its blast radius is limited to the named path, so future crossings do not silently inherit the exception. Broad declarations grant silence to paths nobody has reviewed yet.

    Related topics

    • How CDC Meets Timing

    • Constraint Reviews

    • RTL: Multicycle and False Paths

    Previous

    100 / 179

    Next: Bounded Delay Constraints

    Up next

    Up nextBounded Delay Constraints

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Constraint Reviews