Resets in Digital Design :

There are two types of Resets in Digital Design:

Synchronous Resets :  In Synchronous Reset, flop reset is asserted/de-asserted on a predictable clock edge. The clock edge could be positive or negative depending on the Design requirements.      

Asynchronous Resets :  In this type of reset,  flop do not need a clock for Reset. Since Reset is a separate input into Flop, it could be reset asynchronously.

Digital Design:

Synchronous Reset Example :

always @(posedge clk) begin
  if(Rst)
     Q <= 1’b0;
  else
     Q <=  S;
end

Asynchronous Reset Example :

 always @(posedge clk or Rst) begin
  if(Rst)
    Q <= 1’b0;
  else
    Q <= S;
 end

 Physical Design :

Due to availability Cell libraries in physical design, Synchronous resets synthesize to smaller Flops compared to the Asynchronous counterparts. In Designs where logic is reset on set of conditions, Asynchronous reset may not be the optimum choice. Also one of the biggest problems of Asynchronous reset is de-assertion of Reset. During the de-assertion of Reset, there is a chance that logic may go into Metastable state if reset happens at or close to clock edge. This may not be visible in Simulation and could easily become a problem in Silicon.  In order to avoid it, there are various Reset de-assertion techniques for Asynchronous Resets.

For E.g Asynchronous Assertion & Synchronous de-assertion.

Resets need to be distributed such that flops receiving resets receive it around the same time. This is ensured by creating a balanced Reset Tree. The Reset tree is similar to clock tree but it’s not as critical if the skew is reasonable. The skew is often balanced by using buffer & inverters pairs to Reset or by adjusting clock skew to the source Reset Synchronizer itself.  These techniques are often used after detailed Timing of Resets and clocks are available in physical design. (Reference : Clifford E. Cummings Paper on Resets).

Reset Glitches:

There could also be glitches which may cause flops to be reset accidentally. This behavior is avoided by adding delay circuit to reset. The intent of this delay circuit is to filter glitches in the reset and allow legal reset to propagate. These delay circuits are often available as a part of Gate Library or can be added as an additional logic. The requirement of Delay circuit is not necessary for all the designs and it depends on System Requirements. Due to Reset glitches, the Reset flops are often coded or inferred as non-scannable flops & not available for Scan Tests . 

Multi-Clock Logic Reset Removal:

In multi-logic design, the reset should be distributed in their respective clock domain via reset distribution tree.  The reset removal for such design could be an issue if the reset is removed independently. In such cases reset removal is either coordinated or removed sequentially if system requirements permit.  In most cases, there is type of handshake circuit that waits for all the clock domains to come out of reset. The handshake logic then asserts a signal called IP ready or Design Ready.

Verification :

Disabling Resets in SV Assertions:

The assertions coded in RTL may sometimes need to be disabled as they are no longer applicable in Reset or behavior of certain Signals in Reset is of no significant value. In such cases, the Assertion or property is disabled using “disable iff(reset)” attribute.

E.x :    

assert property (@(posedge clock) disable iff (reset) $onehot(select_bus));      

In above example, the select_bus is a control signal that is expected to be one-hot after reset but we don’t expect one-hot behavior to hold true during Reset i.e select_bus could be 0 or X during reset. In Reset, we avoid the Assertion from false triggering by using “disable” attribute.

Synchronous Resets are less complex to verify as logic blocks are out of reset at a predictable times. This results in less chances of X-propagation in the Design.

On the other hand, Asynchronous designs may cause an accidental X-propagation. For Example : Asynchronous Reset may power an FSM into an unknown State. Also Asynchronous Resets may cause accidental glitches in the Design & it is recommended to use blocking assignments in Testbenches for Resets .

Reset to Memory Array, Data & Control signals.

Control signals & signals on the interface need to Reset to a known value. This is necessary to avoid X-prop or avoid nondeterministic behavior in the System.

It’s not recommended to Reset Data signals or large Memory Arrays. Using Reset Flops may result into larger Area as Reset Flops are bigger than normal flops and also Timing issues on Reset Routing.

Resets in SV Test-Bench:

Resets in a simple Unit-level Test benches are coded using blocking statements. For such implementation initial function is used.  

module unit_tb()

 logic clock;
 logic reset;
 logic clock;

  initial  begin
    clock = 0;
    reset = 1;
    repeat 10 @(posedge clock);
    reset = 0;  
    @(posedge clock);
    req = 1;
    @(posedge clock);
    req = 0;   
    $finish;
  end
 
always_comb #25 clock = ~clock;

endmodule

Hard Reset vs Soft Resets:

There are various types of resets used in logic design. Hard reset is basically a system wide reset wherein logic is reset without any prior indication for saving any FSM States or any valuable System information inside Memory Array or Registers. This Reset is often caused by any catastrophic failure for E.g Circuit failure or User Reset or Device Malfunction.

Soft Resets are caused by failures that are often non-catastrophic for E.g Page-Faults & Exceptions. In such scenarios, valuable information in FSM and Memory is often secured and restored back after Logic is out of reset again. This enables faster recovery and increases overall availability of the system.

Brown-out Resets:

Brown out Resets is a type a Reset that is caused by changes operating voltage levels in the system. This change is operating voltage may be due loss of Power or fluctuations in Power levels. This often happens due to Temperature changes or due to wearing of Electrical components.   The Brown out Resets are often detected in System by Power Management Unit and actions are taken to protect the System by flagging Interrupts or special Interrupt Service Routine like safe Recovery Mode.