Digital Synchronization Question

[Jim Thompson]

Digital Guys,

Please refresh my mind as to bringing in an unsynchronized signal into
a system without incurring meta-stability.

I vaguely remember a two-rank D-flop scheme, but can't find my notes.

Thanks!

...Jim Thompson
--
| James E.Thompson, CTO | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |

I love to cook with wine. Sometimes I even put it in the food.

 

[Tim Wescott]

On 02/14/2011 06:22 PM, Jim Thompson wrote:

Digital Guys,

Please refresh my mind as to bringing in an unsynchronized signal into
a system without incurring meta-stability.

I vaguely remember a two-rank D-flop scheme, but can't find my notes.

That's about the size of it. Some folks like to use three, some folks
say the whole metastability thing is a crock.

Luminary Micro's Stellaris controllers put a counter on each pin, and
you could set it up to only recognize the change internally when the
counter saturated -- i.e., when the _outside_ went from 0 to 1, the
_inside_ would go (1, 2, 3, 4, 5, 6, 7) hey, you've got a 1!

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

 

[John Fields]

On Mon, 14 Feb 2011 19:22:08 -0700, Jim Thompson
<To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> wrote:

Digital Guys,

Please refresh my mind as to bringing in an unsynchronized signal into
a system without incurring meta-stability.

I vaguely remember a two-rank D-flop scheme, but can't find my notes.

Thanks!

...Jim Thompson

+----+ +----+
DIN>-----|D Q|---|D Q|-->DOUT
| | | |
+-|> | +-| |
| +----+ | +----+
| |
CLK>---+--------+

________________
/
DIN___/
_ _
| | | |
CLK____| |_| |_
____________
|
DOUT_______|

---
JF

 

[Bill Sloman]

On Feb 15, 3:22 am, Jim Thompson <To-Email-Use-The-Envelope-I...@On-My-
Web-Site.com> wrote:

Digital Guys,

Please refresh my mind as to bringing in an unsynchronized signal into
a system without incurring meta-stability.

I vaguely remember a two-rank D-flop scheme, but can't find my notes.

The problem that Jim is talking about is that for any clocked flip-
flop exposed to a signal that changes state at a time not synchronised
to the clock signal driving the flip-flop, the signal may be in
transition when the clock interogates the input.

Given this, the output may not settle to a one or a zero within the
time specified for the maximum propagantion time from clock to output.

It can be shown that there is an intermediate input voltage - between
the guaranteed highest "low" voltge and the guaranteed lowest "high"
voltage for which the output never settles but just sits there - in a
meta-stable intermediate state - until the next clock edge pick up a
different voltage level.

If the input voltage level is not within the guaranteed range, but not
exactly equal to the magic voltage required to set up the metastable
state, the metastable state will decay to either a high or low in a
finite time determined by the difference between the input voltage and
the magic voltage level. The "decay" curve is an exponential, starting
slowly and moving progressively more rapidly with time.

The time constant of the exponential is set by the internal resistance
inside the logic gate and the device capacitances. It's a lot shorter
for ECLinPS than for say CMOS.

So you can specify a (narrow) range of input voltages over which the
output won't reach the guaranteed logic levels in a specified time.

In the two-rank D-flip-flop scheme, the interval between suscessive
clock edges is the specified time, and that - plus the time constant
of the flip-flops involved - lets you specify the chance that you will
get an intermedidate output voltage for the the second flip-flop as
the chance that input to the first flip-flop will be in the dangerous
range.

Manufacturers wrote application notes telling people that this chance
could be made remarkably small ...

http://en.wikipedia.org/wiki/Metastability_in_electronics

--
Bill Sloman, Nijmegen

 

[John Larkin]

On Tue, 15 Feb 2011 01:52:30 -0800 (PST), Bill Sloman
<bill.sloman@ieee.org> wrote:

On Feb 15, 3:22 am, Jim Thompson <To-Email-Use-The-Envelope-I...@On-My-
Web-Site.com> wrote:
Digital Guys,

Please refresh my mind as to bringing in an unsynchronized signal into
a system without incurring meta-stability.

I vaguely remember a two-rank D-flop scheme, but can't find my notes.

The problem that Jim is talking about is that for any clocked flip-
flop exposed to a signal that changes state at a time not synchronised
to the clock signal driving the flip-flop, the signal may be in
transition when the clock interogates the input.

Given this, the output may not settle to a one or a zero within the
time specified for the maximum propagantion time from clock to output.

It can be shown that there is an intermediate input voltage - between
the guaranteed highest "low" voltge and the guaranteed lowest "high"
voltage for which the output never settles but just sits there - in a
meta-stable intermediate state - until the next clock edge pick up a
different voltage level.

What's more insidious is that some flipflops oscillate for a while if
teased. The ones that do that tend to be symmetric structures, classis
cross-coupled multivibrator architectures. LS is notorious for being
able to oscillate for microseconds if it's hit just right.
Transmission-gate CMOS parts are more likely to go into the classic
bowling-ball-on-the-hill mode, and to resolve quickly.

I think what's insidious about the oscillatory mode is that loop gain
is limited by saturation, and the multivibrator symmetry makes things
just run around in circles. The only way out is duty-cycle creep,
which can take 10s of cycles for an LS74.

LS was a truly terrible logic family.

If the input voltage level is not within the guaranteed range, but not
exactly equal to the magic voltage required to set up the metastable
state, the metastable state will decay to either a high or low in a
finite time determined by the difference between the input voltage and
the magic voltage level. The "decay" curve is an exponential, starting
slowly and moving progressively more rapidly with time.

The time constant of the exponential is set by the internal resistance
inside the logic gate and the device capacitances. It's a lot shorter
for ECLinPS than for say CMOS.

ECL flops are also symmetric, but they usually resolve either
monotonically, or after one ring.

John

 

[Jim Thompson]

On Tue, 15 Feb 2011 03:53:32 -0600, John Fields
<jfields@austininstruments.com> wrote:

On Mon, 14 Feb 2011 19:22:08 -0700, Jim Thompson
To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> wrote:

Digital Guys,

Please refresh my mind as to bringing in an unsynchronized signal into
a system without incurring meta-stability.

I vaguely remember a two-rank D-flop scheme, but can't find my notes.

Thanks!

...Jim Thompson

+----+ +----+
DIN>-----|D Q|---|D Q|-->DOUT
| | | |
+-|> | +-| |
| +----+ | +----+
| |
CLK>---+--------+

________________
/
DIN___/
_ _
| | | |
CLK____| |_| |_
____________
|
DOUT_______|

---
JF

Thanks, John F! That's what I vaguely remembered.

...Jim Thompson
--
| James E.Thompson, CTO | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |

Remember: Once you go over the hill, you pick up speed

 

[Muzaffer Kal]

On Mon, 14 Feb 2011 19:22:08 -0700, Jim Thompson
<To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> wrote:

Digital Guys,

Please refresh my mind as to bringing in an unsynchronized signal into
a system without incurring meta-stability.

No can do. You can't avoid metastability, you can only reduce the

probability; albeit to a level completely safe.

I vaguely remember a two-rank D-flop scheme, but can't find my notes.

What's needed is a shift register of length N. N=2 is most common but
can be increased depending on the circumstances based on sampling
clock speed, signal rate and desired MTBF.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

 

[Hal Murray]

In article <pmojl65srq9b1aqlfh0o3r5fm3fo7hniur@4ax.com>,
Jim Thompson <To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> writes:

Digital Guys,

Please refresh my mind as to bringing in an unsynchronized signal into
a system without incurring meta-stability.

I vaguely remember a two-rank D-flop scheme, but can't find my notes.

There are two key ideas:
1) You can't fix it. You can only reduce the probability.
Fortunately, in most cases, you can make the MTBF be very
big, like the age of the universe.

2) To reduce the MTBF, add more settling time between those 2 FFs.
The settling time is cycle time minus clock-out minus setup, the
excess time if you weren't interested in metastability.

3) If you find a paper describing a wonderful circuit that is going
to fix metastability, see rule 1. (I got pretty good at finding the
bug. Usually they made it worse as well as harder to analyse.)

