Set-up and hold times and metastability

[James823]

Hi,

I've been looking at synchronising data across clock domains, and hav
managed to confuse myself.
Can someone confirm (or correct me) that the following is true.

Metastability may occur if the input D changes value during the set-up an
hold times, however the enable can be completely asynchronous without eve
causing a problem?

If not, then even something as simple as testing a switch is pressed woul
cause problems right?

Thanks for the help
James

-- PS sorry if this is a double post, I got an error when previousl
sending

---------------------------------------
Posted through http://www.FPGARelated.com

 

[glen herrmannsfeldt]

James823 <3681@embeddedrelated> wrote:

I've been looking at synchronising data across clock domains, and have
managed to confuse myself.
Can someone confirm (or correct me) that the following is true.

Metastability may occur if the input D changes value during the set-up and
hold times, however the enable can be completely asynchronous without ever
causing a problem?

Doesn't seem right to me. If D has the same value as Q, then there
should be no problem. If not, it seems to me just as bad as changing Q.

If not, then even something as simple as testing a switch is pressed would
cause problems right?

The traditional method of using a second FF should still work.

Also, remember the second problem that comes from not meeting
setup/hold, when you have more than one FF some might get the new
value, some keep the old. That is completely separate from
metastability, but also causes systems to fail.

-- glen

 

[Jon]

Metastability may occur if the input D changes value during the set-up and
hold times, however the enable can be completely asynchronous without ever
causing a problem?

No, the enable will have a setup and hold time as well.

Even async resets can cause metastability, if it violates the recovery time.

If not, then even something as simple as testing a switch is pressed would
cause problems right?

Yes.

Depending on the type of switch, you also might need to consider debouncing.

Cheers,
Jon

 

[Mike Perkins]

On 22/11/2012 07:35, James823 wrote:

Hi,

I've been looking at synchronising data across clock domains, and have
managed to confuse myself.
Can someone confirm (or correct me) that the following is true.

Metastability may occur if the input D changes value during the set-up and
hold times, however the enable can be completely asynchronous without ever
causing a problem?

The enable is really a latch enable with all the same issues of
metastability of a clock.

If not, then even something as simple as testing a switch is pressed would
cause problems right?

There are a number of ways of achieving moving data across clock domains.

Simplest is to use a fast clock, where the clock rate is many times the
data rate. The original data clock can be sampled to determine when it
transitions and the data read when it should be stable, if necessary
using suitably delayed data using parallel latches.

A typical method is to buffer the data in a FIFO which typically uses
Gray code counters for pointers. Input and output valid data enables
can be built into the FIFO.

I often use Block Ram based FIFO for moving line or block data from a
video source clock domain to memory and back again. Here I might use
flags to signify when a block of data is ready for the second clock domain.

In general the problem is reduced to having a single signal to denote
valid data. Where any uncertainty will not by itself corrupt data.

Hope that helps.

--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

 

[rickman]

On 11/22/2012 9:35 AM, Mike Perkins wrote:

On 22/11/2012 07:35, James823 wrote:
Hi,

I've been looking at synchronising data across clock domains, and have
managed to confuse myself.
Can someone confirm (or correct me) that the following is true.

Metastability may occur if the input D changes value during the set-up
and
hold times, however the enable can be completely asynchronous without
ever
causing a problem?

The enable is really a latch enable with all the same issues of
metastability of a clock.

If not, then even something as simple as testing a switch is pressed
would
cause problems right?


There are a number of ways of achieving moving data across clock domains.

Simplest is to use a fast clock, where the clock rate is many times the
data rate. The original data clock can be sampled to determine when it
transitions and the data read when it should be stable, if necessary
using suitably delayed data using parallel latches.

What??? How do you "sample" the input without dealing with
metastability in those samples?

A typical method is to buffer the data in a FIFO which typically uses
Gray code counters for pointers. Input and output valid data enables can
be built into the FIFO.

I'm not sure what circuit you are describing. The circuit I have always
used is one where the enable or clock from the sending domain is run
through a handshake circuit that synchronizes it to the receiving
domain. If necessary the data is buffered in a register. A FIFO is
only needed when the data rate can burst faster than the receiving clock
rate.

