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.

For parity you add one bit per ECC line, whatever the line size. But then it doesn't correct, and 2 bits flipped are not detected.
For SECDED (Single Error Correct, Double Error Detect), you have a logical circuit which gives you the bit number which flipped, so for 32 bits ECC line you need enough bits to tell which bit has flipped, plus one value which tells "out-of-range, more than single error", so you need to count from 0 to 32 - so 6 bits. In reality you need to count from 0 to 32+6=38, still 6 bits, to also protect the ECC information.
My comment was about how the logical circuit would treat more than two bit flipped, mathematical proof that > 2 bits flipped is never treated a single error detected and corrected.