Johnson and Graham have a good discussion starting on page 120
of High-Speed Digital Design (aka Black Magic).


In the old days, we would just blindly use 2 FFs without really
understanding what was going on. That mostly works. The system
usually had something slow like an adder or PROM that was limiting
the cycle time so the prop time through that slow path turned
into your settling time. You could get in trouble if you picked
the FFs from another logic family to save power or tried to sneak
a gate in there or used the other edge to reduce latency or ...

With modern FPGAs, you can get in trouble if you put the FFs
far apart and use up all the excess time for routing.


In order to compute MTBF, you need 2 parameters. One is the
probability of going metastable. The other is the recovery rate.

One is the size of the window. The probably of going metastable
depends on the product of how fast the data changes, the clock
rate for your FFs, and the window size.

The second number is the recovery rate. If it goes metastable,
the probably that it will not settle is exponential to the
magic number times the settling time.

The MTBF is the product of your chances of going metastable
and the chances of not recovering.

The constants depend on the technology and on the specific part.

It's hard to find those numbers. Sometimes you can find an app-note,
but they just give you a few typicals from some lab tests with no
hints at what worst case numbers might be.

If you can find those numbers, you can plug them into your setup
and get a guestimate of the MTBF. If you are lucky, you will get
something with a lot of 0s in the exponent. If you don't have
enough 0s, then you get to think harder.

--
These are my opinions, not necessarily my employer's. I hate spam.

 

[Phil Hobbs]

Hal Murray wrote:

In article<pmojl65srq9b1aqlfh0o3r5fm3fo7hniur@4ax.com>,
Jim Thompson<To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> writes:
Digital Guys,

Please refresh my mind as to bringing in an unsynchronized signal into
a system without incurring meta-stability.

I vaguely remember a two-rank D-flop scheme, but can't find my notes.

There are two key ideas:
1) You can't fix it. You can only reduce the probability.
Fortunately, in most cases, you can make the MTBF be very
big, like the age of the universe.

2) To reduce the MTBF, add more settling time between those 2 FFs.
The settling time is cycle time minus clock-out minus setup, the
excess time if you weren't interested in metastability.

3) If you find a paper describing a wonderful circuit that is going
to fix metastability, see rule 1. (I got pretty good at finding the
bug. Usually they made it worse as well as harder to analyse.)

Johnson and Graham have a good discussion starting on page 120
of High-Speed Digital Design (aka Black Magic).


In the old days, we would just blindly use 2 FFs without really
understanding what was going on. That mostly works. The system
usually had something slow like an adder or PROM that was limiting
the cycle time so the prop time through that slow path turned
into your settling time. You could get in trouble if you picked
the FFs from another logic family to save power or tried to sneak
a gate in there or used the other edge to reduce latency or ...

With modern FPGAs, you can get in trouble if you put the FFs
far apart and use up all the excess time for routing.


In order to compute MTBF, you need 2 parameters. One is the
probability of going metastable. The other is the recovery rate.

One is the size of the window. The probably of going metastable
depends on the product of how fast the data changes, the clock
rate for your FFs, and the window size.

The second number is the recovery rate. If it goes metastable,
the probably that it will not settle is exponential to the
magic number times the settling time.

The MTBF is the product of your chances of going metastable
and the chances of not recovering.

The constants depend on the technology and on the specific part.

It's hard to find those numbers. Sometimes you can find an app-note,
but they just give you a few typicals from some lab tests with no
hints at what worst case numbers might be.

If you can find those numbers, you can plug them into your setup
and get a guestimate of the MTBF. If you are lucky, you will get
something with a lot of 0s in the exponent. If you don't have
enough 0s, then you get to think harder.

With jellybean logic, you can find out pretty fast by using a trombone
line to adjust the clock phase.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
ElectroOptical Innovations
55 Orchard Rd
Briarcliff Manor NY 10510
845-480-2058

email: hobbs (atsign) electrooptical (period) net
http://electrooptical.net

 

[John Larkin]

