Channels ▼

Embedded Systems

Simplify Your Flash-Memory Interface

Consumer-class, mobile product designers are constantly looking for high-capacity storage to enable their products to store more pictures, movies, MP3s, or simple data files. NAND flash memory meets these demands with single-level cell (SLC) and multi-level cell (MLC) technologies.

For designs using mid-range densities, SLC NAND flash is a good alternative. Current SLC NAND devices require only single-bit error correction code (ECC) per 512 bytes. As SLC NAND geometries shrink, it's anticipated that ECC requirements for these devices will only increase slightly. Next-generation wireless and embedded processors will include more sophisticated ECC capabilities, providing direct support for future SLC NAND flash memory.

Current MLC devices require 4 bits of ECC for each 512-byte sector. With future generations of MLC NAND flash, ECC requirements are expected to exceed 8-bit correction for each 512-byte sector. Such advanced ECC circuits are implemented in the NAND flash controller hardware within the processor, so care must be taken to ensure that the processor supports the ECC requirements of the NAND flash device.

Added to this consideration is the need for an efficient interface between the processor and the flash memory. Designers can smooth implementation by selecting an interface that's supported by many processors.

Rapidly changing requirements present obvious design challenges for embedded system designers and processor vendors. In addition to hardware ECC requirements, there are planned architectural changes to improve performance in MLC NAND—such as increasing the page size from 2 to 4 kbytes and options for dual-plane arrays—which will mandate other changes as well. To keep pace with NAND flash manufacturers, system designers and processor vendors will need to allocate additional resources for hardware and software development, which could be a significant challenge in itself.

ONFI standard
To minimize the impact of competing and sometimes incompatible NAND flash architectures, several NAND flash suppliers, controller makers, and designers have joined together to announce the Open NAND Flash Interface (ONFI) standard. The primary goal of this standard is to increase compatibility. That said, it doesn't diminish the importance of embedded processor vendors staying abreast of NAND developments.

Processors that provide direct NAND support will typically yield the lowest bill-of- materials (BOM). However, abstracting the complexities of NAND flash operations insulates designers from concerns relative to technology changes as high-density NAND flash evolves. Additional benefits include potentially shorter development cycles and reduced resource allocations.

In concept, the evolution of NAND flash is similar to the evolution of PC hard drives when they were introduced and the ATA specification was established. Providing a high-level, abstracted interface enables the processor and software to treat NAND flash like simple, block-oriented file systems. It also enables NAND flash management tasks, such as error correction, bad block management, and wear leveling, to be incorporated.

Traditional solutions
While several NAND suppliers have tried to solve various aspects of the embedded processor challenge, few have used an abstracted implementation with a standard interface. One configuration, with a processor that supports a direct NAND interface, provides a low-cost solution and relies exclusively on the processor for ECC support (see the figure). Block management and wear leveling are typically handled in software.

Three available NAND flash configurations are compared. The implementation on the left shows a processor that supports a direct NAND flash interface. The Samsung OneNAND approach is in the center. The right side shows Micron's Managed NAND.

SLC NAND flash requires at least 1-bit ECC. While these relatively simple ECC algorithms can be implemented in software, higher-performance applications will require hardware assistance. MLC NAND flash currently requires a minimum of 4-bit ECC. Future devices will require more complex ECC and block management and will continue to escalate the demands on processor-supporting hardware.

Samsung has taken an interesting approach with its OneNAND offering, targeting processors that include a NOR-like interface rather than a direct NAND interface. This approach is attractive for low-density designs, but becomes cost-prohibitive when die are stacked to achieve higher densities. Because each die has roughly 5% allocated for the interface, providing multiple die in one package comes with a significant premium. Samsung has also chosen to integrate 1-bit ECC hardware on the die. This addresses the ECC challenge, but leaves block management and driver software to the processor.

Using Micron's Managed NAND, a controller is packaged in a BGA with one or more NAND devices. With the flash managed by the controller, the necessary software support can be provided by a simple, low-level driver. Managing several flash devices with one controller is also a cost-effective approach for any density. The first product offered will be a 1-Gbyte part.

Abstracted solutions
Some NAND flash vendors already offer abstracted implementations. The iNAND from SanDisk includes a secure digital (SD) interface; Managed NAND from Micron uses a MultiMediaCard (MMC) interface. Most wireless processors include SD or MMC interfaces (see the table).

In addition to eliminating NAND dependencies, such as SLC/MLC or varying page sizes, these new technologies offload block-management and wear-leveling tasks from the operating system to the controller. Depending on the flash support provided by the software, this can potentially save valuable execution time and code-storage space.

With a standard, high-performance MMC interface, Managed NAND supports up to 52 Mbytes/s (peak) using an 8-bit data bus. In addition, the single-controller die can be packaged with various flash components. The common interface, BGA pinout, and package design provide a consistent implementation over a range of densities. A less obvious benefit is the ongoing support plan for various densities. Because the interface to the processor doesn't change, the underlying flash technology inside the BGA can change and evolve without impacting the application. This approach extends the longevity of higher-density solutions and makes it possible to support multiple densities with one pcb.

Managed NAND includes a standard block-level interface and an error-management and wear-leveling controller, freeing the processor from these tasks. This functionality alone could eliminate the need for a higher-performance processor or additional hardware/software design resources. The controller is optimized to take advantage of specific NAND performance features, including program and read caching. This can provide a performance improvement over other implementations. It's also possible to boot directly from Managed NAND (see technical note TN-29-18, "Booting from Embedded MMC").

For designs requiring low- or medium-density NAND flash, SLC memory will continue to be a good choice. For higher-densities, several processors already support the necessary ECC for today's MLC and future SLC devices. The challenge for next-generation embedded processor designs is to meet the increasing ECC support requirements of future MLC NAND devices.

The ONFI standard should help minimize the differences among NAND devices from different vendors. However, hardware development to support even these ONFI-compatible devices will still reside with processor makers. The software development required to support all direct-access NAND devices will keep third- party software vendors, developers, and system integrators busy.

Processor vendors that directly support NAND flash will typically provide the lowest overall pricing. For manufacturers that elect not to support future NAND requirements, or whose road maps don't align directly with those of NAND flash suppliers, Managed NAND offers a solution.

About the author
Jim Cooke is a NAND/MCP flash applications engineering manager at Micron Semiconductor Products Inc. He can be reached at

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.