I often use Block Ram based FIFO for moving line or block data from a
video source clock domain to memory and back again. Here I might use
flags to signify when a block of data is ready for the second clock domain.

In general the problem is reduced to having a single signal to denote
valid data. Where any uncertainty will not by itself corrupt data.

Hope that helps.

Another way to deal with the problem is to minimize and encapsulate it.
This means using a single clock for the entire FPGA design other than
the I/O interfaces where you sync the signals as soon as possible.

Rick

 

[Mike Perkins]

On 22/11/2012 17:33, rickman wrote:

On 11/22/2012 9:35 AM, Mike Perkins wrote:
On 22/11/2012 07:35, James823 wrote:
Hi,

I've been looking at synchronising data across clock domains, and
have managed to confuse myself. Can someone confirm (or correct
me) that the following is true.

Metastability may occur if the input D changes value during the
set-up and hold times, however the enable can be completely
asynchronous without ever causing a problem?

The enable is really a latch enable with all the same issues of
metastability of a clock.

If not, then even something as simple as testing a switch is
pressed would cause problems right?


There are a number of ways of achieving moving data across clock
domains.

Simplest is to use a fast clock, where the clock rate is many times
the data rate. The original data clock can be sampled to determine
when it transitions and the data read when it should be stable, if
necessary using suitably delayed data using parallel latches.

What??? How do you "sample" the input without dealing with
metastability in those samples?

By taking a latched clock being high say for 2 High-Speed clocks before
accepting it as a real clock-high.

A typical method is to buffer the data in a FIFO which typically
uses Gray code counters for pointers. Input and output valid data
enables can be built into the FIFO.

I'm not sure what circuit you are describing. The circuit I have
always used is one where the enable or clock from the sending domain
is run through a handshake circuit that synchronizes it to the
receiving domain. If necessary the data is buffered in a register.
A FIFO is only needed when the data rate can burst faster than the
receiving clock rate.

I agree, it depends on relative clock speeds, the continuity of data,
whilst it is sent, and how it can be received by each clock domain.

I often use Block Ram based FIFO for moving line or block data from
a video source clock domain to memory and back again. Here I might
use flags to signify when a block of data is ready for the second
clock domain.

In general the problem is reduced to having a single signal to
denote valid data. Where any uncertainty will not by itself corrupt
data.

Hope that helps.


Another way to deal with the problem is to minimize and encapsulate
it. This means using a single clock for the entire FPGA design other
than the I/O interfaces where you sync the signals as soon as
possible.

Entirely agree, but that's not always possible.

--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

 

[KJ]

On Thursday, November 22, 2012 2:35:31 AM UTC-5, James823 wrote:

however the enable can be completely asynchronous without ever causing a
problem?

The rule is that every input to a device that samples one signal with another will have either setup/hold or (frequently) both requirements. Flip flops, latches, memory, fifos are all examples of devices that sample one signal (the input data) with another signal (the clock).

It's not clear when you refer to 'enable' if you're referring to the clock enable of a flip flop (in which case the above rule applies since 'enable' is just another input to the logic feeding the flip flop). Or perhaps you mean a transparent latch (in which case the above rule applies...but setup/hold requirements will exist for the other signals relative to the active to inactive edge of the enable signal).

Even the supposed 'asynchronous' reset or preset input to a flip flop will have timing requirements. Specifically, the time that the reset/preset input is released will almost always need to be controlled relative to the clock. In most cases, it cannot be simply allowed to go inactive at any opint in the clock cycle.

Kevin Jennings

 

[James823]

On 11/22/2012 9:35 AM, Mike Perkins wrote:
On 22/11/2012 07:35, James823 wrote:
Hi,

I've been looking at synchronising data across clock domains, and have
managed to confuse myself.
Can someone confirm (or correct me) that the following is true.

Metastability may occur if the input D changes value during the set-up
and
hold times, however the enable can be completely asynchronous without
ever
causing a problem?

The enable is really a latch enable with all the same issues of
metastability of a clock.

[Mike]
This is where I have a problem. My understanding is that internally, th
clock is simply gated by the enable, so the effect of an asynchronou
enable is that the (clock AND enable) signal can have arbitrarily smal
pulse width, i.e. if the following occurs:
0) Initially clock is '0', enable is '1'
1) clock goes to '1'
2) enable goes to '0' after 1 ps or some other arbitrary time