On Mon, 28 Feb 2011 11:35:12 -0500, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

Hal Murray wrote:
In article<pmojl65srq9b1aqlfh0o3r5fm3fo7hniur@4ax.com>,
Jim Thompson<To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> writes:
Digital Guys,

Please refresh my mind as to bringing in an unsynchronized signal into
a system without incurring meta-stability.

I vaguely remember a two-rank D-flop scheme, but can't find my notes.

There are two key ideas:
1) You can't fix it. You can only reduce the probability.
Fortunately, in most cases, you can make the MTBF be very
big, like the age of the universe.

2) To reduce the MTBF, add more settling time between those 2 FFs.
The settling time is cycle time minus clock-out minus setup, the
excess time if you weren't interested in metastability.

3) If you find a paper describing a wonderful circuit that is going
to fix metastability, see rule 1. (I got pretty good at finding the
bug. Usually they made it worse as well as harder to analyse.)

Johnson and Graham have a good discussion starting on page 120
of High-Speed Digital Design (aka Black Magic).


In the old days, we would just blindly use 2 FFs without really
understanding what was going on. That mostly works. The system
usually had something slow like an adder or PROM that was limiting
the cycle time so the prop time through that slow path turned
into your settling time. You could get in trouble if you picked
the FFs from another logic family to save power or tried to sneak
a gate in there or used the other edge to reduce latency or ...

With modern FPGAs, you can get in trouble if you put the FFs
far apart and use up all the excess time for routing.


In order to compute MTBF, you need 2 parameters. One is the
probability of going metastable. The other is the recovery rate.

One is the size of the window. The probably of going metastable
depends on the product of how fast the data changes, the clock
rate for your FFs, and the window size.

The second number is the recovery rate. If it goes metastable,
the probably that it will not settle is exponential to the
magic number times the settling time.

The MTBF is the product of your chances of going metastable
and the chances of not recovering.

The constants depend on the technology and on the specific part.

It's hard to find those numbers. Sometimes you can find an app-note,
but they just give you a few typicals from some lab tests with no
hints at what worst case numbers might be.

If you can find those numbers, you can plug them into your setup
and get a guestimate of the MTBF. If you are lucky, you will get
something with a lot of 0s in the exponent. If you don't have
enough 0s, then you get to think harder.


With jellybean logic, you can find out pretty fast by using a trombone
line to adjust the clock phase.

Cheers

Phil Hobbs

It's common to use bang-bang feedback loops to tease setup/hold times
into the metastable region. You can add a small triangle wave time
sweep to quantify the results. That can gather data a lot faster than
using two unsynchronized clocks.

Peter Alfke, the former Xilinx guru, claimed that the flops inside
their chips resolved so fast that metastability could be ignored. Some
flipflop architectures do settle a lot faster than others.

John

 

[Phil Hobbs]

John Larkin wrote:

On Mon, 28 Feb 2011 11:35:12 -0500, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

Hal Murray wrote:
In article<pmojl65srq9b1aqlfh0o3r5fm3fo7hniur@4ax.com>,
Jim Thompson<To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> writes:
Digital Guys,

Please refresh my mind as to bringing in an unsynchronized signal into
a system without incurring meta-stability.

I vaguely remember a two-rank D-flop scheme, but can't find my notes.

There are two key ideas:
1) You can't fix it. You can only reduce the probability.
Fortunately, in most cases, you can make the MTBF be very
big, like the age of the universe.

2) To reduce the MTBF, add more settling time between those 2 FFs.
The settling time is cycle time minus clock-out minus setup, the
excess time if you weren't interested in metastability.

3) If you find a paper describing a wonderful circuit that is going
to fix metastability, see rule 1. (I got pretty good at finding the
bug. Usually they made it worse as well as harder to analyse.)

Johnson and Graham have a good discussion starting on page 120
of High-Speed Digital Design (aka Black Magic).


In the old days, we would just blindly use 2 FFs without really
understanding what was going on. That mostly works. The system
usually had something slow like an adder or PROM that was limiting
the cycle time so the prop time through that slow path turned
into your settling time. You could get in trouble if you picked
the FFs from another logic family to save power or tried to sneak
a gate in there or used the other edge to reduce latency or ...

