hugh@hcrvx1.UUCP (Hugh Redelmeier) (10/03/85)
About 10 years ago, I first learned of what was called the Glitch Phenomenon. It was described (if I remember correctly) in a tech report from MIT. They showed theoretically that asynchronous systems could not be synchronized in *any* bounded amount of time! They then showed some practical examples with real TTL and oscilloscope traces. If I remember correctly, it is possible to build a circuit that syncronizes, and says when it has done so (after an unbounded but short amount of time). I also seem to remember that a project attempting to build a machine that was internally very asynchronous ended up having to invent equivalents for TTL MSI so they wouldn't get bit by the glitch (perhaps Al Davis's Data-Driven machine). In article <1192@vax1.fluke.UUCP> witters@fluke.UUCP (John Witters) writes: >I'd suggest reading the August 1st 1985 issue of Computer Design before you >rush off and do this. The article of interest is titled "Metastability haunts >VME bus and Multibus II system designers" on page 29. ... >Because the >arbiter makes its arbitration decisions in about 20ns, the output of its >synchronizer has only 20 ns to settle to a stable state, but needs at least 50 >ns to ensure reliable operation. 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
freed@aum.UUCP (Erik Freed) (10/07/85)
> 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.
jack@boring.UUCP (10/09/85)
Can anyone point me to articles on this matter? I'll summarize, of course. -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.