Ecc Size

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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


Re: Ecc Size
The data sheets and app notes for the NAND flash from Samsung or Toshiba
have extensive notes on ECC
Quoted text here. Click to load it



Re: Ecc Size
Quoted text here. Click to load it

Here's one link:

http://download.micron.com/pdf/technotes/nand/tn2908.pdf

/Rolf

Re: Ecc Size

Quoted text here. Click to load it

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
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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