[comp.arch] DRAM ECC on-chip. Won't Handle Whole-row Stuck-at Faults?

dgreen@ucla-cs.UUCP (09/18/87)

In article <8587@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>Clearly, what we need, urgently, is ECC on the damn memory chips.  There
>have already been mutterings about this, but no commercial products as
>far as I know.  This is an ideal place for ECC:  wide words are available
>internally to reduce the number of correction bits needed (to the extent
>that this is desirable -- fewer bits mean poorer coverage against multiple
>errors), modest amounts of circuitry are not hard to add, and the problem
>with needing read-modify-write cycles for a partial write goes away because
>dynamic RAMs have to do this *anyway*.  

How do they compensate for whole-row stuck-at faults within the chip?  When 
a whole column goes out, obviously the ECC will correct for it.  When a 
whole row goes out, I can't see how on-chip ECC could help.

On-chip ECC would certainly take care of ubiquitous one-bit alpha-particle 
errors.

When using 1 bit-wide DRAMs and EXTERNAL error correction circuitry, 
whole-word stuck-at faults are highly unlikely (i.e., nearly impossible).  
And if a whole chip goes out, ECC compensates.  This is one advantage of 
external ECC circuitry.

There could be some way to organize ECC to compensate for whole-row 
stuck-ats.  Anybody know how the ECC is done in these chips?

Dan Greening   Internet   dgreen@CS.UCLA.EDU
               UUCP       ..!{sdcrdcf,ihnp4,trwspp,ucbvax}!ucla-cs!dgreen