Managing flash memory with intelligence
As controllers and firmware enter the core of flash storage systems, features and performance are becoming vital factors in enabling competitive applications.
The whole idea of flash is to make memory easy for consumers to use and reliable for industrial applications, but that is easier said than done. Much of the responsibility for managing flash operation has shifted away from the flash memory devices themselves, creating a need for more sophisticated flash controllers that combine hardware and firmware. Axel explores the range of flash management functions and presents an example of a flash controller architecture that can perform those tasks.
Flash memory has almost completely replaced various historic storage media. For example, just a few years ago consumers used film in nondigital cameras, computers offered floppy disk drives, mobile CD players played favorite tunes, and mobile phones were incapable of taking pictures, browsing the Web, or synchronizing with a PC. In recent years, consumers have become accustomed to using various NAND flash memory devices for data storage applications. Users of mobile phones, digital cameras, and other gadgets are familiar with the terms SD card, USB stick, CF cards, and the like. These small and handy memory systems have become commodities among consumers.
Lately, flash-based Solid-State Disks (SSDs) are becoming more attractive as hard disk drive replacements. Flash-based systems offer many advantages, such as faster speed, greater power efficiency, increased ruggedness compared to rotating media, and easier integration with other chips in system design and production flows. Tremendous technology advances have decreased cost and reduced prices significantly.
Market requirements are changing
These advances, however, are demanding more intelligent control functions and thus creating a greater need for controller-based flash management systems. Requirements for highly reliable storage systems, especially nonremovable storage such as SSD, embedded flash, or embedded MultiMediaCard (eMMC) are more demanding than those for removable consumer-grade cards. Some of the requirements include:
- A decent mechanism to detect and correct errors inherent to flash memories
- Efficient algorithms to maximize lifetime
- Tools to predict lifetime or monitor system status
- The ability to implement customer-specific features
New process "shrinks," interfaces, and cell technologies will continue to improve flash performance and capacity as well as drive cost per MB down. Furthermore, new packaging and manufacturing processes will drive overall system cost down and capacity up. As a result, flash controllers and firmware features will become more important as an enabling and competitive factor for applications.
Ensuring highest performance, reliability, and capacity while guaranteeing data integrity and maximum lifetime are the most important features determined by controllers. The cost of these controllers together with their firmware usually represents only a small fraction of the overall system cost.
Flash memory organization
A look at how flash is organized reveals some of the challenges involved in managing flash memory (see Figure 1). The smallest logical/administrative unit is a sector. Each sector contains a storage area (512 or 2,048 bytes) plus a small overhead area (16 bytes). Sectors are grouped into pages, and blocks include multiple pages (32 pages of 512 bytes or, more recently, 64 pages of 2,048 bytes). Blocks contain a defined number of sectors, and there are typically 1,000 to 8,000 blocks per chip.
Writing or programming is performed at the page level and requires pages to be pre-erased. Once pre-erased, writing can be done an entire page at a time or by addressing a sector within a page that is "empty." Depending on flash memory type, pages can be accessed up to four times when writing a sector.
Erasing is completed at the block level, and blocks wear out over time as memory cells break down after a number of erase cycles. When defective, blocks are considered bad.
Flash memories from different manufacturers vary greatly with respect to bus width, number of blocks, block size, page size, die count, and programming capabilities, including caches. Table 1 shows an example memory organization for a 16 Gb flash device.
These characteristics pose some interesting challenges to the flash controller and its firmware as to how:
- Areas already containing data can be rewritten
- A product's lifetime can be maximized with only a limited amount of erase cycles available
- Data transfer integrity can be ensured
Enter the controller
The complex nature of flash cells and their organization requires reliable control functionality. Flash controllers of all kinds usually consist of an interface to the flash memory, processor, and host interface. Figure 2 shows a block diagram of an SSD memory system.
Hyperstone's flash controllers are based on a 32-bit RISC CPU with dedicated hardware blocks, including an Error Correction Code (ECC) unit, buffers, and flash and host interface control logic.
Controller firmware is specific to the task – the type of flash, application, and host interface implementation. All tasks related to flash, data management, and data transfers between flash and host are implemented in the controller, either in hardware or software.
These flash controllers boot up using firmware stored within the product's flash memory. Other systems might store firmware in the controller's ROM. Therefore, based on identical product hardware, manufacturers can provide different products or feature sets. A flash-based firmware implementation can be updated in the field or immediately before delivery using a preformatting process after the storage product has been assembled.
Flash memory management tasks
Several algorithms and concepts can be used to address the aforementioned challenges of rewriting areas, maximizing flash lifetime, and ensuring data transfer integrity.
Blocks and block mapping
Logical Block Addresses (LBAs) including the related static sector address or information are mapped corresponding to Physical Block Addresses (PBAs). A table maintained by the controller or firmware translates requests for a particular LBA to its corresponding PBA. Logical blocks are distributed across all available flash chips and good blocks. For instance, logical block 0 might correspond to a physical block at chip 1 block 2, and logical block 1 might correspond to a physical block on chip 3, block 3. Figure 3 illustrates logical to physical block addressing.
An anchor block is used to store vital boot information such as firmware location (boot sector), settings, configurations, and other static information that doesn't change. The commit block holds permanent data, tables, or references to tables and management blocks used for mapping, wear leveling, log book, and other management functions. A pool of pre-erased buffer blocks is maintained along with a table holding their status. User blocks are addressable blocks for user data. And finally, defect blocks are unusable or bad blocks; a pool of spare blocks is used to replace blocks that become bad during the card's lifetime.
Hyperstone's firmware provides patented algorithms that balance all blocks, guaranteeing maximum product lifetime. Wear leveling is triggered at buffer block erase time. All blocks are classified into wear level classes. Whenever a block is erased, a counter is increased. If the erase counter reaches a defined threshold, the blockís wear level class is increased. By comparing wear level classes of blocks to be used, the load is balanced throughout all blocks. Depending on the product's overall capacity and data amount per write cycle, the effect might be significant. Ensuring that as few blocks as possible reach their end of life before others and defining an adequate size for the spare block pool can maximize the product's life and guarantee data integrity.
A complementary available software tool, read wear level count, enables system developers to read block usage statistics, showing how many blocks have been erased a certain number of times. Listing the wear level classes and the related number of blocks for each class can support qualification and testing efforts for products based on flash controllers.
ECC is performed on a bit/byte level within sectors. Depending on cell structure and quality, this task is becoming more important in flash devices.
Several algorithms can be used, and the most common today is Reed-Solomon code. Most Reed-Solomon coding schemes use 10-bit symbols, performing parity and syndrome calculation in hardware and correction in software with hardware-assisted Galois field arithmetic where four symbols can be corrected.
Alternatively, a more flexible binary Bose, Ray-Chaudhuri, Hocquenghem code allows parity and syndrome calculation as well as correction to be accomplished in hardware. For this concept, 6 bits are correctable for a 16-byte overhead area per 512 data bytes or 14 bits correctable for a 32-byte (30-byte or larger) overhead area.
Because algorithms can be implemented in software or hardware, there is a trade-off between flexibility to support multiple flash memory cell architectures and ECC performance.
Power loss protection
Hyperstone has developed a patented concept to ensure data integrity when transferring or writing data. Using certain buffer blocks, information is written in a way that minimizes the delta between an old and new state. The data system is coherent at all times.
On power-down, the controller is reset and the flash immediately write-protected. A log of the most recent flash transactions is kept, with entries made just before any programming to the flash. If the last entry of the log becomes corrupted, the controller recovers the last valid entry. This minimizes data loss due to power failures, and data corruption at the physical layer is prevented completely. Data may get lost only if the power loss happens at the exact same time when data is written to the flash. However, in no case will the overall data system become corrupted.
Higher-level application possibilities
Several features tailored for applications can be realized in addition to standard features. Cards can be defined as read-only, content can be protected, and writing to a card can be limited or defined in number, such as write-once, twice, or more times. Event-triggered write protection is possible, as is making cards operate only in certain devices. Proprietary hardware formats can make use of standards such as SD/MMC, ATA, or IDE together with firmware comprising a disk-on-board. Requirements for qualification, tight quality control, or longer life cycles compared to consumer products might easily be addressed and result in specific products or in-sourcing.
Fully featured flash controller architecture
As an example of a more complex controller, the Hyperstone F3 (Figure 4) offers two channels of Enhanced Direct Flash Access, each with a 4-bit ECC unit capable of correcting 4 bytes in a 512-byte sector. Up to 16 flash memory chips (8 chip selects per channel) can be connected directly. The 32-bit RISC microprocessor can be scaled, running at clock frequencies from 10 MHz to 60 MHz using a trimmable internal oscillator.
This controller offers 16 KB internal boot ROM, 20 KB internal SRAM, four 512-byte sector buffers, and 256-byte PCMCIA attribute memory. Performance with single-level cell flash memories of 40 MBps reading and more than 30 MBps writing is achievable. An Icc of less than 200 microamperes can be achieved with automatic power-down mode during wait periods for host data or flash memory operation completion and automatic sleep mode during host inactivity periods.
Specifically designed for applications such as high-speed CompactFlash cards, Disk-on-Module, or SSDs, this controller supports automatic sensing of PCMCIA or True IDE host interface mode. Compliant to PCMCIA 2.1, PC Card ATA, and CF 3.0, it supports memory-mapped or I/O operations, fast ATA host-to-buffer transfer rates, PIO mode 6, MDMA mode 4, and UDMA mode 4 in True IDE mode. While offering Parallel ATA (PATA), Serial ATA (SATA) can also be realized using an additional PATA-to-SATA bridge chip.
Flash controllers enter the core
The cost of an overall flash-based storage system is mainly driven by the flash memory component. Flash devices' decreasing costs usually result in more complex tasks for the system flash controller. A finely tuned balance between hardware and software is necessary for these controllers to provide a robust and functional system.
As controllers and firmware enter the core of flash storage systems, features and performance are becoming vital factors in enabling competitive applications. Ensuring highest performance, reliability, and capacity while guaranteeing data integrity and maximum lifetime are some of the significant features determined by the controller.
Axel Mehnert is Director of Marketing and Customer Support for Hyperstone GmbH in Konstanz, Germany. With 12 years of experience in the electronics industry, he joined Hyperstone in 2002 after working for companies in the United States and Germany, including Texas Instruments and Siemens. Axel holds a BA in Economics from the University of Kiel, Germany, and an MBA from Oregon State University.Hyperstone GmbH
+49 7531 9803 0