Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site steinmetz.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!mcnc!ncsu!uvacs!edison!steinmetz!davidsen
From: davidsen@steinmetz.UUCP (Davidsen)
Newsgroups: net.arch,net.micro.mac,net.micro.68k
Subject: Re: Bad Devices (was Re: timing loops)
Message-ID: <674@steinmetz.UUCP>
Date: Sat, 8-Mar-86 16:46:28 EST
Article-I.D.: steinmet.674
Posted: Sat Mar  8 16:46:28 1986
Date-Received: Mon, 10-Mar-86 08:24:32 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp> <6780@boring.UUCP> <221@dmsd.UUCP> <21@gilbbs.UUCP>
Reply-To: davidsen@kbsvax.UUCP (Davidsen)
Organization: GE CRD, Schenectady, NY
Lines: 42
Xref: watmath net.arch:2754 net.micro.mac:5039 net.micro.68k:1552
Summary: 

In article <21@gilbbs.UUCP> mc68020@gilbbs.UUCP (Tom Keller) writes:
>In article <221@dmsd.UUCP>, bass@dmsd.UUCP (John Bass) writes:
................ long previous quote deleted here ................
>
>   Methinks that you are missing the point here, John.  What is being said is
>that the design and implementation of the VLSI component itself is a botch.
>If you are suggesting that designers should settle for bad designs (and let's
>face it, any component at the chip level that can't be bothered to *TELL* me
>that it isn't ready for further interaction is a ***BAD*** design!) simply 
>because it is *POSSIBLE* to gloss over the problems in software, then I would
>suggest to you that your concepts of engineering and quality are warped.

I hate to get into this, but there are classes of devices which change
state due to processor action (like USARTs, for instance). Given any such
device on the market, or even in the lab, it is posible to access the
device so quickly that the status won't track what's happening. This
sometimes happens when a processor sends a character to a USART or
parallel interface and then tests the busy bit before it has become
active. There is a finite time which any device takes to REALIZE it's not
ready for another command.

By this inference, any such device is always a botch, since at least one
gate delay is present between the write and the status update. Does this
mean using galium arsenide for USARTs to avoid being a botch? Ridiculous!
What has happened is that the circuit designer is using poorly selected
parts (or the user has jumped the processor speed).

Timing loops can (usually) be avoided by checking the status to be sure it
becomes "not ready", before continuing, but then the code will fail if the
processor is slowed to the point that the device goes not ready and ready
before it's checked. The solution is to blame the person who put the chips
together, not to say that some chips are a "botch".
-- 
	-bill davidsen

	seismo!rochester!steinmetz!--\
       /                               \
ihnp4!              unirot ------------->---> crdos1!davidsen
       \                               /
        chinet! ---------------------/        (davidsen@ge-crd.ARPA)

"It seemed like a good idea at the time..."