Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Metastability and synchronizers

Status
Not open for further replies.

bsbs

Junior Member level 2
Junior Member level 2
Joined
Apr 22, 2011
Messages
20
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Visit site
Activity points
1,424
With the help of synchronizers we can definitely avoid meta-stability as it increases the settling time.
1)Does it ensure functional correctness(settling to the correct state)?
2)Can we detect these errors ?
3)How can we ensure functional correctness with synchronizers.
 

With the help of synchronizers we can definitely avoid meta-stability as it increases the settling time.
You don't completely avoid it. you simply reduce the probability that a metastable signal will propagate deeper into your design.
1)Does it ensure functional correctness(settling to the correct state)?
No. With a double DFF synchronize, if an asynchronous signal violates setup / hold time, the first DFF can go metastable - its output may settle at the wrong level. The second DFF doesn't "know" that the first DFF was metastable - it'll sample the wrong level.

2)Can we detect these errors ?
Yes.

3)How can we ensure functional correctness with synchronizers.
If your sampling rate is much higher then your asynchronous input signal. You can treat single clock level changes as errors.

Think of it like that:
You seat at home waiting for a guest and listening to the door bell. You know that your door bell is sometimes "glitchy" and may generate very short rings - therefore you choose to ignore all rings that are shorter then half a second. To do that, you must of course know in advance that none of your potential guests rings for such a short time.
 

Can u explain what you mean by error in your statement?
When i say errors i meant the wrongly settled states,Is it possible to reduce the probability of settling in the wrong states ?

- - - Updated - - -

If your sampling rate is much higher then your asynchronous input signal. You can treat single clock level changes as errors.
Can you explain how this ensures functional correctness ??
Even if you sample at high rate, the second ff will still sample wrong value if the output of first FF has settled to wrong value.
 

When i say errors i meant the wrongly settled states

This is also what I meant.

If your sampling rate is much higher then your asynchronous input signal. You can treat single clock level changes as errors.
Can you explain how this ensures functional correctness ??
Even if you sample at high rate, the second ff will still sample wrong value if the output of first FF has settled to wrong value.
If you assume (and it's safe to so) that the metastabillity will settle by the next clock edge - then the output of the second DFF will be a single clock pulse. Only now your system effectivly ignores signle edged pulse because it has been designed (by you) to assume that these're the result of an error.

Of course, this solution isn't always fissible as it increases latency and dictates the use of system clocks that are much faster then your asynchronous inputs...
 

If you assume (and it's safe to so) that the metastabillity will settle by the next clock edge - then the output of the second DFF will be a single clock pulse.
I assume that you are discussing asynchronous input signals, slow compared to the clock and without glitches. This can create metastability but probably not the scenario you describe.

A metastable output can not settle at a "wrong value" because there is no wrong value. Since the input changed at the wrong time both output values are correct. Metastability is not settling to the wrong value, it is when the settling is delayed (by a random time). Until it settles, the value seen by following logic is random.

The error happens when a metastable signal goes to more than one logic input and not all inputs agree on the value. If you have inputs connected to the same signal and some see a '0' and other see a '1', you have a problem.
The second synchronizer stage (DFF2) only has one input, so a single clock cycle with a metastable input from DFF1 is normally not a problem.

If the signal sampled by DFF2 is 000X111, the output will be 0000111 or 0001111. Both alternatives are clean, without a single cycle glitch. A correct design should handle both sequences without problems.

The single cycle glitch you describe from DFF2 can only happen if the output from DFF1 is metastable for 2 clock cycles, so that DFF2 can settle at a random value for 2 consecutive clocks. It is not impossible, but unlikely.

The real danger is that the output of DFF2 also goes metastable and doesn't settle in time to meet the setup time of the internal registers in the design.

Note that Altera recommends 3 synchronizer stages if the clock frequency and the data change rate are high.
This will not fix a single cycle glitch created in the first two stages, but it will fix the more realistic problem: that the output of the second stage goes metastable for one clock cycle.
 

following std_match's comment, to make the synchronization reliable enough, the number of synchronous flops needed is dependent on the frequency difference between the input and output of the sync-logic. For example, you may need even 4 sync-flops for signal passing from 300MHz clock-domain to 500MHz clock-domain.

Also there is one assumption:
Input signal maximum "toggling" Freq(within any given period of time) is always lower than half of the target clock frequency. Refer to "Nyquist–Shannon sampling theorem"

In addition, if the input signal is a bus, special care must be taken. Be aware that simultaneous changes on more than one bit of the bus will cause intermittent wrong sampling and synchronizing value in target clock domains. This is essentially why graycode or one-bit hand-shaking mechanism is usually employed to handle clock-domain-crossing(CDC) bus sample/synchronization.

it is a typical ASIC CDC topic, which relates to a significant concept of "MTBF": Mean Time Between Failure.
https://en.wikipedia.org/wiki/Mean_time_between_failures

Usually, for mass production chips, MTBF caused by clock-domain-crossing should for example guarantee 100*("number of sold chips/year") years of interval between failures. For example, if 1 million of a type of chip are sold yearly, MTBF for each chip would better be more than 100 million years. If the MTBF for the chip is only say 100 years, then there would averagely be (1 milloin/100)=10,000 chips failing EVERY YEAR! Imagine how much aftermath the company would have to **** up.

Thanks
Leo
 
Last edited:

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top