Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 Tandy Xenix 02/17/86; site gilbbs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!pyramid!hplabs!qantel!ptsfa!gilbbs!mc68020
From: mc68020@gilbbs.UUCP (Tom Keller)
Newsgroups: net.arch
Subject: Re: Re: Bad devices (timing loops)
Message-ID: <38@gilbbs.UUCP>
Date: Thu, 6-Mar-86 19:30:41 EST
Article-I.D.: gilbbs.38
Posted: Thu Mar  6 19:30:41 1986
Date-Received: Sat, 8-Mar-86 22:23:50 EST
References: <374@mips.UUCP>
Distribution: net
Organization: Gil's Place, Santa Rosa CA
Lines: 74
Summary: the status quo is not necessarily the ideal state

In article <374@mips.UUCP>, mark@mips.UUCP (Mark G. Johnson) writes:
> In article <10040@amdcad.UUCP>   phil@amdcad.UUCP (Phil Ngai)  writes:
> 
>  > .....
>  > As a matter of fact, most chips don't tell you when they are
>  > ready.  When was the last time a RAM chip told you it was ready
>  > for CAS after you sent RAS, or even when read data is valid?
>                                   ^^^^ ^^^^ ^^^^ ^^^^ ^^ ^^^^^^
> 
> Actually, RAM chips with this feature were built ten years ago....
> by AMD-Sunnyvale (Mr. Ngai's employer).  Self-timed access cycles
> were accomplished by providing an "MS" output pin on the RAM,
> which signaled cycle-is-done.  This allowed simple handshake
> protocols, as outlined in the reference below:
> 
> ref: Jeffrey M. Schlageter, Nagab Jayakunar, Joseph H. Kroeger,
>      and Vahe Sarkissian, Advanced Micro Devices, Sunnyvale, CA,
>      "A 4K Static 5-V RAM", Paper THPM-12.5, International Solid-
>      State Circuits Conference, Digest of Technical Papers,
>      February 19-21, 1976, pp. 132-7.

   Actually, in reading Mr. Ngai's articles both here and on ba.politics,
as well as elsewhere on the net, my impression is that Mr. Ngai expends 
a great deal of energy defending the status quo. 

   Now I realize that this is not a technical comment, and I further realize
that this will be viewed as a personal "attack".  It is, however, a legitimate
observation on the nature of Mr. Ngai's articles, and as such is a cogent 
contribution to the overall discussion.


   Along these same lines, I apparently managed to offend several people in my
comments to Ken Shoemaker@intel.  I apologize for any discomfort the nature of
my comments may have caused, and hopefully a difference in approach will be
noted in this entry.


   I do feel, however, that my comments were cogent.  Mr. Shoemaker was, in 
essence, using his position as a microprocessor designer at INTEL as a point
of authority to support his thesis.  While I'll grant that it is certainly a
matter of opinion, it is my opinion that working for Intel doesn't qualify
anyone as an authority on anything (judgement based on shipped products and
ethical standards in advertising and specification listings(or lack thereof).
Therefore, it was cogent to point out that his position of authority was
questionable.

   I also suggested that perhaps Mr. Shoemaker's concepts of engineering and
quality were warped.  This suggestion *WAS* preceded by a conditional, 
which I still adhere to:  "*IF* hardware designers are suggesting that system
designers should accept badly designed chips *SIMPLY* because it is possible
to work around the flaws in software, *THEN* I would suggest that their concepts
of engineering and quality are warped.".  Mr. Shoemaker (and several others)
chose to take this as a personal affront.  Perhaps due to the manner in which
I expressed myself.  I therefore also apologize for any personal distress my
ineptitude caused.  I stand by the essence of my statements, however.


   I do not believe that it is always possible to discuss even technical 
issues without occasionally making personal observations and/or comments.  If,
however, it is clearly the wish of the majority of readers of net.arch that
this be the rule, I will abide by it.  

   Thank you.

-- 

====================================

Disclaimer:  I hereby disclaim any and all responsibility for disclaimers.

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

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