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: <8739@utzoo.UUCP>
Date: Sat, 10-Oct-87 19:01:00 EDT
Article-I.D.: utzoo.8739
Posted: Sat Oct 10 19:01:00 1987
Date-Received: Sat, 10-Oct-87 19:01:00 EDT
References: <686@obiwan.UUCP>, <8637@utzoo.UUCP> <8638@utzoo.UUCP>, <870@alaska.cray.com>, <8724@utzoo.UUCP>
Organization: U of Toronto Zoology
Lines: 17

> ... However, if you mean actually decoding the syndrome 
> bits to determine which bit has been flipped, this seems impractical.  What
> happens if the error is in the code that corrects errors?

Greg Noel has pointed out that I responded to one of two possible meanings
of this question; does "code" mean the error-correction software or the
extra bits on the failing memory word?  In the latter case, which may have
been what was meant and which I didn't address, the answer is simple:  if
you want to look at them, which you most assuredly do, the hardware has to
provide a way to do it.  The simplest thing would be a register which latches
the extra bits when an error occurs.  Actually, there's a good chance that
you will have something more complicated than that if the hardware people
have done their job right -- how do you run diagnostics on error-corrected
memory without a way to inspect those bits?
-- 
"Mir" means "peace", as in           |  Henry Spencer @ U of Toronto Zoology
"the war is over; we've won".        | {allegra,ihnp4,decvax,utai}!utzoo!henry