Now, consider the standard NAND (or NOR) gate implementation as 2 layers o
SR latches. So long as the (clock AND enable) pulse width is sufficientl
long to propagate through the two NAND gates which it is connected, th
signal has now reached layer 1. Again, because the input was a pulse, s
too will this signal. The same thing now happens between the inputs t
layer 2, and the output updates.
The reason for metastability caused by D changing is that a change in
needs to propagate through 3 stages of NAND gates (due to the feedbac
structure) before it reaches the inputs to layer 2.
This explains why we now typically have negative hold times and positiv
set-up times. The clock takes 1 NAND propagation to get to the inputs o
layer 2, but the D signal takes 3, hence if the D signal changes 1 NAN
prop. time before the clock changes, the clock will reach the layer
inputs before the D signal i.e. negative hold time.

Following the signals through like this, I can't see any reason that
small pulse width will cause metastability at all. In fact the only issue
can see is that if the pulse is short enough, then the signal won'
propagate because of the capacitance of the gates and interna
interconnect. However, this just means that the signal never gets anywhere
so it's as if the pulse never occurred - hardly a problem at all.

Where's the flaw in my reasoning?

If not, then even something as simple as testing a switch is pressed
would
cause problems right?


There are a number of ways of achieving moving data across cloc
domains.

Simplest is to use a fast clock, where the clock rate is many times the
data rate. The original data clock can be sampled to determine when it
transitions and the data read when it should be stable, if necessary
using suitably delayed data using parallel latches.

What??? How do you "sample" the input without dealing with
metastability in those samples?

[Rickman]

This is exactly the reason that I started this thread - the more I though
about it, the more I realised that the clock rate to data rate ratio i
irrelevant, and it kind of pulled the rug from under me.


Thanks for the quick replies

---------------------------------------
Posted through http://www.FPGARelated.com

 

[glen herrmannsfeldt]

James823 <3681@embeddedrelated> wrote:

On 11/22/2012 9:35 AM, Mike Perkins wrote:

(snip)

The enable is really a latch enable with all the same issues of
metastability of a clock.

[Mike]
This is where I have a problem. My understanding is that internally, the
clock is simply gated by the enable, so the effect of an asynchronous
enable is that the (clock AND enable) signal can have arbitrarily small
pulse width, i.e. if the following occurs:
0) Initially clock is '0', enable is '1'
1) clock goes to '1'
2) enable goes to '0' after 1 ps or some other arbitrary time

Ones I know, have a MUX between Q and D before the FF logic.
Assuming a no-glitch MUX, if Q and D are the same, then there
should be no problem, but if they aren't, then it is the same
as changing D.

-- glen

 

[James823]

James823 <3681@embeddedrelated> wrote:
On 11/22/2012 9:35 AM, Mike Perkins wrote:

(snip)
The enable is really a latch enable with all the same issues of
metastability of a clock.

[Mike]
This is where I have a problem. My understanding is that internally
the
clock is simply gated by the enable, so the effect of an asynchronous
enable is that the (clock AND enable) signal can have arbitrarily small
pulse width, i.e. if the following occurs:
0) Initially clock is '0', enable is '1'
1) clock goes to '1'
2) enable goes to '0' after 1 ps or some other arbitrary time

Ones I know, have a MUX between Q and D before the FF logic.
Assuming a no-glitch MUX, if Q and D are the same, then there
should be no problem, but if they aren't, then it is the same
as changing D.

-- glen

I've noticed that this is how the compiler will synthesize code that ha
complicated enable logic, but for simpler code it uses the enable (at leas
using Quartus Web edition for a Cyclone II - the RTL viewer could be lyin
to me about the true synthesis implementation though).

The reason presumably is that having more than a small amount of logic o
the enable line effectively introduces a clock skew.

---------------------------------------
Posted through http://www.FPGARelated.com

 

[Jon Elson]

James823 wrote:

Hi,

I've been looking at synchronising data across clock domains, and have
managed to confuse myself.
Can someone confirm (or correct me) that the following is true.

Metastability may occur if the input D changes value during the set-up and
hold times, however the enable can be completely asynchronous without ever
causing a problem?

