Hi,

how does an (unclocked) 2:1 multiplexer behave if input B is selected
and input A becomes metastable ? Does the metastability of A have an
influence on the stability of the mux output at any point of time ?


cheers,
hssig

On May 24, 3:58=A0pm, hssig <hs...@gmx.net>
wrote:
> Hi,
>
> how does an (unclocked) 2:1 multiplexer behave if input B is selected
> and input A becomes metastable ? Does the metastability of A have an
> influence on the stability of the mux output at any point of time ?
>
> cheers,
> hssig

For an ideal multiplexer, I'd have to say that input A should
have no effect if B is selected.  However in an FPGA, muxes are
often built from look-up tables, which could exhibit odd
behavior if one input stayed in the logic threshold region
long enough.  Think of a LUT as a bunch of ones and zeroes
feeding a larger (usually 16:1) mux.  Then A, B and SEL would
all be select inputs to the LUT.  Theoretically if SEL is
low, then the output value should not depend on B, but if
the mux uses decoders and FETs to connect one input at
a time to the output, and the B input is neither 1 nor 0,
the output could float.  Normally this period of floating
would be too short for the output to glitch while B is
transitioning.  But a particularly long metastable event
could float the output long enough for it to change state.
Such an event would indeed be rare.

Regards,
Gabor

Gabor <g...@alacron.com> wrote:
> On May 24, 3:58 pm, hssig <hs...@gmx.net> wrote:

>> how does an (unclocked) 2:1 multiplexer behave if input B is selected
>> and input A becomes metastable ? Does the metastability of A have an
>> influence on the stability of the mux output at any point of time ?
 
> For an ideal multiplexer, I'd have to say that input A should
> have no effect if B is selected.  However in an FPGA, muxes are
> often built from look-up tables, which could exhibit odd
> behavior if one input stayed in the logic threshold region
> long enough.  

I believe that the LUT/mux design on most FPGAs is such
that they won't glitch in the case of a single input changing
with LUT entries that don't change the output.  One way to
do that would be to implement the 16:1 mux as 15 2:1 mux
chained together.  That might be a little too much, but you
are supposed to be able to rely on them not glitching.

> Think of a LUT as a bunch of ones and zeroes
> feeding a larger (usually 16:1) mux.  Then A, B and SEL would
> all be select inputs to the LUT.  Theoretically if SEL is
> low, then the output value should not depend on B, but if
> the mux uses decoders and FETs to connect one input at
> a time to the output, and the B input is neither 1 nor 0,
> the output could float.  Normally this period of floating
> would be too short for the output to glitch while B is
> transitioning.  But a particularly long metastable event
> could float the output long enough for it to change state.
> Such an event would indeed be rare.

The one that I would wonder about is, if the metastable input
was oscillating at a high frequency, that it might capacitively
couple through.  My guess is that either they don't oscillate
that fast, or that they won't couple even if they do.
(With the current high-speed devices, it might not be possible
to oscillate that fast.)

-- glen

Hi,

thank you for your opinions.

>I believe that the LUT/mux design on most FPGAs is such
>that they won't glitch in the case of a single input changing
>with LUT entries that don't change the output.

>My guess is that either they don't oscillate
>that fast, or that they won't couple even if they do.


Is there any FPGA vendor paper available that could clarify these
questions ?

cheers,
hssig

On May 24, 10:19=A0pm, glen herrmannsfeldt
<g...@ugcs.caltech.edu>
wrote:
> Gabor <ga...@alacron.com> wrote:
> > On May 24, 3:58=A0pm, hssig <hs...@gmx.net> wrote:
> >> how does an (unclocked) 2:1 multiplexer behave if input B is selected
> >> and input A becomes metastable ? Does the metastability of A have an
> >> influence on the stability of the mux output at any point of time ?
> > For an ideal multiplexer, I'd have to say that input A should
> > have no effect if B is selected. =A0However in an FPGA, muxes are
> > often built from look-up tables, which could exhibit odd
> > behavior if one input stayed in the logic threshold region
> > long enough. =A0
>
> I believe that the LUT/mux design on most FPGAs is such
> that they won't glitch in the case of a single input changing
> with LUT entries that don't change the output. =A0One way to
> do that would be to implement the 16:1 mux as 15 2:1 mux
> chained together. =A0That might be a little too much, but you
> are supposed to be able to rely on them not glitching.
>
> > Think of a LUT as a bunch of ones and zeroes
> > feeding a larger (usually 16:1) mux. =A0Then A, B and SEL would
> > all be select inputs to the LUT. =A0Theoretically if SEL is
> > low, then the output value should not depend on B, but if
> > the mux uses decoders and FETs to connect one input at
> > a time to the output, and the B input is neither 1 nor 0,
> > the output could float. =A0Normally this period of floating
> > would be too short for the output to glitch while B is
> > transitioning. =A0But a particularly long metastable event
> > could float the output long enough for it to change state.
> > Such an event would indeed be rare.
>
> The one that I would wonder about is, if the metastable input
> was oscillating at a high frequency, that it might capacitively
> couple through. =A0My guess is that either they don't oscillate
> that fast, or that they won't couple even if they do.
> (With the current high-speed devices, it might not be possible
> to oscillate that fast.)
>
> -- glen

I don't think that metastability generally causes oscillation.
I would think that as soon as the signals swing one way or the
other they should stabilize.  Think of a coin landing on its
edge.  In the metastable case it stands upright for some time
before leaning toward heads or tails, but once it leans one
way or the other it accelerates to its resting position.

Regards,
Gabor

On 5/25/2010 1:49 PM, Gabor wrote:
>
> I don't think that metastability generally causes oscillation.
> I would think that as soon as the signals swing one way or the
> other they should stabilize.  Think of a coin landing on its
> edge.  In the metastable case it stands upright for some time
> before leaning toward heads or tails, but once it leans one
> way or the other it accelerates to its resting position.
>
> Regards,
> Gabor

http://www.google.com/images?q=metastability

There are some piccies on Philip's site, as well as a whole bunch of 
stuff about metastability. I post this link in the hope it will head off 
yet another useless metastability thread. Fat chance.

Cheers, Syms.

Gabor <g...@alacron.com> wrote:
(snip, I wrote)

>> The one that I would wonder about is, if the metastable input
>> was oscillating at a high frequency, that it might capacitively
>> couple through. 
(snip)
 
> I don't think that metastability generally causes oscillation.

I believe that it isn't usual, but I am not sure that it
isn't possible.

> I would think that as soon as the signals swing one way or the
> other they should stabilize.  Think of a coin landing on its
> edge.  In the metastable case it stands upright for some time
> before leaning toward heads or tails, but once it leans one
> way or the other it accelerates to its resting position.

Consider the case where the coin is spinning?  Or bouncing
around on the table before settling down?  But maybe the
analogy isn't perfect.

-- glen

On May 25, 8:12=A0am, Symon
<symon_bre...@hotmail.com> wrote:

>  I post this link in the hope it will head off
> yet another useless metastability thread. Fat chance.

You need to post again right away.  The metastability should only
really be a problem between your first post and your second post.  Two
posts should be enough to clear it, but there might be some people who
disagree, so maybe you should make two more posts to be on the safe
side.

Pat

On May 25, 9:30=A0am, glen herrmannsfeldt
<g...@ugcs.caltech.edu> wrote:
> Gabor <ga...@alacron.com> wrote:
>
> (snip, I wrote)
>
> >> The one that I would wonder about is, if the metastable input
> >> was oscillating at a high frequency, that it might capacitively
> >> couple through.
>
> (snip)
>
> > I don't think that metastability generally causes oscillation.
>
> I believe that it isn't usual, but I am not sure that it
> isn't possible.
>
> > I would think that as soon as the signals swing one way or the
> > other they should stabilize. =A0Think of a coin landing on its
> > edge. =A0In the metastable case it stands upright for some time
> > before leaning toward heads or tails, but once it leans one
> > way or the other it accelerates to its resting position.
>
> Consider the case where the coin is spinning? =A0Or bouncing
> around on the table before settling down? =A0But maybe the
> analogy isn't perfect.
>
> -- glen

I was going by the posts about FPGA fabric flip-flops.  In the
many discussions on metastability, the gurus seemed to say that
oscillation is not a typical manifestation in these structures.
Of course the chip vendors don't generally want to disclose the
actual flip-flop structure, but it makes sense that
metastability caused by failure to meet setup and hold time
would not generally result in oscillation.  Perhaps metastability
caused by a runt clock pulse might?  In any case, getting back to
the point of the original post, my thought was that a metastable
state could cause the LUT output multiplexer to go essentially
tristate if it is implemented as a decoder driving pass gates.
That of course is another internal structure that the chip
vendors don't want to give the details of.  In any case it is
pretty clear that the LUT's in an FPGA are carefully designed
not to glitch when an input changes state unless that input
changes the output state.  It is possible to test that theory
by designing some asynchronous sequential logic using LUT's
and seeing if it behaves as anticipated.

Regards,
Gabor

On Tue, 25 May 2010 10:16:54 -0700 (PDT), Patrick
Maupin
<p...@gmail.com> wrote:

>On May 25, 8:12 am, Symon <symon_bre...@hotmail.com> wrote:
>
>>  I post this link in the hope it will head off
>> yet another useless metastability thread. Fat chance.
>
>You need to post again right away.  The metastability should only
>really be a problem between your first post and your second post.  Two
>posts should be enough to clear it, but there might be some people who
>disagree, so maybe you should make two more posts to be on the safe
>side.

I'm not sure you're right about that, I think it would be better to
remain undecided for a bit, and see what happens.

- Brian