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
  • RDC Signoff16
    • RDC Methodology
    • Reset-aware Simulation
    • Chip-level RDC Closure
      • Hierarchical RDC
      • IP Integration Resets
      • Power and Warm-reset Interaction
      • Chip-level RDC Reviews
    • RDC Signoff Dashboard
  • Debug and Case Studies11
  • CDC and RDC Interview Prep30
  • Capstone: Sign Off a Multi-clock Peripheral4
Loading lesson

‹Chip-level RDC Closure
  1. Topics
  2. CDC & RDC
  3. RDC Signoff
  4. Chip-level RDC Closure
  5. Hierarchical RDC

Part 8 · RDC Signoff · All levels

Hierarchical RDC

Block-level reset analysis and integration: what must be exposed at the boundary.

On this page

    Analysing a full chip flat is slow and noisy, so teams analyse blocks first and integrate the results. That only works if each block exposes everything the integrator needs at its boundary. A block that is clean internally but silent about its reset assumptions pushes its risk to the top level, where it is hardest to fix.

    What each block must expose

    Boundary item

    Why integration needs it

    Reset ports with polarity and style

    The integrator must know which top-level reset each port joins and whether release is already synchronised inside.

    Assumptions on each reset input

    Minimum assertion time, required release order, and which clock the release is synchronised to.

    Guarantees on each reset output

    What the block drives while in reset and how it behaves at release, so neighbours can rely on it.

    Internal disposition summary

    Clean, or clean except for named findings with dispositions the integrator must honour.

    Clock and reset domain map

    Which internal domains each boundary signal Belongs to, so inter-block crossings are visible.

    What the integrator re-checks at the top

    Integration analysis covers what no block can see alone: reset crossings between blocks, the top-level reset tree from its sources to every block port, synchroniser placement across the boundary, and whether each block assumption is met by its actual connection. A block that assumes a synchronised release connected to a raw reset source is an integration defect, even though both sides looked clean alone.

    What the checks and the review look for

    Structural checks at the top level read the boundary models, not the block internals, so the review first audits the models: every block port mapped, every assumption stated, nothing defaulted. Then it reads the inter-block findings the same way as block findings: each one fixed, accepted with proof, or waived.

    Common pitfall

    Reusing a block in a new top level without re-checking its assumptions silently voids its signoff. The block was clean under its old assumptions; the new connections need a fresh assumption check even when the block RTL is untouched.

    Interview

    Expect: how do you sign off RDC hierarchically? Answer: blocks close against stated boundary assumptions, integration checks the connections and the top-level tree against those assumptions, and reuse re-checks assumptions rather than reusing the verdict.

    Check yourself A block assumes its reset input releases synchronised to clock X, but the top level connects a raw reset. Block verdict and integration verdict?

    The block verdict stands for the block as specified, but integration fails: the assumption is violated at the connection. Fix the connection with a synchroniser or change the block assumption and re-analyse.

    Check yourself Why must integration re-check synchroniser placement across block boundaries?

    Because a synchroniser inside one block may protect only that block. A crossing whose source and destination sit in different blocks can still release into an unprotected flop at the top level.

    Related topics

    • IP integration resets

    • Chip-level RDC reviews

    • RTL: Reset domain crossing

    Previous

    127 / 179

    Next: IP Integration Resets

    Up next

    Up nextIP Integration Resets

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Power and Warm-reset Interaction
    • Chip-level RDC Reviews