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

  • RTL Foundations36
  • Combinational Design25
  • Sequential Design27
  • FSM & Control27
  • Timing & Clocking39
  • Reset & CDC34
    • Reset Architecture
    • Metastability and Synchronisation
    • Asynchronous FIFO
    • CDC Protocols
    • Reset Domain Crossing
      • RDC Is CDC Plus Reset Asymmetry
      • Reset Isolation Pattern
      • Quiescent State Before Reset Release
      • RDC Signoff Checklist
      • Recovery, Removal and Verification Focus
    • CDC Verification
  • Memory & Buses57
  • Advanced RTL28
  • Senior & Interview76
  • Glossary and Notation
Loading lesson

‹Reset Domain Crossing
  1. Topics
  2. RTL Design
  3. Reset & CDC
  4. Reset Domain Crossing
  5. Quiescent State Before Reset Release

Part 6 · Reset & CDC · Intermediate

Quiescent State Before Reset Release

Why the sender waits for the receiver ready flag before sending after reset.

On this page

    Why this matters

    Blocks leave reset at different times. In the lesson's test, a producer that starts as soon as it leaves reset lost 19 of 100 words; one that waits for the consumer's alive flag lost none.

    After this lesson you can: define a quiescent crossing, quiesce a block before reset, and gate a sender on a synchronised readiness flag from the receiver.

    Sender waits for receiver

    Blocks leave reset at different times. A producer that starts while the consumer is still in reset loses words.

    Either one reset sequencer controls the release order (sequencing), or the receiver announces readiness and the sender waits.

    Each slot is one clock cycle, numbered from 0. A word on v0 or v1 is taken by the consumer at the edge that ends its slot, and only counts if rst_c_n is already high there.

    • Slot 1: the producer leaves reset. The consumer stays in reset for three more cycles and leaves it in slot 4.

    • Slots 2 to 6: v0 sends its 5 words at once. The words of slots 2 and 3 reach a consumer still in reset and are lost: 3 of 5 arrive.

    • Slots 5 and 6: alive rises one cycle after the consumer's reset ends, and v1 starts on the next cycle. All 5 of its words arrive.

    What quiescent means

    • No transfer is in flight across the crossing.

    • All handshake wires are at their idle value (req and ack low, valid low).

    • FIFOs are empty, pointers equal.

    • Both sides know the other's state: either a flag says so, or the reset sequence guarantees it.

    Tip

    Make the ready-flag part of the planned release interface: peer_ready in, ready_for_peer out. Synchronize status into the receiver's domain. It authorizes a controlled start only after quiescence/recovery; it is not immediate detection of an unexpected remote reset.

    Common pitfall

    Reset assertion has the mirror problem: a block about to reset should first stop sending and drain what is in flight (quiesce), then reset. Resetting in the middle of a transfer is exactly the case of the previous two lessons.

    Check yourself Why derive alive from the consumer rather than only a producer timer? Does synchronized alive detect an unexpected reset immediately?

    The consumer reports its actual readiness instead of assuming a release delay. But a synchronized copy may remain high for several producer cycles after a remote reset. Planned reset must close acceptance and drain first; unexpected reset needs the recovery acceptance interlock, containment and an epoch/cancellation policy.

    Testbench

    Two producers under a staggered reset release, with and without waiting.

    consumer.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    // Two blocks on one clock. The producer sends 100 words, one per cycle. The consumer counts the words it sees.
    // 'alive' becomes 1 one cycle after the consumer leaves reset: "I am ready to receive".
    module consumer (input logic clk, rst_n, valid, output logic alive, output int received);
      initial received = 0;
      always_ff @(posedge clk or negedge rst_n)
        if (!rst_n) alive <= 1'b0;
        else        alive <= 1'b1;
      always @(posedge clk) if (rst_n && valid) received++;      // words arriving while in reset are lost
    endmodule
    
    module producer #(parameter bit WAIT_ALIVE = 1) (input logic clk, rst_n, alive, output logic valid, output int sent);
      int n = 0;
      initial sent = 0;
      always_ff @(posedge clk or negedge rst_n)
        if (!rst_n) begin valid <= 1'b0; n <= 0; end
        else if (n < 100 && (!WAIT_ALIVE || alive)) begin valid <= 1'b1; n <= n + 1; end
        else valid <= 1'b0;
      always @(posedge clk) if (valid) sent++;
    endmodule
    

    Producer behaviour

    Sent

    Received

    Lost

    Starts as soon as it leaves reset

    100

    81

    19

    Waits for the consumer's alive flag

    100

    100

    0

    This one-clock test demonstrates planned staggered startup only. With unrelated clocks, synchronize alive and account for its detection latency. A stale high alive cannot guarantee protection against an unannounced reset, a stopped clock or power loss; use the recovery barrier and appropriate isolation/fault controls.

    Remember

    • Quiescent means no transfer in flight, handshake wires idle, FIFOs empty, and both sides knowing the other's state.

    • Before a planned reset, stop sending and drain what is in flight. Then reset.

    • A synchronised alive flag may stay high for several cycles after a remote reset. It does not detect an unexpected reset.

    Rule of thumb: the receiver announces readiness and the sender waits; do not rely on a fixed release delay.

    Keep going

    • Interview: run a mock interview on this topic

    Related topics

    • RDC signoff checklist

    Previous

    179 / 350

    Next: RDC Signoff Checklist

    Up next

    Up nextRDC Signoff Checklist

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • RDC Is CDC Plus Reset Asymmetry
    • Recovery, Removal and Verification Focus
    clkrst_p_nrst_c_nalivev0v1
    The testbench below shortened to 5 words and a 3-cycle stagger: the producer that ignores alive (v0) loses 2 words; the one that waits (v1) loses none