RDC Interview Questions for VLSI Interviews

I’ve compiled 35 reset domain crossing (RDC) interview questions from real conversations with senior engineers at Nvidia, Qualcomm, Intel, and the design teams I’ve worked with over the past decade. Reset design is where many strong candidates stumble — it’s one of those topics that feels simple until you’re debugging a silicon issue at 2 AM caused by improper reset sequencing. This guide covers what interviewers actually test for, from synchronizer fundamentals to low-power reset strategies and formal verification sign-off.

Quick Navigation

• Section 1: Reset Fundamentals (Q1–Q8)
• Section 2: Reset Synchronization (Q9–Q18)
• Section 3: Low-Power Reset (Q19–Q27)
• Section 4: Advanced RDC & Sign-Off (Q28–Q35)
• Interview Cheatsheet

Section 1: Reset Fundamentals

Q1. What is RDC and why does it matter? How is it different from CDC?

Reset Domain Crossing (RDC) analysis ensures that asynchronously asserted resets are properly synchronized before deassertion in each clock domain. CDC (Clock Domain Crossing) ensures data signals crossing clock domains are metastably hardened; RDC ensures reset signals themselves don’t violate setup/hold timing or cause metastability.

Here’s where most candidates get this wrong: they think RDC is just “a type of CDC problem.” It’s not. Reset is special because it’s asynchronous — it must assert immediately (no synchronization on assert), but must deassert synchronously to avoid reset removal time violations. CDC tools check data paths; RDC tools (SpyGlass RDC, JasperGold RDC) check reset network topology, synchronizer insertion, and timing. They require different verification strategies.

Q2. Synchronous vs asynchronous reset — advantages and disadvantages of each. Show code examples for both.

Synchronous reset is applied at the clock edge (like a normal input); asynchronous reset takes effect immediately, independent of the clock. Each has trade-offs that determine where it’s appropriate.

Synchronous Reset (Verilog):

always @(posedge clk) begin
  if (reset_sync) begin
    data_q <= 32'h0;
  end else begin
    data_q <= data_d;
  end
end

Asynchronous Reset (Verilog):

always @(posedge clk or negedge reset_async_n) begin
  if (!reset_async_n) begin
    data_q <= 32'h0;
  end else begin
    data_q <= data_d;
  end
end

Asynchronous reset is standard in modern SoC design because power-on reset is inherently asynchronous — at power-up, the clock may not even be running. However, that asynchronous deassertion must be synchronized, or you'll violate reset removal time.

Q3. Why is active-low reset the convention in CMOS design?

Active-low reset (reset_n or RST_N) is the standard because NMOS pull-down transistors are smaller and faster than PMOS pull-up transistors for the same drive strength. An active-low reset can be asserted by pulling a wire to ground (through a small transistor or external button), requiring minimal area.

In practical chip design, during power-on, the supply voltages rise from zero. An active-high reset signal (relying on VDD) wouldn't reliably assert when VDD is still ramping — it's undefined. An active-low reset, by contrast, can be held at ground by a simple NAND gate or transistor network from an external POR circuit, and will assert as soon as VDD begins to rise. This is why POR circuits universally drive active-low reset.

Q4. What is a reset glitch? How does it cause problems? Show a timing diagram.

A reset glitch is a transient pulse on the reset signal — typically caused by voltage overshoot during power ramp-up, or noise injection on a poorly buffered reset tree. If a glitch is narrow enough, it might deassert reset in one flop's domain before the flop latches the reset value, leaving that flop in an inconsistent state.

For example, if a reset glitch arrives just before a clock edge, a flop intended to be held in reset might instead sample its D input, corrupting initialization. This is especially dangerous in JTAG TAP state machines, where improper reset leaves the controller in an undefined state and can prevent subsequent scan operations.

Clock:    _|‾|_|‾|_|‾|_|‾|_|‾|_|‾|_|‾|_
Reset_n:  ‾‾‾‾‾_______|‾‾|_____________  ← glitch pulse
             ↑       ↑   ↑
          assert   glitch deassert

