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 hoptoad.uucp
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!sun!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: net.arch
Subject: Re: Timing loops (H/W vs. S/W design)
Message-ID: <566@hoptoad.uucp>
Date: Fri, 28-Feb-86 05:24:33 EST
Article-I.D.: hoptoad.566
Posted: Fri Feb 28 05:24:33 1986
Date-Received: Sat, 1-Mar-86 22:35:38 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp> <613@sauron.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 50

In article <613@sauron.UUCP>, campbell@sauron.UUCP (Mark Campbell) writes:
> Recently, we began work on a new machine.  The very first thing the H/W
> guys did was obtain a copy of "All the Chips that Fit" (by Lyon and
> Skudlarek, of Sun) and proclaim that we wouldn't make the mistakes that
> Sun made.
> 
> Unfortunately, management then stepped in...
> 
> The one thing we did insist upon, though, was glue logic to support
> those chips that had timing problems.  Mr. Gilmore stated that
> microprocessor designers should design system independed ways of
> dealing with delays.  What should really happen is that the chip
> manufacturers incorporate the delay logic within those chips.

Peripheral chips are driven by strobes from the outside world.  In
almost all cases (except tightly coupled coprocessor style chips), the
peripheral chip does not tell the CPU when it is done with a request;
the system designer is expected to have read the data sheet and set up
the right number of wait states and such.  This makes the peripheral
chip usable in many systems no matter whose CPU or bus you are using.

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?

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.  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).

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 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.  I would rate it as one of the
best chips Zilog has designed.  Its bus interface has clearly shown up
as the weakest part of the chip though -- especially the vectored
interrupt "support".  If one of the seventy-leven companies which are
second sourcing it and putting their own part numbers on it would
instead fix the bus interface, I bet they'd get some sales.
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa