This article entitled Advances in Nonvolatile Memory Interfaces Keep Pace with the Data Volume, recently published in RTC Magazine, gives a nice overview of maintaining performance on newer technologies.

Learn more about Datalight and ClearNAND

A recent article by Doug Wong compared performance characteristics of eMMC and ONFI specification EZ-NAND, specifically Toshiba’s SmartNAND here: http://www.eetimes.com/design/memory-design/4218886

One consideration I would add to this quite excellent summary is about the availability of drivers. Raw NAND has been around for quite a while and the market supplies a large range of drivers. Many of these will utilize the basic functionality of SmartNAND and other EZ NAND chips with only small modifications. Drivers for eMMC, on the other hand, are much harder to find. Only Linux has a freely available driver, which Google’s Android has taken advantage of in recent releases.

At Datalight, we continue to be excited by both of these new technologies. From the JEDEC eMMC parts, the cool features such as Secure Delete and Replay Protected Memory Block are very exciting. On the other hand, the sheer performance of Toshiba’s SmartNAND and other EZ NAND solutions is very much in demand.

InHand’s development platforms are known in the embedded industry for their generous list of features, fast time-to-market, and solid performance. Recently, when a customer’s unusual flash configuration began causing corruption issues related to the default flash driver on Windows CE, InHand turned to Datalight FlashFX Pro, with immediate results. The InHand team was so impressed with the ease of implementation and improved flexibility of FlashFX Pro, that they decided to include it with every Fingertip4 and Fingertip5 module they sell. Continue reading for more about InHand’sDatalight FlashFX Pro experience with .

It’s been over 20 years since NAND flash was supposed to take over the world, so why is the ‘ultra-portable’ laptop I’m writing this on still using HDD? And why, nearly 30 years after the invention of flash, are we still debating its applications vs. the rotating platter? Given the performance advantages of flash and the mechanical shortcomings of HDD – things like wear and susceptibility to shock and vibration, not to mention the latency associated with spinning up for reads – it’s no wonder that flash has long been the darling of memory technology futurists. So why after all this time has flash not replaced older technologies? I’ll give you a hint: It’s all about the money. But it’s not only about the money – check out our list of five top barriers to flash adoption:

1. Cost – Despite years of oversupply in the flash market, and the corresponding reductions in price, flash is still relatively expensive when compared to HDD, especially on a $/bit basis. To make matters worse, the current economic climate has taken its toll on the flash industry, spurring several rounds of consolidation and requiring flash vendors to curb manufacturing costs by shrinking portfolios and closing fabs. Predictably, these changes in the supply landscape are causing prices rise in many cases, making the cost factor an even bigger problem for flash.

2. Shrinking lithography = lower endurance – One way for flash manufacturers to remain competitive is to use smaller die size to reduce raw material costs. Just a couple years ago, the vast majority of NAND flash was manufactured with 90nm lithography. Most vendors are now planning to move to 30nm technology either this year or next. An unfortunate side-effect of smaller lithography is significantly decreased endurance. SLC NAND, which had 100K + erase cycles, is now predicted to be in the 50-70k range. The biggest impact is on MLC NAND where the endurance has gone from 10k erase cycles to around 3k (a 70% reduction!).

3. Increasing ECC – Another side-effect of shrinking lithography is an increase in error rates for flash, requiring stronger correction codes. Most SLC NAND flash today requires 1-bit correction. That number is predicted to increase to 4-bit on 30nm NOR parts. And the ECC outlook for MLC NAND is even worse, requiring ECCs greater than 12-bit (compared to 4-bit or 8-bit today). These increased ECC requirements mean the controller design for managing flash will become more complicated, and more difficult for OEMs to implement. Performance will also be impacted, especially if the ECC is done in software running on the host processor.

4. Vendor volatility – Churn or volatility in the flash market, the products of a difficult economic climate, are making it difficult for OEMs to find a reliable source of flash parts. Examples are everywhere; A major flash supplier is currently under Chapter 11. There are merger talks happening between SanDisk and Samsung. Asian vendors have been hit especially hard, particularly those also in the DRAM business. OEMs are rightfully concerned about interruptions to their production cycles in the midst of all this turmoil.

5. Lack of killer application – While NAND flash densities have continued to increase, the industry is still waiting for the killer application to gobble up these immense quantities of flash. For long SSDs have been viewed as that application but they have not taken off as fast as the flash industry would have liked.

In spite of the obstacles faced by the industry, flash remains a strong and growing choice for data storage and has put breakthrough devices like MP3 players and smart phones (iPhone!) into the hands of millions of consumers. Early adopters of SSD technology in laptop computers, netbooks and enterprise applications are making a solid case for mass market potential there, which should significantly drive flash adoption in the next few years. Visit the FlashFX Tera page to learn how Datalight is making flash easier and more competitive.

Our R&D folks couldn’t wait to get their hands on the new test board from Digi which arrived a couple weeks ago. The board comes with multiple testing interfaces, making it easy to switch between a number of different flash parts for back-to-back comparisons. They have been practically wearing the thing out, testing the performance of a number of different managed and raw NAND parts to get a better idea of the differences our customers see when doing benchmarks. Check out a few pictures of the setup currently in Glenn’s office, and contact us for more information on this project.

Ever since we announced our high performance file system Reliance Nitro, we have been getting questions on how it compares to the original Reliance file system. Below is a quick-reference table noting some of the differences between the two. For a more detailed comparison (including performance benchmarks), please contact us.

We have talked about managed NAND in a few blog posts before. Usually a combination of raw NAND flash (SLC or MLC) combined with a hardware controller that performs flash management features like bad block management, ECC and wear leveling is referred to as managed NAND. The term covers a huge spectrum of flash-based storage devices so in this post we will try and highlight some of the more prevalent types of managed NAND

The following is an enumeration of some of the popular managed NAND form factors. Please note that the list covers flash technologies used for resident storage and does not cover removable storage like USB flash, SD, etc.

•    eMMC
•    eSD
•    CompactFlash
•    Solid State Drives
•    BA NAND
•    Adaptable NAND
•    Specialized
–    Specially designed controller + raw flash

CompactFlash is included here because it is used both as resident and removable storage. CF comes with a Fixed-drive option which allows it to be used a resident managed NAND.

The above technologies differ from each other on several attributes

•    Form factor – managed NAND can come is several form factors. An SSD may sport a standard 2.5” drive enclosure whereas a CF card will take a 1.0” card form factor.
•    Plug-in interface: What interface does the managed NAND use to connect to the device platform
–    MMC
–    SD
–    ATA
–    Custom
•    Cost: Cost depends on several elements
–    Type of flash used: SLC is much more expensive than MLC
–    Type of controller used: consumer grade controllers (used for consumer grade CF for example) are much cheaper than specialized industrial grade controllers
•    Performance
–    Performance varies depending on the flash type, the controller attributes and the interface.

Some of the big players in the managed NAND business are

•    eMMC
–    Micron, Numonyx
•    eSD
–    SanDisk, Toshiba
•    BA NAND
–    Toshiba
•    Solid State Drives, CompactFlash
–    Too many players in these markets

This was a brief view of the managed NAND landscape. If there is interest, we will do a follow up going in details about the specific categories and interfaces

We’re totally psyched about Reliance Nitro, our newest file system (yes, we’re file geeks), and we’re always on the lookout for opportunities to show off the performance and reliability attributes it adds to Windows Mobile and Windows CE. When we discovered the relatively-new Beagle Board, it occurred to us that a small, low-cost platform might be just the thing to demonstrate Nitro’s amazing benefits. As you’ve probably heard, the Beagle is making waves with its low cost (around $150) and diminutive size. It uses an OMAP 3530 processor and 256MB of NAND. Though they are most commonly used with Linux, we lucked out in having a partner (MPC Data) who has already developed a Windows CE BSP for it. After a few phone calls, the wizards at MPC Data were able to develop a slick video playback demo app, and presto, the Reliance Nitro Beagle Demo was born! Amateur videographers that we are (ok, REALLY amateur), we recently videotaped John Burnham, who has been working on this project on the Datalight side (and who is a really good sport, btw) showing what happens when power is interrupted during a file write and the extra reliability factor of Reliance Nitro on Windows CE. Be sure to check it out here.

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