Skip to main content

Reset Domain Crossing (RDC) Explained

 

Reset Domain Crossing (RDC) Explained: Complete Guide for ASIC Verification Engineers

Modern System-on-Chip (SoC) designs contain multiple clock domains and multiple reset domains. While engineers spend significant effort verifying Clock Domain Crossing (CDC), another equally critical challenge often goes unnoticed—Reset Domain Crossing (RDC).

Improper handling of reset signals can introduce hidden bugs that escape simulation and only appear in silicon, making them extremely expensive to debug. This article explains RDC from the ground up, covering its concepts, problems, synchronization techniques, design guidelines, and verification methodology.


What is Reset Domain Crossing (RDC)?

Reset Domain Crossing (RDC) occurs when a reset signal generated in one reset domain affects logic operating in another reset domain.

Unlike CDC, which deals with transferring data across clock domains, RDC focuses on the safe transfer and release of reset signals across independently controlled reset domains.

A design may contain several reset sources:

  • Power-On Reset (POR)
  • Watchdog Reset
  • Software Reset
  • Debug Reset
  • Peripheral Reset

Whenever logic driven by one reset interacts with logic controlled by another reset, RDC analysis becomes necessary.

Why is RDC Important?

Reset signals determine the initial state of digital circuits.

If reset is not released correctly:

  • Flip-flops may exit reset at different times.
  • Unknown values (X) may propagate.
  • State machines may start from illegal states.
  • Metastability can occur.
  • Functional failures may appear only after manufacturing.

Many silicon bugs are traced back to improper reset synchronization rather than logic design errors.

Understanding RDC with an Example

Consider two reset domains.


Here,
  • reset_a controls logic in Domain A.
  • reset_b controls logic in Domain B.
  • The reset signal crosses between independent reset domains.

If reset_b is released asynchronously while Domain B is running, some flip-flops may leave reset before others, causing unpredictable behavior.



Common Problems Caused by RDC

1. Metastability During Reset Release

The assertion of reset is usually safe because every register is immediately forced into a known state.

The real danger occurs during reset deassertion.

If reset is removed close to the active clock edge, a flip-flop may enter a metastable state.

Clock

 ─┐   ─┐   ─┐
  │    │    │
──┘────┘────┘──

Reset

──────────┐
          │
          └────

Release occurs near clock edge
↓

Metastability

2. Partial Reset

Some registers leave reset earlier than others.

Example:

Register A : Released
Register B : Still in Reset
Register C : Released

This creates inconsistent logic states.

3. Different Reset Release Times

Suppose an FSM contains five flip-flops.

If three registers release during one clock cycle and two registers release one cycle later, the state machine may begin in an illegal state.

4. Unknown State Propagation

Improper reset sequencing can generate unknown (X) values.

Reset Released

↓

Unknown State

↓

Combinational Logic

↓

Incorrect Outputs

5. Functional Failures

Improper RDC may cause:

  • Boot failures
  • Peripheral initialization errors
  • Deadlocks
  • Random system hangs
  • Silicon bring-up failures

Types of Reset



Golden Rule of Reset Design

The most widely accepted guideline is:

Assert reset asynchronously (if required), but always deassert it synchronously.

This combines the advantages of fast reset assertion with safe reset release.

Reset Synchronizer (2-Flip-Flop Synchronizer)

The most common solution for RDC is the 2-FF reset synchronizer.



How It Works

  1. Reset may deassert at any time.
  2. First flip-flop samples the reset.
  3. If metastability occurs, it is confined to FF1.
  4. Second flip-flop allows the signal an additional clock cycle to settle.
  5. The synchronized reset is then safely distributed throughout the domain.







Reset Synchronizer Variants

2-FF Synchronizer

Most widely used.

Suitable for:

  • General ASIC designs
  • FPGA designs
  • Medium-speed systems

3-FF Synchronizer

Adds another synchronization stage.

Benefits include:

  • Lower metastability probability
  • Better reliability
  • Preferred for safety-critical designs

Synchronizer with Feedback

Some designs include feedback logic that filters glitches before reset reaches the destination domain.

These are commonly used in:

  • Automotive chips
  • Aerospace systems
  • High-reliability ASICs

RDC Safe Design Practices

Good reset design follows several important rules.

Synchronize Reset Release

Never allow asynchronous reset release across domains.

Use Proper Synchronizers

Use dedicated reset synchronizer circuits rather than directly connecting resets.

Keep Reset Local

Distribute reset freely only inside a single reset domain.

Synchronize it only at the domain boundary.

Release All Flip-Flops Together

Registers belonging to the same functional block should exit reset simultaneously.

Avoid Combinational Logic




RDC Design Guidelines

A robust reset architecture generally follows these recommendations:

  • Use reset synchronizers whenever resets cross domains.
  • Keep reset synchronization local to each clock domain.
  • Avoid directly fanning out asynchronous reset across multiple domains.
  • Minimize combinational logic in reset paths.
  • Verify reset trees carefully.
  • Consider Power-On Reset (POR) separately from functional resets.
  • Review reset sequencing during architecture design.

RDC Verification

Verification is essential because reset bugs are often difficult to reproduce.

Typical RDC verification flow includes:

Identify Reset Domains

Determine every independent reset source in the design.

Find RDC Paths

Locate signals crossing between reset domains.

Check Synchronizers

Ensure every asynchronous reset crossing uses an approved synchronizer.

Verify Reset Deassertion

Confirm that reset is released synchronously within the destination clock domain.

Analyze Reset Tree

Review:

  • Reset fanout
  • Reset distribution
  • Reset buffering
  • Reset latency

Run Static RDC Analysis

EDA tools automatically detect unsafe reset crossings and synchronization issues.

Common tools include:

  • Siemens Questa RDC
  • Synopsys VC SpyGlass RDC
  • Cadence Jasper RDC

Perform Reset Simulations

Functional simulation should include scenarios such as:

  • Power-on reset
  • Warm reset
  • Software reset
  • Partial reset
  • Reset during active transactions
  • Random reset assertion/deassertion

These tests help expose corner-case issues before tape-out.

Bad vs Good RDC Design



Benefits:

  • Synchronous reset release
  • Reliable startup
  • Stable operation
  • Improved silicon robustness



Common RDC Issues

Some of the most frequently encountered reset-related problems include:

  • Using asynchronous resets across domains without synchronization
  • Missing reset synchronizers
  • Combinational logic in reset paths
  • Registers releasing reset at different clock cycles
  • Improper reset sequencing
  • Reset tree imbalance
  • Incomplete reset coverage
  • Reset glitches caused by gating logic

Best Practices for ASIC Designers and Verification Engineers

  • Plan reset architecture during the early design phase.
  • Minimize the number of independent reset domains.
  • Use dedicated reset synchronizers for every reset crossing.
  • Synchronize reset deassertion to the destination clock.
  • Keep reset distribution simple and well-balanced.
  • Verify reset behavior using both simulation and static RDC analysis.
  • Include reset scenarios in regression suites to improve verification coverage.

Key Takeaways

Reset Domain Crossing (RDC) is a critical aspect of modern ASIC and SoC design that ensures reset signals are transferred safely between independent reset domains. While reset assertion can often be asynchronous, reset deassertion should always be synchronized to the destination clock to prevent metastability and inconsistent initialization. Proper use of reset synchronizers, disciplined reset architecture, and thorough RDC verification significantly reduce the risk of silicon failures and improve overall system reliability.

As SoCs continue to grow in complexity with multiple power, clock, and reset domains, RDC verification has become just as important as Clock Domain Crossing (CDC) verification. A well-designed reset strategy is fundamental to building stable, reliable, and production-ready digital systems.

Comments

Popular posts from this blog

Module 1 — SystemVerilog Basics

