Q: async flip-flop reset by a signal from a different clock domain

Mikhail Matusov wrote: : Hi all,

: Is there a danger in doing async reset of a flip-flop by a signal : generated by a state machine running in a different clock domain (than : flip-flop clock)? : I have a bunch of flip-flops that get synchronously written in one : clock domain and they need to be reset from another clock domain. So, : I used async reset... Is this a potential problem? I am having some : misterious random failures and this is one of the suspicious places in : my design...

: Thanks, : /Mikhail

You can always async reset any flop BUT you must ensure that you remove the reset signal with a known relationship to the flops clk. If you remove reset near the time that those flops are being written then all bets are off.

John Eaton

There certainly is a potential for failure here.

The ASYNC reset of a flip-flop is edge sensitive - as long as the signal is asserted, the flop ignores the D and CLK input, and holds the Q at the reset value. Conversely, when the reset is not asserted, flop reverts to its normal behaviour of sampling the D at every rising edge of CLK and placing the value on the Q. In other words, the assertion of the async RST changes the behaviour of the flop.

On de de-asserting edge of RST, the flop is changing from one behaviour to another. As a result, there is a window where the behaviour of the flop is unpredictable; if the deasserting edge of RST occurs very close to the rising edge of the clock, which behaviour is the flop going to exhibit - is it going to maintain the RST value, or is it going to sample the D and place it on the Q? Within a certain window (called the reset recovery time) after the deasserting edge of reset, the behaviour is undetermined - it may do either or maybe even neither - the flip flop may go metastable if the reset recovery time is violated.

Furthermore, if you have a state machine with multiple state bits, all of which are connected to this same asynchronous reset, you have compounded the issue. Since the async reset is routed (separately) to each of the flops, the propagation path to each flop may be different. So, when the RST is deasserted, the deassertion may reach the different flops at different times (by definition, this path is unconstrained since is crosses asyncronous clock boundaries, unless you constrain it by hand). So, if the clock arrives near the deassertion of RST - the flops with short routing delays may acknowledge the deassertion of reset (and hence clock D->Q), the flops with long routing will sill remain in reset, and the ones in the middle will do either or go metastable. This can be a problem if, say, the reset state is

0000, and the next state (assuming reset is deasserted) is 1111. When the CLK and RST are close together, you can end up in pretty much any state, even states that are normally illegal to the state machine.

In general, this is quite a dangerous practice. Even when you are only using the RST for resetting the initial state of the state machine, you should always connect the RST (be it a synchronous RST or async RST) to an input that is already syncronized to the same clock domain (to ensure that you don't violate the recovery time on RST deassertion). This may have changed recently, but in the past, the tools would NOT check for violations of the reset recovery time when using asynchronous resets - you had to force it to do so by placing

ENABLE="Trck";

in your .ucf file.

Avrum

Have you ever said something when you mean the exact opposite? That's what I did here...

Please change the sentence to read "The ASYNC reset of a flip-flop is LEVEL sensitive" (the rest of the description makes more sense when this error is corrected).

Sorry, all.

Avrum

is

Thanks to everyone who contributed to this discussion. I am currently having technical difficulties posting to the Usenet, so please forgive me for the delay. BTW, does anyone knows of a good free news server that would allow posting? Google is very slow to reflect even the messages that have been posted through it and all too frequently doesn't show some of the posts at all (it happened to Avrum's posts this time). I am using newssvr20-ext.news.prodigy.com for reading, but it doesn't allow posting...

/Mikhail

I've been using "News.CIS.DFN.DE" since our corporate server went away. Seems reliable, allows posting, carries the groups I'm interested in...

Sign up at by pointing a web browser at that address IIRC.

Cheers, Martin

--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt