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?
site should help you better understand these issues:
formatting link
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.
This is not correct. There is no "waiting". This is a statistical process.
See the above mentioned article.
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.
High loop gain/bandwidth.
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.
Maximize slack time, use highest performance FFs available, read the above article.
Humans are inherently opaque. Making you clear would probably kill you.
Good luck!
Philip Freidin Metastability Understanding crusader
=================== Philip Freidin snipped-for-privacy@fpga-faq.org Host for
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.