Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Special pages
Niidae Wiki
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Flash memory
(section)
Page
Discussion
English
Read
Edit
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
View history
General
What links here
Related changes
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
===NAND memories===<!-- This section is linked from [[Centrino]] --> NAND flash architecture was introduced by Toshiba in 1989.<ref name="toshiba-20020909b" /> These memories are accessed much like [[block size (data storage and transmission)|block devices]], such as hard disks. Each block consists of a number of pages. The pages are typically 512,<ref name="ieee_cf"> {{Cite news |last1=Kim |first1=Jesung |last2=Kim |first2=John Min |last3=Noh |first3=Sam H. |last4=Min |first4=Sang Lyul |last5=Cho |first5=Yookun |date=May 2002 |title=A Space-Efficient Flash Translation Layer for CompactFlash Systems |periodical=Proceedings of the IEEE |volume=48 |issue=2 |pages=366–375 |doi=10.1109/TCE.2002.1010143 }}</ref> 2,048, or 4,096 bytes in size. Associated with each page are a few bytes (typically 1/32 of the data size) that can be used for storage of an [[error correcting code]] (ECC) [[checksum]]. Typical block sizes include: * 32 pages of 512+16 bytes each for a block size (effective) of 16 [[Kibibyte|KiB]] * 64 pages of 2,048+64 bytes each for a block size of 128 KiB<ref name="micron-tn-29-07">{{Cite web |title=Small-Block vs. Large-Block NAND flash Devices |url=https://www.micron.com/support/~/media/74C3F8B1250D4935898DB7FE79EB56E7.ashx |url-status=live |archive-url=https://web.archive.org/web/20231029033047/http://www.micron.com/support/~/media/74C3F8B1250D4935898DB7FE79EB56E7.ashx |archive-date=29 October 2023 |type=PDF |id=TN-29-07 }}</ref> * 64 pages of 4,096+128 bytes each for a block size of 256 KiB<ref name="nxp-an10860">{{Cite web |date=11 August 2009 |title=LPC313x NAND flash data and bad block management |url=https://www.nxp.com/docs/en/application-note/AN10860.pdf |url-status=live |archive-url=https://web.archive.org/web/20231208071652/https://www.nxp.com/docs/en/application-note/AN10860.pdf |archive-date=8 December 2023 |publisher=[[NXP Semiconductors]] |id=AN10860 }}</ref> * 128 pages of 4,096+128 bytes each for a block size of 512 KiB. Modern NAND flash may have erase block size between 1 MiB to 128 MiB. While reading and programming is performed on a page basis, erasure can only be performed on a block basis.<ref name="L Smith">{{cite web |url=https://www.snia.org/sites/default/education/tutorials/2009/spring/solid/JonathanThatcher_NandFlash_SSS_PerformanceV10-nc.pdf |title=NAND Flash Solid State Storage Performance and Capability – an In-depth Look |last=Thatcher |first=Jonathan |date=18 August 2009 |publisher=SNIA |access-date=2012-08-28 |url-status=live |archive-url=https://web.archive.org/web/20120907062956/http://www.snia.org/sites/default/education/tutorials/2009/spring/solid/JonathanThatcher_NandFlash_SSS_PerformanceV10-nc.pdf |archive-date=7 September 2012}}</ref> Because change a cell from 0 to 1 needs to erase entire block, not just modify some pages, so modify the data of a block may need a read-erase-write process, and the new data is actually moved to another block. In addition, on a [[NVM Express]] Zoned Namespaces SSD, it usually uses flash block size as the zone size. NAND devices also require bad block management by the device driver software or by the [[flash memory controller]] chip. Some SD cards, for example, include controller circuitry to perform bad block management and [[wear leveling]]. When a logical block is accessed by high-level software, it is mapped to a physical block by the device driver or controller. A number of blocks on the flash chip may be set aside for storing mapping tables to deal with bad blocks, or the system may simply check each block at power-up to create a bad block map in RAM. The overall memory capacity gradually shrinks as more blocks are marked as bad. NAND relies on ECC to compensate for bits that may spontaneously fail during normal device operation. A typical ECC will correct a one-bit error in each 2048 bits (256 bytes) using 22 bits of ECC, or a one-bit error in each 4096 bits (512 bytes) using 24 bits of ECC.<ref name="samsung_ecc">{{cite web |url=http://www.elnec.com/sw/samsung_ecc_algorithm_for_256b.pdf |title=Samsung ECC algorithm |access-date=15 August 2008 |publisher=Samsung |date=June 2008 |url-status=live |archive-url=https://web.archive.org/web/20081012043739/http://www.elnec.com/sw/samsung_ecc_algorithm_for_256b.pdf |archive-date=12 October 2008}}</ref> If the ECC cannot correct the error during read, it may still detect the error. When doing erase or program operations, the device can detect blocks that fail to program or erase and mark them bad. The data is then written to a different, good block, and the bad block map is updated. [[Hamming code]]s are the most commonly used ECC for SLC NAND flash. [[Reed–Solomon error correction|Reed–Solomon codes]] and [[BCH codes]] (Bose–Chaudhuri–Hocquenghem codes) are commonly used ECC for MLC NAND flash. Some MLC NAND flash chips internally generate the appropriate BCH error correction codes.<ref name="types_of_ecc" /> Most NAND devices are shipped from the factory with some bad blocks. These are typically marked according to a specified bad block marking strategy. By allowing some bad blocks, manufacturers achieve far higher [[Semiconductor device fabrication#Device test|yields]] than would be possible if all blocks had to be verified to be good. This significantly reduces NAND flash costs and only slightly decreases the storage capacity of the parts. When executing software from NAND memories, [[virtual memory]] strategies are often used: memory contents must first be [[paging|paged]] or copied into memory-mapped RAM and executed there (leading to the common combination of NAND + RAM). A [[memory management unit]] (MMU) in the system is helpful, but this can also be accomplished with [[overlay (programming)|overlays]]. For this reason, some systems will use a combination of NOR and NAND memories, where a smaller NOR memory is used as software ROM and a larger NAND memory is partitioned with a file system for use as a non-volatile data storage area. NAND sacrifices the random-access and execute-in-place advantages of NOR. NAND is best suited to systems requiring high capacity data storage. It offers higher densities, larger capacities, and lower cost. It has faster erases, sequential writes, and sequential reads. {{Further|topic=the NAND flash memory or SSD operation|Copyback}}
Summary:
Please note that all contributions to Niidae Wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Encyclopedia:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Search
Search
Editing
Flash memory
(section)
Add topic