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!philabs!cmcl2!seismo!lll-crg!well!ptsfa!aum!freed From: freed@aum.UUCP (Erik Freed) Newsgroups: net.arch,net.micro.68k Subject: Re: Asynchronous State machines Message-ID: <401@aum.UUCP> Date: Thu, 7-Nov-85 08:11:42 EST Article-I.D.: aum.401 Posted: Thu Nov 7 08:11:42 1985 Date-Received: Sun, 10-Nov-85 03:42:46 EST References: <389@aum.UUCP> <6077@utzoo.UUCP>, <395@aum.UUCP> <6111@utzoo.UUCP> Organization: The Aurora Systems Bunch Lines: 31 Xref: linus net.arch:1858 net.micro.68k:1230 > > I mean we are talking at least 100 -200 ns for the sync problem alone. > > Nonsense, not with FTTL flipflops to do the synchronizing. > Even with FTTL you should have about two 50 ns sync times. (Do the math) this then has the clock to output at the end tagged on. This assumes that you have a state machine running that fast. > > > ... 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. Even if the skew goes away, You still pay a huge penalty. Have you actually implemented a fast async state machine? ( and compared it to a sync one) I don't mean this as a dig it's just that I know a lot of people who argued this way who when they started actually using real world delay line and adding up min/max times changed their tune rapidly. -- ------------------------------------------------------------------------------- Erik James Freed Aurora Systems San Francisco, CA {dual,ptsfa}!aum!freed