Two windows

An asynchronous reset behaves, at its release, like a data input: it must not change too close to the clock edge.

Read the picture as a single clock period, drawn to scale. The shaded strips are the only places where a release is unsafe.

• Removal is the hold-like window: the reset must still be asserted 0.15 ns after the edge, so a release inside the first strip is too soon.

• Recovery is the setup-like window: the reset must be released 0.30 ns before the next edge, so a release inside the last strip is too late.

• The two strips are narrow, about 4.5 % of the cycle together, which matches the roughly 4.75 % violation rate measured below for an unsynchronised release.

• The synchroniser moves the release to 0.3 ns after the edge. That clears the 0.15 ns removal window and leaves the rest of the cycle for recovery.

STA checks both windows for every flop with an asynchronous reset. It uses the flop clock and the reset release arrival time.

A raw asynchronous release may meet a particular window by chance, but cannot guarantee recovery/removal across arbitrary phases. A reset synchronizer aligns nominal release with the destination clock; its clock-to-Q, distribution, skew and endpoint recovery/removal requirements still need STA across the required corners.

Where to put verification effort

Testbench

Raw and synchronised reset releases compared over 2,000 random trials.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

`timescale 1ns/1ps

// A flip-flop with an asynchronous reset and recovery/removal checks:
//   recovery: reset must be released at least TREC BEFORE the next clock edge
//   removal : reset must stay asserted at least TREM AFTER the previous clock edge
// A release that violates either window leaves the flop in an unknown state (here: random).
module rff #(parameter real TREC = 0.30, TREM = 0.15) (
  input  logic clk, arst_n, d,
  output logic q,
  output int   violations
);
  realtime t_clk = -100.0, t_rel = -100.0;
  initial begin q = 1'b0; violations = 0; end

  always @(negedge arst_n) q <= 1'b0;                              // assertion: asynchronous, immediate
  always @(posedge arst_n) begin
    t_rel = $realtime;
    if ($realtime - t_clk < TREM) begin violations++; q <= $urandom_range(0, 1); end   // released too soon after an edge
  end
  always @(posedge clk) begin
    t_clk = $realtime;
    if (arst_n === 1'b0) q <= 1'b0;
    else if ($realtime - t_rel < TREC) begin violations++; q <= $urandom_range(0, 1); end   // released too close before this edge
    else q <= d;
  end
endmodule

module reset_sync (input logic clk, arst_n, output logic srst_n);
  logic r1;
  always_ff @(posedge clk or negedge arst_n)
    if (!arst_n) begin r1 <= 1'b0; srst_n <= 1'b0; end
    else         begin r1 <= 1'b1; srst_n <= #0.3 r1;  end      // 0.3 ns clock-to-Q: the release lands after the edge
endmodule

Zero synchronised violations follows from the chosen 0.3 ns output delay against this model's 0.15 ns removal window and 10 ns period. Real release analysis includes characterized cells, local clock/reset arrival, pulse width, recovery/removal and implemented reset-tree skew.

One mis-timed release can then cause chip-wide, hard-to-reproduce failures.

Related topics

• Next: CDC verification