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. Power and Warm-reset Interaction

Part 8 · RDC Signoff · All levels

Power and Warm-reset Interaction

How power domains, isolation, and warm resets interact with reset domains: the concepts.

On this page

    Resets do not act alone: power switching and warm resets move state at the same time, and each can undo the guarantees the other relies on. This lesson stays at concept level, because power intent Belongs to its own flow; the RDC engineer needs to know where the two flows collide.

    The three interactions

    Interaction

    What happens

    What RDC needs

    Isolation during power-down

    Isolation cells force boundary signals to safe values while a domain is off, which mimics reset without the reset tree moving.

    Neighbour domains must treat isolated inputs like reset-held inputs until the domain is powered and released in order.

    State retention across power cycles

    Retained registers keep their values through a power-down that resets their neighbours.

    After power-up, retained state and freshly reset state must be consistent; a reset that assumes all-zero neighbours is wrong.

    Warm reset without power cycle

    A logic-only reset re-initialises state while power, clocks, and analogue blocks stay up.

    The warm sequence must re-establish the same release ordering as a cold reset, even though the power-up sequence that enforced it never runs.

    Ordering across the collision

    Cold reset gets its ordering from the power-up sequence: supplies ramp, clocks stabilise, resets release in rank order. A warm reset skips the power-up part, so the ordering has to be enforced by the reset controller alone. The RDC intent therefore records warm reset as its own sequence with its own ranks, and structural analysis checks the warm path separately from the cold path.

    What the checks and the review look for

    The review asks for each power mode transition whether the reset state during and after it matches the intent, and for each warm reset whether its release order is stated and checked. A design whose RDC evidence covers only cold reset is half signed off: the warm and power-transition sequences need their own entries in the coverage questions.

    Common pitfall

    Assuming isolation makes RDC irrelevant across a power boundary hides the real check. Isolation controls values during power-down, but the power-up release ordering across the boundary still needs stating and verifying.

    Check yourself Why does a warm reset need its own release-order entry in the intent?

    Because cold-reset ordering rides on the power-up sequence, which a warm reset skips. Without its own enforced order, domains can release in an order the design never verified.

    Check yourself A retained register keeps its value while its neighbour resets. What consistency question must the review ask?

    Whether post-reset operation is correct with arbitrary retained values meeting freshly reset neighbours: the reset sequence must bring the pair to a consistent state, not assume both started at zero.

    Related topics

    • Hierarchical RDC

    • Chip-level RDC reviews

    • Reset coverage

    Previous

    129 / 179

    Next: Chip-level RDC Reviews

    Up next

    Up nextChip-level RDC Reviews

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Hierarchical RDC