anon (anon.delete@this.anon.anon) on January 7, 2021 2:21 am wrote:
> Etienne Lorrain (etienne_lorrain.delete@this.yahoo.fr) on January 7, 2021 1:21 am wrote:
> > Jukka Larja (roskakori2006.delete@this.gmail.com) on January 1, 2021 10:28 pm wrote:
> > > as there isn't clear information about what that "unofficial" means.
> >
> > Maybe, just maybe, it is because of the length of an ECC line.
> > If I remember well, you can prove/check that up to 32 bits protected by 6 bits, your logical
> > SECDED circuitry will always correct one bit error, and always report DED if more than
> > one error is present (no triple or more fault error will be detected as a SEC).
> > You can't do that if your ECC line is longer, more (or equal) to 64 bits protected by more (or equal) than
> > 7 bits, you just have a "strong feeling" it is, but checking every combinations would be too long.
> > Same with DECTED, too many combinations.
>
> Isn't ECC overhead 1/8th the cost of the data? Like if you
> have 8 DRAM chips, the ECC chip would be the ninth one?
>
> Your example of protecting 32 bits by 6 bits is more than that. So I'm not sure if that's cogent or optimal.


Somewhat informally, to correct a single bit error you need enough bits to identify the incorrect bit. Because the ECC code is part of the memory word, five bits isn't enough for a 322-bit word, because you'd have only five bits to cover a the physical 37-bit word (remember the error can occur in the check code), so you need an additional bit. To then detect double bit errors, you then need something akin to an parity bit added to that.

So SECDEC on a 32-bit word requires seven bits, eight bits on a 64-bit word, nine bits on a 128-bit word. Doing that on 64-bit words has the advantage of allowing fairly simple 8x9 or 9x8 RAM configurations.

IOW: 1+ceil(lg(n+1))

(at least for reasonable word sizes, the n+1 is too low for very short word sizes.)