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

M

Mikhail Matusov

Guest
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
 
Yes, you are violating a cardinal rule:
Never re-synchronize an asynchronous input in more than one flip-flop in parallel.
The solution for you is to take the asynchronous reset signal and
synchronize it in one single flip-flop ( feed it intoD and take it then
from Q to perform the reset.) If you can afford the increased latency,
you should concatenate two flip-flops to avoid metastabilty problems.

Peter Alfke, Xilinx
=====================
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
Click to expand...
 
Mikhail Matusov <mbmsv@yahoo.com> 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

"Mikhail Matusov" <mbmsv@yahoo.com> wrote in message
news:21803aae.0308110938.1c152f6d@posting.google.com...
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
Click to expand...
 
Avrum, I agree 99%, but please do not call the asynchr. reset edge
sensitive. It is really the level that resets (and holds reset) the
flip-flop. I suppose it was a typo of yours...

Peter Alfke, Xilinx
===========
Avrum wrote:
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.......,:
Click to expand...
 
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


"Peter Alfke" <peter@xilinx.com> wrote in message
news:3F37EC42.BF4752C1@xilinx.com...
Avrum, I agree 99%, but please do not call the asynchr. reset edge
sensitive. It is really the level that resets (and holds reset) the
flip-flop. I suppose it was a typo of yours...

Peter Alfke, Xilinx
===========
Avrum wrote:

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.......,:
Click to expand...
 
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
 
mbmsv@yahoo.com (Mike M) writes:

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
Click to expand...
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
 
I also use News.CIS.DFN.DE and am happy. However, a month or so ago, on this
server I was unable to get comp.arch.fpga which forced me to look for other
free servers and I found couple of them (one of them was 203.99.143.60, I do
not recall their name)...but as pointed by Mike, it doesn't show all posts
sometimes. I'm glad News.CIS.DFN.DE has this group back now...

"Martin Thompson" <martin.j.thompson@trw.com> wrote in message
news:ulltyezgw.fsf_-_@trw.com...
mbmsv@yahoo.com (Mike M) writes:

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
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top