Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.arch,net.micro.68k
Subject: Re: Asynchronous State machines
Message-ID: <6111@utzoo.UUCP>
Date: Mon, 4-Nov-85 14:40:26 EST
Article-I.D.: utzoo.6111
Posted: Mon Nov  4 14:40:26 1985
Date-Received: Mon, 4-Nov-85 14:40:26 EST
References: <389@aum.UUCP> <6077@utzoo.UUCP>, <395@aum.UUCP>
Organization: U of Toronto Zoology
Lines: 26

> ... The relatively small
> amount of min/max skew in delay lines seems rather dwarfed by these advantages.

It was *not* relatively small in the delay-line data sheets I was looking
at; it was enough for me to reject them quite quickly.  I am told that
delay lines with tighter specs are available, however.

> I mean we are talking at least 100 -200 ns for the sync problem alone.

Nonsense, not with FTTL flipflops to do the synchronizing.

Understand, I am not belittling the virtues of asynchronous design, just
pointing out that the asynchronous components aren't as good as one would
like sometimes, and the synchronous components aren't as bad as people claim.

> ... Try
> looking at say a 16R8 versus a 16L8 PAl with the non-registered version you
> only have to worry about the skew *BETWEEN* prop times on a single pal. This
> allows some very creative fast designs. For the registered version you have
> to wait the maximum prop and clock_to_output times.

In return for that delay, however, the skew pretty much goes away.  This
is not a trivial issue for some things.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry