Mitigating metastability.

Hi,
    Before I start, metastability is like death and taxes,
unavoidable! That said, I've read the latest metastability thread. I
thought these points were interesting.

Firstly, A quote from Peter, who has carried out a most thorough
experimental investigation :-
"I have never seen strange levels or oscillations ( well, 25 years ago
we had TTL oscillations). Metastability just affects the delay on the
Q output."

Secondly, from Philip's excellent FAQ :-
"Metastable outputs can be 

1)      Oscillations from Voh to Vol, that eventually stop. 
2)      Oscillations that occur (and may not even cross) Voh and Vol 
3)      A stable signal between Voh and Vol, that eventually resolves.
4)      A signal that transitions to the opposite state of the pre
clock
        state, and then some time later (without a clock edge)
transitions
        back to the original state. 
5)      A signal that transitions to the oposite state later than the 
        specified clock-to-output delay. 
6)      Probably some more that I haven't remembered. "

	So, this got me thinking on the best way to mitigate the effects of
metastability. If Peter is correct in his analysis of his experimental
data, and I've no reason to doubt this, then Philip's option 5) is the
form of metastability appearing in Peter's Xilinx FPGA experiments.

	So, bearing this in mind, a thought experiment. We have an async
input, moving to a synchronising clock domain at (say) 1000MHz. Say we
have a budget of 5ns of latency to mitigate metastability. The sample
is captured after the metastability mitigation circuit (MMC) with a FF
called the output FF.
	My first question is, which of these choices of MMC is least likely
to produce metastability at the output FF?
1) The MMC is a 4 FF long shift register clocked at 1000MHz.
MMC1 : process(clock)
begin
  if rising_edge(clock) then
    FF1 <= input;
    FF2 <= FF1;
    FF3 <= FF2;
    FF4 <= FF3;
    output <= FF4;
  end if;
end process;

2) The MMC is 4 FFs, each clock enabled every second clock.
MMC2 : process(clock)
begin
  if rising_edge(clock) then
    toggle <= not toggle;
    if toggle = '1' then
      FF1 <= input;
      FF3 <= FF1;
      output <= FF3;
    else
      FF2 <= input;
      FF4 <= FF2;
      output <= FF4;
    end if;
  end if;
end process;

	Option 1) offers extra stages of synchronization between the input
and output, but the 1ns gap between FFs means that metastability is
more likely to propagate. Option 2) waits 2ns for the sample FFs to
make up their mind, vastly decreasing the metastability probability.
	My second question is, does the type of metastability, i.e. the
things in Philip's list, affect which is the better choice? For
instance, if the first FF in the MMC exhibits oscillations in
metastability, then the second FF in the MMC would have several
chances, as its input oscillates, to sample at the 'wrong' time. This
might favour MMC option 2). If, however, the first FF in the MMC goes
into option 5) metastability, then there's only one chance for the
second FF to sample at the 'wrong' time. This might confer an
advantage on MMC option 1).

	Anyway, I'm still thinking about this. I think the clock frequency
may decide which is better for a given FF type. Any comments?
                       Cheers, Syms.

All you need to answer these questions is the equation that describes
your metastability.  That is contained in most of the references that
have been given.  The settling time is found in an exponent, so using
two FFs with half the time of a single FF will make the problem worse,
not better.   

The best (and only) way to resolve metastability is to provide more
time.  The probability never goes to zero, but you can get arbitrarily
close.  


Symon wrote:
> 
> Hi,
>     Before I start, metastability is like death and taxes,
> unavoidable! That said, I've read the latest metastability thread. I
> thought these points were interesting.
> 
> Firstly, A quote from Peter, who has carried out a most thorough
> experimental investigation :-
> "I have never seen strange levels or oscillations ( well, 25 years ago
> we had TTL oscillations). Metastability just affects the delay on the
> Q output."
> 
> Secondly, from Philip's excellent FAQ :-
> "Metastable outputs can be
> 
> 1)      Oscillations from Voh to Vol, that eventually stop.
> 2)      Oscillations that occur (and may not even cross) Voh and Vol
> 3)      A stable signal between Voh and Vol, that eventually resolves.
> 4)      A signal that transitions to the opposite state of the pre
> clock
>         state, and then some time later (without a clock edge)
> transitions
>         back to the original state.
> 5)      A signal that transitions to the oposite state later than the
>         specified clock-to-output delay.
> 6)      Probably some more that I haven't remembered. "
> 
>         So, this got me thinking on the best way to mitigate the effects of
> metastability. If Peter is correct in his analysis of his experimental
> data, and I've no reason to doubt this, then Philip's option 5) is the
> form of metastability appearing in Peter's Xilinx FPGA experiments.
> 
>         So, bearing this in mind, a thought experiment. We have an async
> input, moving to a synchronising clock domain at (say) 1000MHz. Say we
> have a budget of 5ns of latency to mitigate metastability. The sample
> is captured after the metastability mitigation circuit (MMC) with a FF
> called the output FF.
>         My first question is, which of these choices of MMC is least likely
> to produce metastability at the output FF?
> 1) The MMC is a 4 FF long shift register clocked at 1000MHz.
> MMC1 : process(clock)
> begin
>   if rising_edge(clock) then
>     FF1 <= input;
>     FF2 <= FF1;
>     FF3 <= FF2;
>     FF4 <= FF3;
>     output <= FF4;
>   end if;
> end process;
> 
> 2) The MMC is 4 FFs, each clock enabled every second clock.
> MMC2 : process(clock)
> begin
>   if rising_edge(clock) then
>     toggle <= not toggle;
>     if toggle = '1' then
>       FF1 <= input;
>       FF3 <= FF1;
>       output <= FF3;
>     else
>       FF2 <= input;
>       FF4 <= FF2;
>       output <= FF4;
>     end if;
>   end if;
> end process;
> 
>         Option 1) offers extra stages of synchronization between the input
> and output, but the 1ns gap between FFs means that metastability is
> more likely to propagate. Option 2) waits 2ns for the sample FFs to
> make up their mind, vastly decreasing the metastability probability.
>         My second question is, does the type of metastability, i.e. the
> things in Philip's list, affect which is the better choice? For
> instance, if the first FF in the MMC exhibits oscillations in
> metastability, then the second FF in the MMC would have several
> chances, as its input oscillates, to sample at the 'wrong' time. This
> might favour MMC option 2). If, however, the first FF in the MMC goes
> into option 5) metastability, then there's only one chance for the
> second FF to sample at the 'wrong' time. This might confer an
> advantage on MMC option 1).
> 
>         Anyway, I'm still thinking about this. I think the clock frequency
> may decide which is better for a given FF type. Any comments?
>                        Cheers, Syms.

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

>	My first question is, which of these choices of MMC is least likely
>to produce metastability at the output FF?

>1) The MMC is a 4 FF long shift register clocked at 1000MHz.

>2) The MMC is 4 FFs, each clock enabled every second clock.

You should also consider 1 FF clocked as late as you can wait.

Each FF has a setup time and a clock-output delay.  I'm talking
about the actual measured time, not the data book worst case times.

If you chain FFs together, that time gets subtracted from the
settling time.  The settling time is in an exponent.  Waiting a
little bit longer helps a lot.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

On 29 Aug 2003 16:23:32 -0700, symon_brewer@hotmail.com (Symon) wrote:
>Hi,
>    Before I start, metastability is like death and taxes,
>unavoidable! That said, I've read the latest metastability thread. I
>thought these points were interesting.
>
>Firstly, A quote from Peter, who has carried out a most thorough
>experimental investigation :-
>"I have never seen strange levels or oscillations ( well, 25 years ago
>we had TTL oscillations). Metastability just affects the delay on the
>Q output."
>
>
>Secondly, from Philip's excellent FAQ :-

Thanks.

>"Metastable outputs can be 
>
>1)      Oscillations from Voh to Vol, that eventually stop. 
>2)      Oscillations that occur (and may not even cross) Voh and Vol 
>3)      A stable signal between Voh and Vol, that eventually resolves.
>4)      A signal that transitions to the opposite state of the pre
>        clock state, and then some time later (without a clock edge)
>        transitions back to the original state. 
>5)      A signal that transitions to the oposite state later than the 
>        specified clock-to-output delay. 
>6)      Probably some more that I haven't remembered. "
>
>	So, this got me thinking on the best way to mitigate the effects of
>metastability. If Peter is correct in his analysis of his experimental
>data, and I've no reason to doubt this, then Philip's option 5) is the
>form of metastability appearing in Peter's Xilinx FPGA experiments.

Peter's experimental data revolves around detecting metastables, and
counting them to create the data we use for our calculations.
Very good stuff!

I too have created metastability test systems, which not only count
the metastables, but also display them on an osciloscope.

I would like to make a very strong distinction about the typically
presented scope pictures of metastability, and the data that I have
taken.

