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!qantel!ptsfa!aum!freed
From: freed@aum.UUCP (Erik Freed)
Newsgroups: net.arch,net.micro.68k
Subject: Re: Asynchronous State machines
Message-ID: <402@aum.UUCP>
Date: Fri, 15-Nov-85 11:33:37 EST
Article-I.D.: aum.402
Posted: Fri Nov 15 11:33:37 1985
Date-Received: Sun, 17-Nov-85 06:57:44 EST
References: <389@aum.UUCP> <6077@utzoo.UUCP>, <395@aum.UUCP> <6111@utzoo.UUCP>, <401@aum.UUCP> <6138@utzoo.UUCP>
Organization: The Aurora Systems Bunch
Lines: 44
Xref: linus net.arch:1898 net.micro.68k:1255

> > 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.
> 
> You can run things a little faster than that.  (Yes, I've done the math.)
> State machines running that fast are not insuperably difficult.

Henry,
	I guess it all depends on your data rate and design goals. For a
Vme bus interface gadget, and for what I consider safe MTBF, this is about
the lowest in most cases. Go lower and you are introducing possible flakiness.
especially considering that Fairchild's data just might be self-serving...
My comment about the  speed of the state machine is based on the fact that
your clock rate sometimes (read often) depends on more things than just
how fast you want to synchronize.

> 
> > ... 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.
> 
> Well, when I started looking at real-world delay lines and adding up the
> times, I said "forget this garbage" and went back to using a state machine
> that didn't have things like +-10% all through the spec.  10% here and 10%
> there adds up awfully fast.  As I've mentioned, I am told that one can get
> delay lines with tighter specs; I just didn't happen to find any.

Again you must be building to very different specs. The +-10% seems way out of
line to me. that is for delay lines with very long delays. I thought we were
talking about fast state machines :-) My point was that people who have 
actually completed an ASM at the end of it recognize that when you absolutely,
positively have to have that signal overnight there is nothing like a ASM.
I never expected to get an argument about the *SPEED* of ASM's. I don't think
that someone who has implemented both would really argue the speed. The weak
point of ASM's is race conditions or hazards. This really is factor which can
create longer development times (assuming that you actually get it working).
All I can say is that you really ought to look over a ASM masters shoulder
and see what can be done with them before you `throw your delay lines away'
-- 
-------------------------------------------------------------------------------
                           Erik James Freed
			   Aurora Systems
			   San Francisco, CA
			   {dual,ptsfa}!aum!freed