July 3, 1997

DATA STORAGE IN A FLASH

Flash vendors are overwhelming the market with incompatible products for data and file storage. Look beyond the data sheets and consider both current and future operating requirements.

BRIAN DIPERT, TECHNICAL EDITOR

FLASH MEMORY is an attractive alternative to magnetic media for data and file storage. It's more rugged and power-miserly. It boasts a smaller form factor at all but the highest densities. For fractions of a megabyte to a few megabytes, it can even be cheaper. In addition, flash offers much shorter read times and comparable write times. And it's now in demand for products that are "going digital" in a major way: still cameras and videocameras, answering ma-chines, and handheld voice recorders.

But which type of flash memory should you choose? Unlike code-targeted devices, in which, after years of product shipments, a few de facto standards in pinout, architecture, and command set have begun to emerge, you face a bewildering array of choices when evaluating data- and file-storage memories. Proper selection requires some critical analysis into which features your application requires, which are nice to have, and which are unnecessary. It also involves looking beyond your existing needs to those throughout your system's expected lifetime and whether the hardware and software are in place to satisfy your requirements. Over time, a few dominant data and file flash standards will probably emerge, just as they did for code, but that's not the case today.

When researching various flash memories for applicability to your design, the acronyms, the abundance of specifications, and the multitude of "best" approaches might initially overwhelm you. Your focus is and should be on the system and its needs, and the less you have to worry about the internal details of the flash memory, the better. Fortunately, flash technology all comes down to a few key concepts, which each vendor prioritizes in attempting to deliver the best product for its target customers.

Program/erase at the cell level

The two main techniques vendors use to alter the data stored in a flash-memory cell are channel-hot-electron (CHE) injection and Fowler-Nordheim (FN) tunneling (Figures 1a and b, respectively). In each case, an applied electrical field adds or removes electron charge from the transistor's floating gate, changing the threshold voltage. A subsequent read at a consistent reference voltage turns on some transistors, which may result in a one or zero at the memory output, and leaves off others. Both approaches use high voltages either from the outside world or from internal, on-chip charge pumps.

EPROMs have long used the CHE programming technique. Some CHE-based flash memories draw electrons from the source junction; others, from the drain. Well-understood and characterized, CHE places no significant stress on the oxide layer below the floating gate, ensuring high reliability through extended cycling. CHE shortcomings, though, include fundamentally low-efficiency programming, which high internal voltages and electric fields sometimes overcome, with subsequent high current draw. Whereas write performance is not a primary concern for infrequently updated code, it's often crucial for data- and file-storage applications.

All flash technologies use FN tunneling for erasing, and non-NOR technologies employ it for both programming and erasing. FN offers focused electron transfer; it directly adds or removes all charge to or from the floating gate. This characteristic manifests itself as low-current programming and erasing, which enables high-efficiency and low-power operation, shrinking on-chip voltage pump size. Some flash manufacturers further leverage FN's low current requirements in enabling simultaneous programming and erasing of multiple bytes and blocks. The selection of FN electron-flow direction for programming or erasing is relatively unimportant and defines only the subsequent data-sensing scheme. Depending on the technology, FN electron tunneling occurs between the floating gate on one side and the substrate, drain, source, or optional erase gate on the other.

Not all flash suppliers have migrated to an FN-only approach because most of today's flash-memory business is code storage, which requires a reliable medium. Therefore, the chosen technology must minimize stress to the thin oxide layer between the substrate and the floating gate. Also, voltages applied to the array's decoded rows and columns during programming or erasing cannot alter data in cells other than those intended. Code applications also typically do not require high write performance. NOR suppliers can leverage technology that has proven itself through many years of EPROM manufacturing. FN-only techniques, on the other hand, are most common today in EEPROMs, which often use a combination of redundancy and on-chip error detection and correction to improve reliability. EEPROMs often even remove electrons across an oxide gap to a separate erase gate (Figure 1b) from the one they use for adding electrons, again minimizing a given oxide area's stress through multiple program and erase cycles.

The situation is changing, however. After years of development and limited production, flash suppliers now understand their technology and how to optimize it for their reliability goals. Also, data and file applications are often more tolerant of occasional errors than are code-storage alternatives. For example, an uncompressed or even moderately compressed audio sample with a bad data byte might cause only a barely noticeable momentary change in volume or pitch (a popping sound). Also, many mass-storage applications can use system-level EDAC as they transfer data between flash and system main memory and can even map out bad bytes and blocks within the flash-memory array either during media initialization or subsequent normal system operation.

Defining read speed

NOR, DINOR, and some EEPROM flash architectures provide a parallel internal architecture (Figure 2a), which enables fast random access to any location within the array for reads. This approach has obvious benefits for applications that value direct code execution from the same flash memory and systems that need quick access to random pieces of data (see box, "EEPROM: another flash-memory target"). However, many data- and file-storage designs require no fast random access; their benchmark is the slow seek and rotation delays of a hard drive.

NAND, AND, and other EEPROM-based flash internal architectures comprise rows of transistors strung together serially (Figure 2b). The resultant random-access time is comparatively longer than that of parallel-architecture flash memory, because the memory must first sequentially sense and transfer data within each cell in the row to an on-chip buffer. However, subsequent access within the buffer is as fast as that of a parallel-architecture memory. Also, although the internal serial arrangement essentially limits these memories to data and file applications, manufacturers claim it also enables closer packing of array transistors and removal of unnecessary circuits, such as additional routing resources.

A parallel internal architecture can translate to both parallel and serial external interfaces, serving both code and data- and file-storage applications. A serial internal architecture can also provide both serial and parallel external interfaces, subject to the slow random-read characteristic. When sustained bandwidth between system and flash memory is the ultimate determinant of read and write performance, a wider interface is better. In other cases, the lower pin count and power consumption of a serial interface may be more attractive.

Many vendors, products

Flash architectures come in a variety of densities, operating voltages, packages, and temperature ranges (Table 1,pg 82). Most manufacturers have well-stocked Web sites, which you should refer to for the latest information and more in-depth comparisons. In focusing on data- and file-storage products, the table does not list every vendor's product or every vendor. Some companies focus exclusively on flash memories for code storage. Some manufacturers, such as LG Semicon, Matsushita, and Oki, are acting as subcontractors for other companies but may enter the market later. Others are evaluating or developing technologies and may also join the list in the future. Texas Instruments, for example, believes that the current single-bit NOR technology will not allow them to hit most cost points for high-density data-storage applications and is actively investigating other approaches. NEC is codeveloping a next-generation process with SanDisk. Fujitsu, currently shipping NOR flash memories for code designs, is also developing a NAND process. Hyundai, Micron, and Siemens are also developing their own data-focused technologies with an eye toward production within the next several years.

Although flash memories from partner companies may have identical architectures, command sets, pinouts, and read specifications, secondary characteristics, such as programming and erasing time and power consumption, may significantly differ. This divergence can reflect different silicon designs, fabrication characteristics, or testing methods. For example, several companies that use NAND flash memories report performance differences between Samsung and Toshiba devices.

Read/write/erase performance

Table 1 reflects device capability at the most favorable combination of operating, program, and erase voltages and temperatures. The table shows a mix of minimum, typical, and maximum specifications, reflecting what the vendors' documentation does--and does not--provide. Typical specifications are useful for predicting your system's nominal operating characteristics, but flash-memory performance may significantly differ at voltage and temperature extremes and at extended cycle counts.

The amount of address and command overhead required to initiate an internal program or erase operation can be significant, especially for serial interface memories. Manufacturers sometimes use long command se-quences as a write-protection mechanism. If you're not careful, though, these sequences can take significantly more time than the internal program or erase cycle itself. Slow serial-peripheral-interface clocks, unnecessary wait states, and other system-software overhead and hardware-bus cycles can take longer than flash memory requires. These delays can also make technological differences irrelevant (see box, "The great flash-memory shoot-out'').

In an attempt to reduce system overhead, some manufacturers integrate one or several RAM buffers on the flash die. Table 1 reflects this capability, often identified by a difference between burst- and sustained-write bandwidths, as well as the ability to execute multiple operations in parallel, such as simultaneous multibyte programming or block erasing. Fractions or multiples of 512 bytes plus additional bytes for system-level EDAC are common page-buffer sizes, derived from the 512-byte DOS sector. Your decision on whether to use flash memories with page buffers often hinges on how big an array of chips you need. If you need large numbers of chips, you might find it more cost-effective to implement a portion of discrete RAM or buffers in the system ASIC vs paying for RAM on each flash memory. You can more cost-effectively implement large SRAM densities on metal-line-rich logic processes than you can on flash memory, which typically uses multiple polysilicon layers.

Write and erase performance presents an interesting system-level trade-off. You can often reduce flash-media density, cost, and sustained write-performance requirements by preprocessing and compressing the incoming data stream. However, the higher horsepower DSP and larger, faster scratchpad RAM that this technique requires may still cause you to overshoot your system-cost and power-consumption targets. The decision about whether to use slower and cheaper or faster and more expensive flash memory often hinges on the relative percentage of system cost that the memory represents, as well as how stringent power-consumption, board-space, and other considerations are.

Speaking of power, Table 1 omits these specs because they vary, depending on operating mode, voltage, temperature, clock frequency, and other factors. When evaluating flash memories, keep in mind that both current draw and amount of time in various operating modes are important in determining system battery life. For example, even if one flash memory draws half the current of another when programming, this fact may not matter if programming takes four times as long. Also, use realistic assumptions for the percentage of time the flash memory is in each operating mode. How often does your system access the flash memory, and what percentage of those accesses are reads, programs, and erases? Some flash memories offer hardware- or soft-
ware-initiated power-down modes that lower current draw to negligible levels.

Defining blocking

Flash is available in a variety of block sizes. The importance of this feature relates directly to the average size of each data sample or file your design stores in flash memory. For example, heavily compressed, black-and-white digital images take tens of kilobytes, whereas an uncompressed, high-resolution, 24-bit, color bit-map file may take tens of mega-bytes. Today's state-of-the-art audio-compression technologies typically achieve 20-to-1 compression ratios. A system capturing one-channel, 8-bit voice and sampling at an 8-kHz Ny-quist frequency can store a 30-sec compressed sample in a 12-kbyte file. On the other hand, a system capturing two-channel, 16-bit, high-fidelity sound at a 44-kHz sampling rate requires 264 kbytes to store the same 30-sec sample and 5.28 Mbytes to store it uncompressed.

The larger the block relative to the average sample size, the less efficiently you are able to use the media. This situation doesn't matter--up to a point--thanks to some clever engineering (Figure 3). As you selectively delete files, the flash-file system marks them invalid--not erasing them from the media--by programming file-header bits and using additional available space within the flash array to store replacement or additional samples. However, the array eventually becomes almost full of a combination of valid and "deleted" files. The file system then must initialize a cleanup management function. The smaller the average file relative to block size, the more likely that a mix of valid and "deleted" files resides in any block and the more media management the file system must do to create block-sized free space. Even if the file system performs this cleanup during periods when the system isn't accessing the flash (acting as a background task and minimizing performance impacts), the additional program and erase requirements impact power consumption.

Large-block-memory advocates point out that smaller blocks require more on-chip periphery circuits to decode and effectively isolate one block from all others, impacting die size and cost. However, this characteristic is technology-dependent as well; some approaches naturally lend themselves to smaller blocks. Cost is often the most important criterion for any memory, but a combination of secondary benefits may sometimes sway your decision to an alternative approach. A block that is significantly smaller than the average data sample or file may also complicate the design, burdening the flash-file system with multiple block erases per file operation and increasing power consumption.

