Reset Synchronization

1. The Reset Problem

In multi-domain chips, reset must reach every flip-flop in every clock domain. But reset itself is asynchronous—it doesn't follow any clock.

The problem: If an async reset directly resets flip-flops in Clock B domain without synchronization, it may cause metastability.

// ❌ WRONG: Async reset from system without synchronization
always @(posedge clk_b or negedge sys_reset) begin
  if (!sys_reset) begin
    data_reg <= 32'b0;  // DANGER: async reset to Clock B domain
  end else begin
    data_reg <= data_in;
  end
end

Problem: sys_reset is asynchronous from Clock B
         Deassertion (rising edge) might violate setup/hold
         data_reg may capture metastable state
         Effects propagate throughout Clock B domain

2. Synchronized Reset Architecture

Two-Stage Reset Synchronizer

Solution: Synchronize reset through dual-FF in each domain, just like any async signal crossing.

module reset_synchronizer #(parameter STAGES = 2) (
  input  clk,
  input  async_reset,       // Asynchronous system reset
  output synchronized_reset
);

  reg [STAGES-1:0] reset_sync;

  always @(posedge clk or negedge async_reset) begin
    if (!async_reset) begin
      reset_sync <= {STAGES{1'b0}};  // Assert: direct (async)
    end else begin
      reset_sync <= {reset_sync[STAGES-2:0], 1'b1};  // Deassertion: sync'd
    end
  end

  // Output is synchronized (safe for use in this clock domain)
  assign synchronized_reset = reset_sync[STAGES-1];

endmodule

// Usage in each clock domain:
reset_synchronizer #(.STAGES(2)) reset_clk_a (
  .clk(clk_a),
  .async_reset(sys_reset),  // From system (async)
  .synchronized_reset(rst_a)  // For use in Clock A domain
);

reset_synchronizer #(.STAGES(2)) reset_clk_b (
  .clk(clk_b),
  .async_reset(sys_reset),  // From system (async)
  .synchronized_reset(rst_b)  // For use in Clock B domain
);

// Now use rst_a and rst_b in flip-flops (safe):
always @(posedge clk_a or negedge rst_a) begin
  if (!rst_a) ...  // Synchronized reset (no metastability risk)
end

3. Reset Timing & Constraints

Critical Timing Window

Reset has two edges:

• Assertion (falling edge): Should be direct (fast). All flip-flops go to reset state ASAP.
• Deassertion (rising edge): MUST be synchronized through dual-FF. No metastability.

4. Partial vs. Full Reset

Full System Reset

Resets all flip-flops in all clock domains simultaneously. Used at power-on or critical error conditions.

RTL structure: One async reset signal, distributed through dual-FF synchronizers to each domain.

Partial Domain Reset

Reset only one clock domain while others continue operating.

Challenge: If Clock A domain is reset while Clock B is running, CDC logic between them must handle the transition gracefully.

• FIFO pointers in Clock A reset: Must notify Clock B domain that pointers are invalid
• CDC synchronizers affected: May capture reset values momentarily
• Solution: Explicit handshake protocol (acknowledge sync reset completion before resuming operation)

5. Reset Assertion vs. Deassertion Behavior

Why the Asymmetry?

Assertion: Putting logic into reset state (0) is safe—no data loss, just initialization.

Deassertion: Releasing from reset means flip-flops will start capturing data. If deassertion is metastable, captured data is corrupted. Therefore, deassertion must be synchronized.

6. Real-World Reset Scenarios

Scenario 1: Power-On Reset (POR)

At power-on, voltage ramps up slowly. Power-on reset (POR) circuit detects when voltage is stable and releases reset.

• POR signal is truly asynchronous (not related to any clock)
• Must be synchronized into each clock domain before use
• Typical: 2-4 FF stages per domain for safety

Scenario 2: Watchdog Reset

Watchdog timer detects system hang and asserts reset.

• Watchdog runs in Clock A domain
• Reset must propagate to Clock B domain
• Solution: Watchdog asserts sys_reset, which syncs into all domains

Scenario 3: Software-Triggered Reset

Processor writes to a control register to trigger reset.

• Control register in Clock A domain
• Must reset other domains
• Solution: Async reset signal generated from register, synchronized into other domains

7. Reset Recovery & Removal Time

Two critical timing constraints for reset:

• Reset recovery time: Minimum time between reset deassertion and next clock edge before data capture
• Reset removal time: Minimum time between reset removal and setup time violation

8. Common Reset Mistakes

• ❌ Mistake: Direct async reset to all flip-flops (no synchronization)
• ✓ Fix: Synchronize reset deassertion through dual-FF per domain
• ❌ Mistake: Single reset synchronizer shared across domains
• ✓ Fix: Separate reset synchronizer per clock domain
• ❌ Mistake: Synchronizing reset assertion (wastes time)
• ✓ Fix: Assert reset directly (async), only sync deassertion
• ❌ Mistake: Not accounting for reset propagation delay in startup
• ✓ Fix: Verify all domains have received synchronized reset before releasing wait state

9. Formal Verification of Reset

Properties to verify:

• All flip-flops reset: Every FF eventually goes to reset value
• No metastability on deassertion: Reset deassertion doesn't cause data corruption
• Reset reaches all domains: No domain is "stuck" in reset
• Reset removal timing met: Setup/hold not violated after reset release

10. Reset Checklist

• ✅ Direct async assertion: Reset falls immediately (no delay)
• ✅ Synchronized deassertion: Reset rises through dual-FF per domain
• ✅ One synchronizer per domain: Not shared
• ✅ Reset recovery time: Met in all domains
• ✅ Reset removal timing: Setup/hold not violated during deassertion
• ✅ Formal verification: All domains eventually reset
• ✅ Partial reset handling: Protocol for resetting individual domains
• ✅ Test reset propagation: Verify all domains see reset in simulation

Next (Day 10): Multi-domain chip design strategies and integration patterns.