Optimizing SSDs with Software Defined Flash, Part 2

Author: Rahul Advani

In my last post, I talked about the increasing use of enterprise Solid-State Drives (SSDs) and the many different requirements they must be tuned for based on data center application needs. The dilemma for the SSD makers is how to meet these disparate needs while still offering affordable solutions to end users. Supporting these disparate requirements that span cold storage to high-performance SSDs for database applications cost-effectively requires a well-planned, flexible silicon architecture that will allow for software defined solutions.  These solutions need to support software optimizations based around (to name a few):

  • Different densities and over-provisioning NAND levels
  • Different types of NAND (SLC/MLC/TLC) at different nodes
  • Different power envelopes
  • Different amounts of DRAM
  • Often need to support Toggle and ONFI, in order to maintain flexibility of NAND use

The table below shows the many different configurations that PMC’s flash controller supports:

Platform Knobs Using a flexibly architected controller, you can modify features including power, flash density, DRAM density, flash type and host interface bandwidth for purpose-built designs based on the same device.  This allows you to span the gamut from cold storage (cost-effective but lower performance) to a caching adaptor (premium memory usage and higher performance) through different choices in firmware and memory. The key is that firmware and hardware be architected flexibly. Here are three common design challenges that can be solved with software defined flash and a flexible SSD processor:

  • Protocol communication between the flash devices:  Not only does NAND from different vendors (ONFI and toggle protocols) differ, but even within each of these vendor’s offerings there can be changes to the protocol.  Examples are changing from five to six bytes of addressing, or adding prefix commands to normal commands.  Having the protocol done by firmware allows the flexibility to adapt to these changes.  Additionally, having a firmware-defined protocol allows flash vendors to design in special access abilities.
  • Flash has inconsistent rules for order of programming and reading:  A firmware-based solution can adapt to variable rules and use different variations of flash, even newer flash that might not have been available while developing the hardware.  By having both the low-level protocol handling, as well as control of the programming and reading all in firmware, it allows for a solution that is flexible enough to use many types and variations of flash.
  • Fine-tuning algorithms/product differentiation: Moving up to the higher level algorithms, like garbage collection and wear leveling, there are many intricacies in flash. Controlling everything from the low level up to these algorithms in firmware allows for fine-tuning of these higher level algorithms to work best with the different types of flash.  This takes advantage of the differences flash vendors put into their product so they can be best leveraged for diverse applications.

A flexible architecture that can support software defined flash optimizations is the key to supporting many different of usage models, types of NAND and configurations.  It also helps reduce cost, which will accelerate deployment of NAND-based SSDs and ultimately enhance end-user experience.

This entry was posted by Carol Whitmarsh on at and is filed under Flash/NVM. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Leave a Reply

You must be logged in to post a comment.