With modern FPGAs, you can get in trouble if you put the FFs
far apart and use up all the excess time for routing.


In order to compute MTBF, you need 2 parameters. One is the
probability of going metastable. The other is the recovery rate.

One is the size of the window. The probably of going metastable
depends on the product of how fast the data changes, the clock
rate for your FFs, and the window size.

The second number is the recovery rate. If it goes metastable,
the probably that it will not settle is exponential to the
magic number times the settling time.

The MTBF is the product of your chances of going metastable
and the chances of not recovering.

The constants depend on the technology and on the specific part.

It's hard to find those numbers. Sometimes you can find an app-note,
but they just give you a few typicals from some lab tests with no
hints at what worst case numbers might be.

If you can find those numbers, you can plug them into your setup
and get a guestimate of the MTBF. If you are lucky, you will get
something with a lot of 0s in the exponent. If you don't have
enough 0s, then you get to think harder.


With jellybean logic, you can find out pretty fast by using a trombone
line to adjust the clock phase.

Cheers

Phil Hobbs

It's common to use bang-bang feedback loops to tease setup/hold times
into the metastable region. You can add a small triangle wave time
sweep to quantify the results. That can gather data a lot faster than
using two unsynchronized clocks.

Peter Alfke, the former Xilinx guru, claimed that the flops inside
their chips resolved so fast that metastability could be ignored. Some
flipflop architectures do settle a lot faster than others.

John

Needs a nice low-jitter clock, though--trombone lines keep the data
perfectly phase coherent with the clock.

You could probably do pretty well with a slightly unbalanced line and a
DDS to change the clock frequency.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
ElectroOptical Innovations
55 Orchard Rd
Briarcliff Manor NY 10510
845-480-2058

email: hobbs (atsign) electrooptical (period) net
http://electrooptical.net

 

[John Larkin]

On Mon, 28 Feb 2011 10:09:42 -0800 (PST), "langwadt@fonz.dk"
<langwadt@fonz.dk> wrote:

On 28 Feb., 17:55, John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Mon, 28 Feb 2011 11:35:12 -0500, Phil Hobbs



pcdhSpamMeSensel...@electrooptical.net> wrote:
Hal Murray wrote:
In article<pmojl65srq9b1aqlfh0o3r5fm3fo7hn...@4ax.com>,
  Jim Thompson<To-Email-Use-The-Envelope-I...@On-My-Web-Site.com>  writes:
Digital Guys,

Please refresh my mind as to bringing in an unsynchronized signal into
a system without incurring meta-stability.

I vaguely remember a two-rank D-flop scheme, but can't find my notes.

There are two key ideas:
1) You can't fix it.  You can only reduce the probability.
   Fortunately, in most cases, you can make the MTBF be very
   big, like the age of the universe.

2) To reduce the MTBF, add more settling time between those 2 FFs.
The settling time is cycle time minus clock-out minus setup, the
excess time if you weren't interested in metastability.

3) If you find a paper describing a wonderful circuit that is going
to fix metastability, see rule 1.  (I got pretty good at finding the
bug.  Usually they made it worse as well as harder to analyse.)

Johnson and Graham have a good discussion starting on page 120
of High-Speed Digital Design (aka Black Magic).

In the old days, we would just blindly use 2 FFs without really
understanding what was going on.  That mostly works.  The system
usually had something slow like an adder or PROM that was limiting
the cycle time so the prop time through that slow path turned
into your settling time.  You could get in trouble if you picked
the FFs from another logic family to save power or tried to sneak
a gate in there or used the other edge to reduce latency or ...

With modern FPGAs, you can get in trouble if you put the FFs
far apart and use up all the excess time for routing.

In order to compute MTBF, you need 2 parameters.  One is the
probability of going metastable.  The other is the recovery rate.

One is the size of the window.  The probably of going metastable
depends on the product of how fast the data changes, the clock
rate for your FFs, and the window size.

The second number is the recovery rate.  If it goes metastable,
the probably that it will not settle is exponential to the
magic number times the settling time.