Whenever you erase a block, you cycle it. When you write additional data to a partially programmed block but don't erase it, you don't cycle it. (Many flash-file systems exploit this important characteristic.) With increasing usage and subsequently higher cycle counts, a block's program and erase performance degrades because of the trapped charge in transistor oxides and other stress phenomena. Eventually, you will be unable to program or erase and thus will have to retire locations within the block--or even the entire block.

All flash memories for data- and file-storage applications specify at least a minimum of 10,000 cycles. In most cases, this count exceeds your system's needs during its operating lifetime. Intel provides a utility on its Web site at developer.intel.com/design/flcomp/toolbrfs/cycling.htm, which approximates your cycling requirements for frequently updated data or files. To do so, the utility asks you for the following:

1. The amount of flash-memory space that regularly cycles or the number of blocks multiplied by the size of each block,

2. The average data sample or file size written,

3. How often the data sample or file is written, and

4. The target system's operating lifetime.

The utility then calculates the estimated cycling requirements using the following equation:

Cycling=(file size/total flash memory)·(update frequency)·(system lifetime).

For example, plug in the following values for steps 1 through 4, respectively:

1. A 2-Mbyte flash-memory space, half of which cycles regularly (1 Mbyte=1,048,576 bytes);

2. Average file size=16,384 bytes;

3. A file that is written once every 15 minutes, or 96 times a day; and

4. A system lifetime of 10 years, or 3650 days (leap years excluded).

The utility then calculates the cycling requirement as:

(16,384/1,048,576)·(96)·(3650), or 7008 cycles/block.

This approximation can be used with many flash technologies and works best when files write sequentially and update or delete in a FIFO fashion (Figure 3). When this situation is not the case, a large ratio of average-file-to-block size can result in more per-block cycling because of background file management and wear leveling.

Although every vendor supplies cycling specifications, few provide corresponding byte-, block-, or device-level failure-rate data. Vendors also provide no consistent data on whether cycling specifications are minimum, typical, or maximum. SanDisk, one of the most straightforward vendors in this respect, states that, at 300,000 cycles, its controller chip automatically replaces a block with a spare even if the block is still operating properly. Ask flash-memory vendors if all blocks within the device, most blocks, or at least one block will still function at the stated cycle count and what component sample size the vendor used in the reliability testing that resulted in these predictions. Additional useful information includes determining how the failure rate and programming and erasing time change with increasing block- cycling count. This data helps you predict your system's performance and determine how robust your flash-file system should be.

File systems complete the puzzle

Flash-file software is the glue that connects your flash-memory component, array, or module to the rest of the system. Even if the flash memory provides hard-disk-drive-like 512-byte blocks, it still needs software to translate disk commands to flash operations and to retire bad blocks. Flash-file-system software also minimizes cycling "hot spots," such as those that a hard-disk drive's frequently updated file-allocation table causes, through wear leveling or spreading writes and erases across the available flash-disk memory map.

SanDisk's software strategy for many years has been to encourage standardization around the disk-drive IDE/ATA command set, relying on a dedicated interface controller to manage the flash media. SanDisk sells only chip sets and cards containing both flash memory and a controller ASIC--not stand-alone flash memory. This approach has some compelling selling points: one software standard for a variety of flash-memory chips and systems, both now and later, and the potential for higher system performance by offloading CPU file-management functions to a separate slave controller. According to SanDisk, an ATA driver is also small: For example, an x86 DOS implementation takes approximately 5 kbytes.