VLSI Verification  •  SystemVerilog Series Module 1 — SystemVerilog Basics A complete, example-driven walkthrough of SystemVerilog fundamentals: data types, variables vs nets, arrays of every flavor, strings, enums, structs, unions, and typedef — the building blocks every verification engineer needs before UVM. 🧩 Beginner → Intermediate ⏱ ~25 min read 💻 Code Examples Included 📑 Table of Contents Introduction to SystemVerilog Verilog vs SystemVerilog Data Types: 2-State vs 4-State Logic Variables and Nets Arrays: Packed vs Unpacked Dynamic Arrays Queues Associative Arrays Strings Enumerations Structures Unions Typedef 1 Introduction to SystemVerilog SystemVerilog (IEEE 1800) is a unified hardware description and verification language (HDVL). It extends Verilog (IEEE 1364) with powerful constructs for design (interfaces, always_comb/always_ff, enhanced d...

GPU Memory System & Interconnect: How Data Travels Inside a Modern GPU

GPU Memory System & Interconnect: How Data Travels Inside a Modern GPU Modern GPUs deliver incredible computing power by processing thousands of operations simultaneously. While compute cores often receive the spotlight, the real performance of a GPU depends heavily on how efficiently data moves between memory and compute units. A GPU memory system is designed to provide extremely high bandwidth while keeping latency as low as possible. This is achieved through a collection of specialized hardware components working together, including the Memory Controller, HBM/GDDR memory, Crossbar, Network-on-Chip (NoC), DMA Engine, PCIe Interface, and NVLink. In this article, we'll explore each component in detail and understand how they collectively enable high-performance parallel computing. Why Does GPU Memory Matter? Every GPU application—from gaming and graphics rendering to AI model training and scientific simulations—requires continuous movement of enormous amounts of data. For examp...

Clock Domain Crossing (CDC): A Complete Beginner's Guide to Metastability, Synchronizers & Safe Data Transfer

Clock Domain Crossing (CDC): A Complete Beginner's Guide to Metastability, Synchronizers & Safe Data Transfer Modern System-on-Chip (SoC) designs rarely operate with a single clock. Instead, different modules such as CPUs, GPUs, memory controllers, communication interfaces, and peripherals often run at different clock frequencies or even use completely independent clock sources . When data moves from one clock domain to another, timing uncertainty can cause serious problems such as metastability , data corruption , and unpredictable system behaviour . This challenge is known as Clock Domain Crossing (CDC) . CDC is one of the most important topics in ASIC Design , RTL Design , ASIC Verification , FPGA Design , and SoC Architecture . Every modern chip—from smartphones to automotive processors—uses CDC techniques to ensure reliable communication between multiple clock domains. In this article, we'll explore CDC fundamentals, metastability, synchronization techniques, asynchro...

AXI Verification Interview Questions and Real-World Debugging

AMBA Protocol Series · Part 10 of 10 AXI Verification Interview Questions and Real-World Debugging Common protocol violations, how to read them off a waveform, and a curated set of interview questions with concise, correct answers — the capstone of the core 10-day series. AMBA Protocol Series: From APB & AHB to AXI — A Complete Guide for VLSI Engineers This wraps up the core 10-day series. Everything here draws directly on Days 1–9 — if any answer below feels unfamiliar, that's a good signal for which earlier post to revisit. (If you want to go further, see the 20-day extended list at the end of this post.) In This Article Common Protocol Violations Debugging From a Waveform Interview Questions and Answers Series Recap Extending the Series 1. Common Protocol Violations VALID deasserted before handshake — a source drops VALID before READY ever went high (violates the Day 8 stabi...

Cache Basics and Cache Mapping Techniques

  Cache Basics and Cache Mapping Techniques  Modern processors execute billions of instructions every second. However, processor speed has increased much faster than main memory (RAM) speed. This difference, known as the memory wall , creates a performance bottleneck because the CPU often has to wait for data from slower memory. To solve this problem, computer systems use cache memory —a small, high-speed memory located between the CPU and the main memory. In this article, we will understand the fundamentals of cache memory, the principle of locality, cache organization, and the three major cache mapping techniques. What is Cache Memory? Cache memory is a small, high-speed memory that stores copies of frequently accessed data from the main memory. Since accessing cache is much faster than accessing RAM, the CPU first checks whether the required data is available in the cache. If the data is found in the cache, it is called a cache hit . Otherwise, the CPU fetches the dat...

Timing Basics in Static Timing Analysis (STA): Delay Models, Sequential Timing, and Wire Delays

Timing Basics in Static Timing Analysis (STA) Static Timing Analysis (STA) is one of the most important verification techniques used in modern VLSI design. Before a chip is manufactured, engineers must verify that every signal reaches its destination within the required clock period. Even if a design passes functional simulation, it may still fail after fabrication because of timing violations. Unlike simulation, Static Timing Analysis mathematically analyzes every timing path without applying input test vectors. This makes STA significantly faster and capable of analyzing millions of timing paths efficiently. Table of Contents What is Static Timing Analysis? Why STA is Required Propagation Delay Contamination Delay Cell Delay Models Combinational Gate Delay Sequential Timing Setup Time Hold Time Wire Delay RC Delay Model PVT Corners Worked Examples Interview Questions Key Takeaways What is Static Timing Analysis? Static Ti...

Computer Architecture Interview Question Part 1

Skip to content Computer Architecture Interview Series Part 1 · CPU Basics · RISC vs CISC · ISA 50 Most Asked Computer Architecture Interview Questions (Part 1) The foundational round every VLSI, ASIC, and CPU design interview opens with: instruction set architecture, RISC vs CISC trade-offs, Von Neumann vs Harvard design, registers, endianness, and the fetch-decode-execute cycle — explained the way interviewers actually expect you to answer.  40 Questions (Q1–Q40) ⌛ 22 min read  VLSI & Computer Architecture Interviews On this page Foundations of Computer Architecture RISC vs CISC — Core Differences Von Neumann, Harvard & the Semantic Gap Architecture Styles, Endianness & Registers ILP, VLIW, Superscalar & Amdahl's Law Register Files, Microcontrollers & the Fetch Cycle Tip...