Two stage synchroniser,how does it work?

I have no doubt that a two stage synchroniser works for crossing clk
domains
(or synchronising any asynchronous signal), however I have struggled for
years to get convinced with the theoretical explanations(including the ball
over the hill analogy). 
Surely the first flip will get into wrong output due to timing violation.
This wrong output becomes the wrong input to second flip. So how does data
get through correctly?

Any help appreciated...

kadhiem

On Wed, 08 Apr 2009 02:51:03 -0500, "kadhiem_ayob"
<kadhiem_ayob@yahoo.co.uk> wrote:
>I have no doubt that a two stage synchroniser works for crossing clk
>domains
>(or synchronising any asynchronous signal), however I have struggled for
>years to get convinced with the theoretical explanations(including the ball
>over the hill analogy). 
>Surely the first flip will get into wrong output due to timing violation.
>This wrong output becomes the wrong input to second flip. So how does data
>get through correctly?

Actually the problem is not "wrong output due to timing violation" ie
if sampling time is during the change of the input signal then the
exact value of the signal is difficult to determine so there is no
"wrong value" as such; you should be happy with either 1 or 0. 
The problem is that sometimes, very rarely, you get neither; ie the
output of the sampler meanders mindlessly for a while before it takes
a value of 1 or 0 and this causes all kinds of havoc downstream.
And strictly speaking, two stage synchronizer doesn't always work
either. It reduces the probability that the meta-stable event will
happen. This probability is inversely proportional to the clock period
and the speed of the sampler. So after the first sampler the longer
time you wait, the lower the probability becomes. For most design
points a second sampler is enough to lower it to acceptable levels.
Every synchronizer you add to the chain lowers the probability
exponentially but never to zero. 
But of course one only has to worry about a MTTF which is longer than
the life of our star for which a 4 stage synchronizer would be enough
in most cases. It's either that or till your PC crashes next time some
time during the next week for which even a 2 stage synchronizer is
overkill :-)

Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com

If the flip output is irrelevant(being 0 or 1 or undefined) then we got
problem with data value integrity rigt from the start of chain.
We need to separate between the issue of metasatibilty probability and
data value crossing.
surely the probability of metastability goes down after every stage but
data value goes wrong through anyway from the start irrespective of
probability issue. This is what puzzles me.

kadhiem 

On 8 Apr., 10:40, "kadhiem_ayob" <kadhiem_a...@yahoo.co.uk> wrote:

> surely the probability of metastability goes down after every stage but
> data value goes wrong through anyway from the start irrespective of
> probability issue. This is what puzzles me.

What is the wrong about that value?
You have two free running clocks that both have uncertainties
(Frequency drift, jitter.)
Now it happens that you sample an input close to a value transition
depending on the exact phase of your clock 0 or 1 might be the
correct value. You application mus work in either case, because it
does not know enough about the clocks to expect one or the other.

You need other machanisms to handle that issue. For asyncrhonous
serial protocols you could for example use oversampling. With 8x
oversampling
you know the phase of the input data some time ago with 13% accuracy.
If your clocks are atleast somewhat stable you can deduce where the
next
transition should occur and select a sample that is save.

Kolja Sulimma

>On 8 Apr., 10:40, "kadhiem_ayob" <kadhiem_a...@yahoo.co.uk> wrote:
>
>> surely the probability of metastability goes down after every stage
but
>> data value goes wrong through anyway from the start irrespective of
>> probability issue. This is what puzzles me.
>
>What is the wrong about that value?
>You have two free running clocks that both have uncertainties
>(Frequency drift, jitter.)

Are you saying that the first flip will sample its input correctly despite
the fact that it will be plagued with timing violations? Will its Q output
equal its D input regularly? In that case why do we bother about any clked
design timing issues at all? 

>You need other machanisms to handle that issue. For asyncrhonous
>serial protocols you could for example use oversampling. With 8x
>oversampling

Sorry but we are on the wrong track of discussion now...

Regards

kadhiem

Muzaffer Kal <kal@dspia.com> wrote:
(snip)
 
> Actually the problem is not "wrong output due to timing violation" ie
> if sampling time is during the change of the input signal then the
> exact value of the signal is difficult to determine so there is no
> "wrong value" as such; you should be happy with either 1 or 0. 
> The problem is that sometimes, very rarely, you get neither; ie the
> output of the sampler meanders mindlessly for a while before it takes
> a value of 1 or 0 and this causes all kinds of havoc downstream.
> And strictly speaking, two stage synchronizer doesn't always work
> either. It reduces the probability that the meta-stable event will
> happen. 

Yes.

> This probability is inversely proportional to the clock period
> and the speed of the sampler. 

Metastability resolution is exponential in the time available.  
With only one FF, the available time is the clock period minus 
the propagation time to the next FF. (Possibly to more than 
one FF.) For high speed designs, the added propagation delay 
can be enough that the probability is significant.

