Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ucla-cs!zen!ucbvax!hplabs!hp-pcd!uoregon!omepd!randys
From: randys@mipon3.intel.com (Randy Steck)
Newsgroups: comp.unix.wizards,comp.arch
Subject: Re: Double-bit errors and ECC memory
Message-ID: <1064@omepd>
Date: Thu, 17-Sep-87 20:35:23 EDT
Article-I.D.: omepd.1064
Posted: Thu Sep 17 20:35:23 1987
Date-Received: Sun, 20-Sep-87 03:24:12 EDT
References: <1184@itm.UUCP> <797@spar.SPAR.SLB.COM> <2891@phri.UUCP> <7319@steinmetz.steinmetz.UUCP> <8587@utzoo.UUCP>
Sender: news@omepd
Reply-To: randys@mipon3.UUCP (Randy Steck)
Organization: Intel Corp., Hillsboro
Lines: 51
Xref: mnetor comp.unix.wizards:4318 comp.arch:2233

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.

There is certainly a trend toward making "smarter" memory chips, but ECC is
a different animal all together that does not really lend itself to
implementation on the memory chip.  It certainly doesn't belong on the most
common organization of the memory device (X1) since the overhead of using
it is so high (in terms of silicon cost).  The cost and yield curve in this
case tends to argue that the ECC logic be included directly on a much
smarter and more configurable memory controller.  I would propose a memory
controller that was smart enough to do ECC, powerful enough to drive the
array of memory devices directly (relaxing the access time requirements),
and smart enough to work with others of its type in a system without
contention.

>and the problem
>with needing read-modify-write cycles for a partial write goes away because
>dynamic RAMs have to do this *anyway*.  (Essentially all accesses to DRAMs
>are r-m-w cycles, because the internal readout operation is destructive
>and must be followed by a writeback, ....

Unfortunately, this is not really true.  The apparent RMW cycle that is
performed by DRAMs is a characteristic of the circuitry and not of the
logical design.  In other words, the designer of the DRAM has done nothing
to sequence the refresh of the DRAM cell.  The act of reading the memory
cell is sufficient to refresh it to its fully charged state.  The
requirements of ECC would be that a cell would have to also be "flipped"
during the interval in which it is read, which would be extremely difficult
without some form of sequencing logic.  (And sequencing is really very tough
without a clock!)

>It's to the credit of DRAM designers that these grubby details are largely
>invisible nowadays; high time they did the same for ECC.)

Although I have enormous respect for my colleagues who *want* to spend
their lives looking at circuit simulations to create a DRAM, I think it is
stretching to say that they have gone to great lengths to hide the "grubby
details".  These details are an inherent part of the mechanism by which
DRAM cells are read and written.  There is no easy counterpart to the
problem for ECC.

Please notice that I am not saying that it cannot be done (Micron Tech.
already did it!), just that it is not feasible for the foreseeable future
given the alternative implementations.  Besides, do you really care where
the ECC is done as long as it is done and you don't have to bother with
it?

Randy Steck
Intel Corp.     ...intelca!mipos3!omepd!mipon3!randys