Articles
Reset Domain Crossing Interview Questions: Deassertion, Synchronizers, and Recovery
Practice reset domain crossing interview questions with staggered release traces, synchronizer limits, stopped clocks, partial reset, and recovery contracts.
Two blocks share a clock, but only one is reset during a recovery operation. Its output changes asynchronously while the other block keeps sampling. A second design synchronizes both reset releases, yet one block becomes active a cycle earlier and exposes inconsistent state. Reset domain crossing interview questions test both problems: electrical timing at the reset boundary and the protocol that makes recovering logic safe to use.
A useful starting point is to separate local reset release from system recovery readiness. A reset synchronizer addresses its specified local signal boundary. It does not automatically restore agreement about pending requests, ownership, or the validity of another domain's state.
Evidence boundary: AMD, Altera, and Siemens documentation supplies the official vendor facts linked below. The release ledger and recovery traces are original engineering exercises, not candidate reports or company-specific interview predictions. Practice the broader boundary reasoning with Design signals across power and clock domains.
Can there be RDC without a clock-domain crossing?
Official vendor guidance: Siemens explains that independent reset domains can create metastability and reconvergence issues, including cases involving different reset behavior within the same clock domain. See reset signal networks and RDC.
Original exercise: Source register A and destination register B use the same clock. A has an independently asserted asynchronous reset; B remains active. Resetting A can change its output outside the ordinary clocked data transition. B may sample that transition without the timing relationship expected for ordinary same-clock data.
Sharing the clock therefore does not establish a safe relationship for every transition on the path. The answer must name the source reset, destination reset, whether the destination remains active, and what protects it from observing an invalid or asynchronous source change.
If both registers are guaranteed held in reset during the event, the analysis differs. But “both reset at startup” is not proof of that guarantee for a warm reset, software reset, power-domain reset, or error-recovery sequence. The relevant contract covers all permitted reset combinations.
This is why copying a CDC checklist is insufficient. Clock-domain analysis concerns the relationship of clocks and data transfers; reset-domain analysis also needs reset relationships, assertion effects, and recovery ordering. One design can contain both kinds of crossing.
Why distinguish assertion from deassertion?
Official fact: AMD's XPM_CDC_ASYNC_RST documentation for UG953 version 2026.1 describes an output that asserts asynchronously and deasserts synchronously to the destination clock. Its number of stages also determines a minimum asserted output pulse width. See the asynchronous reset synchronizer macro.
Asynchronous assertion can put the covered registers into their reset state without waiting for a running clock, subject to the implementation's electrical requirements. Release must allow the recovering sequential logic to resume under its destination timing requirements. Do not describe the synchronizer as eliminating all metastability or all reset-tree timing work.
Original exercise: Domain B's clock is stopped while an external reset is released. A destination-clocked release chain cannot advance without destination clock edges. In the modeled scheme, local reset remains asserted until the clock resumes and the release sequence completes. “Wait two nanoseconds” cannot substitute for the required clock events.
A reset controller should specify whether clocks must be stable before release, how reset pulse requirements are satisfied, and how readiness becomes visible afterward. If a PLL lock signal participates, it is another signal with its own boundary behavior; it is not a magical asynchronous guarantee.
Official IP-specific example: Altera's AXI Streaming IP for PCI Express guide version 26.1 documents interface reset behavior relative to the interface clock. See Interface Reset Signals. Read the actual IP contract instead of assuming every block accepts your preferred reset polarity or release sequence.
Why can separate reset synchronizers reconverge unsafely?
Official fact: Altera's Quartus 21.3 rule RDC-50001 flags multiple asynchronous reset synchronizer chains from different reset domains reaching the same register. Its explanation warns that chains need not leave reset on the same clock cycle, so downstream logic can contain both active and reset data. See RDC-50001.
Original release ledger: Assume two related state producers feed downstream logic. Both use the same destination clock, but independently released resets. The table specifies a possible logical sequence; it does not predict an analog metastability waveform.
| Destination edge | A reset state | B reset state | Downstream interpretation |
|---|---|---|---|
| Edge 1 | Held | Held | Reset values only |
| Edge 2 | Released | Held | Active A state mixed with reset B state |
| Edge 3 | Released | Released | Both local states active; agreement still needs checking |
| Edge 4 | Released and initialized | Released and initialized | Transfer allowed only if the recovery contract is satisfied |
A and B can each have locally sensible reset release while their combined meaning is temporarily invalid. For example, A's valid indication might describe data whose index or ownership state in B still has a reset value.
The appropriate repair depends on the architecture. Related state may need a common release relationship, safe isolation, an initialization phase, or a protocol-level readiness exchange. Do not automatically duplicate synchronizers and then recombine their outputs as if their latency were guaranteed identical.
Adding one delay cycle can match a particular trace but leave the underlying contract unspecified. State what bounds the difference and what prevents consumption during that difference. Otherwise, a configuration change or reset sequence can reopen the same problem.
Does synchronizing reset protect all data paths?
Engineering inference: No blanket answer follows from the presence of a reset synchronizer. Inspect what the source can change while the destination remains active and how invalid values are prevented from influencing destination state.
A single-bit control might be protected by a suitable synchronization or handshake scheme. A multibit payload needs a consistency arrangement; independently synchronizing each bit does not establish one coherent message. Reset can invalidate a CDC protocol's assumptions even when its normal-operation transfer scheme is sound.
Consider a toggle-based event transfer. If resetting one endpoint changes its toggle to a default while the peer retains a previous value, the peer may interpret the change as an event. Conversely, an outstanding real event can disappear. The release synchronizer alone does not specify whether the protocol discards, replays, or reconciles that work.
A claim that isolation solves the crossing should identify when isolation is asserted, what values it clamps, and when it is safely removed. The clamping control and release sequence themselves must be valid at the receiving boundary. An uncontrolled combinational mask is not automatically a complete recovery solution.
Define a partial-reset recovery contract
Original exercise: Producer A submits commands to consumer B. A remains powered and active when B resets. Before reset, command 17 is outstanding. What should A do with its retained request after B recovers?
Choose and document a contract. Possibilities include discarding all outstanding work with an explicit failure response, replaying requests under a duplicate-handling rule, or restoring retained state consistently. The choice changes the required state machine and checks.
For an illustrative discard-and-restart contract, A blocks new submissions when B is unavailable. B initializes its local queue and advertises readiness for a new epoch. A retires prior outstanding work according to the error contract, observes the new readiness through an appropriate crossing mechanism, and only then starts new work.
| Recovery stage | A's responsibility | B's responsibility |
|---|---|---|
| B reset begins | Stop sending work that assumes B is active | Enter reset; expose safe boundary behavior |
| B's local reset releases | Continue blocking transfers | Initialize queue, counters, and protocol state |
| New readiness is communicated | Reconcile old outstanding work | Advertise valid initialized state |
| Recovery agreement completes | Submit only work belonging to the agreed epoch | Accept commands under the recovered contract |
An epoch tag is an optional design technique, not a universal requirement. If it is used, specify its width, reuse behavior, reset retention, and safe transfer. A stale completion must not become a valid new completion merely because a counter eventually wraps.
Official vendor guidance: Siemens' specification-driven RDC methodology begins with requirements and a verification plan, then design and verification, followed by results tracking. See A Specification-Driven Methodology for RDC Logic. The contract above is an original application of that requirements-first approach.
What should the verification plan exercise?
Original plan: Vary reset assertion and release relative to the receiving clock, permitted reset combinations, clock availability, and outstanding protocol work. These dimensions test different failure mechanisms; repeating the startup reset sequence many times does not cover them all.
Include a source-only reset while the destination runs, a destination-only reset with a pending request, overlapping resets, staggered releases, and a stopped destination clock. Exercise the documented minimum pulse behavior and reset polarity for the actual implementation. Also test release followed quickly by another reset.
For the command exercise, check that no transfer is accepted before readiness, old command 17 does not silently reappear as new work, and every retained outstanding request reaches a documented outcome. Check recovery completion under the stated assumptions, such as the clock eventually resuming and the peer remaining available.
Distinguish safety from liveness. “No transfer occurs while unready” is a safety condition. “The system eventually resumes” needs assumptions and progress evidence. A design that blocks forever can satisfy the former while failing the latter.
Digital simulation can expose ordering and protocol failures; an ordinary cycle model does not establish analog metastability probability or physical recovery/removal timing closure. Structural RDC analysis, timing analysis, formal checks, and simulation contribute different evidence. Record which mechanism each result checks and which evidence remains missing.
How should you explain an RDC waiver?
A reviewed waiver needs an explicit reason the path is safe or irrelevant under the supported reset sequences. Retain the path, reset relationship, configuration, isolation or handshake argument, assumptions, and evidence. A comment saying “same clock” does not answer the source-only asynchronous reset scenario.
If the justification assumes the destination is always reset first, identify the controller property establishing that sequence. If the justification assumes data is ignored until initialization, identify the gating logic and check that no downstream path bypasses it. If the path exists only in a disabled configuration, retain the configuration evidence.
Revisit the waiver after adding warm reset, clock gating, power management, or a new consumer. A previously valid startup-only assumption may no longer describe the system. Waivers are bounded reasoning attached to a design revision, not a permanent escape from review.
The release and recovery ledgers here were checked as executable logical models. No analog metastability experiment, commercial RDC run, or physical timing signoff was performed. Those limits matter when translating a good interview explanation into production verification evidence.
Five questions for reset-aware reasoning
Two verification-planning questions also appear in the functional coverage article because the question bank has limited direct ASIC planning material. Here they serve a different purpose: defining and checking reset sequences rather than counting coverage goals.
| Question | RDC reasoning to add |
|---|---|
| Design signals across power and clock domains | Specify isolation and readiness across partial reset. |
| Explain use cases for clock synchronizers | Explain what a synchronizer does and what protocol work remains. |
| ASIC Verification Fundamentals Across SystemVerilog UVM CDC and Architecture | Separate structural, timing, and functional evidence. |
| Verification Plan for a FIFO, a Round-Robin Arbiter and a Valid/Ready Handshake | Add source-only and destination-only reset cases. |
| Reason About Endianness, Ring Buffers, and Stack Behavior in Firmware | Explain retained ring ownership after device recovery. |
Continue with Design signals across power and clock domains. Draw the reset tree and one outstanding request, then stop a destination clock. Explain when local release, readiness, and the first valid transfer can occur.