If not, then even something as simple as testing a switch is pressed would
cause problems right?
Metastability on modern CMOS processes is a pretty rare event. Supposedly,

Xilinx has found that the window for metastability on their FFs is
no more than a couple of ps wide! So, unless you have extremely fast
data rates or a timing that puts the transition right over the window,
it could take years for you to get one true metastable event.

The real logic hazard is for a signal that changes near the clock
edge to propagate through the chip in such a way that the transition
arrives before the clock at some FFs, and after the clock at some
others, either due to routing or combinatorial delays. A simple
state machine can be sent to never-never land when this occurs.
By properly synchronizing when crossing clock boundaries, you
allow the tools to be sure that no signal can change state too
close to the setup time and cause such a hazard.

Many people claim such problems were metastability, when they were
more prosaic logic hazards.

Jon

 

[Mike Perkins]

On 22/11/2012 19:42, James823 wrote:

On 11/22/2012 9:35 AM, Mike Perkins wrote:

[Mike]
This is where I have a problem. My understanding is that internally, the
clock is simply gated by the enable, so the effect of an asynchronous
enable is that the (clock AND enable) signal can have arbitrarily small
pulse width, i.e. if the following occurs:
0) Initially clock is '0', enable is '1'
1) clock goes to '1'
2) enable goes to '0' after 1 ps or some other arbitrary time

Now, consider the standard NAND (or NOR) gate implementation as 2 layers of
SR latches. So long as the (clock AND enable) pulse width is sufficiently
long to propagate through the two NAND gates which it is connected, the
signal has now reached layer 1. Again, because the input was a pulse, so
too will this signal. The same thing now happens between the inputs to
layer 2, and the output updates.
The reason for metastability caused by D changing is that a change in D
needs to propagate through 3 stages of NAND gates (due to the feedback
structure) before it reaches the inputs to layer 2.
This explains why we now typically have negative hold times and positive
set-up times. The clock takes 1 NAND propagation to get to the inputs of
layer 2, but the D signal takes 3, hence if the D signal changes 1 NAND
prop. time before the clock changes, the clock will reach the layer 2
inputs before the D signal i.e. negative hold time.

Following the signals through like this, I can't see any reason that a
small pulse width will cause metastability at all. In fact the only issue I
can see is that if the pulse is short enough, then the signal won't
propagate because of the capacitance of the gates and internal
interconnect. However, this just means that the signal never gets anywhere,
so it's as if the pulse never occurred - hardly a problem at all.

Where's the flaw in my reasoning?


If not, then even something as simple as testing a switch is pressed
would
cause problems right?


There are a number of ways of achieving moving data across clock
domains.

Simplest is to use a fast clock, where the clock rate is many times the
data rate. The original data clock can be sampled to determine when it
transitions and the data read when it should be stable, if necessary
using suitably delayed data using parallel latches.

What??? How do you "sample" the input without dealing with
metastability in those samples?

[Rickman]
This is exactly the reason that I started this thread - the more I thought
about it, the more I realised that the clock rate to data rate ratio is
irrelevant, and it kind of pulled the rug from under me.

This is my view and I open to criticism.

Metastability by itself is easy to either cope with or you can eliminate
it's effect. Some thoughts:

A consequence of a changing data input for a latch can cause uncertainty
of the latch output, and the worst case scenario is where the output is
indeterminate, at non high or low output level, ie at mid-level.

Generally that output will end up either high or low at the end of the
same clock period, however there is still a miniscule chance that this
will remain at an indeterminate level.

If this output is used by a further latch, depending on setup or hold
times the probability of still being indeterminate at this latch output
is reduced much further.
However if this output is used by a number of latches, then these will
have different thresholds, set-up and hold times such that these
subsequent latches may occasionally each produce a different result.
In this case I generally double latch the signal (or more) before making
it available for further circuitry.

However, when it comes to passing data, the real problem isn't so much
metastability, but clock skew and varying data routing delays. These
are far more likely to corrupt data.

In general, if you consider metastability first, then all else tends
falls into place.



--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

 

[Mike Perkins]

On 22/11/2012 19:42, James823 wrote:

On 11/22/2012 9:35 AM, Mike Perkins wrote:
On 22/11/2012 07:35, James823 wrote:
Hi,

