FPGA Central

Hi,

Kindly clarify the following doubts on Two FF synchronizer.
Most of the material available in net says the two flip-flop
synchronizer is sufficient to remove all likely metastability.

The first flip-flop samples the asynchronous input signal and waits
for a full clock cycle to permit any metastability output signal to
come to stable either 1 or 0.

How can the ouput of the first FF will becomes stable before the
next clock cycle? On what factors it will depend?
(Theoritically it not guarenteed that Two FF synchronizer avoids
metastability but proctically it is, how?)

Whats vendors approach for the first FF to go to stable state before
next sampling edge arrives?
Whats information/insructions the vendor can provide designers
regarding first FF settling time etc....?

What are all the options available in the designer hand to make the
two ff synchronizer work properly?

Please make me clear.

Thanks in advance.

Regards,
SruthiTeja.

Read the Xilinx appnote XAPP094.
http://direct.xilinx.com/bvdocs/appn...=%22xapp094%22

It gives you a feel for the probability of the first flip-flop reaching
a stable state within a given time (in your case a whole clock period).
As you will note, mettbility is a probabilistic event, there is no
"guaranteed" solution.
But when the Mean Time Between Failure (MTBF) is billions of years, the
design can be considered pretty safe...
Peter Alfke, Xilinx

himassk wrote:
> Hi,
>
> Kindly clarify the following doubts on Two FF synchronizer.
> Most of the material available in net says the two flip-flop
> synchronizer is sufficient to remove all likely metastability.
>
> The first flip-flop samples the asynchronous input signal and waits
> for a full clock cycle to permit any metastability output signal to
> come to stable either 1 or 0.
>
> How can the ouput of the first FF will becomes stable before the
> next clock cycle? On what factors it will depend?
> (Theoritically it not guarenteed that Two FF synchronizer avoids
> metastability but proctically it is, how?)
>
> Whats vendors approach for the first FF to go to stable state before
> next sampling edge arrives?
> Whats information/insructions the vendor can provide designers
> regarding first FF settling time etc....?
>
> What are all the options available in the designer hand to make the
> two ff synchronizer work properly?
>
> Please make me clear.
>
> Thanks in advance.
>
> Regards,
> SruthiTeja.

The following long article at the www.fpga-faq.org site should help
you better understand these issues:

http://www.fpga-faq.org/FAQ_Pages/00...etastables.htm


On 7 Sep 2006 08:48:50 -0700, "himassk" <[email protected]> wrote:
>Hi,
>
>Kindly clarify the following doubts on Two FF synchronizer.
>Most of the material available in net says the two flip-flop
>synchronizer is sufficient to remove all likely metastability.

That is correct, with the qualifier that the path delay between the
two flip flops should be minimized, thus maximizing the slack time,
and the clock frequency should be minimized, thus maximizing the
slack time.

>The first flip-flop samples the asynchronous input signal and waits
>for a full clock cycle to permit any metastability output signal to
>come to stable either 1 or 0.

This is not correct. There is no "waiting". This is a statistical
process.

>How can the ouput of the first FF will becomes stable before the
>next clock cycle? On what factors it will depend?

See the above mentioned article.

>(Theoritically it not guarenteed that Two FF synchronizer avoids
>metastability but proctically it is, how?)

The practical result is that if there is sufficient slack time between
the 2 FFs, the probability of the metastable getting through both is
very small.

>Whats vendors approach for the first FF to go to stable state before
>next sampling edge arrives?

High loop gain/bandwidth.

>Whats information/insructions the vendor can provide designers
>regarding first FF settling time etc....?

Metastable characteristics data, and test results to back it up.
The parameters can be used in the MTBF calculations to decide if
a 2, 3 or more stage synchronizer is needed.

>What are all the options available in the designer hand to make the
>two ff synchronizer work properly?

Maximize slack time, use highest performance FFs available, read the
above article.

>Please make me clear.

Humans are inherently opaque. Making you clear would probably kill you.

>Thanks in advance.

Good luck!

>Regards,
>SruthiTeja.


Philip Freidin
Metastability Understanding crusader


===================
Philip Freidin
[email protected]
Host for WWW.FPGA-FAQ.ORG

himassk wrote:
> Hi,
>
> Kindly clarify the following doubts on Two FF synchronizer.
> Most of the material available in net says the two flip-flop
> synchronizer is sufficient to remove all likely metastability.
>
> The first flip-flop samples the asynchronous input signal and waits
> for a full clock cycle to permit any metastability output signal to
> come to stable either 1 or 0.
>
> How can the ouput of the first FF will becomes stable before the
> next clock cycle? On what factors it will depend?
> (Theoritically it not guarenteed that Two FF synchronizer avoids
> metastability but proctically it is, how?)
>
> Whats vendors approach for the first FF to go to stable state before
> next sampling edge arrives?
> Whats information/insructions the vendor can provide designers
> regarding first FF settling time etc....?
>
> What are all the options available in the designer hand to make the
> two ff synchronizer work properly?
>
> Please make me clear.

You have received some good answers to your questions, but partly
because I think you could still benefit from a simple explanation and
partly because I feel like listening to myself talk, I will give you a
third explanation of metastability and how to avoid its consequences.

Metastability is a state of a FF or other similar device (such as a
pencil standing on the pointed end) that has two stable states and if
released at any point in between will eventually assume one of those
two states. The trick is that depending on how close to the threshold
point the pencil or FF is released, it can take an arbitrarily long
time to end up in one of the stable states.

For a pencil, holding it at a given position and releasing it is like
the active edge of the clock occuring too close to a transition of the
data input. If the FF samples the data input while it is changing, the
intermediate logic gates may also be in transition and the feedback of
the FF can be in the middle of the voltage range. If the logic values
were all at stable values the output would change at a time that is a
known delay from the clock edge. But since the internal logic values
are not valid, the delay will not depend on the path delays, but rather
on how fast the invalid logic values are pushed one way or the other to
a stable state. Just like the pencil, this depends on how close to the
threshold the invalid value is.

This is when statistics take over. If you assume the delta from the
logic value to the threshold is not deterministic, but rather random
(as will usually be the case) then the time delay will also be random
reaching out to infinity. The curve is such that there is a higher
probability at shorter delays and an ever decreasing probability at
longer delays. Since the area under the curve has to integrate to
unity, you can see that the probability must go down very quickly since
it stretches forever.

So the upshot is that the current logic found in FPGAs is designed to
maximize the probability of short delays. This means if you allow 2 or
3 ns of excess setup time between FFs (slack time), the probability of
the first FF output still being metastable is so low, that you will
never see it in your lifetime if you watch a billion FPGAs.

I have not supported this with any hard data, but the FPGA vendors have
done that for us. I believe Peter Alfke has made numerous measurements
of the metastability coefficients for their products and the 2 or 3 ns
is the short version of his data. Someone please correct me if I am
wrong about the numbers.

But please remember that it is the slack time, not the clock cycle time
that allows metastability to be resolved. You can put logic in the
path as long as you have sufficient slack time. Conversely, a clock
cycle may not be long enough if the routing delay is too long reducing
the slack time. It does not hurt to add a specific timing constraint
to these paths.