Home » Resources » Migrating from mDOC: Options, Challenges, and Benefits

Migrating from mDOC: Options, Challenges, and Benefits

DiskOnChip is a well-known line of flash memory products created by M-Systems (now SanDisk). First introduced in 1994, DiskOnChip (also called mDOC) became very popular in embedded applications because of its simple integration and strong performance. As a result, mDOC was quickly adopted by embedded device makers, in spite of the fact that it was more expensive than raw flash chips. Key to the product’s easy integration was TrueFFS, M System’s device driver which made mDOC appear as a block device, able to be formatted using any file system. TrueFFS performed functions of wear leveling and bad block management whereas the ECC (Error Correction Codes) were handled in hardware by mDOC’s controller. Most mainstream embedded operating systems were supported by mDOC, with Windows and Linux being two of the most popular[1]. Unlike raw flash parts, which are made by several manufacturers, M-Systems (and later SanDisk) was the sole supplier of mDOC.

 

Figure mDOC logical architecture

Figure: mDOC logical architecture 


Recently, SanDisk announced end-of-life (EOL) for several parts in the mDOC product line[2].  Customers who were using these parts were asked to place their final order and transition to a different storage technology. Usually when a flash part is EOL’d by one manufacturer, customers can source a compatible flash part from another manufacturer. This involves changing software configuration and driver support, but does not typically require a redesign of hardware. However, since SanDisk was the sole source for mDOC parts, many customers had to redesign their entire system. Faced with mounting redesign costs, customers of the EOL’d mDOC parts found themselves in a very difficult situation.

The mDOC EOL highlights an important logistical challenge that OEMs face when working with flash memory. Using single-source parts can be expensive and disruptive in the long run due the possibility of part allocation, higher costs, and the risk of EOL. Most large OEMs have a multi-sourcing process which work well for raw flash but can be difficult for specialty parts like mDOC. Mid-to-small OEMs often get caught relying on a single vendor/part because of the difficulty of designing support for multiple parts. These customers are also more likely to be affected by price volatility and EOL schedules because they simply don’t have the clout of the top tier manufacturers.

Clearly, it’s in an OEM’s best interest not to rely on availability of a single part, or tie product planning too closely to one flash vendor. At the same time, OEMs have huge pressure to keep costs down and get to market faster with better performing devices. A solution that can provide vendor independence, better performance and faster integration with low total cost of ownership (TCO) is hence very appealing.

In this paper, we will discuss various alternatives that OEMs have for migrating from mDOC. We will present the pros and cons of each approach along the four parameters highlighted above

  1. Vendor independence
  2. Ease of migration (from mDOC to this solution)
  3. Performance (I/O throughput, boot speeds, file system operations, etc)
  4. TCO

 

mDOC Migration Alternatives

  

Option 1: OneNAND + Datalight FlashFX Pro

OneNAND belongs to a category called “fusion-flash,” which combines several different memory technologies (NAND, NOR and SRAM) in a single chip form factor to provide space savings and better performance. OneNAND technology is designed by Samsung Electronics but Samsung has licensing agreements with Toshiba and Numonyx to produce OneNAND memory. As a result OEMs can multi-source OneNAND parts.

 

Figure: Samsung OneNAND

Figure: Samsung OneNAND (courtesy: Samsung)


The above diagram, referenced from Samsung’s website shows the architectural overview of OneNAND. OneNAND is comprised of:

  1. SLC NAND core – allows for large data storage at lower prices. 100k write cycles ensure the part will last for a longer time. NAND also allows for faster erase cycles.
  2. SRAM– allows for very fast read performance with the RAM acting as buffer.
  3. NOR Interface – allows for XIP (eXecute In Place), useful for boot applications.

OneNAND provides ECC in hardware, enabling faster performance. Other flash management functions like wear leveling, bad block management, background compaction (aka garbage collection) and block device emulation still must be done by software.

 

Figure: OneNAND +Datalight FlashFX Pro

Figure: OneNAND +Datalight FlashFX Pro


Datalight has partnered with Samsung to provide flash management functionality for OneNAND. Datalight’s FlashFX Pro, along with OneNAND, provides direct replacement for mDOC and TrueFFS.

Evaluating this option

  1. Vendor independence – Even though OneNAND is Samsung technology, it can be sourced from Samsung and Numonyx today (and Toshiba in near future). This provides vendor dependence and ability to multi-source, albeit with limited options.
  2. Ease of Integration – Datalight FlashFX Pro makes OneNAND look like a block device driver, allowing customers to easily migrate their applications from mDOC. Datalight provides sample boot code for allowing OEMs to boot from OneNAND. Datalight FlashFX Pro comes pre-ported to all top embedded OS thus allowing OEMs to quickly integrate it in their devices.
  3. Cost – OneNAND is more expensive than raw flash due to its additional features and because it uses faster and more reliable SLC flash. Costs also vary on the volume of the parts purchased. Datalight FlashFX Pro has flexible licensing terms including royalty-free options.
  4. Performance – utilizing SLC flash and SRAM buffer, OneNAND offers the best performance replacement for mDOC.

   

Option 2: Raw NAND + Datalight FlashFX Pro

Raw Flash refers to flash memory without any controller or fusion memory. Raw flash memory can be categorized into two major technologies, NOR and NAND. For a more detailed discussion on these two technologies, consider reading the Datalight whitepaper, NAND vs. NOR.

As a replacement option for mDOC, NAND flash offers the advantages of high capacity, low price, fast writes and erases, and a broad choice of vendors. Raw NAND flash cannot be used as-is in a device environment because it is not a block device storage medium. It needs a flash manager like Datalight FlashFX Pro to make it appear as a block device, and to take care of bad block management, wear leveling, ECC and garbage collection.

NAND flash comes in two variants, SLC (single level cell) and MLC (multi level cell). SLC technology provides higher reliability and performance but at lower capacities and higher cost. MLC provides higher capacity at a much lower cost, but it is slower in performance and less reliable. The choice between SLC and MLC will typically depend on the type of device, data criticality, device lifetime, performance requirements and budget constraints.

Many device designs use a NAND controller to improve the performance of raw NAND. NAND controllers may be included in the CPU, or can also be a separate FPGA.

Figure: Raw NAND Flash + Datalight FlashFX Pro

Figure: Raw NAND Flash + Datalight FlashFX Pro

  

Evaluating this option

  1. Vendor independence – NAND flash is manufactured and sold by several vendors. Standards such as ONFI allow flash parts of different manufacturers to be compatible with each other. Having compatible solutions from several vendors make multi-sourcing NAND flash very easy and allows for significant cost savings.
  2. Ease of Integration – Datalight FlashFX Pro makes RAW flash look like a block device driver, allowing customers to easily migrate their applications from mDOC. Datalight FlashFX Pro comes pre-ported to all top embedded OS thus allowing OEMs to quickly integrate it in their devices.
  3. Cost – This option provides the most cost efficient option for mDOC migration. Using Datalight FlashFX Pro, which supports 200+ flash parts, OEMs can take best advantage of multi-sourcing, thus reducing hardware costs.
  4. Performance – Datalight FlashFX Pro and Datalight Reliance file system are optimized to provide fast performance on raw NAND flash. Both products outperform default flash management solutions by a huge margin. Using a NAND controller can also improve the performance of raw NAND. Datalight FlashFX Pro provides built-in support for a large variety of NAND controllers.

  

Option 3: Managed NAND + block driver

The term “managed NAND” refers to a new class of flash memory which implements flash management features in a hardware controller built into the memory with a BGA package. Advantages claimed by managed NAND vendors include simplicity of integration and better performance.

Managed NAND provides easy migration from mDOC-based designs. It requires a block driver to make it appear as a block device; this driver is provided by the flash vendor. Alternate better performing drivers are also available from third-parties.

 

 Figure: Managed NAND + Block Driver  

 

A few things to note about managed NAND:

  1. Most implementations of managed NAND use less-reliable, slower MLC NAND – if you plan to build long-lasting and highly reliable devices, this might be a challenge.
  2. Since all of the flash management is done in hardware, there is not much flexibility for the OEM to tune performance to their specific use scenarios.

  

Evaluating this option

  1. Vendor independence – Managed NAND solutions are usually vendor specific, requiring reliance on a single vendor to provide parts. This is beginning to change with emergence of standards like eMMC and eSD.
  2. Ease of Integration – Managed NAND provides easy integration with your environment. Procuring drivers for your specific OS may be a challenge.
  3. Cost – Managed NAND has a premium over raw flash memory. The price difference can be anywhere between $1 and $10 per chip depending on the flash part size and volumes. A high-performing block driver can also add cost to your BOM.
  4. Performance – Managed NAND provides very good performance if implemented with a high-performing block driver.

 

Option 4: Raw Flash + In-House solution

Instead of purchasing a flash manager, OEMs occasionally choose to build one from scratch. Functionally, this is similar to option 2, except the OEM has to implement the equivalent of FlashFX Pro, providing bad block management, wear leveling, and small sector emulation. Pros and Cons of this option are similar to any Build vs. Buy decision, with some flash-specific caveats:

  1. Flash memory technology is rapidly changing. As the mDOC EOL illustrates, flash parts have a very short market lifespan. Manufacturers are also reducing lithography and increasing density. As a result, flash management software is becoming increasingly complex to build and even more complicated to maintain.
  2. Elements of flash management such as BBM and wear leveling are not trivial to implement but elementary functionality can be built by any OEM. To get these solutions perfected and optimized for long flash lifetime and fast performance takes significant flash expertise.

  

Evaluating this option

  1. Vendor independence – OEMs can choose to implement their solution so as to be vendor independent. It will be a sufficiently large undertaking but can allow the OEM ultimate flexibility.
  2. Ease of Integration – This is subjective to OEM’s flash expertise, number of people working on it, licensing intellectual property, product testing and qualification.
  3. Cost – There are no royalties to pay but the upfront cost of building the solution as well cost of time to market delay have to factored in the equation.
  4. Performance – Performance is also subjective to how much effort the OEM can put in performance optimization process.

    

Option 5: Raw Flash + Vendor solution

This option is similar to option 4, except that the flash management solution is provide by the flash vendor. For high volume customers, flash vendors typically provide a flash management solution. The flash vendors make this investment to get continual business from the customer. Software solution is not the core competency of the flash vendor and the solutions group exists to complement the hardware business.

This option can be economical for the OEM upfront but it does not address the core risk of vendor dependence. mDOC EOL has shown that relying on one vendor for the entire storage stack can be a risky undertaking, especially in the volatile flash memory market. In this scenario, OEMs also have much less flexibility in multi-sourcing flash memory (and therefore limited ability to reduce costs).

  

Evaluating this option

  1. Vendor independence – Since the OEM is relying on a single vendor’s solution, there is very little flexibility in using multiple vendors.
  2. Ease of Integration – Subjective to the quality of the flash vendor’s solution.  Oftentimes a flash vendor’s implementation is generic in the sense that it has not been customized to work in a variety of specific OS environments.  This requires the OEM to write the OS specific portion of the driver.
  3. Cost – No upfront costs. Less BOM cost savings because of low flexibility in multi-sourcing.
  4. Performance – Again, subjective to the quality of the vendor’s solution and effort put in optimizing performance. 

  

Note on Removable Flash

One of the alternatives for mDOC replacement is using removable storage medium like Compact Flash (CF) or Secure Digital (SD) cards instead of embedded flash. This option allows OEMs to use commercial, off-the-shelf storage cards for data storage. Use of removable flash can be an attractive alternative for cost and vendor independence reasons, but performance and reliability can be a challenge. We are not covering this option in detail in this paper.

 

Comparison of all options

mDOC replacement options

 

Summary

Changing product design is never easy, especially when it is not adequately planned for.  Changing product design due to sudden EOL of flash parts is a very real risk that OEMs must consider in the highly volatile and dynamic flash market. The best plan to adapt to this changing market is to reduce reliance on a single flash vendor/part for your product design.

There are several options for migrating from mDOC, as this white paper has highlighted. Each has its own pros and cons. Evaluation of these options is largely dependent on the specifics of a particular product’s use case, but vendor independence has been heavily underscored in this whitepaper because it is critical, given the volatility of the flash market. Factors such as cost, performance, ease of integration, reliability, and flexibility are parameters whose importance has to be judged by your specific business and technical needs.

 

[1] The latter became more popular when Open Source drivers for mDOC were released for Linux. M-System drivers were not GPL- compliant leading to initial challenges of using mDOC on Linux.

[2] Entire list of publically announced EOL parts can be found here