What you normally see published (in terms of scope photos, as opposed
to drawn diagrams) is a screen of dots representing samples of the Q
output. These scopes are high bandwidth sampling scopes that typically
take 1 sample per sweep, and rely on the signal being repetitive to
build up a picture of what is going on. Examples are the Tek 11801 and
11803, as well as the newer TDS7000 and TDS8000 . The CSA11803 and
CSA8000 are basically the same scopes with some extra software.

The picture at the top of page 3 of this document is typical:

    http://www.onsemi.com/pub/Collateral/AN1504-D.PDF

The scope is triggered by the same clock as the clock to the device
under test (DUT), and the scope takes a random sample (or maybe a
few samples) over the duration of the sweep. Most sweeps are of
the flip flop not going metastable, and so the dots accumulate and
show the trajectory of the flip flop. Occasionally the flip flop
goes metastable, and sometimes the random sample occurs during the
metastable time. These show up as the dots that are to the right
of the solid rising edge on the left. Every dot that is not on
that left edge represents times when the flip flop had a longer
than normal transition time, after you take into consideration
clock jitter, data output jitter, scope trigger jitter, and scope
sweep jitter. All of these can be characterized by first doing a
test run that does not violate the setup and hold times of the DUT.

The problem with these test systems is that when you do record
a metastable event, you only get 1 sample point on the trajectory
and you can say very little about the trajectory, other than it
passed through that point. Even when these scopes take multiple
samples per sweep, they are often microseconds apart, and of
little interest in the domain we are talking about here.

Although the collected data is predominantly of non metastable
transitions, these all pile up on top of each other as the left
edge of the trace, and do not significantly detract from seeing
the more interesting dots to the right.

The test systems that I have designed are quite different. These
test systems only collect trajectory data when the flip flop
goes metastable, and they sample the DUT output at 1GSamples per
second, thus taking a sample every nanosecond. The result is
that the scope pictures I have show the actual trajectory of
the metastable.

For your viewing pleasure, I have put them up on the web:

   www.fpga-faq.com/Images/meta_pic_1.jpg
   www.fpga-faq.com/Images/meta_pic_2.jpg
   www.fpga-faq.com/Images/meta_pic_3.jpg

These are far from just delayed outputs! The end result though
is still the same, systems that fail. But seeing these scope
pictures of the actual Q output might make you think about how
you measure metastability.

For example, on meta_pic_1.jpg lower trace, the vertical scale
is 1V per division, and the 0V level is 1/2 a division above
the bottom of the screen. The horizontal scale is 4ns per
division. Now what if your test system took a sample at 10ns,
and used a threshold of 1.5 volts (2 div up from the bottom of
the picture). You would say that the signal is always high
at this point. If you sampled again at 20 ns (middle of the
screen, you would say that it has resolved for all the traces
shown, and you would count all the transitions that returned
to ground (because they were high at 10ns). All those traces
that ended up high would not be counted. This would be bad
if in the real system the device listening to the DUT
happened to have a threshold of 2.1 volts (right in the
middle of that cute little hump).

This also shows why using a signal like this as a clock
could be a real disaster.

Knowing what the trajectory of the DUT output looks like
can make you think a lot harder about how you test it.

>	So, bearing this in mind, a thought experiment. We have an async
>input, moving to a synchronising clock domain at (say) 1000MHz. Say we
>have a budget of 5ns of latency to mitigate metastability. The sample
>is captured after the metastability mitigation circuit (MMC) with a FF
>called the output FF.
>	My first question is, which of these choices of MMC is least likely
>to produce metastability at the output FF?
>1) The MMC is a 4 FF long shift register clocked at 1000MHz.
>MMC1 : process(clock)
>begin
>  if rising_edge(clock) then
>    FF1 <= input;
>    FF2 <= FF1;
>    FF3 <= FF2;
>    FF4 <= FF3;
>    output <= FF4;
>  end if;
>end process;

Basically the improvement in MTBF is a function of the slack time
you give it to resolve. This is the sum of the slack time between
FF1 and FF2, FF2 and FF3, FF3 and FF4, and FF4 and output.
Lets throw some numbers at it. Setup time is 75ps, clock to Q is
200ps, routing delay between any pair of Q to D paths is 100ps.
Clock distribution skew is 25ps (in the unfortunate direction).
So we have 4 paths of 1000ps - (75+200+100+25) = 4 * 600ps = 2.4ns

