Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!lll-crg!lll-lcc!qantel!ptsfa!gilbbs!mc68020
From: mc68020@gilbbs.UUCP (Tom Keller)
Newsgroups: net.arch,net.micro.mac,net.micro.68k
Subject: Re: Bad Devices (was Re: timing loops)
Message-ID: <21@gilbbs.UUCP>
Date: Thu, 27-Feb-86 15:05:25 EST
Article-I.D.: gilbbs.21
Posted: Thu Feb 27 15:05:25 1986
Date-Received: Sat, 1-Mar-86 17:40:39 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp> <6780@boring.UUCP> <221@dmsd.UUCP>
Organization: Gil's Place, Santa Rosa CA
Lines: 40
Xref: watmath net.arch:2655 net.micro.mac:4903 net.micro.68k:1526
Summary: timing loops *ARE* a botch, when ICs are involved

In article <221@dmsd.UUCP>, bass@dmsd.UUCP (John Bass) writes:
> > As a kernel hacker, I would maintain that a device that requires a
> > certain latency and neither rejects further commands nor signals an
> > iterrupt until it's ready is a botch.  Why patch software when the
> > hardware CAN do it right?  Software is not the answer to hardware
> > designer ineptitude.  Even if it has to be done at the board level,
> > the proper choice is to add the hardware to disable access to the
> > device until its latency period is over.
> DO IT RIGHT ???? ^&%^%@%(*) Right depends on the goals and requirements.
> From were many of us sit RIGHT is LOW COST, LOW POWER, SMALL SIZE, and
> a dozen other reasons for using a KNOWN hardware/software tradeoff to
> reduce componet counts. From Marty's IVORY TOWER in AT&T land he has a very
> obscure view of RIGHT -- a company that produces $300 power supplies that
> deliver 40 watts (they do last 30 years with minor service though) and other
> common place electronics (like telephones) that are now 1/3 the cost once the
> repairability and service life requirements have been reduced by other vendors.
> Not that I especially like some of the CHEAP phones -- but a good trend overall.
> Timing loops are FAIR GAME for any lowcost design -- and can be VERY general
> with the aid of a subroutine that takes as it's argument the min number of
> time units to spin out.


   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.

   *GIVEN* that this component was the only choice (for some inexplicable
reason), it *STILL* does not follow that the cheapest solution is necessarily
the best.  KNowing very little about the other requirements of the system being
designed by the original poster, I don't believe that you have any grounds for
your argument in this case.

   tom keller
   {ihnp4, dual}!ptsfa!gilbbs!mc68020

   (* we may not be big, but we're small! *)