> So after the first sampler the longer
> time you wait, the lower the probability becomes. For most design
> points a second sampler is enough to lower it to acceptable levels.
> Every synchronizer you add to the chain lowers the probability
> exponentially but never to zero. 

Never to zero, but with minimal propagation delay, and with
the assumption that the clock period is constrained by 
propagation delay elsewhere in the design, it should be
enough.  Additionally, the design should allow for either
possible value.  For one signal, that usually isn't a problem.
With more than one signal, it is possible that some will
change before the clock transition, and some after, even
without any metastability.  Gray code is sometimes used
to get around that problem.

-- glen

kadhiem_ayob <kadhiem_ayob@yahoo.co.uk> wrote:
> If the flip output is irrelevant(being 0 or 1 or undefined) then we got
> problem with data value integrity rigt from the start of chain.
> We need to separate between the issue of metasatibilty probability and
> data value crossing.

Yes, but both problems occur when there is no known 
relationship between the two signals.  

> surely the probability of metastability goes down after every stage but
> data value goes wrong through anyway from the start irrespective of
> probability issue. This is what puzzles me.

In the case of a slow clock and multiple signals, it might be 
that you would only have worry about the different signals
and not about metastability.  In a large fraction of the
cases, though, one wants the clock to be as fast as possible.

-- glen

"kadhiem_ayob" <kadhiem_ayob@yahoo.co.uk> wrote:

>Are you saying that the first flip will sample its input correctly despite
>the fact that it will be plagued with timing violations? Will its Q output
>equal its D input regularly? In that case why do we bother about any clked
>design timing issues at all? 

No.  A "metastable" Q output from the first stage does not refer to a
"wrong" output value, such as it being a "1" when it should be a "0", but
about the Q output getting stuck half-way or oscillating for a while,
which can happen if its D input was in transition when it was clocked. If
that metastable Q output was fed to, for example, an incremental counter,
then that counter could do something worse than incrementing or not
incrementing -- like making a big jump to a completely different value
because its own setup time was violated.  *That* is why metastable states
are considered so nasty.

Adding a second d-type with a short propagation delay from the first
means that there's a whole clock cycle for the first stage to come out of
metastability and give a good setup time for the second D-type, so that
*its* Q output is either a secure 0 or 1 but not something between the
two.  Thus it becomes a negligible source of error compared to a system's
overall reliability.  Understand now?

>>For asyncrhonous serial protocols you could for example use oversampling. ...

>Sorry but we are on the wrong track of discussion now...

It's an example where you'd need to tolerate the uncertainty of an signal
being read either as a 0 or a 1 for a few ticks of the receiving circuit,
but where things would go horribly wrong if metastability was able to
propagate into the core of the receiving circuit.

-- 
Dave Farrance

>No.  A "metastable" Q output from the first stage does not refer to a
>"wrong" output value, such as it being a "1" when it should be a "0",
but
>about the Q output getting stuck half-way or oscillating for a while,
>which can happen if its D input was in transition when it was clocked.
If
>that metastable Q output was fed to, for example, an incremental
counter,
>then that counter could do something worse than incrementing or not
>incrementing -- like making a big jump to a completely different value
>because its own setup time was violated.  *That* is why metastable
states
>are considered so nasty.
>
>Adding a second d-type with a short propagation delay from the first
>means that there's a whole clock cycle for the first stage to come out
of
>metastability and give a good setup time for the second D-type, so that
>*its* Q output is either a secure 0 or 1 but not something between the
>two.  Thus it becomes a negligible source of error compared to a
system's
>overall reliability.  Understand now?

unfortunatley it is not convincing. it is ok for a discussion of
Metsatability per se but not data transfer.

the above argument states clearly that first Q output is not copy of D
input but is unstable halfway. So is the input to second flop. Now lets
look at value rather than stability at second Q output, stable yes but
correct who knows... 

Sorry for being so microanatomical but history has other examples when
consensus doesn't fit reality  

kadhiem

On Apr 8, 8:51=A0am, "kadhiem_ayob" <kadhiem_a...@yahoo.co.uk> wrote:
> I have no doubt that a two stage synchroniser works for crossing clk
> domains
> (or synchronising any asynchronous signal), however I have struggled for
> years to get convinced with the theoretical explanations(including the ba=
ll
> over the hill analogy).
> Surely the first flip will get into wrong output due to timing violation.
> This wrong output becomes the wrong input to second flip. So how does dat=
a
> get through correctly?
>
> Any help appreciated...
>
> kadhiem

There's an online presentation that goes into the various effects off
async clock domain crossing and the use of 2 x DFF synchronisers that
you may find useful.

This is part of a verification seminar covering Mentor's 0-In CDC
verification solution and can be found here:
https://admin.na3.acrobat.com/_a781163502/vscdc/

Regards
- Nigel
Mentor Graphics