I've been looking at synchronising data across clock domains, and have
managed to confuse myself.
Can someone confirm (or correct me) that the following is true.

Metastability may occur if the input D changes value during the set-up
and
hold times, however the enable can be completely asynchronous without
ever
causing a problem?

The enable is really a latch enable with all the same issues of
metastability of a clock.

[Mike]
This is where I have a problem. My understanding is that internally, the
clock is simply gated by the enable, so the effect of an asynchronous
enable is that the (clock AND enable) signal can have arbitrarily small
pulse width, i.e. if the following occurs:
0) Initially clock is '0', enable is '1'
1) clock goes to '1'
2) enable goes to '0' after 1 ps or some other arbitrary time

Now, consider the standard NAND (or NOR) gate implementation as 2 layers of
SR latches. So long as the (clock AND enable) pulse width is sufficiently
long to propagate through the two NAND gates which it is connected, the
signal has now reached layer 1. Again, because the input was a pulse, so
too will this signal. The same thing now happens between the inputs to
layer 2, and the output updates.
The reason for metastability caused by D changing is that a change in D
needs to propagate through 3 stages of NAND gates (due to the feedback
structure) before it reaches the inputs to layer 2.
This explains why we now typically have negative hold times and positive
set-up times. The clock takes 1 NAND propagation to get to the inputs of
layer 2, but the D signal takes 3, hence if the D signal changes 1 NAND
prop. time before the clock changes, the clock will reach the layer 2
inputs before the D signal i.e. negative hold time.

Following the signals through like this, I can't see any reason that a
small pulse width will cause metastability at all. In fact the only issue I
can see is that if the pulse is short enough, then the signal won't
propagate because of the capacitance of the gates and internal
interconnect. However, this just means that the signal never gets anywhere,
so it's as if the pulse never occurred - hardly a problem at all.

Where's the flaw in my reasoning?

Causes of metastability are different thresholds, different delays,
noise and a limited slew rate of signals.

I'm not sure if D-Type flip-flops are such simple affairs in FPGAs, nor
how an enable is implemented.

In short each latch has more than one gate driven by the D-input, and
within the latch each signal will likely drive more than one gate.
Hence metastability is inevitable.

--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

 

[rickman]

On 11/22/2012 1:40 PM, Mike Perkins wrote:

On 22/11/2012 17:33, rickman wrote:
On 11/22/2012 9:35 AM, Mike Perkins wrote:

Simplest is to use a fast clock, where the clock rate is many times
the data rate. The original data clock can be sampled to determine
when it transitions and the data read when it should be stable, if
necessary using suitably delayed data using parallel latches.

What??? How do you "sample" the input without dealing with
metastability in those samples?

By taking a latched clock being high say for 2 High-Speed clocks before
accepting it as a real clock-high.

You aren't seeing the picture. This doesn't solve metastability in any
meaningful way. The edge detection logic can still be "glitched" by
metastability and disrupt the rest of the circuit.

Easier is just to run the slow clock input through two FFs with no logic
between them and getting a metastability minimized signal. Then you can
use it as you wish.

Another way to deal with the problem is to minimize and encapsulate
it. This means using a single clock for the entire FPGA design other
than the I/O interfaces where you sync the signals as soon as
possible.

Entirely agree, but that's not always possible.

When is this not possible? The only limitation would be that the
"master" clock to rule them all has to be the fastest by enough margin
to accommodate the jitter in the two clocks. This prevents ever missing
a transition.

Rick

 

[rickman]

On 11/22/2012 11:59 PM, Jon Elson wrote:

James823 wrote:

Hi,

I've been looking at synchronising data across clock domains, and have
managed to confuse myself.
Can someone confirm (or correct me) that the following is true.

Metastability may occur if the input D changes value during the set-up and
hold times, however the enable can be completely asynchronous without ever
causing a problem?

If not, then even something as simple as testing a switch is pressed would
cause problems right?
Metastability on modern CMOS processes is a pretty rare event. Supposedly,
Xilinx has found that the window for metastability on their FFs is
no more than a couple of ps wide! So, unless you have extremely fast
data rates or a timing that puts the transition right over the window,
it could take years for you to get one true metastable event.