Many companies besides SanDisk now also provide ATA-based flash-memory adapters and cards using other flash technologies. These companies include Hitachi (AND), Mitsubishi (DINOR), Nexcom (EEPROM), and Smart Modular Technologies (NAND). Samsung and Toshiba also advocate host-based and PCMCIA adapter-based ATA controllers for their solid-state floppy-disk (SSFDC) modules. ATA controllers come from companies such as Cirrus Logic, Macronix, Oki, and Silicon Systems. An ATA approach is also attractive to flash-memory manufacturers because the controller can handle chips with some nonfunctional blocks. This capability enables companies to boost yields, especially in initial product manufacturing, and lower costs. Hitachi and Mitsubishi (AND); Integrated Silicon Devices (ISD); Nexcom; and Samsung and Toshiba (NAND) all provide optional flash memories with some bad bytes or blocks. The manufacturers tell you which blocks are unusable by programming them with a data pattern before shipping them or via a data structure written to a guaranteed good block during device testing.

The ATA controller can, however, add power consumption, board space, and cost beyond flash memory and software alone, and for these reasons, other manufacturers are advocating software-only alternatives. The original flash-file system for linear, fast-random-access flash memory, Microsoft's Flash File System (FFS), has fallen out of favor because of its more-than-60-kbyte driver and the need for additional Card and Socket Services and flash drivers. FFS also delivered slow perform-ance, especially during file deleting and rewriting during normal system operation, and was incompatible with some DOS and Windows programs. (It used DOS' file-based INT 21H instead of the lower level, sector-based BIOS INT 13H.

The Flash Translation Layer (FTL), the successor to FFS, is today a PCMCIA-approved flash-media standard, along with ATA. M-Systems with its TrueFFS is the primary vendor in the FTL sector. The company also licenses the technology to PCMCIA-software providers Phoenix Technologies and Systemsoft. Instead of replacing a system's file system, TrueFFS works alongside it, translating sector-based operations (INT 13H in DOS) to flash-compatible alternatives and managing background cleanup, wear leveling, and EDAC. The approximately 20-kbyte TrueFFS driver includes optional PCMCIA Card Services functions and currently supports AMD, Fujitsu, Intel, and Sharp NOR flash memory. It also works with Hitachi and Mitsubishi's AND technology and Samsung and Toshiba's NAND flash, providing an alternative to hardware ATA controllers. TrueFFS functions under multiple DOS and Windows variants, as well as the embedded VxWorks, QNX, and PSOS+ operating systems. Microsoft supports TrueFFS in the new OSR.2 release of Windows 95, and you can also get the Windows 95 TrueFFS virtual-device driver from M-Systems' Web site.

What if your embedded design doesn't need full file-system functions, such as subdirectory support or background cleanup? In these cases, your list of software-only options expands even further. M-Systems also supplies FLite, a modular version of TrueFFS that includes an optional DOS-compatible file system and nears ATA-driver sizes in minimal-function configurations. Intel supplies two free file-system utilities, Linear File Manager (LFM) and Virtual Small Block File Manager (VFM). LFM, like Microsoft's FFS, enables you to optionally execute code directly from the flash media instead of copying files to RAM, whereas VFM is closer to True-FFS in concept and performance. Meanwhile, Datalight offers CardTrick, which, although not FTL-format-compliant, stores files in variable-sized blocks for efficient use of available flash-memory space and also operates under DOS INT 13H.

