Chipress

In practice, reset assertion is asynchronous and de-assertion is synchronous. Synchronous reset de-assertion can make sure flops are under metastability after reset removal. However, due to place and route, reset de-assertion does not happen simultaneously for all flops in an SoC. RTL designers must be cautious when dealing with reset de-assertion.

There are several steps / measures that designers can take:

1. At STA level, designers must make sure reset removal time and recovery time are met for all flops. Otherwise,
2. At the physical design level, reset tree synthesis must be well balanced by inserting buffers or place & route optimization. A properly balanced reset tree topology will reduce the difference of absolute delay of reset de-assertion reaching each flop. Otherwise,
3. At SoC / RTL design level, wait multiple cycles for reset de-assertion reaching all flops, i.e., use a global counter to count cycles, and SoC can only start normal operations after the counter expires. This would give more margin in reset tree synthesis or reset timing closure. Or, 
4. Use reset staggering. Instead of resetting all flops at the same time, reset “region” by “region” across multiple cycles. SoC can only resume normal operation after reset staggering completes. Reset staggering introduces an extra benefit of reducing supply rail IR-drop during design reset phase. Or,
5. Introduce reset domain. Though reset de-assertion no longer needs to be synchronous across reset domains, SoC / RTL designers must run reset domain check (RDC), making sure “asynchronous” reset de-assertion will not cause metastability issues for “consumer” reset domain.