I don't know enough about other platforms to comment, but on the SPARCs where I know something about parity/ECC and RAM, non-parity is 32 bits wide, parity is 33, and ECC is 36. 4 extra bits doesn't seem like enough to do even SEC to me, never mind SECDED, so I'm not sure how 36 bits can actually provide ECC, but that's what it's called. (For a 32-bit word, there must be at least 32 codewords at Hamming distance 1 that are at distance >1 from all other valid codewords, so there must be at least 32 times as many possible codewords as valid codewords - but 4 extra bits gives only 16 times as many possible codewords as valid codewords.) Maybe the memory controller actually handles it as 64-bit words with 8 bits of ECC data each or something equally odd. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

der Mouse wrote: For 64 bit memory (assuming you want to treat it as a 64 bit entity) you need 7 bits (minimum) to "correct a single bit error". Simple rule of thumb: the extra bits in some way need to be able to tell you WHICH of the other bits is wrong. So, you need log2(width) bits to specify one of "width" bits (e.g., 5 for 32 bits, 6 for 64 bits, 3 for 8 bits, etc.). But, you also have the "all bits are correct" case which must be conveyed. So, log2(width)+1 are required. *How* those bits are used in the code words is up to the particular code.

der Mouse wrote: The beauty of the Hamming codes was the simplicity of doing so. If you have D data bits, you take build an L-row matrix wherein each column is the L-bit representation of such that no two columns are the same -- and the "0...0" vector never appears (L is the number of bits that you are adding to the data bits -- there must be D+L columns in said matrix). So, for an 8 bit value, you would create a matrix: 0 0 0 0 0 0 0 1 1 1 1 1 0 0 0 1 1 1 1 0 0 0 0 1 0 1 1 0 0 1 1 0 0 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 Your input code word (D+C digits... C=4 here) is then multiplied by this matrix. A result of "0..0" indicates a valid code word (no error). Any other value tells you which bit needs to be twiddled in the input code word. The "check digits" (given this form of the code) are interspersed among the data digits by noting where the column vectors in this matrix have only a single bit set in them. (E.g. the 1st, 2nd, 4th and 8th columns). You can obviously rearrange the columns. Or, select a different subset of those available (e.g., replace the last column with 1 1 1 1) [let me know if this isn't quite right... I'm just calling it up from memory and I haven't had to design any ECC hardware in *decades*! :-/ ]

Only if the ECC is incompetently done; a single-bit error, in the ECC world, can be in any of the bits. ECC is not simply adding checking bits to a normal word; if you use 71 bits of memory to store 64 bits of data ECC-protected, there normally will not be any 64 of those 71 bits where you can look to always find the upper-layer data. Instead, the coding scheme just ensures there are 2^64 distinct 71-bit words with a Hamming distance of at least 3 (for SEC) or 4 (for SECDED) between any two of them, with structure that makes it relatively easy to extract the 64 bits of data from a 71-bit codeword. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Andy Holt wrote: Also at one time with small Dynamic memory ( how one defines small is a minor point today ) one could do error checking on refesh cycles thus keeping bit errors down to a minium.

Andy Holt wrote: Note, not all ECC's are Hamming! It's beauty is that it is simple to implement (though not as efficient as a code could theoretically be) Except *disk* memory, of course... :> Sorry if my comment wasn't clear enough: For 64 bit memory (assuming you want to treat it as a 64 bit entity) you need 7 bits (minimum) to "correct a single bit error". -----------------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^ Simple rule of thumb: the extra bits in some way need to be able to tell you WHICH of the other bits is wrong. So, you need log2(width) bits to specify one of "width" bits (e.g., 5 for 32 bits, 6 for 64 bits, 3 for 8 bits, etc.). But, you also have the "all bits are correct" case which must be conveyed. So, log2(width)+1 are required. If you want to *detect* two bit errors, then you need extra check digits. (Hamming distance is the number of bits of "difference" between VALID code words). In particular, you can DETECT no more than X errors if the Hamming distance is X+1. Note that n simple parity, all valid code words differ in at least 2 bits -- a data bit and, if a data bit is toggled (to represent a different value from some *other* data value), that means the parity bit is also toggled! So, parity can detect 2=X+1 or *1* error. You can CORRECT no more than Y errors if the Hamming distance is 2Y+1. Since the distance for simple parity (above) is 2, 2=2Y+1 or *0* bits can be corrected. So, to DETECT 2 errors, you need a Hamming distance of 3. To CORRECT 1 error you also need a Hamming distance of 3. But, there's no free lunch. You get one or the other "capability" for that distance. To do *both*, you need a Hamming distance of X+Y+1 -- or, 4, in this case. A Hamming CODE will correct a single bit error (distance = 3). A Hamming code is formed by adding C bits to the data word. It must be possible to indicate which of the resulting D+C bits is in error -- so, log2(D+C) <= C (this is roughly C=log2(D)+1). But, this just gives you a "distance 3" code. To get a distance *4* code (which allows CORRECT 1 *and* DETECT 2), you add a parity bit to the C bits (one extra bit means the distance is now 1 greater between VALID code words). When the input code word differs by more bits than can be accommodated, the code typically "corrects" to a wrong data value (or, ignores the error altogether!) -- just like simple parity...

Jules Richardson wrote: No. The code words represent the only "legitimate" way of encoding a particular "value" (data bits plus check bits). So, an error in a check bit is likewise detected (and corrected -- assuming it is a single error). My explanation wasn't meant to be thorough. Rather, just a simple aid to figuring out how many bits you need (at a minimum) for a *single* bit correction. If you *really* want me to dig out formal definitions for all of these, I can -- but *you* can probably google an explanation just as quickly! :> No. To paraphrase a (bad) commercial: "bits is bits". The memory controller checks each "entity" fetched from the memory array. It dynamically determines what the check bits *should* be for those data bits and compares to the check bits read. If a discrepancy exists, the controller figures out WHICH bit(s) need to be corrected and makes the adjustment before presenting the corrected *data* bits to the host/cpu. On each write operation, the check bits corresponding to the data being written are synthesized and stored in the memory array alongside the data bits. (how errors are reported/handled is immaterial to the controller) Note that ECC is not infallible. It just increases the likelihood of getting good data *if* the number of instantaneous failures never exceeds the maximum number for which the code was designed. E.g., typically, you can detect two bit errors and correct *one* (whereas simple parity detects one and corrects zero). Note that a system designed to "detect 2, correct 1" will often gladly report *3* errors as "no errors" (just like flipping *two* bits in a simple parity scheme results in NO parity error -- even if one of those bits is the parity bit)

On Mon, 15 May 2006 09:43:29 -0400 (EDT) der Mouse <mouse at rodents.montreal.qc.ca> wrote: SGIs want SIMMs in banks of four. Some Alphas (IIRC AS1000) need fife SIMMs per bank (one SIMM only for ECC) and some Alphas (AS600) need eight SIMMs per bank. So according to Dons explanation there should be enough redundancy to do real ECC with 36 bit SIMMs in those machines. -- tsch??, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/