Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site aum.UUCP
Path: utzoo!linus!decvax!decwrl!Glacier!well!ptsfa!aum!freed
From: freed@aum.UUCP (Erik Freed)
Newsgroups: net.micro.68k,net.arch
Subject: Re: Glitch Phenomenon (Re: Multiple 68020's on VME ?)
Message-ID: <384@aum.UUCP>
Date: Mon, 7-Oct-85 10:39:40 EDT
Article-I.D.: aum.384
Posted: Mon Oct  7 10:39:40 1985
Date-Received: Thu, 10-Oct-85 06:04:15 EDT
References: <442@rna.UUCP> <1192@vax1.fluke.UUCP> <1258@hcrvx1.UUCP>
Organization: The Aurora Systems Bunch
Lines: 34
Xref: linus net.micro.68k:1157 net.arch:1673

> Theoretically, any finite bound is not good enough.  Perhaps the
> probability of metastbility extending past 50ns should be calculated
> *and stated*.  Of course, maybe the journal article did (I don't have
> access to it), but even the net article should qualify these bald
> numbers. The danger at 50ns might well be acceptably unlikely (the
> probability exponentially decreases with time) but it depends very much
> on the circuit technology and design -- not too nice for an interface
> standard.  As a software-type, I like things to be right or wrong,
> but I understand engineers live in another universe (perhaps the real
> one).
> 
> Hugh Redelmeier (416) 922-1937
> {utzoo, ihnp4, decvax}!hcr!hugh

This metastability problem is being grossly overdone. Fairchild when they
first brought out the F series TTL, did a little tutorial booklet on
this and included equations to figure out MTBF for different sampling
times. It turns out that the particular logic's "window of decision"
makes a huge difference as well as the logics recovery time and recovery
behavior when a transition occurs in that "window of decision". Of course
the reason that fairchild came out with this is that F parts have (supposedly)
very small windows of decision and quick recovery times. The times we usually
designed with had MTBF's that involved continous cycles for hundreds of years
before any chance of a glitch could happen and even then you can sometimes
design so that the glitch doesn't necessarily destroy the cycle. The real
solution and one that is very much overlooked is the use of asynchronous
state machines wherever possible. Most engineers do not realize the speed
and elegance of these little beasties. Of course there are problems associated
with them but if you spend the time to do them right, in my experience, they
are a *big* win. If you keep most of the VME interface logic asynchronous,
you pretty much avoid the "glitch" problem altogether. Most engineers brought
up on prom based sequenced state machines are blind to the obvious advantages
of the new fast pals and delay lines. The metastability problem has achieved
an *TTL-VOODOO* status. Lets demyth this right away.