>2) The MMC is 4 FFs, each clock enabled every second clock.
>MMC2 : process(clock)
>begin
>  if rising_edge(clock) then
>    toggle <= not toggle;
>    if toggle = '1' then
>      FF1 <= input;
>      FF3 <= FF1;
>      output <= FF3;
>    else
>      FF2 <= input;
>      FF4 <= FF2;
>      output <= FF4;
>    end if;
>  end if;
>end process;

Ok, so this is weird, and it adds a mux :-)

Transit time through muxes is 200ps (assume that
getting toggle to it is a non issue), and its
output connects to the D of the output FF.
No extra routing delay.

Path 1:
slack from FF1 to FF3 plus slack from FF3 to output

2000-(75+200+100+25)+2000-(75+200+100+25+200)= 3.0ns

Path 2:
same slacks, just different FFs   3.0ns

So: weird but better :-)

I could of course screw up the results by changing
the delay numbers, but they are pretty realistic for
current technology.

>	Option 1) offers extra stages of synchronization between the input
>and output, but the 1ns gap between FFs means that metastability is
>more likely to propagate. Option 2) waits 2ns for the sample FFs to
>make up their mind, vastly decreasing the metastability probability.

Yep.

>	My second question is, does the type of metastability, i.e. the
>things in Philip's list, affect which is the better choice? For
>instance, if the first FF in the MMC exhibits oscillations in
>metastability, then the second FF in the MMC would have several
>chances, as its input oscillates, to sample at the 'wrong' time. This
>might favour MMC option 2).

Actually MMC 2 is favored regardless of oscillations or not
because of the 600ps of additional slack time.

>If, however, the first FF in the MMC goes
>into option 5) metastability, then there's only one chance for the
>second FF to sample at the 'wrong' time. This might confer an
>advantage on MMC option 1).

My thinking on this has always been that the only thing
that matters is the resolving time (slack) and the thought
experiments about later stages sampling at just the right time
to catch the previous FF resolving only cloud the issue. I am
not as confident on this issue as I am on others though.

What I am confident on though, is that there is a better MMC
than your two, and it follows on from MMC #2.

Just use 2 FFs, and clock them every 4 ns:

(that is, enable them every 4th clock cycle. This
would mean though that unlike MMC #2, which runs 2
parallel paths and avoids some latency, this could
have upto 4 ns of extra latency, if you just miss
the input change)

slack from FF1 to output:

4000-(75+200+100+25) = 3.6ns

If the latency is really a problem, you could build
on the MMC #2 design and have 4 paths each out of phase
by 1 clock cycle. Since the path is now only 2 FFs long
you would have to have 4 output FFs, and the selector
mux would be after these 4 FFs. On the bright side, the
mux delay does not eat into the resolving slack time,
but it would eat some of the available cycle time in
the logic that follows the output FF.

>
>	Anyway, I'm still thinking about this. I think the clock frequency
>may decide which is better for a given FF type. Any comments?
>                       Cheers, Syms.


Thanks for an interesting question. Comments above :-)

Philip Freidin




Philip Freidin
Fliptronics

Hi Philip,
      Thanks for your post, those pictures were certainly very
interesting! What parts did you use? I notice they seem to disagree
with Peter's quote that "Metastability just affects the delay on the Q
output.". I wonder, Peter, if Xilinx FFs behave differently from the
ones in Philip's photos? (Other than speed, of course.) I must admit,
one reason I posted was that I found hard to believe that any FF
wouldn't show runt pulses, or funny output levels, albeit for brief
periods of time, during metastable events.
      It's also interesting that the straight shift register isn't
necessarily the best way to reduce metastability effects. That was
what I suspected and was another reason behind my post. I agree that
the 'four paths out of phase' solution is better, and preserves the
sampling resolution. Often the sampling resolution needs to be
preserved, which was why I didn't present an 'enabled every third or
fourth go' type circuit.
      Anyway, thanks to all for their thoughts, it's an interesting
topic!
                   cheers, Syms.

Symon,

I think the sampling o-scope shots agree perfectly with what Peter said.
Runt pulse, and funny levels are the easiest metastable results to catch,
as they are just before the long unknown settling time behavior that is so
vexing to designers.

It also makes a difference where you look:  a master-slave FF reduces the
duration of the unknown transistion over a simple FF without a slave to
help "sharpen up" the transistions.

Austin

Symon wrote:

> Hi Philip,
>       Thanks for your post, those pictures were certainly very
> interesting! What parts did you use? I notice they seem to disagree
> with Peter's quote that "Metastability just affects the delay on the Q
> output.". I wonder, Peter, if Xilinx FFs behave differently from the
> ones in Philip's photos? (Other than speed, of course.) I must admit,
> one reason I posted was that I found hard to believe that any FF
> wouldn't show runt pulses, or funny output levels, albeit for brief
> periods of time, during metastable events.
>       It's also interesting that the straight shift register isn't
> necessarily the best way to reduce metastability effects. That was
> what I suspected and was another reason behind my post. I agree that
> the 'four paths out of phase' solution is better, and preserves the
> sampling resolution. Often the sampling resolution needs to be
> preserved, which was why I didn't present an 'enabled every third or
> fourth go' type circuit.
>       Anyway, thanks to all for their thoughts, it's an interesting
> topic!
>                    cheers, Syms.

Hi Austin,
       Maybe I got the wrong end of the stick, but when Peter said:-
"I have never seen strange levels or oscillations ( well, 25 years ago
we had TTL oscillations). Metastability just affects the delay on the
Q output." I thought he meant that he'd only seen metastability where
the output from the FF was always either on or off, just that
sometimes the transition was delayed. Philip's pictures clearly show
'strange levels'. This is important, I believe, when deciding what the
effects of metastable FFs are on following circuitry. I guess we'll
have to wait until he returns from his Portugese jaunt before we find
out what he meant!!
        Of course, I agree the Master/Slave thing helps. A master FF
on its own is what I'd call a latch, the clock controlling whether
it's transparent or not. The slave is the sameish circuit again, fed
from the output of this, but its clock is inverted. So, I guess that
you're saying because the master and slave are fabricated right next
to each other, the input to the slave can be expected to transition
faster than the input to the master which travels from further away?
Less capacitive interconnect to drive. (BTW, I assumed throughout the
metastability stuff we were talking about D-type FF, rather than
latches.)
                  thanks, Syms.

Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F550102.DC2B872F@xilinx.com>...
> Symon,
> 
> I think the sampling o-scope shots agree perfectly with what Peter said.
> Runt pulse, and funny levels are the easiest metastable results to catch,
> as they are just before the long unknown settling time behavior that is so
> vexing to designers.
> 
> It also makes a difference where you look:  a master-slave FF reduces the
> duration of the unknown transistion over a simple FF without a slave to
> help "sharpen up" the transistions.
> 
> Austin
> 
> Symon wrote:
> 
> > Hi Philip,
> >       Thanks for your post, those pictures were certainly very
> > interesting! What parts did you use? I notice they seem to disagree
> > with Peter's quote that "Metastability just affects the delay on the Q
> > output.". I wonder, Peter, if Xilinx FFs behave differently from the
> > ones in Philip's photos? (Other than speed, of course.) I must admit,
> > one reason I posted was that I found hard to believe that any FF
> > wouldn't show runt pulses, or funny output levels, albeit for brief
> > periods of time, during metastable events.
> >       It's also interesting that the straight shift register isn't
> > necessarily the best way to reduce metastability effects. That was
> > what I suspected and was another reason behind my post. I agree that
> > the 'four paths out of phase' solution is better, and preserves the
> > sampling resolution. Often the sampling resolution needs to be
> > preserved, which was why I didn't present an 'enabled every third or
> > fourth go' type circuit.
> >       Anyway, thanks to all for their thoughts, it's an interesting
> > topic!
> >                    cheers, Syms.

Symon wrote:
> 
> Hi Austin,
>        Maybe I got the wrong end of the stick, but when Peter said:-
> "I have never seen strange levels or oscillations ( well, 25 years ago
> we had TTL oscillations). Metastability just affects the delay on the
> Q output." I thought he meant that he'd only seen metastability where
> the output from the FF was always either on or off, just that
> sometimes the transition was delayed. Philip's pictures clearly show
> 'strange levels'. This is important, I believe, when deciding what the
> effects of metastable FFs are on following circuitry. I guess we'll
> have to wait until he returns from his Portugese jaunt before we find
> out what he meant!!

I think the exact behavior is largely irrelevant since a simple delay is
just as disasterous as anything else you would encounter.  Since you
don't know *when* the transition would happen, it could happen at the
moment the next FF is latching the intermediate value.  That is enough
for the next FF and all following logic to behave badly as well.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Symon,

Agreed.  D FF is what I was assuming here, but folks do have different ways of building them, and
not all master-slave implementations are the same (in fact I have seen perhaps a dozen different
versions).