Expected behavior: flop reset until next clock edge
Actual: glop may see glitch and incorrectly latch data

Q5. What is Power-On Reset (POR)? How is it generated on chip?

Power-On Reset (POR) is the circuit that asserts reset during the power-up transient and deasserts it once supply voltages have stabilized. Without POR, flops might not reset to a known state during power-up, causing silicon to come out of reset in a random state.

A typical POR circuit uses a current-starved inverter chain or a comparator that monitors the supply voltage (VDD). During power-up, VDD is below a threshold (e.g., 0.5V), and the POR circuit drives reset_n low. As VDD rises above the threshold, POR releases reset, allowing the logic to begin operation. Modern SoCs also include a power-good signal (PWRGOOD) that cross-references the POR output, ensuring all supplies are stable before reset is released.

Q6. What is reset recovery time and reset removal time? Show a timing diagram.

Reset recovery time is the minimum time between reset deassertion and the next active clock edge. Reset removal time is similar but often refers to the time between reset release and when the next flop is guaranteed to sample the new input correctly.

If reset is released too close to a clock edge, the flop's reset logic might not have time to propagate the reset value to the slave latch before the clock samples it. This causes a timing violation and unpredictable behavior. Modern static timing analysis (using tools like PrimeTime) checks these violations as part of the "reset timing" analysis phase.

Clock:         _|‾|_|‾|_|‾|_|‾|_|‾|_|‾|
Reset_n:       ‾‾‾‾‾‾_________|‾‾‾‾‾‾
Reset_n Q:     -----------→ metastable → 1
                       ↑                 ↑
                    violation!        recovers

Recovery time (tREC) = time from reset release to clock edge
If tREC < spec (typically 1-2ns), flop behavior is undefined

Q7. What happens if reset recovery or removal time is violated?

A reset recovery/removal time violation causes metastability in the flop's output. The flop's reset logic (typically a cross-coupled NAND or NOR latch) is forced out of equilibrium, and the output voltage settles between 0 and 1, creating an indeterminate state.

In simulation, this appears as an 'X' (unknown) value. In silicon, the metastable output may oscillate briefly, then settle to 0 or 1 unpredictably. If this metastable output feeds a combinational path to other logic, multiple flops may see conflicting values, causing logic errors, state machine deadlocks, or system hangs. In high-speed designs, this is catastrophic — recovery violations must be eliminated before tape-out.

Q8. Reset fanout considerations — why is a buffered reset tree important?

Reset is the highest-fanout signal in any design — it connects to the reset pin of every flop, sometimes numbering in the millions. A single unbuffered reset signal cannot drive this load without excessive skew, delay, and power dissipation.

A buffered reset tree (similar to a clock tree) distributes reset through hierarchical buffers, reducing skew and transition time. Good reset tree design ensures reset reaches all domains within a bounded time window, and that recovery/removal timing is met globally. Poor reset trees cause skew-induced recovery violations in some flops while other flops release reset early.

Section 2: Reset Synchronization

Q9. What is a reset synchronizer? How does it work? Show a timing diagram.

A reset synchronizer is a 2-flop cascade that synchronizes an asynchronously asserted reset signal before it's released into a clock domain. The first flop catches the asynchronous deassertion and goes metastable; the second flop allows metastability to settle before the synchronized output is used.