I don't have the stats memorized, but I don't think this is an accurate
description. If you design is truly async then the rate is such that
with a number of units in the field you will likely see failures long
before the warranty period is up... lol But by providing even as little
as two nanoseconds of settling time the probability is hugely reduced so
that it would then be years if not centuries between failures for
thousands of units.

But this is also related to the significance of a failure. If it is a
router handling Internet traffic in a user's home, I think a failure
once a month per unit will never be noticed. If it is a more critical
application a failure once a decade across the product line might be a
problem.

The real logic hazard is for a signal that changes near the clock
edge to propagate through the chip in such a way that the transition
arrives before the clock at some FFs, and after the clock at some
others, either due to routing or combinatorial delays. A simple
state machine can be sent to never-never land when this occurs.
By properly synchronizing when crossing clock boundaries, you
allow the tools to be sure that no signal can change state too
close to the setup time and cause such a hazard.

Static timing analysis is typically used to eliminate such timing
problems. That is FPGA 101 type stuff. Timing tools can't help you
with clock crossings, but they are easy to do if you pay attention and
don't miss any... that is the domain of project management.

Many people claim such problems were metastability, when they were
more prosaic logic hazards.

Yes, the two are sometimes confused.

Rick

 

[Mike Perkins]

On 23/11/2012 21:31, rickman wrote:

On 11/22/2012 1:40 PM, Mike Perkins wrote:
On 22/11/2012 17:33, rickman wrote:
On 11/22/2012 9:35 AM, Mike Perkins wrote:

Simplest is to use a fast clock, where the clock rate is many
times the data rate. The original data clock can be sampled to
determine when it transitions and the data read when it should
be stable, if necessary using suitably delayed data using
parallel latches.

What??? How do you "sample" the input without dealing with
metastability in those samples?

By taking a latched clock being high say for 2 High-Speed clocks
before accepting it as a real clock-high.

You aren't seeing the picture. This doesn't solve metastability in
any meaningful way. The edge detection logic can still be "glitched"
by metastability and disrupt the rest of the circuit.

I didn't explain myself very well.

The technique I was eluding to (badly) regards noisy and slow inputs
(such as from a PS2 mouse) is to have a counter; to count up when the
input is high, and to count down when the input is low. The output
would only be changed to a "1" if the counter was at maximum and changed
to a "0" if the counter was at minimum.

Easier is just to run the slow clock input through two FFs with no
logic between them and getting a metastability minimized signal.
Then you can use it as you wish.

I agree and I said earlier the same about being latched through two FFs.

Another way to deal with the problem is to minimize and
encapsulate it. This means using a single clock for the entire
FPGA design other than the I/O interfaces where you sync the
signals as soon as possible.

Entirely agree, but that's not always possible.

When is this not possible? The only limitation would be that the
"master" clock to rule them all has to be the fastest by enough
margin to accommodate the jitter in the two clocks. This prevents
ever missing a transition.

I was thinking of a modem example I came across where there were two
clocks at near FPGA max speed; where each interface could wander in
frequency either way. Given it was dealing with packets of data, it was
much easier to a Block RAM FIFO to cross clock domains.


--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:

On 11/22/2012 1:40 PM, Mike Perkins wrote:

(snip)

By taking a latched clock being high say for 2 High-Speed clocks before
accepting it as a real clock-high.

You aren't seeing the picture. This doesn't solve metastability in any
meaningful way. The edge detection logic can still be "glitched" by
metastability and disrupt the rest of the circuit.

Easier is just to run the slow clock input through two FFs with no logic
between them and getting a metastability minimized signal. Then you can
use it as you wish.

Well, how do you check if a signal was high for two clock cycles?
Seem to me that you delay it through two FF's and AND them together.

That could ignore real signals that are high for a short enough time,
but there really shouldn't be any of those. Doesn't seem a bad thing
to do in many cases.

Metastability resolves exponentially. It is pretty much only a problem
when the signal goes into logic with a propagation delay a large
fraction, maybe 80% or 90% of a clock cycle. In that case, the extra FF
multiplies the resolution time by a factor of 5 or 10, which decreases
the probability of a problem by a power of 5 to 10.

If it could happen one in 1e9 clock cycles without the extra FF, then
it will then be one in 1e45 to 1e90 clock cycles.

A am pretty sure no circuit has ever survives 1e90 clock cycles.

-- glen

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:

On 11/22/2012 11:59 PM, Jon Elson wrote:

(snip)

Metastability on modern CMOS processes is a pretty rare event. Supposedly,
Xilinx has found that the window for metastability on their FFs is
no more than a couple of ps wide! So, unless you have extremely fast
data rates or a timing that puts the transition right over the window,
it could take years for you to get one true metastable event.

For an asynchronous system, you usually assume that the probability
is uniform in time. So a 1GHz clock, with a pulse every ns, will
hit your 1ps window on in every 1000 times, about every microsecond.

I don't have the stats memorized, but I don't think this is an accurate
description. If you design is truly async then the rate is such that
with a number of units in the field you will likely see failures long
before the warranty period is up... lol But by providing even as little
as two nanoseconds of settling time the probability is hugely reduced so
that it would then be years if not centuries between failures for
thousands of units.

Well, an important thing left out is the resolution time. You need two
numbers, the window size (or probability) of going into a metastable
state, and the time constant (it goes into an exponent) on how long
you stay in that state. Even if the window is 1ps, if it resolves in
100ps you aren't likely to see it. (You really can't set the clock
period less than 90% of the actual delay, though most of that should
be included in the specifications.)

But this is also related to the significance of a failure. If it is a
router handling Internet traffic in a user's home, I think a failure
once a month per unit will never be noticed. If it is a more critical
application a failure once a decade across the product line might be a
problem.

Yes. But once it gets into the lifetime of the universe range,
it is usually good enough.

The real logic hazard is for a signal that changes near the clock
edge to propagate through the chip in such a way that the transition
arrives before the clock at some FFs, and after the clock at some
others, either due to routing or combinatorial delays. A simple
state machine can be sent to never-never land when this occurs.
By properly synchronizing when crossing clock boundaries, you
allow the tools to be sure that no signal can change state too
close to the setup time and cause such a hazard.

Static timing analysis is typically used to eliminate such timing
problems. That is FPGA 101 type stuff. Timing tools can't help you
with clock crossings, but they are easy to do if you pay attention and
don't miss any... that is the domain of project management.

Well, you have to have at least on FF on an asynchronous input.

Metastability says you should have two.

That still leaves the problem of multiple inputs. For FIFO's, the
solution is to use gray code. You get either the previous or new value
of the count, never any other values.

Many people claim such problems were metastability, when they were
more prosaic logic hazards.

Yes, the two are sometimes confused.

Yes, both the single and multiple input case show up in actual
designs.

-- glen

 

[glen herrmannsfeldt]

Mike Perkins <spam@spam.com> wrote:

On 23/11/2012 21:31, rickman wrote:
On 11/22/2012 1:40 PM, Mike Perkins wrote:

By taking a latched clock being high say for 2 High-Speed clocks
before accepting it as a real clock-high.

You aren't seeing the picture. This doesn't solve metastability in
any meaningful way. The edge detection logic can still be "glitched"
by metastability and disrupt the rest of the circuit.

I didn't explain myself very well.

The technique I was eluding to (badly) regards noisy and slow inputs
(such as from a PS2 mouse) is to have a counter; to count up when the
input is high, and to count down when the input is low. The output
would only be changed to a "1" if the counter was at maximum and changed
to a "0" if the counter was at minimum.

OK, this is for decoding the output of a quadrature encoder.

Even if you know the maximum rate, in the mouse case, how fast
the mouse could move, if it is sitting right on the edge the
outputs can change very often, or even stay between "0" and "1".

The fast clock method works well in that case. Properly designed,
only one input can be in a bad state at once, and the output can
switch between those values (+1 and -1).

-- glen

 

[glen herrmannsfeldt]

James823 <3681@embeddedrelated> wrote:

I've been looking at synchronising data across clock domains, and have
managed to confuse myself.
Can someone confirm (or correct me) that the following is true.

Metastability may occur if the input D changes value during the set-up and
hold times, however the enable can be completely asynchronous without ever
causing a problem?

The article http://www.technion.ac.il/~sbeer/publications/p3.pdf
seems to have some pretty good data (actual numbers) on
metastability.

-- glen