Modern System-on-Chip (SoC) designs contain multiple functional blocks, clock domains and power domains. These blocks do not always start operating at the same time. Some may receive a global power-on reset, while others are reset independently during initialization, error recovery or power-management operations.
This creates a design challenge known as Reset Domain Crossing (RDC).
An RDC issue occurs when signals originating from logic controlled by one reset domain interact with logic controlled by another reset domain without adequate protection. Even when two blocks use the same clock, different reset assertion and deassertion sequences can cause unpredictable behavior.
For example, consider two IP blocks operating on the same 100 MHz clock. Block A is released from reset first, while Block B remains in reset for another few clock cycles. If Block A sends a status signal to Block B during this period, Block B may observe an invalid or unexpected value when it starts operating.
The problem is not necessarily related to clock frequency or clock phase. It is related to the different reset states and release sequences of the connected logic.
Understanding RDC is therefore important for RTL designers, SoC integration engineers and verification engineers working on reliable chip designs.
Reset Domain Crossing (RDC), What it means?
A reset domain is a group of registers or logic elements controlled by a particular reset signal or reset sequence.
An SoC may contain several reset domains, such as:
- A system-level reset domain.
- A processor reset domain.
- A peripheral reset domain.
- A memory-controller reset domain.
- Independently resettable power-domain logic.
When signals cross between these domains, engineers must ensure that the receiving logic does not capture invalid data or enter an unexpected state because the source and destination have different reset conditions.
Consider a simple example:
- Module A uses reset_a_n.
- Module B uses reset_b_n.
- Both modules operate using clk.
- reset_a_n is deasserted before reset_b_n.
Module A may start generating valid transactions while Module B is still held in reset. If the interface does not account for this difference, Module B may receive an unexpected control signal immediately after reset release.
This is an RDC concern.
Why Reset Synchronization Is Important
Reset signals determine the initial state of sequential logic. If reset is released at an unsuitable time, a flip-flop may experience a recovery or removal timing violation.
These timing requirements are particularly important for asynchronous reset inputs.
- Recovery time: The minimum time between reset deassertion and the next active clock edge.
- Removal time: The minimum time reset must remain inactive after an active clock edge.
If these requirements are violated, the flip-flop may enter a metastable condition or behave unpredictably.
The risk becomes more significant when an asynchronous reset is distributed to many registers. Even if the reset signal reaches all registers logically, routing delays and clock relationships can cause different registers to observe reset release at different times.
This can result in:
- Registers leaving reset inconsistently.
- State machines entering unexpected states.
- Invalid control signals appearing at module interfaces.
- Incorrect initialization of counters and status registers.
- Intermittent startup or recovery failures.
A reset strategy must therefore control not only when reset is asserted, but also how it is released.
Asynchronous Assertion and Synchronous Deassertion
One commonly used reset synchronization approach is asynchronous assertion with synchronous deassertion.
It provides two important behaviors:
Asynchronous assertion: Reset can become active immediately, without waiting for a clock edge. This is useful when the system must quickly place logic into a known reset state.
Synchronous deassertion: Reset is released only after the destination clock has captured the release condition through a synchronizer chain.
This reduces the risk of recovery and removal violations at the receiving registers.
Example: Two-Stage Reset Synchronizer
Consider a block operating on clk_a and receiving an active-low asynchronous reset called arst_n.
The following SystemVerilog example illustrates a two-stage reset synchronizer:
module reset_sync (
input logic clk_a,
input logic arst_n,
output logic rst_n_sync
);
(* ASYNC_REG = "TRUE" *) logic [1:0] sync_ff;
always_ff @(posedge clk_a or negedge arst_n) begin
if (!arst_n)
sync_ff <= 2'b00;
else
sync_ff <= {sync_ff[0], 1'b1};
end
assign rst_n_sync = sync_ff[1];
endmodule
How does this work?
- When arst_n becomes low, both synchronizer flip-flops are asynchronously cleared.
- When arst_n becomes high, the first flip-flop captures logic 1 at the next rising edge of clk_a.
- The second flip-flop captures the first stage's output on a subsequent rising edge.
- After the second stage becomes high, rst_n_sync is deasserted.
Therefore, the local reset remains active until the destination clock has provided the required synchronization cycles.
The ASYNC_REG attribute is a commonly used implementation hint for identifying synchronizer registers. Its exact syntax and handling depend on the synthesis and implementation tools being used.
Important: This is an illustrative two-stage structure. Actual reset architecture must account for the target technology, reset polarity, minimum reset pulse width, clock availability, reset-tree implementation and design methodology. A synchronizer does not eliminate metastability; it reduces the probability that metastability propagates into downstream logic.
Reset Release Across Multiple Clock Domains
A common mistake in SoC integration is using one synchronized reset signal for several unrelated clock domains.
Suppose a chip contains:
- clk_cpu for the processor.
- clk_peripheral for peripheral logic.
- clk_memory for the memory controller.
These clocks may have different frequencies and may not have a fixed phase relationship.
If all three blocks use one reset synchronizer driven by clk_cpu, the reset release may not be properly aligned with the receiving clock edges in the peripheral and memory domains.
A safer architecture generally uses a separate reset synchronizer for each destination clock domain.
For example:
Block | Clock | Local reset |
CPU | clk_cpu | cpu_rst_n |
Peripheral | clk_peripheral | peripheral_rst_n |
Memory controller | clk_memory | memory_rst_n |
Each local reset is released using its corresponding destination clock.
The reset controller may coordinate the overall sequence, but each clock domain should receive a reset release that is safe for its own clock.
This becomes particularly important when a clock is stopped during power management. A synchronously deasserted reset cannot complete its release sequence until the destination clock is running. The power-up or wake-up sequence must therefore ensure that the clock is available before reset release is expected.
Common RDC Scenarios in Real SoC Designs
RDC problems are not limited to power-on reset. They can occur during normal operation when individual blocks are reset independently.
Scenario 1: One Block Is Reset While Another Remains Active
Consider a processor subsystem connected to a peripheral controller.
The peripheral controller is reset because of an internal error, but the processor remains operational. If the peripheral's output signals are not placed into safe states, the processor may continue receiving stale valid, interrupt or status signals.
Design consideration: Define the interface behavior during reset. Signals such as valid, request, interrupt and ready should have documented reset behavior. The receiving block should not treat stale outputs as valid transactions.
Scenario 2: Different Reset Release Times
Suppose a source block and destination block use the same clock but independent resets.
The source block starts operating first and changes its output state. The destination block is released later and captures that signal.
If the source output is not valid for the destination's startup sequence, the destination may enter an incorrect state.
Design consideration: Use reset sequencing, interface isolation or valid-ready control so that communication begins only when both sides are ready.
Scenario 3: Power-Domain Shutdown and Wake-Up
In a low-power SoC, one power domain may be switched off while other domains remain active.
When the domain powers up again, its internal registers may need reset or retention restoration. Signals from the powered-down domain must not be interpreted as valid by active logic.
Design consideration: Coordinate reset release with power-good indication, isolation control and retention restoration. Reset synchronization alone does not replace power-domain sequencing.
How to Perform RDC Verification
RDC verification checks whether reset-dependent signal crossings are safe under the reset sequences defined by the architecture.
A practical verification process includes the following steps.
Step 1: Identify Reset Domains
Create a reset-domain map that records:
- Reset signals and their polarities.
- Registers controlled by each reset.
- Clock domains associated with the registers.
- Asynchronous and synchronous reset behavior.
- Independent reset and power-management conditions.
This information helps identify potential crossings between independently controlled logic.
Step 2: Analyze Reset Relationships
Check whether two connected blocks share the same reset source and release sequence.
If they do not, examine the signals crossing between them. Pay particular attention to control signals, state outputs, handshake signals and status indicators.
Step 3: Run Static RDC Analysis
Static RDC tools analyze the RTL structure and reset relationships to identify potentially unsafe crossings.
Depending on the tool and methodology, reports may identify:
- Signals crossing between different reset domains.
- Missing or incorrectly structured reset synchronizers.
- Reset-dependent reconvergence paths.
- Potential metastability propagation.
- Unsafe reset interactions between sequential elements.
A flagged crossing is not automatically a functional bug. Engineers must examine the source and destination logic, reset intent, interface protocol and applicable constraints before deciding whether to fix or waive it.
Step 4: Review Reset Synchronizer Structures
Check whether reset synchronizers are correctly connected to the intended destination clocks and whether their outputs drive the appropriate local logic.
Also review whether synchronizer stages are preserved during implementation and whether reset release is consistent with the clock and power-up sequence.
Step 5: Verify Reset Sequences Through Simulation
Simulation should cover more than the initial power-on reset.
Useful test scenarios include:
Test scenario | Expected behavior |
Global reset assertion | All intended blocks enter their reset states |
Independent block reset | Unaffected blocks continue operating safely |
Different reset release times | Interfaces remain safe until both sides are ready |
Reset during an active transaction | Transaction recovery follows the interface specification |
Reset while clock is stopped | Reset release waits for the required clock activity |
Power-down and wake-up | Isolation, retention and reset sequencing operate correctly |
Step 6: Add Assertions for Reset-Dependent Behavior
SystemVerilog Assertions (SVA) can check important reset conditions.
For example, suppose rst_n_sync is the active-low local reset and out_valid must remain low while the block is in reset.
property valid_low_during_reset;
@(posedge clk_a)
!rst_n_sync |-> !out_valid;
endproperty
assert property (valid_low_during_reset);
This assertion checks that out_valid is low whenever the sampled local reset is active.
The assertion must be adapted to the actual interface specification. For example, some outputs may be intentionally retained or may have different reset values. Assertions should verify the documented behavior rather than impose an assumed reset value on every signal.
For broader RTL verification, reset scenarios should also be combined with functional traffic, error recovery and power-management sequences.
Tools and Practical Skills Used in RDC Analysis
RDC analysis is commonly performed as part of RTL quality checks, CDC analysis and SoC integration signoff. Engineers use static analysis tools to inspect reset relationships, identify unsafe crossings and review reported violations.
For example, the InSkill Lint and CDC training includes reset synchronizer and RDC topics alongside CDC analysis and hands-on tool exercises. The RTL Design and Integration training also covers reset synchronization, RDC, linting, CDC and integration-related design checks.
The objective is not simply to clear tool violations. Engineers must understand why a crossing is reported, determine whether it is genuinely unsafe and implement a solution that preserves the intended reset architecture.
Conclusion
Reset Domain Crossing is an important part of reliable RTL design and SoC integration. Different blocks may use independent reset signals, different release sequences and separate power-management controls. Without a well-defined reset strategy, signals can cross between blocks before the receiving logic is ready to process them.
Asynchronous assertion with synchronous deassertion, destination-specific reset synchronization, controlled reset sequencing and interface-level protection are important techniques for reducing these risks.
For RTL and verification engineers, the key is to combine correct reset architecture with static RDC analysis, simulation-based reset testing and assertions. This helps identify reset-related issues before they become difficult-to-reproduce silicon problems.