Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: comp.arch
Subject: Re: Double-bit errors and ECC memory
Message-ID: <8637@utzoo.UUCP>
Date: Mon, 21-Sep-87 21:38:59 EDT
Article-I.D.: utzoo.8637
Posted: Mon Sep 21 21:38:59 1987
Date-Received: Mon, 21-Sep-87 21:38:59 EDT
References: <686@obiwan.UUCP>
Organization: U of Toronto Zoology
Lines: 23

> The gripes against ECC are (1) it's "dishonest" because it lets mfrs
> sell defective chips.  {This was also heard three years previously
> when redundant memories were first discussed.}  (2) There's no way to
> tell whether a given chip has a hard error {ECC masks it}, in which
> case the single-bit ECC provides no protection against soft errors.

Mmm, I was actually thinking of ECC provided purely for post-manufacturing
errors, not as a way of covering up manufacturing defects.  And doing it
right would definitely require some way to find out what had happened on
chip, so that the software could cope appropriately.  In other words, what
we have right now in board-level implementations, but done on the chip.
(Yes, I realize there is a pin-count problem that makes it difficult to
devise a way of asking the chip for an error report.)

If the manufacturers want to use ECC as a way of dealing with chip defects,
that's fine by me, but it's *not* what I'm asking for.

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.)
-- 
"There's a lot more to do in space   |  Henry Spencer @ U of Toronto Zoology
than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry