ASIC Verification: Asynchronous and Synchronous Reset

Tuesday, May 20, 2008

Asynchronous and Synchronous Reset


A fully asynchronous reset is one that both asserts and de-asserts a flip-flop asynchronously. Here, asynchronous reset refers to the situation where the reset net is tied to the asynchronous reset pin of the flip-flop. Additionally, the reset assertion and de-assertion is performed without any knowledge of the clock. This type of reset is very common but is very dangerous if the module boundary represents the FPGA boundary.

The biggest problem with the asynchronous reset circuit described above is that, it will work most of the time. However, if the edge of the reset deassertion is too close to the clock edge and violate the reset recovery time, then the output of FF goes to metastable. The reset recovery time is a type of setup timing condition on a flip-flop that defines the minimum amount of time between the de-assertion of reset and the next rising clock edge as shown in Figure.

It is important to note that reset recovery time violations only occur on the de-assertion of reset and not the assertion. Therefore, fully asynchronous resets are not recommended.


The most obvious solution to the problem introduced in the preceding section is to fully synchronize the reset signal as you would any asynchronous signal.

The advantage to this type of topology is that the reset presented to all functional flip-flops is fully synchronous to the clock and will always meet the reset recovery time. The interesting thing about this reset topology is actually not the deassertion of reset for recovery time but rather the assertion In the previous section, it was noted that the assertion of reset is not of interest, but that is true only for asynchronous resets and not necessarily with synchronous resets. Consider the scenario illustrated in Figure.
Consider the scenario where the clock is running sufficiently slow, the reset is not captured due to the absence of a rising clock edge during the assertion of the reset signal. The result is that the flip-flops within this domain are never reset.

Fully synchronous resets may fail to capture the reset signal itself (failure of assertion) depending on the nature of the clock.

For this reason, fully synchronous resets are not recommended unless the capture of the reset signal (reset assertion) can be guaranteed by design.

Asynchronous Assertion, Synchronous De-assertion

A third approach that captures the best of both techniques is a method that asserts all resets asynchronously but de-asserts them synchronously.
In Figure, the registers in the reset circuit are asynchronously reset via the external signal, and all functional registers are reset at the same time. This occurs asynchronous with the clock, which does not need to be running at the time of the reset. When the external reset de-asserts, the clock local to that domain must toggle twice before the functional registers are taken out of reset. Note that the functional registers are taken out of reset only when the clock begins to toggle and is done so synchronously.

A reset circuit that asserts asynchronously and de-asserts synchronously generally provides a more reliable reset than fully synchronous or fully asynchronous resets.

The code for this synchronizer is shown below.

module reset_sync(
output reg rst_sync,
input clk, rst_n);
reg R1;
always @(posedge clk or negedge rst_n)

R1 <= 1'b0;
rst_sync <= 1'b0;


R1 <= 1'b1;
rst_sync <= R1;


axaxaxas_mlo said...

I found the article interesting. I design for FPGAs, and I used to use synchronous reset. I think I'll start to use your recommended topology, since it doesn't use up more resources.

Thanks and bye!!

Anonymous said...

good job !!

Unknown said...

excellent explanation for Recovery time. in the same way can you explain about Removal time

vehofugipi said...

thanks a lot for this!
your blog seems very helpful.

Muralikrishna Pattaje said...

There is no possibility of failure of de-assertion of reset if the clk is slow ?

smubarak said...

Yea , its interesting , but here i have a question in verification point of view ,
suppose according to design spec. reset should be synchronous but designer wrongly implemented as asynchronous reset, so without reviewing the code how can the verification engineer can check this ?

Erkka said...

I was wondering the last figure sync_deass_async_ass.JPG

Note that reset controller is totally asynchronous to the fast clock. Hence, it seems that either (or both) synchronizing flip-flops could go metasable if reset de-assertion violates the recovery constraint.

In the other reset synchronizer only the first dff can go metastable and the second only very very rarely. So they would be the recommended way, if I understood correctly.

Erkka said...

The sentence
"if the edge of the reset deassertion is too close to the clock edge and violate the reset recovery time, then the output of FF goes to metastable." could be rephrased to "...goes metastable if FF output should change".

Then the last reset synchronizer should work despite my earlier concerns. The second FF has been reset to 0 and it loads 0 from D input when reset is deasserted. Then only the first one would go metastable but that is not a problem.