Do you have a question? Post it now! No Registration Necessary
- Subject
- Posted on
- Ecc Size
- 08-24-2005
posted on
August 24, 2005, 2:21 pm
August 24, 2005, 2:21 pm
Hi,
I was browsing thru the net and could find no documents on ECC
implementation (algorithm) calculation of the size of ECC for a
specific Nand Device.
Like if i have a flash Device (nand) of 512MiB, then how is the ecc
size calculated. Any pointers or PDFs or links would be highly
appreciable.
Thanks in advance,
Gromer
I was browsing thru the net and could find no documents on ECC
implementation (algorithm) calculation of the size of ECC for a
specific Nand Device.
Like if i have a flash Device (nand) of 512MiB, then how is the ecc
size calculated. Any pointers or PDFs or links would be highly
appreciable.
Thanks in advance,
Gromer
Re: Ecc Size
Remember, when using an ECC code, the number of bits must be
twice as large as the number of bits required to provide a
"bit address" of a single bit error.
This is because the ECC is calculated basically as odd
parity bit for different groupings of bits in the data block.
One bit is the parity of all even-numbered bits
One bit is the parity all odd-numbered bits
One bit is the parity of all bits with bit address bit 1 = 0
One bit is the parity of all bits with bit address bit 1 = 1
One bit is the parity of all bits with bit address bit 2 = 0
One bit is the parity of all bits with bit address bit 2 = 1
etc..
The upshot of this, is that if you compare the ECC you generate
from the data to the ECC stored with the data, they should be
equal if the data has no error (never mind that multiple bit
errors could cause identical ECC's). If there is a single bit error
in the data, the XOR of the generated and read ECC's will return
a number with each pair of bits being 10 or 01 (The bad bit only
being present in one of the bit groupings). If you extract
all the odd number bits (or the complement of the even bits, same
thing) you will get the bit address of the bad bit. Neat, huh?
Additionally, if all bit pairs but one are 10 and 01, that tells
you the single bit error was in the ECC. (the bit in the bad bit
pair).
Other mismatches mean 2 or more bits are in error. Three bits
or more bad could look like no error or correctible one bit error.
So I guess your answer is: 2*n, where 2^n is the number of bits
in the data.
But you don't do an ECC over the entire chip, as the question
seems to indicate. Each block has it's own ECC. Errors are
much more prevalent than a single bit per chip.
256 byte data (2048 bits) has a 22 bit ECC. 2048=2^11. 2*1122%
512 byte data (4096 bits) has a 24 bit ECC. 4096=2^12. 2*1224%
Rufus
I don't have my links handy right now, I'll try to remember...
Re: Ecc Size
Not quite. You've got the general idea, but you're misremembering
some of the details.
Hamming code requires enough ECC check bits to count all of the
bits in both the data and the ECC itself plus 1. For example,
6 check bits can protect up to 57 bits of data. 58 through 120
bits of data requires 7 check bits, etc.
Hamming code can correct a single-bit error, but can't distinguish
multi-bit errors, treating them as incorrect single-bit errors.
By adding just one more check bit, you can create a SECDED code
(single-error correcting, double-error detecting) which tends to
be much more useful. With this sort of code, you can protect
8 bytes (64 bits) of data with 8 check bits.
For more details, see problems #4 to #8 (particularly #5) on
this page:
http://www.circuitcellar.com/library/eq/179/index.htm
Actually, 512 bytes (4096 bits) can be protected with a 14-bit
SECDED code. But Hamming-based codes are less useful on large
blocks of data because the probability of multi-bit errors is
too high. It's better to switch to codes that work on multi-bit
symbols such as Reed-Solomon.
-- Dave Tweed
Re: Ecc Size
Hi Dave, I always stand to be corrected when running from cerebral memory,
but my posting is consistent with this document (I found the link):
http://www.samsung.com/Products/Semiconductor/Flash/TechnicalInfo/Eccalgo.pdf
Perhaps the ECC described isn't a Hamming Code?
Please solve this mystery for me, as it has been bothering me for a long
time now.
Rufus
Site Timeline
- » Reverse current into a lithium battery
- — Next thread in » Embedded Programming
- » Q: lpc921 compatiblity with 8051?
- — Previous thread in » Embedded Programming
- » A new benchmark suitable for small systems: stdcbench
- — Newest thread in » Embedded Programming
- » Seltsames aus China
- — The site's Newest Thread. Posted in » Electronics (German)