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