Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!mcvax!ukc!stc!root44!miduet!misoft!adam
From: adam@gec-mi-at.co.uk (Adam Quantrill)
Newsgroups: comp.unix.wizards,comp.arch
Subject: Re: Double-bit errors and ECC memory
Message-ID: <661@gec-mi-at.co.uk>
Date: Wed, 7-Oct-87 07:00:37 EDT
Article-I.D.: gec-mi-a.661
Posted: Wed Oct  7 07:00:37 1987
Date-Received: Mon, 12-Oct-87 22:33:13 EDT
References: <1184@itm.UUCP> <797@spar.SPAR.SLB.COM> <2891@phri.UUCP> <8587@utzoo.UUCP> <9024@ut-sally.UUCP> <14617@watmath.waterloo.edu>
Sender: news@gec-mi-at.co.uk
Reply-To: adam@gec-mi-at.co.uk (Adam Quantrill)
Organization: Marconi Instruments Ltd., St. Albans, UK
Lines: 22
Xref: mnetor comp.unix.wizards:4832 comp.arch:2605

In article <14617@watmath.waterloo.edu> ccplumb@watmath.waterloo.edu (Colin Plumb) writes:
>
>If your ECC scheme is sophisticated enough, it can handle multi-bit errors,
>and thus ignore a hard error (read: flaw in the chip) or two.  Thus, yield
>goes *up*.  The only problem is that this circuitry slows the chip down.
>
It needn't slow down the chip that much. If you do the ECC at chip refresh time,
the random errors will be spotted then and appropriate action taken. Also, this
approach will minimise the chance of two independent errors corrupting the same
row, especially if that row hadn't been accessed for yonks.

It would still be a good idea to have an extra pad on the chip to flag hard
errors so the chip can be graded to:

-totally correct
-correctable hard errors
-duff

but I don't think it would be necessary to bring this out to a pin.
       -Adam.

/* If at first it don't compile, kludge, kludge again.*/