Hi All,

A common problem in large designs is violation on async reset. I am aware that in most cases it doesn't matter for example If I know my user logic design doesn't do anything until some stream arrives which could be milliseconds or more. But I am not sure about vendor ips. Let us take the simplest ip - a single clock fifo - again it is expected to get data written to it later... is there any explanation if this fifo could fail at reset release. Does anybody know how the pointers might behave at reset release such that it could go wrong right at release and stay wrong.

Regards

Kaz

The simplest way it can cause an issue is by causing metastability in flip flops if the reset is removed too close to the active edge of the clock. Of course depending on where this occurs in your design it could or could not cause an issue.

Many devices have macros for example the Xilinx XPM macro which synchronizes the async reset to the correct clock. You also have to be careful of the internal routing introducing this issue also, where the internal routing delays can cause the same issue 

By chance I wrote a blog for Blue Pearl on this a few weeks ago Blog here

Hi Adamt99,

Thanks for the reply but if the design does not do anything at start so how metastability could occur if no signal is transitioning. Then if it does occur how come it wouldn't settle in milliseconds. I am actually aware of what you said but my question is "How does it matter" rather than "why does it occur"

The transition is caused by the reset signal being released in the set up / hold period of the flip flop, not due to the input transitioning in that same window. 

It is bad as it can lead to unexpected behaviour in your design especially if you are doing high rel stuff. 

Recovery time - Min time required from reset release TO active clock edge. Removal time - Min time required from active clock edge TO reset release. In the case of FPGAs the clock routing is already fixed and tools ensure violations do not occur. In the case of ASICs the RESET routing and CLOCK routing has to be planned ahead of time and there are dedicated teams. These requirements become important as the design size grows. This also depends on clock frequency. As the system frequency increases designer has to pay more attention to sub-system resets. In multi-clock systems this issue needs closer inspection. If the designer follows FPGA vendor recommended "reset architecture" probability of violations is very low. Probability of violations is higher when asynchronous RESET is used and when design itself is asynchronous. 

Thanks but again I am not asking about basic textbook definitions and micro details.

I am simply asking this "Does it matter if a design is not doing anything at start" ?. 

Imagine that you have a state machine whose state is represented by a 2-bit vector (two flip-flops). In reset, the state is set to "00" which is a valid state. After you de-assert reset, the state is set to "11", which is also a valid state.

Is it not possible that if the async reset transitions close to the active edge of the clock, the flip-flop holding one of those bits could transition from "0" to "1" one clock cycle before the other?

In such a case, you could enter state "01" or "10", which may be invalid/undefined/undesired/dangerous states.

Of course, this is a simple and contrived example, but my point is that I think it could be dangerous in general. Even if no input data is going to arrive for some thousands of clock cycles, your system may have state of some kind that you need to think about.

When state changes immediately on reset release then we are doing work. What I mean by "not doing anything at start" is that literally we don't... such that the new state is only arrived at after long time from reset release being enabled by some late input arriving.

If literally nothing happens when reset is released, then it is not clear to me what the purpose of the reset is. However, in this special case, I agree you would be safe.

Yes nothing happens until some input arrives to kick start states or counters...etc. You don't have to release activity immediately just because reset is released. And you don't need to keep reset asserted until then.

The purpose of reset is as usual to return back in case testing goes wrong or operating design breaks due to wrong inputs.