The MTBF is the product of your chances of going metastable
and the chances of not recovering.

The constants depend on the technology and on the specific part.

It's hard to find those numbers.  Sometimes you can find an app-note,
but they just give you a few typicals from some lab tests with no
hints at what worst case numbers might be.

If you can find those numbers, you can plug them into your setup
and get a guestimate of the MTBF.  If you are lucky, you will get
something with a lot of 0s in the exponent.  If you don't have
enough 0s, then you get to think harder.

With jellybean logic, you can find out pretty fast by using a trombone
line to adjust the clock phase.

Cheers

Phil Hobbs

It's common to use bang-bang feedback loops to tease setup/hold times
into the metastable region. You can add a small triangle wave time
sweep to quantify the results. That can gather data a lot faster than
using two unsynchronized clocks.

Peter Alfke, the former Xilinx guru, claimed that the flops inside
their chips resolved so fast that metastability could be ignored. Some
flipflop architectures do settle a lot faster than others.

John

but even if metastability can be ignored a flop or two is needed as
synchronizer
async signal go to more that one flop because they may not all see the
signal change if it is close to a clock edge

-Lasse

Our rule is that an async input should never go to more than one
synchronizer flop. That becomes a race problem, a much worse hazard
than metastability.

John

 

[langwadt@fonz.dk]

On 28 Feb., 17:55, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:

On Mon, 28 Feb 2011 11:35:12 -0500, Phil Hobbs



pcdhSpamMeSensel...@electrooptical.net> wrote:
Hal Murray wrote:
In article<pmojl65srq9b1aqlfh0o3r5fm3fo7hn...@4ax.com>,
  Jim Thompson<To-Email-Use-The-Envelope-I...@On-My-Web-Site.com>  writes:
Digital Guys,

Please refresh my mind as to bringing in an unsynchronized signal into
a system without incurring meta-stability.

I vaguely remember a two-rank D-flop scheme, but can't find my notes.

There are two key ideas:
1) You can't fix it.  You can only reduce the probability.
   Fortunately, in most cases, you can make the MTBF be very
   big, like the age of the universe.

2) To reduce the MTBF, add more settling time between those 2 FFs.
The settling time is cycle time minus clock-out minus setup, the
excess time if you weren't interested in metastability.

3) If you find a paper describing a wonderful circuit that is going
to fix metastability, see rule 1.  (I got pretty good at finding the
bug.  Usually they made it worse as well as harder to analyse.)

Johnson and Graham have a good discussion starting on page 120
of High-Speed Digital Design (aka Black Magic).

In the old days, we would just blindly use 2 FFs without really
understanding what was going on.  That mostly works.  The system
usually had something slow like an adder or PROM that was limiting
the cycle time so the prop time through that slow path turned
into your settling time.  You could get in trouble if you picked
the FFs from another logic family to save power or tried to sneak
a gate in there or used the other edge to reduce latency or ...

With modern FPGAs, you can get in trouble if you put the FFs
far apart and use up all the excess time for routing.

In order to compute MTBF, you need 2 parameters.  One is the
probability of going metastable.  The other is the recovery rate.

One is the size of the window.  The probably of going metastable
depends on the product of how fast the data changes, the clock
rate for your FFs, and the window size.

The second number is the recovery rate.  If it goes metastable,
the probably that it will not settle is exponential to the
magic number times the settling time.

The MTBF is the product of your chances of going metastable
and the chances of not recovering.

The constants depend on the technology and on the specific part.

It's hard to find those numbers.  Sometimes you can find an app-note,
but they just give you a few typicals from some lab tests with no
hints at what worst case numbers might be.

If you can find those numbers, you can plug them into your setup
and get a guestimate of the MTBF.  If you are lucky, you will get
something with a lot of 0s in the exponent.  If you don't have
enough 0s, then you get to think harder.

With jellybean logic, you can find out pretty fast by using a trombone
line to adjust the clock phase.

Cheers

Phil Hobbs