Even though software-only ap-proaches negate the need for a hardware flash controller, their perform-ance depends heavily on that of the host µC or µP. If you need a faster, more expensive CPU than you originally planned, the result could impact both your cost and power budget. Your decision also hinges on whether your design includes removable flash media and requires data interchange among otherwise-incompatible systems now and later (for example, among a variety of digital cameras, PCs, and flash cards using multiple manufacturers' silicon). If your design has these requirements, ATA is conceptually the better choice, although incompatibilities still sometimes crop up, as they did to early Kodak digital cameras and some HP palmtops.

FTL supporters have made some progress in interoperability, however, as the recently announced Common Flash Interface (CFI) specification shows. The developers of CFI originally intended it as a "one-algorithm-fits-all" approach. However, CFI is now a set of six algorithms, supporting AMD, Fujitsu, Intel, Mitsubishi, and Sharp. When vendors begin to ship CFI-compliant flash memories, the memories will communicate to the file system via an extension of the device ID, which algorithm and what percentage of it they support, as well as component density, block size, and other relevant details. The issue of forward and backward compatibility between system and flash media is still not completely resolved, however. What if a NAND supplier wants to add its algorithms to the CFI suite in the future, or what if a CFI member discovers that existing algorithms cannot support memory features? Unlike the PC's embedded software, most consumer-targeted embedded software resides in ROM that you cannot update, creating the potential for future incompatibility between the system and flash media.

Many flash-memory data and file applications are high-volume consumer products in which low-cost media are critical. The memory that can deliver the most density at a given price stands a good chance of winning. Therefore, multilevel cell (MLC), with its ability to increase the amount of information stored in a given number of flash-memory cells, sounds like a winner. But, so far, only two companies, ISD and, more recently, SanDisk, have commercialized such technology (see box, "Would you believe...256 bits per cell?"). What's causing the delay?

The threshold voltages of a programmed and erased NAND transistor using traditional binary storage reflects the amount of electron charge on the floating gate (Figure 4a). Other flash-memory technologies vary the threshold voltages. However, the basic principle is the same. In multilevel NAND, different amounts of electron charge on the floating gate represent one of four possible combinations of 2 bits (Figure 4b). A conceptual analogy (though not a completely accurate one) is a 2-bit ADC.

One trade-off vendors might have to make to use MLC technology is the potential added cost of increased peripheral circuitry, additional voltage pumps, more complex state machines, and multiple sense amps. Additional silicon-circuit overhead makes MLC most attractive at high densities, where the already-large array of cells can amortize the added cost. MLC also requires more accurate algorithms to place only enough charge on the floating gate to represent the desired bit combination. The resultant potential for slower, more power-hungry programming is a concern for very write-intensive data and file applications. On-chip page buffers and multibyte parallel programming, as offered by ISD, can reduce this additional overhead.

By doubling or quadrupling the amount of information in each cell, MLC also increases effective erase-block sizes, putting a burden on the flash-file-system software for small data samples or files. Also, less margin between valid voltage levels means less immunity to system noise, temperature effects, and charge degradation resulting from oxide defects, which might impact data reliability.

NOR-flash-memory advocates be-lieve that CHE programming's relatively small current flow allows it to more accurately control the number of electrons you can add to the transistor floating gate. Also, NOR supporters feel that the parallel internal-NOR architecture, by allowing fine-grained direct access to each array cell, enables precise placing and sensing of the multiple threshold levels. Predictably, other flash-memory suppliers dispute these claims. Both ISD and SanDisk use FN programming, and SanDisk also employs a serial internal architecture.

SanDisk is sampling a line of PCMCIA and CompactFlash cards based on its DoubleFlash technology and slates production for this year. Intel went public with its MLC technology development program at the February 1995 IEEE International Solid State Circuits Conference (ISSCC). The company also demonstrated a flash-memory card based on MLC flash memories at the 1996 ISSCC. NEC and Samsung have also presented MLC flash papers at ISSCC, and NEC also discussed an MLC DRAM at this year's show.

References

1. Dipert, Brian, and Markus Levy, Designing with Flash Memory, (ISBN: 0-929392-17-5), Annabooks, San Diego, CA, 1993. To order, call 1-800-462-1042.

2. Levy, Markus, "Designing with flash memory: a tool exhibition," EDN, July 4, 1996, pg 81.

3. Levy, Markus, "High-density flash memory now a practical option for system design," EDN, Feb 16, 1995, pg 53.

Acknowledgments

I'd like to thank Loren Shalinsky from AMD and Kirk "I'm FlashMan" Blum from Intel for helping me debug various PCMCIA- and TrueFFS-compatibility issues and Patrick Henry from Hyundai for sharing his insights on data and file flash-memory-market needs.

| EDN Access | Feedback | Table of Contents |