Peter will have some explaining to do when he gets back .... as the quote does sound odd.  There
is most definitely voltage levels that remain in the undecided region for various lengths of time
until the circuit resolves its state.

Austin

Symon wrote:

> Hi Austin,
>        Maybe I got the wrong end of the stick, but when Peter said:-
> "I have never seen strange levels or oscillations ( well, 25 years ago
> we had TTL oscillations). Metastability just affects the delay on the
> Q output." I thought he meant that he'd only seen metastability where
> the output from the FF was always either on or off, just that
> sometimes the transition was delayed. Philip's pictures clearly show
> 'strange levels'. This is important, I believe, when deciding what the
> effects of metastable FFs are on following circuitry. I guess we'll
> have to wait until he returns from his Portugese jaunt before we find
> out what he meant!!
>         Of course, I agree the Master/Slave thing helps. A master FF
> on its own is what I'd call a latch, the clock controlling whether
> it's transparent or not. The slave is the sameish circuit again, fed
> from the output of this, but its clock is inverted. So, I guess that
> you're saying because the master and slave are fabricated right next
> to each other, the input to the slave can be expected to transition
> faster than the input to the master which travels from further away?
> Less capacitive interconnect to drive. (BTW, I assumed throughout the
> metastability stuff we were talking about D-type FF, rather than
> latches.)
>                   thanks, Syms.
>
> Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F550102.DC2B872F@xilinx.com>...
> > Symon,
> >
> > I think the sampling o-scope shots agree perfectly with what Peter said.
> > Runt pulse, and funny levels are the easiest metastable results to catch,
> > as they are just before the long unknown settling time behavior that is so
> > vexing to designers.
> >
> > It also makes a difference where you look:  a master-slave FF reduces the
> > duration of the unknown transistion over a simple FF without a slave to
> > help "sharpen up" the transistions.
> >
> > Austin
> >
> > Symon wrote:
> >
> > > Hi Philip,
> > >       Thanks for your post, those pictures were certainly very
> > > interesting! What parts did you use? I notice they seem to disagree
> > > with Peter's quote that "Metastability just affects the delay on the Q
> > > output.". I wonder, Peter, if Xilinx FFs behave differently from the
> > > ones in Philip's photos? (Other than speed, of course.) I must admit,
> > > one reason I posted was that I found hard to believe that any FF
> > > wouldn't show runt pulses, or funny output levels, albeit for brief
> > > periods of time, during metastable events.
> > >       It's also interesting that the straight shift register isn't
> > > necessarily the best way to reduce metastability effects. That was
> > > what I suspected and was another reason behind my post. I agree that
> > > the 'four paths out of phase' solution is better, and preserves the
> > > sampling resolution. Often the sampling resolution needs to be
> > > preserved, which was why I didn't present an 'enabled every third or
> > > fourth go' type circuit.
> > >       Anyway, thanks to all for their thoughts, it's an interesting
> > > topic!
> > >                    cheers, Syms.

Rick,

I agree that the effect is the same:  you just don't know when it will
resolve, and thus the value that you "see" at the next level is basically
unknown.

It could be that Peter's point is that the next circuit in line does make a
decision, and it most certainly makes the "unknown" into a '1', or into a
'0'.  It is unlikely that the next circuit in line will propagate the same
intermediate behavior, and if it can (gain is too low), then things just get
more fuzzy until someone upstream ends up resolving the level back to a '1'
or a '0'.

Austin

rickman wrote:

> Symon wrote:
> >
> > Hi Austin,
> >        Maybe I got the wrong end of the stick, but when Peter said:-
> > "I have never seen strange levels or oscillations ( well, 25 years ago
> > we had TTL oscillations). Metastability just affects the delay on the
> > Q output." I thought he meant that he'd only seen metastability where
> > the output from the FF was always either on or off, just that
> > sometimes the transition was delayed. Philip's pictures clearly show
> > 'strange levels'. This is important, I believe, when deciding what the
> > effects of metastable FFs are on following circuitry. I guess we'll
> > have to wait until he returns from his Portugese jaunt before we find
> > out what he meant!!
>
> I think the exact behavior is largely irrelevant since a simple delay is
> just as disasterous as anything else you would encounter.  Since you
> don't know *when* the transition would happen, it could happen at the
> moment the next FF is latching the intermediate value.  That is enough
> for the next FF and all following logic to behave badly as well.
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX