Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/13/84; site intelca.UUCP
Path: utzoo!linus!decvax!ucbvax!ucdavis!lll-crg!dual!qantel!hplabs!intelca!kds
From: kds@intelca.UUCP (Ken Shoemaker)
Newsgroups: net.arch
Subject: Re: Glitch Phenomenon (Re: Multiple 68020's on VME ?)
Message-ID: <112@intelca.UUCP>
Date: Mon, 7-Oct-85 03:58:17 EDT
Article-I.D.: intelca.112
Posted: Mon Oct  7 03:58:17 1985
Date-Received: Sat, 12-Oct-85 07:49:30 EDT
References: <442@rna.UUCP> <1192@vax1.fluke.UUCP> <1258@hcrvx1.UUCP>
Organization: Intel, Santa Clara, Ca.
Lines: 52

> 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

Actually, there is a parameter that can be measured for your everyday
flip flop to indicate mean time between synchronization failures.
Note that by their very nature synchronization circuits WILL fail
every so often, but usually the average time between synchronizer
failures is over 20 years, which is probably a bit less likely than
most of the other circuits in the computer.

A typical synchronization circuit, in TTL, looks like two back-to-back
flip flops, again, typically clocked by the same clock.  The idea
is that you won't always meet the setup/hold times of the first FF,
but you will of the second.  This works, since most FFs when their
setup/hold times are not met ultimately decide to drive their outputs
either high or low.  The time it takes this to happen when setup/hold times
are not met is related to the speed of the FF circuit, and is in direct 
proportion to the size of the real sampling window of the device, i.e., the 
size of the area where the output starts to switch, and the specified
output delays are no longer met.  Note that the closer you get to the 
center of the sampling window, the worse that the output delays
become.  Anyway, by measuring the size of the sampling window and
the delta between the time the first FF is clocked and the time the
second FF is clocked, you can calculate the mean time between synchronization
failures (obviously, the number of synchronizations you do per second
also must be taken into consideration).  Intuitively, this makes sense,
since what you are trying to do is to minimize the percentage of time
that a transition can take place that will cause the first FF not to come
to a stable output voltage before the setup time of the second FF
has started.

Any attempt to synchronize an asynchronous signal runs into
the same problem.  If there is a special problem with the VME bus,
it could be related to poor design of the bus controllers' internal
synchronizers, or an especially high-speed clock which does not allow
the first half of the synchronizer time to resolve the sygnal.
As external devices, 74AS74s or 74F74s seem to be the devices of choice
to perform this function.  Fairchild even put out a paper showing how
much better the 74F74 is at resolving asynchronous signals over a
74S74 a few years back.
-- 
...and I'm sure it wouldn't interest anybody outside of a small circle
of friends...

Ken Shoemaker, Microprocessor Design for a large, Silicon Valley firm

{pur-ee,hplabs,amd,scgvaxd,dual,qantel}!intelca!kds
	
---the above views are personal.  They may not represent those of the
	employer of its submitter.