[comp.arch] Error Correcting dRAM chips

mark@mips.UUCP (Mark G. Johnson) (09/22/87)

In article <208@slxsys.UUCP> , jpp@slxsys.UUCP (John Pettitt) writes:
	> Why not have an `ECC_FAULT' pin on the ram chip that signals
	> that the on chip ecc logic just found and corrected an error ?
	> This output would then be used to generate a 'ram fault'
	> signal to the os, and with the correct software place
	> the service call . . .

Do you want all dRAM chips to include this pin?  Even those from vendors
who choose not to use on-chip ECC?  If not, this implies a new,
non-standard RAM chip definition available from some but not all vendors.
Not many customers these days are willing to design-in and buy anything
but a Worldwide Standard, multiple sourced RAM chip.  {didn't used to
be true - a startup company invented and was sole-source for multiplexed
address 4K dRAMs in narrow (0.300") packages.  Folks bought em like crazy.}

If you want *all* dRAMs to have an ECC_FAULT pin you've got a problem,
a big problem.  You've got to convince JEDEC to define a new, standard
pinout.  These guys have historically canned any proposal to add
extra pins onto dRAMs; their position is that extra pins waste board
space.  So you've got to change the minds of some very conservative,
timid companies who are quite happy, thank you, to keep doing it
the same old way.  Hasn't happened very often - the 4K dRAM example
is the exception rather than the rule.

Then in <8637@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
	> I don't have any real hope that anyone is going to do what I
	> want, though.  (Heavens!  Change the DRAM interface to make
	> the system-level design simpler?!?  Much too radical.
	> Completely unacceptable to Marketing.)
Agreed - sad but true.

-- 
-Mark Johnson	*** DISCLAIMER: The opinions above are personal. ***	
UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mark   TEL: 408-720-1700 x208
US mail: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086