This is a great article and covers the topic in an efficient way. However, I would like to make a correction:
One of the consequences of Metastability is mentioned as:
The destination domain output may settle down to the new value or may return to the old value. However, the propagation delay could be high leading to timing issues.
This is not correct. The flop B output will eventually settle to the correct (A) value. It is only when in the uncertain state that flops downstream can see different values which causes a design issue. If the flop B output were to finally settle to an incorrect value (as also show in the waveforms for B1 and B2), then the same could happen at the output of a synchronizer cell and that would defeat the purpose.
The point I am trying to make is that the syncronizer cell takes away the uncertain period from being seen by the capture flop and passes the CORRECT/ INTENDED value to the capture flop. If there is a rise transition on A, then flop B output will also always have a rise transtition and wont ever get a fall transntion.
May I start a controversial remark? may I say an iconoclast approach?
The Clock Domain Crossing Issues are everything else that is not METASTABILITY.
Per design the "metastability risk" must be constrained to the same level of any synchronous signal in a synchronous design per se, this is known and documented 2/3/4 special flops and no combinatorial, neither reconvergences.
Then all issues remaining are how to validate and verify the specific logic(s) is(are) functionally guaranteeing the proper functions for not missing any data.
Many tools are addressing the checking and verification with more or less quality and thoroughness.
If you are interesting by the topic you can join the group:
I found this article very well written and gives a great theoretical explaination for 99.9% of the cases - What I would find interesting is a use of statistical method to analyze and detect the metastable conditions.... using spice / or whatever you all think would get - call it Part II. Go to the SI guys : use eye patterns , etc.
send me the pdf of this report posted
The suggested patent pending solution to metastability is flawed, as are all such proposals. The injected noise is just as likely to move a stable event to a metastable event as it is to move a metastable event to a stable event.
And Philip Freidin 8/27/2003
"Nothing improves the MTBF of a metastable synchronizer better than
just waiting longer. Not clocking the intermediate signal on the
negative clock edge. Not voting. Not threshold testing. Not adding
noise. Not fancy SPICE simulations. Not predicting circuits. Not
circuits designed to bias the outcome to either 1 or 0. Not
clocking it twice as fast through twice as many flip flops.
From Thomas Cheney, October 1979:
"In closing, there is a great deal of theoretical and experimental
evidence that a region of anomalous behavior exists for every device
that has two stable states. The maturity of this topic is now such that
papers making contrary claims without theoretical or experimental support
should not be accepted for publication".
But it is possible to avoid most of the problems with a simple solution. Like other people I'm not able to design circuits without metastable states, but my patent pending solution ends it in a short and in its maximum defined time. If you see a flip flop as an analog circuit, you may inject a low AC signal in the feedback loop.
If you do that, so the amplifier circuit with its positive feedback will go very fast to a stable state. You are able, to build a D-flip-flop with such a modified feedback discrete, but I wish to have such flip flops in programmable logic and other integrated circuits.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.