The circuit works like this: async reset is asserted immediately (first flop's reset pin goes low), but when reset is released, the first flop's output is metastable. The second flop, clocked a cycle later, samples this potentially metastable output and (with high probability) resolves to a stable 0 or 1. By the time the second flop's output is used as the domain's synchronized reset, metastability has been resolved and no timing violations can occur.

Clock:      _|‾|_|‾|_|‾|_|‾|_|‾|_|‾|_|‾|_
Reset_n:    ‾‾‾‾‾____|‾‾‾‾‾‾‾‾‾‾‾‾‾

Flop1 Q:    ‾‾‾‾‾____X???X???‾‾‾‾‾‾‾  ← metastable

Flop2 Q:    ‾‾‾‾‾‾‾‾‾‾‾???X???‾‾‾‾  ← metastable one cycle later

Sync_Rst:   ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾     ← clean output

Key: by time Flop2_Q is used as reset, all metastability is resolved

Q10. Why is synchronous deassertion of reset critical? What happens without it?

Without synchronous deassertion, you have an asynchronous reset signal feeding logic clocked in multiple clock domains. Some flops will see reset release just before their clock edge and go metastable; others will see it after and reset cleanly. This creates unpredictable behavior: some flops are in a reset state, others are not, even though they should all be reset together.

The practical failure mode: after power-up or a soft reset, some parts of the design initialize correctly while others don't. State machines might be in undefined states, FIFO pointers might be corrupted, and the system exhibits intermittent, hard-to-debug failures. This is a classic silicon bug that often requires a silicon spin to fix.

Q11. Show the reset synchronizer circuit in Verilog (2-flop synchronizer).

Here's the standard 2-stage reset synchronizer. The first flop catches the async reset; the second resolves metastability:

module reset_synchronizer (
  input  clk,
  input  async_reset_n,
  output reset_n_sync
);

  reg sync_stage1, sync_stage2;

  // Stage 1: catch async reset, can go metastable
  always @(posedge clk or negedge async_reset_n) begin
    if (!async_reset_n)
      sync_stage1 <= 1'b0;
    else
      sync_stage1 <= 1'b1;
  end

  // Stage 2: resolve metastability
  always @(posedge clk or negedge async_reset_n) begin
    if (!async_reset_n)
      sync_stage2 <= 1'b0;
    else
      sync_stage2 <= sync_stage1;
  end

  assign reset_n_sync = sync_stage2;

endmodule

This is simple but effective. The async_reset_n directly resets both stages (allowing immediate assertion), but the synchronized output comes from stage 2, which has one full clock cycle to resolve metastability after reset is released.

Q12. What is a multi-stage reset synchronizer? When is it used?

A multi-stage (typically 3 or 4-stage) reset synchronizer adds more flops to the chain, giving more time for metastability to resolve. It's used in very high-frequency designs (multi-GHz) where the MTBF (mean time between failures from unresolved metastability) of a 2-stage synchronizer is unacceptable, or in designs with tight timing margins where reset must be highly synchronized.

The trade-off: more stages mean longer latency for reset propagation (one additional cycle per stage). In most designs, 2 stages is sufficient — the metastability window is so narrow that the probability of failure is already extremely low. However, aerospace/automotive safety-critical designs or very aggressive frequency targets often require 3+ stages.

Q13. What are reset domains in SoC design?

A reset domain is a region of logic that shares a common synchronous reset signal. Unlike clock domains (defined by the clock input), reset domains are defined by the reset signal that controls them. A single clock domain may span multiple reset domains if different parts of the design have independent resets (e.g., functional reset vs. JTAG reset).

In a typical SoC, you might have: (1) a global reset applied to the whole chip, (2) domain-specific resets for each clock domain (requiring synchronizers between them), and (3) special resets for debug/test (TRST). Each interface between reset domains requires a synchronizer to ensure timing correctness.

Q14. How do you handle reset when two clock domains use different resets?

Insert a reset synchronizer at the domain boundary. If clock domain A has reset_a and domain B has reset_b, and they are asynchronous relative to each other, then any logic that must be synchronized to domain B should use reset_b synchronized to domain B's clock, not reset_a.

More concretely: if you have a FIFO with read-side in domain B and write-side in domain A, the read pointer resets with reset_b synchronized to the read clock. The write pointer resets with reset_a synchronized to the write clock. This ensures each pointer is properly reset in its own domain without violating reset removal timing.

Q15. How do you flush a FIFO on reset? (both pointers reset, isolation)

When reset asserts in a FIFO, both the read and write pointers must reset to the same value (typically 0) so the FIFO is empty. If you're in a dual-clock FIFO, the read pointer resets on the read clock and read reset, while the write pointer resets on the write clock and write reset — but they must reset to the same initial value.

The logic is straightforward: connect the flops holding the pointer values to the appropriate reset signal. When reset asserts, the pointers go to 0. The more subtle issue is isolation: after reset, the FIFO might have garbage in the memory array, so you should disable read/write operations until reset has fully propagated. Some designs use a reset_done flag that goes high several cycles after reset deassertion, gating the read/write control signals.

Q16. What is reset isolation in low-power designs?

Reset isolation prevents reset from propagating into power-gated domains after they've been powered down. When a power domain is turned off, it loses its supply voltage, and all flops lose their state. If a reset signal from the always-on domain reaches a flop in the powered-off domain, it's meaningless — the flop has no power anyway.

Reset isolation cells (similar to isolation cells in the data path) physically disconnect the reset signal from the powered-off domain. When the domain powers back up, the retained values (in retention flops) or reset values are restored. This prevents spurious reset events in the powered-down domain and keeps the reset tree clean.

Q17. Reset in CDC contexts — what happens to data in flight when reset asserts?

When reset asserts while a CDC synchronizer is in flight, the first flop of the synchronizer (the one catching the asynchronous data) is reset to a defined value (usually 0). This breaks the CDC synchronizer's invariant — the data being synchronized is lost.

In well-designed systems, reset assertion is orchestrated so that data transfers complete (or are flushed) before reset hits. For example, in a FIFO-based datapath, you'd drain the FIFO before asserting reset. If you can't guarantee clean reset, then use a "reset_done" signal: don't allow new transactions to enter CDC synchronizers until several cycles after reset deassertion, giving any in-flight data time to propagate through.

Q18. What is reset sequencing in SoC? (power-up sequence, dependency ordering)

Reset sequencing defines the order in which different resets are asserted and released during power-up. For example, in a multi-supply SoC, you might require that the core voltage (VDD_core) stabilizes before the IO voltage (VDD_IO), and reset for IO logic shouldn't be released until both supplies are stable.

This is managed by the reset controller and POR circuit. The reset controller monitors supply voltages (via power-good signals) and only releases domain-specific resets when the prerequisites are met. Improper sequencing (e.g., releasing reset before the supply voltage has stabilized) can cause flops to operate in the undefined region and leads to silicon failures.

Section 3: Low-Power Reset

Q19. How does power gating affect reset? What must happen when a domain powers back on?

When a power domain is gated off, it loses its supply voltage, and all state is lost (unless held in retention flops). The flops have undefined states, and the reset signal becomes irrelevant — the domain is already "reset" by virtue of being powered down.

When the domain powers back on, you must re-initialize the state. This is done via: (1) a power-up sequence that releases reset after the supply stabilizes, or (2) explicit retention flops that preserve critical state across power-down. The reset signal for the powered-on domain must be synchronized to the domain's clock and released cleanly, or you'll see reset removal violations in the newly powered-on logic.

Q20. What are retention flip-flops? How does reset interact with them?

Retention flops are special flip-flops with an additional "retention" port. When power is about to be gated off, the retention signal is asserted, freezing the flop's output at its current value. The flop's storage nodes are powered by a "sleep" supply (always-on power), so the state survives power-down.

Reset interaction: when reset is asserted in a domain that will be powered down, retention flops reset normally (to the reset value specified in RTL). When the domain wakes up, retention flops don't reset — they restore their retained values. This creates a controlled power-down/power-up sequence: reset in the powered-down state, but restore in the powered-up state.

Q21. Isolation cell behavior during reset assertion

Isolation cells (also called "level shifters" or "isolation logic") sit at the boundary between powered and unpowered domains. Their job is to prevent undefined logic levels from propagating from the powered-down domain to the powered-up domain.

During reset assertion in a powered-up domain that drives into a powered-down domain, the isolation cell is configured to block the signal and hold a safe value (usually the inactive state). This prevents reset-induced glitches from causing spurious behavior in the powered-down domain. When the powered-down domain wakes up, the isolation cell is released and normal signaling resumes.

Q22. Always-on (AON) reset domain — why is it critical?

The always-on (AON) domain is powered 24/7 and never powers down. It includes the POR circuit, reset controller, power management unit (PMU), and sometimes real-time clock (RTC). Reset and power sequencing are controlled by the AON domain, so it must always be operational.

The AON domain has its own reset (usually a synchronized version from POR), and this reset cannot be gated by power-down logic — that would create a deadlock where the domain powering back up has no reset control. Every SoC with power gating has a clear AON strategy; interviewers will ask about this if your design uses power gating.

Q23. UPF reset specifications — power_switch, isolation, retention strategies

Unified Power Format (UPF) is the standard language for power specification. It includes directives for power switches, isolation cells, and retention flops. Within UPF, you specify which flops are retention flops, which domains have isolation cells, and which reset signals apply to which domains.

Example UPF directives (conceptually):

create_power_domain CPU -include_scope
set_domain_reset_control CPU -reset reset_sync_cpu
create_domain_specification CPU
  add_ip_instance my_cpu_ctrl {...}

create_power_switch cpu_switch -domain CPU -control_signal power_ctrl
create_isolation_cell iso_cell -domain CPU -isolation_signal iso_en

set_retention my_status_flop -retention_power retention_supply
set_retention_state my_status_flop -retention_value 1'b1

The reset controller in UPF ensures that resets are released in the correct order and at the right times relative to power sequencing.

Q24. Power-aware DFT and reset — scan chain reset design

In designs with scan-based DFT, the scan chain must also be reset properly. Scan flops are usually regular flops with added scan mux logic, and they reset the same way as functional flops. However, if scan chains cross power domains, scan reset must be sequenced correctly — you can't load a scan pattern into a powered-down domain.

The solution: scan chains are usually kept within a single power domain, or scan muxes are held in a safe state during power-down. Some designs use separate scan reset signals (test_reset_n) that are independent of functional reset, allowing full chip scan patterns to be loaded before functional reset is released.

Q25. Reset network analysis using SpyGlass RDC

SpyGlass RDC (by Synopsys) is the industry-standard tool for RDC sign-off. It analyzes the reset network topology to verify: (1) every flop in every clock domain has an appropriate reset, (2) reset synchronizers are correctly implemented (2-flop, no combinational logic in between), (3) reset timing is met (recovery/removal), and (4) reset doesn't create combinational loops or glitches.

The tool checks constraints like "which reset signals are asynchronous?" and "which flops are in which clock domain?" then ensures proper synchronization. A common finding: "asynchronous reset not synchronized" — means a reset signal asserted asynchronously is used directly in a domain without passing through a synchronizer.

Q26. Reset glitch width requirements for reliable operation

A reset glitch is tolerable if its width is significantly smaller than the setup/hold window of the affected flop. Most flops have setup times of 100–500 ps, so glitches narrower than ~50 ps might not affect operation. However, if a glitch is 1 ns or wider, it can definitely cause a reset violation.

Practical consideration: the POR circuit and reset tree should be designed to avoid glitches altogether. If glitches are unavoidable (e.g., from process noise), the reset tree should be buffered to filter them out. Tools like Innovus can measure reset slew and identify potential glitch issues during physical design.

Q27. Multi-supply reset — what happens if VDD2 powers up before VDD1?

In multi-supply designs, if a secondary supply (VDD2) powers up before the core supply (VDD1), the logic powered by VDD2 begins operation while the core logic is still dark. This can cause: (1) the secondary domain to try to communicate with the unpowered core domain (undefined behavior), or (2) current to leak from VDD2 into VDD1 through poorly designed isolation cells.

The solution: use power sequencing to ensure VDD1 rises before VDD2, and use POR circuits that monitor all supplies. Once all supplies are stable (via power-good signals), reset is released. Improper supply sequencing is a classic low-power design bug that requires silicon debug to resolve.

Section 4: Advanced RDC & Sign-Off

Q28. RDC formal verification — what does JasperGold RDC check?

JasperGold RDC (by Cadence) performs formal verification of reset properties. It checks: (1) reset synchronizers are correctly implemented (checks that there's no combinational logic between the two stages), (2) all flops are properly reset, (3) there are no combinational loops involving reset, and (4) resets are asserted and released correctly relative to clock edges.

Unlike static analysis (SpyGlass), JasperGold uses formal methods to mathematically prove properties. For example, it can prove that "if reset is asserted, all flops will be in their reset state within N cycles." This is stronger than static checks and can catch subtle issues that simulation might miss.

Q29. What is a reset storm? How do you avoid it?

A reset storm is when reset is asserted and released multiple times in rapid succession, often due to glitches on the reset signal or improper reset sequencing. Each assertion can cause state loss, and if the storm continues, the chip never fully initializes.

Prevention: (1) ensure the POR circuit has hysteresis, so once VDD crosses the threshold, it doesn't dip back below it, (2) use a reset filter (delay line) that requires the supply to be stable for several milliseconds before releasing reset, and (3) in software, implement a watchdog timer that resets the chip if it detects abnormal behavior, but with enough time for initialization.

Q30. Watchdog timer reset design — requirements and pitfalls

A watchdog timer (WDT) periodically checks that firmware is alive (by reading a "kick" register within a timeout window). If the firmware hangs, the WDT fires and asserts a reset. The WDT itself is often in the AON domain, powered continuously so it can monitor the main logic.

Pitfall 1: the WDT reset can trigger a reset storm if the firmware hangs during reset recovery, creating an infinite reset loop. Pitfall 2: improper reset sequencing between the WDT and the main logic can cause the system to hang in reset. Pitfall 3: the WDT reset must be synchronized to the main clock domain to avoid reset removal violations.

Q31. JTAG TAP reset (TRST) — how it interacts with chip reset

TRST (Test Reset) is the reset signal for the JTAG Test Access Port (TAP), often independent of the main chip reset. TRST asynchronously resets the TAP state machine to the Test-Logic-Reset state. The TAP state machine must be independent of the main logic to allow scan operations even when the main logic is in an undefined state.

However, in SoC design, TRST sometimes affects the main reset logic — for example, after a JTAG reset, the TAP controller can assert the main reset. The interaction must be carefully specified so that: (1) JTAG can recover from errors without resetting the whole chip, and (2) JTAG can assist in reset recovery if the main logic is stuck.

Q32. Reset in multi-chip systems — board-level reset sequencing

In systems with multiple chips (e.g., SoC + FPGA + power management IC), reset must be coordinated across chips. Typically, a board-level POR circuit (or the main SoC's POR) asserts reset on all chips simultaneously. However, if reset lines have different lengths or termination, skew can occur, causing some chips to release reset before others.

Solution: synchronize resets at each chip's boundary using local synchronizers, and implement board-level reset sequencing where one chip's reset is derived from another's (e.g., FPGA reset is asserted only after SoC reset is released).

Q33. Software-triggered reset vs hardware reset — SoC reset controller design

Hardware reset (POR or external reset button) is asynchronous and immediate. Software reset (warm reset) is triggered by firmware writing to a reset register in the reset controller, allowing for a more controlled shutdown before the chip is reset.

The reset controller is usually in the AON domain and includes a reset register that, when written, sequences a reset operation: (1) notifies all subsystems to prepare for reset, (2) waits for acknowledgments, (3) asserts the reset signal, and (4) handles the reset sequence. Improper software reset can leave devices in inconsistent states, so the register is usually write-protected and requires a specific unlock sequence.

Q34. How do you verify reset correctness in simulation?

Reset verification in simulation involves: (1) asserting reset at the beginning of each test, verifying all flops go to known values, (2) releasing reset and checking the first valid state is reached, (3) running transactions, then asserting reset mid-transaction to verify state is properly cleaned up, and (4) checking that reset assertion doesn't corrupt in-flight CDC or FIFO operations.

Test scenarios include: power-up reset, warm software reset, reset during active transactions, and reset while clocks are running vs. stopped. A good testbench includes a reset_verify check that asserts all expected flops are in their reset state, catching incorrect reset hookups.

Q35. RDC sign-off checklist — what must be green before tapeout?

Before tapeout, RDC sign-off requires: