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
      • The Generic CDC Flow
      • Setup: Clocks, Resets and Intent
      • Violation Classes
      • Hierarchical versus Flat Analysis
    • CDC Constraints and STA
    • 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 Tool Flow
  1. Topics
  2. CDC & RDC
  3. CDC Signoff Methodology
  4. CDC Tool Flow
  5. Setup: Clocks, Resets and Intent

Part 7 · CDC Signoff Methodology · Advanced

Setup: Clocks, Resets and Intent

What CDC analysis needs to know: clocks, relationships, resets, quasi-static intent, and constraints.

On this page

    Structural analysis cannot discover intent from RTL alone. It needs to be told which clocks exist, how they relate, which resets belong to which domain, which signals are quasi-static, and which constraints apply. Setup is that telling, and every finding the analysis reports is only as trustworthy as the setup behind it.

    What the analysis needs

    Setup item

    What it says

    Example

    Clock list

    Every clock in the design, including generated, gated, and muxed clocks

    A divided clock and a mux-selected clock listed as clocks in their own right

    Clock relationships

    Which clock pairs are asynchronous and which are related

    Two free-running oscillators marked asynchronous to each other

    Reset intent

    Which reset belongs to which domain and how it releases

    A reset synchronised to its own domain before fanning out

    Quasi-static intent

    Which signals are stable while the design operates

    A configuration register loaded once, then held

    Constraint intent

    Which crossings carry timing exceptions and bounded-delay limits

    Bounded datapath delay limits on a crossing bus (a concept, not a command)

    Generated clocks deserve special care: a clock divider or a clock mux creates a domain the RTL never names, and an unlisted domain is an unanalysed domain. Gated clocks are covered alongside the standard clock-gating material in clock gating.

    What happens when setup is wrong

    Setup errors fail in two opposite directions, and telling them apart is the core setup skill.

    Failure

    Cause

    Symptom

    Response

    False clean

    Missing clock, wrong relationship, excluded hierarchy

    Too few findings; known crossings absent

    Stop. Fix setup and re-run; no classification done on this run counts.

    False noise

    Related clocks marked asynchronous, missing quasi-static intent

    Floods of findings on safe paths

    Refine intent, do not waive in bulk; each waiver still needs evidence.

    False clean is the dangerous direction: it looks like success. Any run whose counts drop sharply after a setup edit should be treated as suspect until the setup diff is reviewed line by line.

    Reviewing setup

    Setup is reviewed like RTL: by a second pair of eyes, against the architecture document, before the first classification pass. The checks are small and mechanical, which is exactly why skipping them is embarrassing later.

    • Every clock in the architecture document appears in the clock list, including generated and muxed clocks.

    • Every asynchronous pair is a deliberate statement, not a default; related clocks are not marked asynchronous to silence timing.

    • Resets are attached to their own domains, and reset crossings are visible to the analysis rather than hidden by exclusion.

    • Quasi-static declarations name the qualification mechanism that keeps each signal stable.

    • The setup is version-controlled with the RTL it was checked against, so a run can always be reproduced.

    Common pitfall

    Copying setup from a previous project is the fastest route to false clean: clock names match by accident, relationships differ silently, and the analysis signs off a design it never understood.

    Check yourself A run reports no crossings between two domains that the architecture document says communicate. What do you check first?

    The setup: whether both clocks are defined, whether their relationship is stated, and whether either hierarchy is excluded. Missing findings point at blindness before they point at cleanliness.

    Check yourself Marking two related clocks as asynchronous removes timing violations. Why is that a setup defect rather than a fix?

    It trades a timed, checked path for an unchecked one without adding any synchroniser. The timing report goes quiet while the underlying requirement stays unsatisfied, and CDC analysis now has to carry the whole burden on a false premise.

    Related topics

    • The Generic Flow

    • Hierarchical versus Flat Analysis

    • Clock Groups and False Paths

    Previous

    96 / 179

    Next: Violation Classes

    Up next

    Up nextViolation Classes

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Hierarchical versus Flat Analysis