Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site amdcad.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!amdcad!phil
From: phil@amdcad.UUCP (Phil Ngai)
Newsgroups: net.arch,net.micro.68k
Subject: Re: Asynchronous State machines
Message-ID: <6385@amdcad.UUCP>
Date: Sat, 16-Nov-85 01:23:44 EST
Article-I.D.: amdcad.6385
Posted: Sat Nov 16 01:23:44 1985
Date-Received: Sat, 16-Nov-85 09:26:50 EST
References: <389@aum.UUCP> <6077@utzoo.UUCP> <395@aum.UUCP> <6111@utzoo.UUCP> <401@aum.UUCP> <6138@utzoo.UUCP> <402@aum.UUCP>
Reply-To: phil@amdcad.UUCP (Phil Ngai)
Organization: AMD, Sunnyvale, California
Lines: 25
Xref: watmath net.arch:2092 net.micro.68k:1316

Say, Henry, perhaps you should explain what you mean when you say
you've done the math and synchronous state machines can be run faster
than 50 nS?  I am guessing you added the data to clock setup time, the
clock to Q time, and the delay through your state logic and called
that your period.

What I think the advocate of ASM is talking about is the time required
for a FF to settle out of a metastable state with an acceptable MTBF.
For something reasonable like once every 40 years at say a 1 MHz rate,
I recall a device like a S FF would take 70-80 nS. I understand the
new F logic settles faster and that may be the origin of the 50 nS
number quoted.

This decision time is required whenever your inputs are not synchronous
with your clock if you are using a SSM. ASMs don't need this and that
is the claimed advantage. I'd agree that ASMs are a obscure design
technique which deserve more recognization. Their obscurity is probably
due to the fact that they are harder to understand than SSM.
-- 
 The California Lottery may be a tax on the stupid, but at least
 some of the proceeds are used for education.

 Phil Ngai +1 408 749-5720
 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
 ARPA: amdcad!phil@decwrl.dec.com