5 Reasons for Ditching Managed NAND
Everyone knows that NAND has challenges: from factory bad blocks and spontaneous bit failures to endurance limits, etc. That’s why a few years ago managed NAND (NAND flash plus an integrated controller) seemed to be the answer, offering the density of raw NAND, while mitigating many of its inherent limitations. What many device manufacturers may not realize is that the management hardware comes with significant costs, both in terms of dollars per part as well as design limitations. In the world of tradeoffs in which every system designer lives, there are solid technical reasons to consider using raw NAND and leaving the management to software instead. While there are clear commercial advantages for Datalight (as a provider of vendor-neutral software-based flash management) to advocate this approach, we also believe that there are strong technical reasons that flash silicon vendors would do well to embed ECC capabilities into their NAND flash devices rather than relying on ‘total hardware’ solutions such as eMMC or other complex and costly controllers. Beyond the benefits outline below, this approach would allow the flash manufacturers the ability to continue to differentiate their products from others in the industry.

1.    Cost
The cost of managed NAND parts is coming down, but the stuff still sells at a premium over its raw NAND brethren. 

2.    Flash Optimization
There are many new features of NAND available to us today.  Performance features such as cached reads, multi-plane operations, concurrency, and others are becoming invaluable to keep performance at the ever-increasing demands of portable media. The Open NAND Flash Interface (ONFI) has defined a standard method to query the capabilities and characteristics of NAND flash which can be put to use by both software and hardware systems. A software media manager offers the flexibility to take advantage of the most current flash memory features and put them to use efficiently, or to avoid certain features that may be unproven or problematic. A software solution will allow a developer to take full advantage of the media’s characteristics and features unburdened by the indirection or inability for the hardware to expose them.

3.    Visibility/Flexibility
Software (in general) is easily inspected and validated. Features such as wear-leveling move data around the flash device to optimize its life expectancy. Without the ability to inspect source code, a managed NAND solution makes it difficult to validate wear-leveling operation and/or characterize its effect on performance and reliability.  Hardware implementations are often generalized to suit a majority of use cases, while a software solution is easily tailored to the specific use case during development.

4.    Performance
Speaking of use cases, there are many system features that are not available to hardware that may make a generalized hardware solution less advantageous to a specific use case.  For example, system idle time can be used to improve the media performance by scheduling background cache operations and compaction to occur then.  Coordination between the file system and flash media manager can further optimize operations by freeing space when it will no longer be needed and having the media manager code cache certain regions of the flash where meta data might be held. Migrating flash management features to hardware removes this ability to coordinate with other components of the software stack, such as file systems.

5.    Reliability
Lest you think we believe that everything is better left to software, consider error detection and correction (EDC). Error rates are increasing substantially as flash manufacturers push the limits of physics.  Errors can be introduced externally by heat or other radiation, during writes or reads of data, and even to data that was successfully written at a different time. Historically SLC NAND flash required only a single bit error detection and correction (a hamming code is usually sufficient), while MLC parts require minimally four bit EDC.  As the die sizes continue to shrink, error rates will continue to increase, even for SLC flash. 
Calculating the codes to detect and correct such errors is getting increasingly complex and solving such a solution in software for higher-bit EDCs (above 4-bit) is time consuming and often unacceptably slow.  Hardware ECC is a necessary requirement for systems with high EDC requirements and where performance is a concern.

Many of the processors on the market today are incorporating EDC in their NAND controllers. Choosing one of these processors (e.g. TI OMAP 35xx) in combination with raw NAND flash and software management can give you the high-performance EDC to handle next generation flash while maintaining the design flexibility that a software manager provides.

Flash manufacturers have much to gain by adding ECC code into their NAND flash parts.  They know better than anyone what kind of ECC is necessary for a specific part and by adding just that one piece of hardware to their offerings, rather than the jack of all trades, master of none approach of complete flash management, they will better serve the markets. 

In short, features should reside where they can be handled most efficiently; ECCs belong in hardware, other flash management functions belong in software.  While managed NAND certainly has its place and its appeal in the market, we believe the best combination of value, performance and flexibility lies in using a combination of raw NAND and hardware with built-in ECC capabilities.

The Challenge
Recently, LG Electronics, a well-known Korean-based manufacturer of consumer electronics, created a multimedia-enabled portable navigator for the North American market. The LN790 features a 4.3” LCD screen, Bluetooth hands-free functionality, and video-enabled playback. Ruggedness and fast access to data are important to consumers in this market, so the device was designed to boot directly from a NAND mass storage environment using Windows CE. Unfortunately, LG product engineers had a difficult time getting the device to boot fast enough using CE’s FAL/FMD flash drivers.  At just over two minutes, the startup time did not match LG’s reputation for high-performance consumer devices.

