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