Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!gatech!amdcad!phil
From: phil@amdcad.UUCP (Phil Ngai)
Newsgroups: net.arch,net.micro.mac,net.micro.68k
Subject: Re: timing loops
Message-ID: <9584@amdcad.UUCP>
Date: Sun, 16-Feb-86 21:19:44 EST
Article-I.D.: amdcad.9584
Posted: Sun Feb 16 21:19:44 1986
Date-Received: Mon, 17-Feb-86 06:24:50 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp>
Reply-To: phil@amdcad.UUCP (Phil Ngai)
Organization: AMD, Sunnyvale, California
Lines: 28
Xref: watmath net.arch:2537 net.micro.mac:4695 net.micro.68k:1487

In article <530@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>E.g. in meeting the recovery time of a particularly good USART chip
>with a horrible bus interface, the Z8530, you need to wait 2.2us
>between writes to it.  Give me a good way to wait 2.2us *without*
>depending on instruction timing, and I'll consider your request.

In a design I did with the 8530, the device selection logic made all
8530 cycles about 3 uS long with wait states. For the first 2.2 uS of
the cycle, the 8530 was actually not being accessed.  This guaranteed
the cycle recovery time needed. I had to use a PAL state machine to
assure another parameter (address set up time) and so this cycle
recovery time didn't cost anything extra, except the time it took me
to think it up.

I must admit part of my motivation for doing this was nightmares I had
of obscure bugs showing up because the programmer didn't bother to
read the specs carefully and violating the cycle recovery time.  (or
not even understanding what cycle recovery time was) In this example,
it was possible to idiot proof the hardware at no incremental cost.  I
imagine it is possible to come up with cases where it does cost more
but in my experience a sufficiently innovative design engineer can do
it at no or very low cost (extra pin on PAL).
-- 
 Real men don't have answering machines.

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