Why is the NVMe SSD interface inherently more efficient than disk-based protocols such as SATA?

The speed at which the electronics industry moves sometimes masks other developments that are incredibly slow-paced and the conversion of storage I/O protocols from hard-disk-centric to solid-state disks (SSDs) is a shining example. Most SSDs currently employ I/O protocols originally developed for hard disks such as SAS and SATA. We (the industry) did this in the name of expediency. The fastest way to introduce SSDs into the design mix for PCs and servers was to disrupt the supply chain as little as possible. That meant living with motherboards, operating system drivers, interface ports, cables, and even stamped sheet-metal enclosures that had evolved in a world occupied only by hard-disk storage.

That expediency costs us in terms of lost efficiency with respect to SSDs. Take the adoption of the SATA protocol for SSDs as a case study. Where did the SATA storage protocol come from? It is a serialized version of a storage protocol called PATA or “parallel ATA.” Where did PATA come from? The “ATA” part of PATA stands for “AT Attachment” where the “AT” comes from “Advanced Technology,” which was IBM’s name for the second iteration of the original IBM PC, the IBM PC/AT. You know, the version of the IBM PC based on the “advanced” Intel 80286 processor. That PC.

Shugart Technology ST-506 Hard Disk Drive (circa 1980)

What was advanced about the ATA hard-disk interface? It moved the hard-disk controller from an expansion card into the hard drive. Please let that statement sink in. There was a time, in the pre-ATA days, when the hard disk drive was dumb as a rock. It took commands like “step in,” “step out,” “read sector,” and “write sector.” Data supplied to the disk drive had to be appropriately encoded by the external hard-disk controller. This even older, more primitive hard-disk interface came from the original Shugart Technology 5Mbyte (as in “megabyte”) ST-506, the original 5.25-inch hard drive introduced in 1980. Everyone in the hard disk industry—eventually hundreds of vendors—quickly copied the ST-506 interface.

The innovation of the ATA interface—originally developed by Western Digital as the IDE (Integrated Drive Electronics) interface—was to make the hard-disk controller more intimate with the hard drive and the HDA (head disk assembly). This move freed the controller from needing to know how to best control every hard disk ever made. An IDE controller only needs to know about the HDA that it’s welded to.

Because of all this legacy, the SATA protocol still needs to know the basics of hard-disk management. The protocol keeps track of cylinders, heads, and sectors—the atoms and molecules of hard-disk-based storage.. These concepts, of course, are only associated with spinning media—hard-disk storage. They have no meaning for storage based on NAND Flash semiconductor memory. To be used with NAND Flash media, these concepts must first be translated.

Now let’s step back and take a breath here. Let’s remember what we’re actually trying to do at the highest level. At the application level, we actually deal with files. Not cylinders. Not heads. Not sectors. However, the hard disk drive has become so integral to microprocessor-based computing over the past three decades (since the ST-506 drive appeared in 1980) that the translation from files to cylinders, heads, and sectors is buried deeply into our operating systems. With no alternatives for storage, it made perfect sense to meld the file-storage needs of the operating system with the sector-centric world view of the hard disk.

NAND Flash memory does not share that world view.

And that is what brings us (taking the long way home) to NVMe or NVM Express. Leading companies in the storage industry have recognized that the current, popular storage interfaces are too hard-disk centric; they carry too much conceptual baggage that caters to the specific needs of hard disk drives since 1980. Now this baggage is old, but it still serves us well as long as we’re using hard drives. It doesn’t work as well for SSDs. The following diagram shows why.

The block diagram shows the number of translation steps needed to get from the Host CPU to storage in the NAND Flash memory cells. The Host CPU’s parallel bus is serialized and transformed into PCIe, currently the leading bus interface for PCs and many servers. Somewhere, perhaps on a motherboard or perhaps on an expansion card, the PCIe interface is transformed into a SATA interface. The SATA interface then arrives at a SATA controller that manages the attached “hard drives,” whether these drives are actually hard disk drives or SSDs.

At some point, the SATA commands (cylinders, heads, sectors) must be transformed into storage blocks more readily understood by the NAND Flash memories. The NAND Flash memories have their own special needs or peculiarities such as their own block/bank/sectoring scheme, error management protocols including ECC, and wear-leveling algorithms. These peculiarities are handled by the NAND Flash Controller, which then drives the attached NAND Flash memory devices as appropriate.

Translation from PCIe to SATA then to NAND Flash results in a lot of unnecessary overhead, brought on by the desire to slip SSDs into the supply chain with as little disruption as possible.

However, the industry now seems ready to trade off some disruption for more efficiency. The NVMe standard is the result of that change in mindset. Using the NVMe approach, an SSD-based system might look something like this:

To get to this point, changes must occur deep in the operating system. The NVMe specification is now getting close to a year old. Windows and Linux drivers now exist. The revolution is coming.

For more information on the NVMe specification, click here.