The Datalight Solution
As LG engineers went searching for solutions to the boot speed problem, they discovered that Datalight FlashFX® Pro uses a more efficient approach to managing bad blocks than CE’s standard FMD/FAL drivers, which can speed boot time significantly.  This difference is especially apparent when the device is using a large NAND disk, because boot time is somewhat proportional to the size of the flash.
Why is FlashFX Pro more efficient? Startup with FAL requires the driver to read more data as part of its mount sequence, a lengthy process particularly if the disk is large. In contrast, FlashFX Pro requires a much simpler check of the media to complete the initial mount.

The Customer Payoff
After implementation of FlashFX Pro, LG engineers were delighted to discover that the device’s boot time was cut by more than half. By using FlashFX Pro instead of the native Windows CE drivers, LG designers were able to achieve the performance their customers expect from a premium-quality personal navigator.  There was also an additional benefit they hadn’t counted on – FlashFX Pro support for over 200 flash parts means that the LN790 will be future-proof from flash parts going on allocation, unexpected price fluctuations, and end-of-life issues.

SanDisk recently announced that it is end-of-lifing several flash parts in the mDOC family and OEMs who were using these parts in their devices are now looking at viable alternatives.  In order to help these affected customers make informed decision, we have published a new whitepaper on options for migrating from Sandisk mDOC flash family.

The paper is available at http://www.datalight.com/mdocwhitepaper/

Just got the PR from SD Card Association (SDA) announcing availability of eSD - embedded flash technology standard (full release below). We applaud the development of standards that will make it easier for OEMs to meet the growing data storage demands in their devices. As a member of the SD Card Association, Datalight has long been a proponent of increasing the reliability of data storage. While the eSD standard will help with integration and hardware reliability challenges, it will also shift the spotlight to the shortcomings of traditional file systems. Building a fully robust and incorruptible product requires  reliability throughout the entire hardware platform and software stack.

Full Press release

SD CARD ASSOCIATION INTRODUCES EMBEDDED SD
FOR MOBILE PHONES, CONSUMER DEVICES

New Embedded SD standard offers field-proven SD functionality
and design ease to increase device storage options

SAN RAMON, Calif. – Sept. 11, 2008 – The SD Card Association (SDA) announced today it will enter the embedded storage market with the Embedded SD standard for storage devices in November. The Embedded SD specification extends the widely adopted, market-proven SD interface to embedded storage, doubling device storage potential and easing platform design in mobile handsets and consumer electronics devices.

As next-generation mobile handsets and CE devices demand high-capacity embedded storage and flash management solutions, Embedded SD simplifies system engineering by leveraging well-known SD standards. It allows all removable, embedded storage devices and input/output (I/O) peripherals to utilize the same common interface. Embedded SD separates flash management from the host and provides manufacturers and consumers with the flexibility of up to 32 GB scalable high-capacity on-board memory, plus 32 GB of removable memory with any SD High-Capacity memory card.

“The miniSD and microSD form factors are the leading interfaces for removable storage cards for mobile handsets, currently dominating the market, and are expected to constitute 90 percent of all card slots in mobile handsets in 2010, according to our analysis,” said Nam Hyung Kim, director and chief analyst for iSuppli Corp. “The new Embedded SD standard is built on that leading SD standard and takes aim at mobile handset storage needs like low power consumption, boot functionality, small form factor and integrated flash management.”

The Embedded SD standard regulates the specifications of SD interface-based embedded flash devices, easing the integration of storage devices and avoiding market fragmentation in the mobile and CE industries.

The Embedded SD specification defines the mechanical and electrical framework of the new embedded form factor and is also focused on enabling advanced functionality in embedded storage devices. Embedded SD devices offer a smart system solution with a smooth migration path from legacy designs, reduced design complexity and support for code, applications and user data storage.

“The SD Card Association plans to significantly reduce market fragmentation by delivering superior compatibility to the world of embedded storage, just as we have done in the storage card industry,” said James Taylor, president and chairman of the SD Card Association. “The association will continue to drive significant host market expansion while maintaining backwards compatibility with future interface development. The continuous collaboration and cooperation within the association’s ecosystem serves as a strong engine for innovation, consistency and growth.”

To speed adoption of Embedded SD, support of boot functionality requires only minor changes in the host ROM code of currently mass deployed baseband, application and multimedia processors with minimal additional changes to block device driver to support the additional functionality of embedded SD.

The Embedded SD Standard Defined:

•         Fully Compatible with SD standard – Embedded SD is fully compatible with the industry leading SDHC (SD 2.00) interface, ensuring a seamless migration from current SD to Embedded SD designs.
•         Both 3.3V and 1.8V Power Supplies – Supported for both flash and I/O power sources.
•         Boot from Embedded SD – Reliable and secure storage of boot code on an Embedded SD device reduces the number of memory components in a design, as well as the number of busses required, enabling more efficient designs.
•         Flexible Partition Mechanism – Allows multiple physical partitions accommodating varied data sources such as boot code, OS, applications and multimedia content with customizable levels of protection for each partition.  Original equipment manufacturers, mobile network operators and content providers gain optimal flexibility and control to configure the Embedded SD device for different usages and data types.
•         Protection Mechanism – Flexibility to separately configure each physical partition with different read and write/erase protection modes.
•         Data Robustness – Optional configuration of each physical partition of the Embedded SD device, including full immunity to power failure and protection of critical data (boot code, operator data, etc.).
•         Power-Saving Sleep Mode – Option to customize power needs and reduce power consumption and boost battery life.

SD Card Association
The SD Card Association is an open industry standards organization established in January 2000 by Matsushita Electric (Panasonic), SanDisk and Toshiba, and is supported by a consortium of more than 1,100 companies. The SDA’s mission is to set industry standards and promote SD product acceptance in a variety of applications. SD Memory Card standards are currently being built into a wide range of digital products such as cellular phones, audio players, automotive multimedia systems, handheld PCs and digital video and still cameras. For more information about SDA, please visit the association’s web site, www.sdcard.org. Parties interested in joining SDA are encouraged to visit the web site or contact helpdesk@sdcard.org.

There are two possible configurations in how boot code might be stored on a device

1. Boot code is stored in raw flash (no file system) and directly accessed from bootloader
2. Boot code is stored on a Reliance formatted flash volume

Option 1: Raw flash
If the boot image is being stored in RAW flash outside the file system, then the only way to be able to ensure that you got an update without damaging the original would be to reserve extra RAW space such that you could simultaneously have two boot images. The bootloader now needs to be able to switch between them and/or locate both of them The process of updating the boot image to a new location would include erasing the old image after updating the new, and having some sort of checksum to ensure the image was intact in case both were still there.

In this case, there would be no really good way to protect the update of the file to that exact same location without compromising the boot image itself. Many customers still use this way to store their boot images, but of course this means that they can’t take advantage of disabling transactions, atomically updating the boot image, and then doing a single transaction to commit all (or none) of the changes.

Option 2: Reliance
In this case, customer would not have a bootloader that checked a physical location for a boot image – they would have a bootloader that opened a file in the Reliance file system at boot time instead, if they were using a file system. Datalight Reliance comes with an utility called “Datalight Loader” which includes a lightweight Reliance reader. This utility integrates seamlessly in your bootloader code and allows the bootloader to mount and read Reliance partitions. Since the bootloader is capable of “reading” a Reliance disk, it doesn’t care where in the file system Reliance stores the file – it just opens the file, and loads it.

In this mode, while updating the boot image, the update utility disables all transactions and initiates the boot image update. Reliance never overwrites live data and hence this new boot code is written to a free-area of the flash. Once the entire boot image code is written, the bootloader calls for a manual transaction event, in which we update the metaroots to point to the new boot code area as the committed area. Old boot code area is now marked as free and can be used for future operations.

If power loss occurs during this replacement process, the device still boots back using the previous boot image, which was never modified

Continuing the conversation started in Flash File Systems and JFFS2 blog posts, this post talks about a YAFFS, another Linux flash file system alternative. YAFFS (Yet Another Flash File System) was designed to solve some of the performance issues suffered by JFFS2 on NAND flash. Later, YAFFS was upgraded (to YAFFS2) to work with modern, high-density NAND flash. Like JFFS2, YAFFS2 is a log-structured flash file system. YAFFS2 is licensed under the GPL for use with Linux; it also can be ported to and licensed for non-GPL environments, if needed

Interesting facts about YAFFS

1. Reliability against data corruption - As a log-structured file system, YAFFS2 is intended to be power-fail safe, though there have been reports of data corruption during the garbage collection process and cases where YAFFS2 has lost directories.

2. Wear Leveling - YAFFS2 only implements dynamic wear leveling. Wear leveling is not performed for static data. This may cause a higher number of blocks to be rendered useless at a faster rate than if both static and dynamic wear-leveling scheme were available. [For more information on static and dynamic wear-leveling, see our whitepaper on the topic at www.Datalight.com/whitepapers].

3. Performance: According to the YAFFS development team, YAFFS2 will perform best on disks that are greater than 64MB, while JFFS2 is still preferred for smaller disks.

For a detailed look at YAFFS, there is a great presentation on YAFFS by Wookey at Embedded Linux Conference 2007.