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
    • CDC Waiver Policy
    • CDC Review Gate
      • Pre-Tapeout Gates
      • Review Checklists
      • Signoff Readiness
      • Handoff to Physical Design and DFT
    • 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 Review Gate
  1. Topics
  2. CDC & RDC
  3. CDC Signoff Methodology
  4. CDC Review Gate
  5. Handoff to Physical Design and DFT

Part 7 · CDC Signoff Methodology · Advanced

Handoff to Physical Design and DFT

What implementation and test teams need to know about crossings and constraints.

On this page

    CDC signoff on RTL proves the design is correct; it does not implement it. The physical-design and test teams inherit every assumption the RTL signoff made — synchroniser identity, placement intent, constraints, test-mode behaviour — and any assumption that does not survive the handoff fails silently in silicon. The handoff package is what carries them across.

    What physical design needs

    Item

    Why PD needs it

    Synchroniser inventory

    To identify the flops that must not be merged, retimed, or optimised away

    Placement intent

    To keep synchroniser flops together so wire delay does not eat settling time

    Do-not-touch marking

    To protect synchroniser modules and Gray registers through synthesis and optimisation

    Datapath delay bounds

    To implement the skew limits the protocol arguments assume

    Clock-group and false-path declarations

    To apply the same exceptions — no more, no fewer — that signoff reviewed

    What DFT needs

    Scan stitching threads through synchronisers, and test modes create clock relationships the functional design never sees. DFT needs to know which crossings are functional (and must be preserved through scan insertion) and which paths are test-only (and need their own constraints and waivers, scoped to test mode). A synchroniser reordered for scan convenience is a synchroniser destroyed for functional safety — the handoff must say which structures are untouchable and why.

    Closing the loop

    • The handoff is versioned with the signed-off RTL and constraints, so PD and DFT can always check what they built against what was approved.

    • Changes during implementation — retiming, ECOs, scan reordering — return to CDC for re-check; the gate-level lesson explains what to re-run.

    • Handoff review is joint: PD confirms the constraints are applicable, DFT confirms test-mode crossings are covered, CDC confirms nothing was lost in translation.

    Common pitfall

    Handing off the RTL without the constraints and the waiver file tells implementation what to build but not what was assumed. The most common handoff failure is a synchroniser that survives synthesis but loses its delay bound, because the bound never left the front-end.

    Check yourself Scan insertion reorders two synchroniser flops for chain balance. Who must approve, and what is re-checked?

    CDC must approve, because the structure is untouchable without review. The structural re-check confirms the synchroniser still stands, and timing confirms the bound still holds on the new placement.

    Check yourself Why must test-mode crossings get their own constraints and waivers?

    Because test modes create clock relationships functional analysis never covered. Borrowing functional exceptions for test paths — or leaving test paths uncovered — both fail: each mode needs its own reviewed statements.

    Related topics

    • Signoff Readiness

    • Gate Level and ECO Checks

    • Constraint Reviews

    Previous

    110 / 179

    Next: CDC Signoff Dashboard

    Up next

    Up nextCDC Signoff Dashboard

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Pre-Tapeout Gates
    • Review Checklists