Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sauron.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!ittatc!dcdwest!sdcsvax!ncr-sd!ncrcae!sauron!campbell
From: campbell@sauron.UUCP (Mark Campbell)
Newsgroups: net.arch
Subject: Re: Timing loops (H/W vs. S/W design)
Message-ID: <618@sauron.UUCP>
Date: Mon, 3-Mar-86 08:45:22 EST
Article-I.D.: sauron.618
Posted: Mon Mar  3 08:45:22 1986
Date-Received: Wed, 5-Mar-86 04:25:32 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp> <613@sauron.UUCP> <566@hoptoad.uucp>
Reply-To: campbell@sauron.UUCP (Mark Campbell)
Organization: NCR Corp., Advanced System Development, Columbia, SC
Lines: 77


In article <566@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>In article <613@sauron.UUCP>, campbell@sauron.UUCP (Mark Campbell) writes:
>> ...              What should really happen is that the chip
>> manufacturers incorporate the delay logic within those chips.
>
> [Fundamental H/W realities...]
>
>Given that piece of reality, how should chip manufacturers "incorporate
>the delay logic within those chips"?  What should the chip do if it
>gets a strobe and isn't ready for one?

Obviously you don't let the chip get a strobe for which it's not ready;
you delay DSACK on the first access to the chip until the delay time has
expired (i.e., until the device may be accessed legally again).  What
you've done is implemented the registered PAL approach (state-machine)
at the device level.

>I currently prefer the approach of having a status pin saying "ready"
>or "not ready", which external hardware (or software) can use to avoid
>strobing the chip when it is not ready.

Just use the status pin to indicate when it is safe to contine, and
you've solved the problem.  In essence, you've constructed the same
delay mechanism which you proposed to the uP guys (more on that later).

>                                        However, pins are expensive,
>so this only happens when there's a spare pin around.  If they're going
>to add a few pins to make the chip nicer, I vote for a few other uses
>first (like multiple address lines to avoid the write-the-address-then-
>write-the-data approach, which falls down if you take an interrupt in
>the middle).

Spare pins aren't usually an all or nothing proposition...a single delay
status pin is a lot cheaper than demultiplexing the address/data lines.
Besides, I'd rather perform an extra two instructions (raising the
priority of the processor, writing the address/data, and lowering the
priority) than worry about ALL of the problems associated with delays.

>System designers can nowadays use a PAL to generate the right number of
>wait states, when a few years ago there was just a decoder and you were
>stuck with whatever timing it could provide.  This does cost quite a bit
>more than a few extra bytes of software, though.

The cost is three to five dollars per registered PAL...and you're right,
it ain't cheap.  I realize that this translates to at least nine to
fifteen dollars to the customer.  But how much do you think it will cost
the customer when he gets an intermittent character lost somewhere
down the road? And how much S/W development time do you think it will cost
each time the fault is "discovered"?  You can't use a single point model
of cost in this situation; it just doesn't apply.

>> The use of the term "particularly good" when referring to a device with
>> a major flaw such as this is a non sequiteur.
>
>The Z8530 *is* a particularly good chip.  [...]

And the 432 *was* a particularly good chip (set), it was just a little
slow. (:-)  Seriously, it very well might be an *excellent* chip, just
like the TOD chip I previously mentioned.  However, both are *extremely
bad* chips in the context of supporting Unix, because both contain major
flaws with respect to Unix.  H/W exists only to execute S/W (just like an
OS exists only to execute applications), and if the H/W does it poorly,
then it just isn't good H/W...regardless of the cost.

I believe the last sentence will cause a lot of flamage.  Before you H/W
designers go on a crazed rampage, let me say that I consider this subject
somewhat moot.  The original posting came from a guy at Motorola warning
against timing loops.  This was followed by John Gilmore suggesting uP
modifications that would solve this problem.  Well, I believe that John,
in his last posting (not the message that this is in response to) gave a
solution which is adequate.  I hope it is implemented; however, I also
hope that peripheral chip manuafacturers will clean-up their bus interface
problems.
-- 

Mark Campbell    Phone: (803)-791-6697     E-Mail: !ncsu!ncrcae!sauron!campbell