If you’ve been following this blog, you’ve probably noticed a lot of discussion and analysis around eMMC. We’ve written about the reasons we are so excited about eMMC, but also why the Write Amplification issues caused by eMMC parts are a problem that needs more attention by the industry.

As more and more device manufacturers use eMMC in their devices, product reviews are beginning to highlight some of the limitations of eMMC that we have been discussing. A case in point is this recent review of Google Nexus 7 by Anand Lal Shimpi and Brian Klurg.

As the review points out, the performance downside of using eMMC parts is that they are “optimized for reading and writing large images as if they were used in a camera.” Also, eMMC was never designed to be used by a “full blown multitasking OS,” and therefore can cause major problems with device responsiveness. This is mainly because multi-tasking (i.e. any other action performed while download is in progress) effectively “turns the IO stream from purely sequential to pseudo-random.” This corroborates with our view that many eMMC parts are not equipped for optimal performance for random reads and writes. The authors’ benchmark results (below) underscore the severity of the problem:

So, how can device manufacturers get better performance from their eMMC parts, and continue to leverage the simplicity of programming and consistency of design parameters that eMMC offers?

Simplistically put, the eMMC driver is responsible for flash-aware allocation of data to flash memory. The combined layers of the driver and the file system, sometimes known as the flash file system, is the level at which hardware behavior can be translated to software behavior in a way that enhances performance without compromising the endurance and data integrity.  Also, the complementary interaction between the driver and the file system layer can bring further benefits to the device performance, endurance and reliability. Getting this part of the system right goes a long way to solving eMMC’s write amplification problem.

Here at Datalight, we have been researching the most efficient way of doing this, drawing on our decades of experience of developing driver and file system software for a wide array of flash parts. Stay tuned for more in-depth explanations on how we’re doing it, but for now we are very excited about the early test results we’re seeing in our lab, especially enhancements combining an optimized file system with our new eMMC driver.

We’re constantly on the lookout for ways to help our customers boost performance and improve power efficiency, and often our inspiration comes by way of the conversations we have with them. Recently, several of these discussions highlighted user scenarios where the complexity of the application would benefit from an enhancement to the classic Dynamic Transaction Point™ technology found in our Reliance Nitro file system. Here are a couple examples of the user scenarios I’m talking about, specifically for multi-threaded environments:

In a multi-threaded system, the activity among threads can be unpredictable, sometimes requiring multiple writes by the file system to the media within milliseconds. Each write requiring its own transaction commit or flush by the file system takes a toll on performance with no real reliability benefit.

Another challenge in a multi-threaded system is power efficient utilization of the processor when the file system is configured to commit data after specific time intervals. These transactions “wake up” the processor just to generate a request, even though no actual commits or flushes occur if there was no disk activity since the last transaction point. This unnecessary activation of an inactive processor is a waste of valuable power. By suspending thread activity until new disk activity occurs, battery life could be extended significantly.

Understanding how customers use the configurable transaction points of our Reliance Nitro file system was instrumental in improving Reliance Nitro. Below is a little background on Reliance Nitro and Dynamic Transaction Point technology:

The Reliance Nitro file system is a highly reliable, power interrupt-safe transactional file system. Keeping the reliability intact without risking loss or corruption of data means that customers have the flexibility to configure when a “transaction” (i.e. a set of operations that constitute a change as a whole), is to be written to the storage media from cache. This can even be done during operation of the device (run time), and includes the following options:

(a) Timed: Transacts or commits to storage media after a specified time interval (e.g., commit data to storage media every 10 milliseconds).

 (b) Automatic: Transacts every time a file system event happens (e.g., handheld scanner commits every time the database file is written to (file_close)).

(c) Application-controlled: Transacts every time all conditions are met (e.g., several files that are dependent on each other and need to be updated together have been all changed.)

Using these options in combination gives customers the flexibility to choose under exactly which conditions they want to transact and protect important data, precision that enables total control over the balance between performance and protection for any use case.

Our efforts to address the needs of our multi-threaded customers described at the beginning of this blog post have led us to the next big breakthrough in embedded file system design, and the next big feature for Reliance Nitro. I will be blogging more about this feature soon!

Also coming soon, keep an eye out for our 2012 Customer Survey, another way we seek to continuously improve our understanding of what our customers need. We sincerely hope to get your feedback on the survey, but don’t hesitate to contact us anytime if you have suggestions for improvement.

Learn More About Dynamic Transaction Point technology

In conversations with the embedded OEMs we work with, a common issue affects almost every manufacturer – the cost of diagnosing and fixing causes of field failure. This impacts time-to-market and pulls resources from development for field diagnostics and post-mortem analysis.

This issue is especially relevant due to the following reasons:

• Need for defect prevention during field operations: The high degree of reliability required for protecting critical data dictates that devices must not fail. To ensure that devices are wear-fail-safe, manufacturers are required to run extensive tests for a range of user scenarios so as to safeguard against edge cases. The analysis of test results can be a daunting task due to several interfaces between hardware and software and application layers. Hence, there is a need to continuously track these interactions so that, during a failure, any difference in the interactions can be discovered and corrected.

• Vulnerability of device to wear-related failures: As flash media continues to increase in density and complexity, it is becoming more vulnerable to wear-related failures.  With the shrinking lithography comes increased ECC requirements, and the move to more bits/cell, there’s a concern that what was written to the disk, may not be what is read off the disk. However, most applications assume that the data written to the file system will be completely accurate when read back.  If the application does not fully validate the data read there may be errors in the data that cause the application to fail, hang or just misbehave. These complications require checks to validate data read as against the data written so as to prevent device failures due to data corruption.

• Complexity of hardware and software integration: The complex nature of hardware and software integration within embedded devices makes finding the cause of failures a painstaking job, one that requires coordination between several hardware and software vendors. For this reason, it often takes OEMs days to investigate causes at the file system layer alone. Problems below that layer can involve more extensive testing and involve multiple vendors. Log messages can help manufacturers pinpoint the location of failure so that the correct vendor can be notified.

This ability to pinpoint the cause of failure is especially helpful when an OEM is:

• Troubleshooting during the manufacturing and testing process to make sure that their devices do not fail for the given user scenarios
• Doing post-mortem analysis on parts returned from their customers to understand the reason and solution for failures
• Required to maintain a log of interactions between the various parts of the device for future assistance with failure prevention or optimization.

So, what are we doing to help our customers find and correct the cause of field failures? Stay tuned for as we have some upcoming news on this topic. Also, do you have an embedded device related issue which you wish someone should look into? Please share your issues and solutions in the comment section of this blog.

Today’s embedded applications such as digital cameras, smartphones, and tablets almost always store their content on flash memory. In the past, this has required a dedicated controller to manage the reading and writing of data, driven by the application CPU. However, as semiconductor technology has evolved to allow vastly increased storage density, it has become inefficient for the controller to manage these functions from outside the flash memory die. Hence, eMMC was developed as a standardized method for bundling the controller into the flash die. As eMMC has improved, the standard has also provisioned for features such as secure erase and trim and high-priority interrupt to meet the demand for high performance and security. So while the eMMC standard was created to improve data rates and throughputs for high-density chips designed to store high-resolution video, newer generations are doing more for more applications, and each generation of the standard will include additional new features for a richer end-user experience.

Read more about eMMC