Re: Thinking out loud about metastability - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Thinking out loud about metastability
Quoted text here. Click to load it

I don't think you understand the point.  We are not saying that balance
or noise are required to demonstrate metastability.  It was pointed out
that in a simulation of the effect, something would be needed to move
the FF off the balance point and noise was suggested.  But in the real
world the "balance point" is so vanishing small, it would never actually
happen.  That is not saying that the FF can not go metastable without
being balanced.  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Thinking out loud about metastability

Quoted text here. Click to load it

Whoever said, "If you require noise to shift you out of metastability,
then the people who argue that more noise will get you out quicker
could then be right," could you explain further?  Are you saying that
noise is required to resolve the metastable state, or is this a
counter-argument to the "noise may get you out faster" claim?  Or is
it something else entirely?

Bob Perlman
Cambrian Design Works


Re: Thinking out loud about metastability
Quoted text here. Click to load it

I guess this was not well stated.  This was in response to someone else
who seemed to be saying that noise is needed to get out of
metastability.  Just before this I believe I spoke about the perfect
balance point being so small that it was not significant.  So noise is
not really needed.  The quote above was to say that if noise really is
required, then the advocates of more noise may be right.  But my point
is that noise is not needed since there is virtually never a "perfect"
balance.  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Thinking out loud about metastability
Noise is not needed, but it may help to accelerate departure from the
balance point shortening the metastable period.  On the other hand, noise
can also work the other way pushing the Q point closer to the balance point
thereby delaying recovery.  As a result, noise has no net effect on the
metastable probabilities.

rickman wrote:

Quoted text here. Click to load it

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
We've slightly trimmed the long signature. Click to see the full one.
Re: Thinking out loud about metastability
Quoted text here. Click to load it

 I understand the (dominant) thermal aspects, but my physics teacher
taught me that all extrapolation is dangerous :) - hence the question
about the quantize effects, on the tail.

 Problem is, the tail is by nature hard to measure, and so mostly we get
the
statisical arm waving of a continuous 'vanishingly small' curve of
Time/Probability.

 With each FPGA generation, we must be getting closer to being
able to look for these more subtle effects.

 eg Electron charge is in region of 10^-19, and Gate charge of a MOS FET
is
measured in some fC/um^2 (femto = 10^-15), so in 90nm devices we
should be in the 10^-17/10^-18 region.

 Does anyone have a real value for Qc in 90nm process ?

-jg

Re: Thinking out loud about metastability
Quoted text here. Click to load it
machine.


Ray, maybe we can absorb some energy from a parallel universe and ...
:)

From the site referred by Philip:
"Hopefully, the discussion will discourage further attempts to
eliminate
this unavoidable characteristic"

I think a researcher should never say something like that. The right
phrase should be:
Hopefully, the discussion will encourage further attemps to better
understand and avoid this characteristic.

Nobody knows everything. Physics don't change (I hope), but the way we
model it is always evolving. Things considered impossible became
possible.
 
 
Quoted text here. Click to load it
state.  As
Quoted text here. Click to load it
eliminate it.
Quoted text here. Click to load it
rate.  Trouble
Quoted text here. Click to load it
clock speeds
Quoted text here. Click to load it
not improve.
Quoted text here. Click to load it

I understood the problem. I've found some "solutions", but when I
tried to prove them I could only prove they don't work at all. But,
like Winston Churchill, I'll never surrender, not any time soon.

Anyway, thankyou. I always appreciate what you (Ray), Austin, Peter,
Rick, and everybody else that contributes here have to say. Well,
Peter's "Grrr" not included :).

Luiz Carlos.

Re: Thinking out loud about metastability
On 28 Aug 2003 12:52:11 -0700, oen snipped-for-privacy@yahoo.com.br (Luiz Carlos)

Quoted text here. Click to load it

This is the classic defense of otherwise indefensible ideas.  "They
said that a flying machine was impossible."  "They said that Einstein
was crazy."  Statements like these ignore certain realities, namely:

(a) Much of what was said to be impossible still is, and shows every
sign of remaining so.  If you believe that there are laws of physics,
even laws that are somewhat at odds with the ones we now hold true,
then those laws must say that certain things can happen and others
cannot.  If they don't, they aren't laws.

(b) In all of human history, most of the people "they" called crazy
were, in fact, crazy.

Luiz, it's fine with me if you want to believe that metastability can
be prevented.  But for all of you folks who have been reading this
thread and wondering just what to do about metastability in your
designs, just read Philip Freidin's excellent summary and follow the
link he pointed to for more information.

Do we really want to keep repeating the same old mistakes?  Woudn't it
be more fun to make some new ones?

Bob Perlman
Cambrian Design Works

      

Re: Thinking out loud about metastability
Quoted text here. Click to load it

Hi Bob,
Which laws?
Classical physics laws, like every other, have a domain where they
give better approximations. We are still trying to find the Theory Of
Everything.
Peter has mentioned the "Heisenberg's Uncertainty Principle", but I
read somewhere, althought we can't know where a particle is in a
momentum, we can know where it is not, so, we can infer where it is.
If we take the electron spin, there is no metastability. It changes
it's direction in one "fundamental" clock cycle (time is not
continuous). I think there is also no metastability problems in Single
Electron Devices. So, Virtex436 possibly will not have metastability
problems.

Quoted text here. Click to load it

Bob, I know that everything I said don't help us with our today
metastability problems. I spent a lot of time trying to defend my
opion about something that is not related to the topic, fruitless!
I'll try to not repeat the same mistake.
I agree with you about Philip, it really looks like he knows a lot.
Thanks to everybody, I learned a lot about metastability.

Luiz Carlos

Re: Thinking out loud about metastability
Quoted text here. Click to load it

Rick, I din't say that. I said electron spin does not presents
metastability.

Anyway, did you hear about spintronics? Maybe the scientists behind
this idea may go back to school too!

Look at
http://www.eetimes.com/story/OEG20001221S0035
Cut and paste please, I don't know how to include hypertexts.
I think that shows my whole point of view: if you believe, insist!

Unhappily (for me) I could not find the text about the electron
position.

Luiz Carlos

Re: Thinking out loud about metastability
Quoted text here. Click to load it

It does not matter in the least what state the electron is in.
Metastability is a measurement problem.  When you try to measure the
state of a FF with a gate or second FF, that is where metastability is
an issue.  The first FF is in a state where the voltage will ultimately
resolve itself to a final value.  So the issue of metastability is
really one of measuring the state well enough to resolve the final state
of the FF.  Just like the metastability was created by the inability of
the FF to measure the state of the input at the sampling time.  

Electron spin has all the same measurement issues that a FF has.  If the
state of the electron spin is changing as the measurement is made, then
what state is it in?  What will be the result of the measurement?  


Quoted text here. Click to load it



--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Thinking out loud about metastability
Quoted text here. Click to load it

Rick, the electron spin is +1/2 or -1/2, there is no in between state,
it changes instantaneously (in one fundamental clock tick, ~10^-43
seconds).

Luiz Carlos

Re: Thinking out loud about metastability
Quoted text here. Click to load it

But the measurement is not instantaneous.  So the transistion could
occur during a measurement.  Result... inconclusive measurement which is
what metastability is all about.  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Thinking out loud about metastability
Quoted text here. Click to load it

You just need to measure the spins to see the results. You can
maintain they stable during this. To carry out the operations the
spins interact and you don't need to measure them. But, if you imply a
measure in the interaction process, so the measure is instantaneous.

Luiz Carlos

Re: Thinking out loud about metastability
In newsgroup: comp.arch.fpga
Quoted text here. Click to load it

Well, actually it is.  It might *affect* the spin (Heisenberg wins
again) but unlike classical measurements there shouldn't be any ifs
about the result.

There is a lot of things in the quantum world which is completely
counterintuitive to everything we have learned.  If you look at
quantum teleportation, for example, you'd have to conclude information
was conducted backwards in time...

