Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Flash memory
(section)
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!
==Low-level access== The low-level interface to flash memory chips differs from those of other memory types such as [[dynamic random-access memory|DRAM]], [[read-only memory|ROM]], and [[EEPROM]], which support bit-alterability (both zero to one and one to zero) and [[random access]] via externally accessible [[address bus]]es. NOR memory has an external address bus for reading and programming. For NOR memory, reading and programming are random-access, and unlocking and erasing are block-wise. For NAND memory, reading and programming are page-wise, and unlocking and erasing are block-wise. ===NOR memories=== [[File:IPhone 3G teardown - Intel 3050M0Y0CE -3303.jpg|thumb|NOR flash by Intel]] Reading from NOR flash is similar to reading from random-access memory, provided the address and data bus are mapped correctly. Because of this, most microprocessors can use NOR flash memory as [[execute in place]] (XIP) memory,<ref>{{cite book | url=https://books.google.com/books?id=vaq11vKwo_kC&dq=nand+flash+xip&pg=PA12 | title=Inside NAND Flash Memories | isbn=978-90-481-9431-5 | last1=Micheloni | first1=Rino | last2=Crippa | first2=Luca | last3=Marelli | first3=Alessia | date=27 July 2010 | publisher=Springer }}</ref> meaning that programs stored in NOR flash can be executed directly from the NOR flash without needing to be copied into RAM first. NOR flash may be programmed in a random-access manner similar to reading. Programming changes bits from a logical one to a zero. Bits that are already zero are left unchanged. Erasure must happen a block at a time, and resets all the bits in the erased block back to one. Typical block sizes are 64, 128, or 256 [[KiB]]. Bad block management is a relatively new feature in NOR chips. In older NOR devices not supporting bad block management, the software or [[device driver]] controlling the memory chip must correct for blocks that wear out, or the device will cease to work reliably. The specific commands used to lock, unlock, program, or erase NOR memories differ for each manufacturer. To avoid needing unique driver software for every device made, special [[Common Flash Memory Interface]] (CFI) commands allow the device to identify itself and its critical operating parameters. Besides its use as random-access ROM, NOR flash can also be used as a storage device, by taking advantage of random-access programming. Some devices offer read-while-write functionality so that code continues to execute even while a program or erase operation is occurring in the background. For sequential data writes, NOR flash chips typically have slow write speeds, compared with NAND flash. Typical NOR flash does not need an [[error correcting code]].<ref name="types_of_ecc"> Spansion. [http://www.spansion.com/Support/Application%20Notes/Types_of_ECC_Used_on_Flash_AN.pdf "What Types of ECC Should Be Used on Flash Memory?"] {{webarchive|url=https://web.archive.org/web/20160304044226/http://www.spansion.com/Support/Application%20Notes/Types_of_ECC_Used_on_Flash_AN.pdf |date=4 March 2016 }}. 2011. </ref> ===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}} ===Standardization=== A group called the [[Open NAND Flash Interface Working Group]] (ONFI) has developed a standardized low-level interface for NAND flash chips. This allows interoperability between conforming NAND devices from different vendors. The ONFI specification version 1.0<ref>{{cite web |url=http://onfi.org/wp-content/uploads/2009/02/onfi_1_0_gold.pdf |title=Open NAND Flash Interface Specification |publisher=Open NAND Flash Interface |date=28 December 2006 |access-date=31 July 2010 |url-status=dead |archive-url=https://web.archive.org/web/20110727145313/http://onfi.org/wp-content/uploads/2009/02/onfi_1_0_gold.pdf |archive-date=27 July 2011}}</ref> was released on 28 December 2006. It specifies: * A standard physical interface ([[pinout]]) for NAND flash in [[Thin small-outline package|TSOP]]-48, WSOP-48, [[Land grid array|LGA]]-52, and [[Ball grid array|BGA]]-63 [[IC package|packages]] * A standard command set for reading, writing, and erasing NAND flash chips * A mechanism for self-identification (comparable to the [[serial presence detect]]ion feature of SDRAM memory modules) The ONFI group is supported by major NAND flash manufacturers, including [[Hynix]], [[Intel]], [[Micron Technology]], and [[Numonyx]], as well as by major manufacturers of devices incorporating NAND flash chips.<ref>A list of ONFi members is available at {{cite web |url=http://onfi.org/membership/ |title=Membership - ONFi |access-date=2009-09-21 |url-status=live |archive-url=https://web.archive.org/web/20090829141114/http://onfi.org/membership/ |archive-date=29 August 2009}}</ref> Two major flash device manufacturers, [[Toshiba]] and [[Samsung]], have chosen to use an interface of their own design known as Toggle Mode (and now Toggle). This interface isn't [[Pin compatibility#Pin-to-pin compatibility|pin-to-pin compatible]] with the ONFI specification. The result is that a product designed for one vendor's devices may not be able to use another vendor's devices.<ref name="toshiba-20100811">{{Cite press release |date=11 August 2010 |title=Toshiba Introduces Double Data Rate Toggle Mode NAND in MLC And SLC Configurations |url=http://www.toshiba.com/taec/news/press_releases/2010/memy_10_599.jsp |url-status=dead |archive-url=https://web.archive.org/web/20151225111800/http://www.toshiba.com/taec/news/press_releases/2010/memy_10_599.jsp |archive-date=25 December 2015 |publisher=[[Toshiba]] |place=Irvine, Calif. }}</ref> A group of vendors, including [[Intel]], [[Dell]], and [[Microsoft]], formed a [[NVM Express|Non-Volatile Memory Host Controller Interface]] (NVMHCI) Working Group.<ref name="microsoft-20070530">{{Cite press release |date=30 May 2007 |title=Dell, Intel And Microsoft Join Forces To Increase Adoption of NAND-Based Flash Memory in PC Platforms |url=https://news.microsoft.com/2007/05/30/dell-intel-and-microsoft-join-forces-to-increase-adoption-of-nand-based-flash-memory-in-pc-platforms/ |url-status=live |archive-url=https://web.archive.org/web/20230603210924/https://news.microsoft.com/2007/05/30/dell-intel-and-microsoft-join-forces-to-increase-adoption-of-nand-based-flash-memory-in-pc-platforms/ |archive-date=3 June 2023 |access-date=12 August 2014 |publisher=[[Microsoft]] |location=Redmond, Wash }}</ref> The goal of the group is to provide standard software and hardware programming interfaces for nonvolatile memory subsystems, including the "flash cache" device connected to the [[PCI Express]] bus.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)