second flop in asyn reset distribution

Ok!  From all the previous topic and other resources on the net I see
following ckt touted to work for distributing async resets.

always@(posedge clk or negedge ext_reset_l)
  if(!ext_reset_l)
     int_reset_l <= 2'b00;
  else
     begin
     int_reset_l[0] <= 1'b1;
     int_reset_l[1] <= int_reset_l[0];
     end
end
assign chip_reset_l = int_reset_l[1];

My questions is -
What happens if the second flop (int_reset_l[1]) goes metastable  or
if it cannot then why?

I cannot understand why so many have recommended the above ckt. as a
solid form of negating async reset syncly!?

e.g. http://i.cmpnet.com/deepchip/downloads/cliff_resets.zip

I would appreciate it much if someone can educate me on this?
TIA.

>My questions is -
>What happens if the second flop (int_reset_l[1]) goes metastable  or
>if it cannot then why?

You don't have to worry about the leading edge of reset making
the second FF go metastable.  That case is cleanly asynchronous.
The rest of the FSM might go metastable, but that will only last
one clock.  The next cycle will fix things up.  (More likely
is a bogus state because of setup timings not reaching all
FFs at the same time - simple timing violation.)

You do have to worry about what happens during that clock.
Most of the time, the next step downstream will recover.
It might be more complicated than that in safety critical
applications.

On the trailing edge of reset, you don't have to worry about
metastability since the second FF is going from 0 to 0.
The first FF might go metastable.  You do have to make sure
there is enough time on the clock between the first and
second FFs to cover that case.  You can't get it perfect,
just good enough for your application.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray wrote:

>>My questions is -
>>What happens if the second flop (int_reset_l[1]) goes metastable  or
>>if it cannot then why?

(snip)

> On the trailing edge of reset, you don't have to worry about
> metastability since the second FF is going from 0 to 0.
> The first FF might go metastable.  You do have to make sure
> there is enough time on the clock between the first and
> second FFs to cover that case.  You can't get it perfect,
> just good enough for your application.

The probability of metastability effects decreases exponentially with 
time.   Assuming that you have logic between FFs elsewhere in the design 
there should be plenty of time when there is no logic.  That is, when 
the probability is less than once in the life of the universe, maybe a 
lot less, that is usually enough.

-- glen

Hi,

there is an interesting paper about this topic.
It includes various reset strategies and should clarify your doubts.

It can be found at the following url:
http://www.sunburst-design.com/papers/

HTH

Ansgar

--
Attention please, reply address is invalid, please remove "_xxx_" ro reply
"fpgabuilder" <fpgabuilder-news@yahoo.com> schrieb im Newsbeitrag
news:1107990759.754345.93630@l41g2000cwc.googlegroups.com...
> Ok!  From all the previous topic and other resources on the net I see
> following ckt touted to work for distributing async resets.
>
> always@(posedge clk or negedge ext_reset_l)
>   if(!ext_reset_l)
>      int_reset_l <= 2'b00;
>   else
>      begin
>      int_reset_l[0] <= 1'b1;
>      int_reset_l[1] <= int_reset_l[0];
>      end
> end
> assign chip_reset_l = int_reset_l[1];
>
> My questions is -
> What happens if the second flop (int_reset_l[1]) goes metastable  or
> if it cannot then why?
>
> I cannot understand why so many have recommended the above ckt. as a
> solid form of negating async reset syncly!?
>
> e.g. http://i.cmpnet.com/deepchip/downloads/cliff_resets.zip
>
> I would appreciate it much if someone can educate me on this?
> TIA.
>

Thanks everyone.

Well,  I guess the question I have is why is that reset is related ot
clock only when d input is changing?  Can the inverters in the second
flop not go metastable when the reset changes but d input does not?
AFAIK, this would depend on how the ff is constructed.  But the most
basic FF that I have studied in past have set and preset input in the
feedback loop of the master latch part of the FF.

BTW, Ansgar, thanks for the link.  Actually the paper that I reference
in my post is the by the same authors Wills and Cummings, as pointed
out in your post and when I looked previously there it was the same and
did help answer my question.

>Well,  I guess the question I have is why is that reset is related ot
>clock only when d input is changing?  Can the inverters in the second
>flop not go metastable when the reset changes but d input does not?
>AFAIK, this would depend on how the ff is constructed.  But the most
>basic FF that I have studied in past have set and preset input in the
>feedback loop of the master latch part of the FF.

Metastability requires a race condition.  You have to be interested
in whether the FF will go from a 0 to a 1 or stay at a 0.  (or the
other way around)

There is such a race condition when reset goes away if you are
trying to clock a 1 into a FF.  If you are trying to clock in
a 0, there is no problem - you get 0 or 0 so it doesn't matter.

The second FF in the case being discussed is the 0 to 0 case.

The first FF might go metastable.  The whole point of this
discussion is to move the metastability considerations from
all over the FSM to one concentrated place where the designer
can check it carefully by hand.  The tools don't help much,
at least not yet.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Here is a simple explanation:
In any conventional flip-flop the asynchronous CLEAR input clears both
the master and the slave directly and permanently as long as CLEAR is
active.
The synchronous RESET is just another (overriding ) input to the logic
driving the D input.

All behavior can be deduced from these simple facts

Peter Alfke, Xilinx Applications

Thanks folks.

Hal, I understand at the purpose behind synchronizing the reset.  I am
curious to find out what goes on inside the flip-flop that does not
cause it go metastable when the d input does not change but the reset
changes. 

Thanks.

So let's take this slowly:
You apply asynchronous reset, which forces both latches to 0. There is
no metastability as long as CLEAR is active.
Then you take away CLEAR asynchronously with repect to the clock. Let's
assume the D input is a 1 (if it were a 0, we would not have this
dicussion)
Both latches are 0 while CLEAR is active,, but if CLEAR goes away right
before the clock rising edge, the 1 on D might sneak in and set the
master in a metastable way. After the rising clock edge, the master now
drives the slave.
That means you see a metastable (unbounded) 1 on the slave output Q.

This happens only when the CLEAR goes inactive right before the rising
clock edge, and only while D is 1.

(I had this problem once in a FIFO synchronizer, and I solved it by
using CLEAR to drive the D input in such a way that the Low on D
appears before CLEAR goes Low= inactive. A simple inverter or buffer
does the trick, depending on the chosen polarities.)
Peter Alfke, Xilinx Applications

Peter, Hal and all.

I was really interested in analysing this at the transistor level which
I have now thanks to your inputs and other vlsi references that I
looked up.  

Thanks.
-sanjay