<thhgttg>This is of course, impossible.</thhgttg>
--
If you send me mail in HTML format I will assume it's spam.
We've slightly trimmed the long signature. Click to see the full one.
Re: Thinking out loud about metastability

Quoted text here. Click to load it
motion machine.
metastable state.  As
Quoted text here. Click to load it
eliminate it.
clock rate.  Trouble
Quoted text here. Click to load it
the clock speeds
Quoted text here. Click to load it
may not improve.

Really the problem is insisting on synchronous designs.  Asynchronous
(self-timed) logic doesn't have this problem.  Well, metastability is still
there, but the logic will wait, however long it takes, for it to resolve.

I used to hear stories, though I am not sure that I believe them, of people
seeing metastability effects on the PDP-10 (KA10), which used self timed
logic.   Supposedly they could see it stop processing, and then start again
with no ill effect.  How they know it wasn't in I/O wait, or some other such
state, I have no idea.

-- glen



Re: Thinking out loud about metastability
Quoted text here. Click to load it

I am no expert in async logic, but I have never heard of a circuit that
can even detect metastability.  I also thought that async logic did not
"measure" the time it took for a calculation, it simply allowed
different times for different calculations.  The control path for a
given circuit has a longer delay than the data path and would be
dependant on the calculation being performed.  How exactly would a
circuit detect when an async calculation is complete?  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Thinking out loud about metastability


(snip regarding the DEC KA-10, metastability, and self-timed logic)

Quoted text here. Click to load it

Well, I agree with the skepticism in the first place, but consider a CPU
with lights indicating the current contents of the registers.  Normally, the
values will be changing very fast.  If they suddenly stop changing, it could
be because of unresolved metastability.  The logic will wait quietly for it
to resolve, and then continue.

It might be, though, that the machine is in I/O wait, and there really is
nothing to do.  I never got to actually see the machine, but at the time
many machines had console lights, at least for the instruction counter and a
few other important registers.  (Though I don't believe that the PDP-10 had
a wait state like IBM S/360 did, where no instructions were executed.)

-- glen



Re: Thinking out loud about metastability
Quoted text here. Click to load it

I don't see how this is possible.  You are assuming that the CPU has
some way to measure that a FF output is metastable.  I don't know of any
way of doing that.  How is this circuit designed?  

Quoted text here. Click to load it

It is also possible that the lights are not a valid indication of the
state of the CPU.  Since the CPU runs at thousands of times faster than
the eye can see, it is entirely possible that a loop is being executed
that makes the lights appear to be lit, but are actually flashing much
faster than you could see.  If the duty cycle is high for each light
that is flashing you would not see a dimming either.  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Thinking out loud about metastability


(snip)

Quoted text here. Click to load it

There are books, and probably web sites explaining self timed logic, or
asynchronous logic.

There are no clocks, but it takes more wires for each signal.   Designing is
completely different than synchronous logic designs, which means that the
current design tools don't help very much.   I don't know it well enough to
explain here, though.

-- glen



Re: Thinking out loud about metastability
Quoted text here. Click to load it

Yes, everything I have read (which is not a lot) simply relies on the
control path (the clock) to have a longer delay than the data path.  So
the data will always reach the next stage before the control saying the
data is ready.  

There is no way to determine when a circuit is metastable or not.  Async
circuits are not magic, they just depend on predictable delays, just
like any other circuit.  The design is different because there is no
common clock so each circuit can run with its own delay.  Since the next
circuit will take the output when it is ready, there is no problem with
synchronization.  

One problem I do see is that if each stage has a different delay, then
it can not accept a new input from the preceding stage until the output
has been taken by the following stage.  It seems in the end the async
circuit will run no faster than the slowest stage, which is what the
sync clocked circuit will do.  

But I have not read about it much, so perhaps there is more to it than
just this.  But without design tools or any expectation of using it
soon, there is not much incentive to spend much time reading up on it
now.  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline