Avoiding meta stability?

Is the following a good way to avoid meta stability problems? The signal 'd'
is synchronous to a1.8 MHz clock?



At least one of the signals a,b or c could end up in a meta stabel
condition.



It then takes the median of the 3 samples.


library   IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity median3 is
    Port ( clk_24M : in std_logic;
           d : in std_logic;
           q : out std_logic := '0');
end median3;

architecture beh of median3 is
  type state_type is (load_a, load_b, load_c);
  signal state : state_type := load_a;
begin
  process(clk_24M)
    variable a,b,c : std_logic := '0';
  begin
    if rising_edge(clk_24M) then
      case state is
        when load_a =>    a := d; state <= load_b;
        when load_b =>    b := d; state <= load_c;
        when load_c =>    c := d; state <= load_a;
        when others =>            state <= load_a;
      end case;

      q <= (a and b) or (a and c) or (b and c);

    end if;
  end process;
end beh;

Bill wrote:
> Is the following a good way to avoid meta stability problems?
...
> At least one of the signals a,b or c could end up in a meta stabel
> condition.
...
> It then takes the median of the 3 samples.
... [VHDL stuff]
>       q <= (a and b) or (a and c) or (b and c);

You ask about metastability, which is a problem down to the
transistor and parasitic capacitance level, and then suggest some
VHDL. The actual behavior of this function is unknown until you
know what logic gates and transistors (and other physical circuit
items) your VHDL will produce after synthesis, optimization and layout,
etc. Depending on the actual realization of your majority function,
it could actually worsen the resolution time of the circuit over
that of just using a closely spaced register pair delay on the
same clock.


IMHO. YMMV.
-- 
rhn A.T nicholson d.O.t C-o-M

"Metastability" is a popular word to scare inexperienced designers.

If you run a 1.8 MHz clock (even with a similar asynchronous data
rate), your chance of having a 3 ns extra metastable delay is once per
billion years (at 24 MHz it would be only 5 million years).
For every additional ns of acceptable settling time, the
mean-time-between-failure increases at least a million times. (see
XAPP094 on the Xilinx website)
The probability of your flip-flop failing during the life of this
universe (even if you do nothing) with more than 10 ns of
unaccounted-for delay is so minute it is practically zero.
There are more important things to worry about, forget metastability...
Peter Alfke, Xilinx Applications (who actually has created quantitative
data about metastability)

Peter Alfke wrote:
> "Metastability" is a popular word to scare inexperienced designers.
>
> If you run a 1.8 MHz clock (even with a similar asynchronous data
> rate), your chance of having a 3 ns extra metastable delay is once
> per billion years (at 24 MHz it would be only 5 million years).
> For every additional ns of acceptable settling time, the
> mean-time-between-failure increases at least a million times.

This certainly depends on the logic family, which the OP didn't
specify.  I have seen IO equipment, constructed with older slower
logic families, fail due to improper synchronization at clock rates
of much less than 24 MHz.  Even today, with fast submicron CMOS,
you can still create reliability problems with worse case register
placements or interconnect routing.


IMHO. YMMV.
-- 
rhn A.T nicholson d.O.t C-o-M

Peter - 

A few comments:

 - You can run your design at only 24 MHz?  And you have an extra 3ns?
Luxury!

 - A circuit may fail only once every billion years, but the failure
will always occur when the customer is present.

 - You can forget about metastability, but metastability will never
forget about you.

Take care,
Bob Perlman
Cambrian Design Works

On 4 Oct 2005 13:21:55 -0700, "Peter Alfke" <peter@xilinx.com> wrote:

>"Metastability" is a popular word to scare inexperienced designers.
>
>If you run a 1.8 MHz clock (even with a similar asynchronous data
>rate), your chance of having a 3 ns extra metastable delay is once per
>billion years (at 24 MHz it would be only 5 million years).
>For every additional ns of acceptable settling time, the
>mean-time-between-failure increases at least a million times. (see
>XAPP094 on the Xilinx website)
>The probability of your flip-flop failing during the life of this
>universe (even if you do nothing) with more than 10 ns of
>unaccounted-for delay is so minute it is practically zero.
>There are more important things to worry about, forget metastability...
>Peter Alfke, Xilinx Applications (who actually has created quantitative
>data about metastability)

Bob, I agree with everything you wrote, but the original posting
mentioned 1.8 MHz and 24 MHz. I did not make that up. It sure is not a
typical modern design...
I think we would agree that such a slow design will, almost inevitably,
have a few ns slack to accomodate a possible metastable delay.
If you use a 500 Mhz clock to synchronize a 400 MHz asynchronous data
stream, the problem is much more real.
I am so happy that we went to the trouble of measuring the delays on
real (V2Pro) silicon, same as we had done with XC4000 years before.
That gives us quantitative data. Less arm-waving.