It's common to use bang-bang feedback loops to tease setup/hold times
into the metastable region. You can add a small triangle wave time
sweep to quantify the results. That can gather data a lot faster than
using two unsynchronized clocks.

Peter Alfke, the former Xilinx guru, claimed that the flops inside
their chips resolved so fast that metastability could be ignored. Some
flipflop architectures do settle a lot faster than others.

John

but even if metastability can be ignored a flop or two is needed as
synchronizer
async signal go to more that one flop because they may not all see the
signal change if it is close to a clock edge

-Lasse

 

[langwadt@fonz.dk]

On 28 Feb., 19:59, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:

On Mon, 28 Feb 2011 10:09:42 -0800 (PST), "langw...@fonz.dk"



langw...@fonz.dk> wrote:
On 28 Feb., 17:55, John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Mon, 28 Feb 2011 11:35:12 -0500, Phil Hobbs

pcdhSpamMeSensel...@electrooptical.net> wrote:
Hal Murray wrote:
In article<pmojl65srq9b1aqlfh0o3r5fm3fo7hn...@4ax.com>,
Jim Thompson<To-Email-Use-The-Envelope-I...@On-My-Web-Site.com> writes:
Digital Guys,

Please refresh my mind as to bringing in an unsynchronized signal into
a system without incurring meta-stability.

I vaguely remember a two-rank D-flop scheme, but can't find my notes.

There are two key ideas:
1) You can't fix it. You can only reduce the probability.
Fortunately, in most cases, you can make the MTBF be very
big, like the age of the universe.

2) To reduce the MTBF, add more settling time between those 2 FFs.
The settling time is cycle time minus clock-out minus setup, the
excess time if you weren't interested in metastability.

3) If you find a paper describing a wonderful circuit that is going
to fix metastability, see rule 1. (I got pretty good at finding the
bug. Usually they made it worse as well as harder to analyse.)

Johnson and Graham have a good discussion starting on page 120
of High-Speed Digital Design (aka Black Magic).

In the old days, we would just blindly use 2 FFs without really
understanding what was going on. That mostly works. The system
usually had something slow like an adder or PROM that was limiting
the cycle time so the prop time through that slow path turned
into your settling time. You could get in trouble if you picked
the FFs from another logic family to save power or tried to sneak
a gate in there or used the other edge to reduce latency or ...

With modern FPGAs, you can get in trouble if you put the FFs
far apart and use up all the excess time for routing.

In order to compute MTBF, you need 2 parameters. One is the
probability of going metastable. The other is the recovery rate.

One is the size of the window. The probably of going metastable
depends on the product of how fast the data changes, the clock
rate for your FFs, and the window size.

The second number is the recovery rate. If it goes metastable,
the probably that it will not settle is exponential to the
magic number times the settling time.

The MTBF is the product of your chances of going metastable
and the chances of not recovering.

The constants depend on the technology and on the specific part.

It's hard to find those numbers. Sometimes you can find an app-note,
but they just give you a few typicals from some lab tests with no
hints at what worst case numbers might be.

If you can find those numbers, you can plug them into your setup
and get a guestimate of the MTBF. If you are lucky, you will get
something with a lot of 0s in the exponent. If you don't have
enough 0s, then you get to think harder.

With jellybean logic, you can find out pretty fast by using a trombone
line to adjust the clock phase.

Cheers

Phil Hobbs

It's common to use bang-bang feedback loops to tease setup/hold times
into the metastable region. You can add a small triangle wave time
sweep to quantify the results. That can gather data a lot faster than
using two unsynchronized clocks.

Peter Alfke, the former Xilinx guru, claimed that the flops inside
their chips resolved so fast that metastability could be ignored. Some
flipflop architectures do settle a lot faster than others.

John

but even if metastability can be ignored a flop or two is needed as
synchronizer
async signal go to more that one flop because they may not all see the
signal change if it is close to a clock edge

-Lasse

Our rule is that an async input should never go to more than one
synchronizer flop. That becomes a race problem, a much worse hazard
than metastability.

John

exactly a state machine where only some the flops see a state changing
signal
can really go off to lala land

same reason async reset should be done carefully

-Lasse