The rule still is: If you have reason to worry about metastability,
give the flip-flop in question maximum slack to settle, and have it
drive only one near-by synchronizing flip-flop. Without that
precaution, you might get into trouble...
Peter Alfke

In saying that Peter, I had a design I was working on last year using a 986
kHz clock (or there abouts) and a 16.384MHz clock.. and metastability
'glitches' hit 1 in 10 times... we use a Spartan 2e :-)
with the usual double flip flop it was cured :-)


Simon


"Peter Alfke" <peter@xilinx.com> wrote in message
news:1128457315.762325.327300@o13g2000cwo.googlegroups.com...
> "Metastability" is a popular word to scare inexperienced designers.
>
> If you run a 1.8 MHz clock (even with a similar asynchronous data
> rate), your chance of having a 3 ns extra metastable delay is once per
> billion years (at 24 MHz it would be only 5 million years).
> For every additional ns of acceptable settling time, the
> mean-time-between-failure increases at least a million times. (see
> XAPP094 on the Xilinx website)
> The probability of your flip-flop failing during the life of this
> universe (even if you do nothing) with more than 10 ns of
> unaccounted-for delay is so minute it is practically zero.
> There are more important things to worry about, forget metastability...
> Peter Alfke, Xilinx Applications (who actually has created quantitative
> data about metastability)
>

I think the frequencies are real too.. we use 10 Xilinx FPGA's in one
product.. its cheaper than ASIC's in low volumes... and we get a good price.
:-)
The main external clocks are 8 kHz, 968 kHz, 16.384 MHz, 25 Mhz.. I have
been known to splash out and use 32.768 MHz too.  you may notice the telco
frequencies here... 25 is 1/2 of 50 (Ethernet) the rest are 4 x E1.

Simon


"Peter Alfke" <alfke@sbcglobal.net> wrote in message
news:1128486239.789657.247430@z14g2000cwz.googlegroups.com...
> Bob, I agree with everything you wrote, but the original posting
> mentioned 1.8 MHz and 24 MHz. I did not make that up. It sure is not a
> typical modern design...
> I think we would agree that such a slow design will, almost inevitably,
> have a few ns slack to accomodate a possible metastable delay.
> If you use a 500 Mhz clock to synchronize a 400 MHz asynchronous data
> stream, the problem is much more real.
> I am so happy that we went to the trouble of measuring the delays on
> real (V2Pro) silicon, same as we had done with XC4000 years before.
> That gives us quantitative data. Less arm-waving.
>
> The rule still is: If you have reason to worry about metastability,
> give the flip-flop in question maximum slack to settle, and have it
> drive only one near-by synchronizing flip-flop. Without that
> precaution, you might get into trouble...
> Peter Alfke
>

"Metastability" or "delay matching"?
I was never bitten by the first, but the second...
By the way, a single flip-flop solves the second...

Ricardo.

Simon Peacock escreveu:
> In saying that Peter, I had a design I was working on last year using a 986
> kHz clock (or there abouts) and a 16.384MHz clock.. and metastability
> 'glitches' hit 1 in 10 times... we use a Spartan 2e :-)
> with the usual double flip flop it was cured :-)
> 
> 
> Simon
> 
> 
> "Peter Alfke" <peter@xilinx.com> wrote in message
> news:1128457315.762325.327300@o13g2000cwo.googlegroups.com...
> 
>>"Metastability" is a popular word to scare inexperienced designers.
>>
>>If you run a 1.8 MHz clock (even with a similar asynchronous data
>>rate), your chance of having a 3 ns extra metastable delay is once per
>>billion years (at 24 MHz it would be only 5 million years).
>>For every additional ns of acceptable settling time, the
>>mean-time-between-failure increases at least a million times. (see
>>XAPP094 on the Xilinx website)
>>The probability of your flip-flop failing during the life of this
>>universe (even if you do nothing) with more than 10 ns of
>>unaccounted-for delay is so minute it is practically zero.
>>There are more important things to worry about, forget metastability...
>>Peter Alfke, Xilinx Applications (who actually has created quantitative
>>data about metastability)
>>
> 
> 
> 

Simon, your problem was not metastability. Since many designers do not
really understand the metastable mechanism, it gets blamed for all
mystery problems.  In many cases the problem is caused by synchronizing
an asynchronous input in more than one flip-flop in parallel. This will
inevitably fail, because the two flip-flops have  different capture
times. But that has nothing whatsoever to do with metastabilty...
Peter Alfke