Virtually Verifying SSD Controllers

Solid State Drives (SSDs) are rapidly gaining popularity for storage in many applications, in gigabytes of storage in lightweight laptops to tens to hundreds of terabyte drives in datacenters. SSDs are intrinsically faster, quieter and lower-power than their hard disk-drive (HDD) equivalents, with roughly similar lifetimes, though SDDs are (currently) more expensive. All appealing characteristics in a datacenter, perhaps in some suitable mix with cheaper HDDs. However there are other challenges with SDDs which make them in some ways more difficult to manage.

The memory cells inside an SSD wear out through repeated read/write/erase actions. Also writes to an SSD are at a page or block level (I’ll use block from here on for simplicity). You can’t just update one word; if you want to update a block already containing data you have to copy the block to SRAM, make the update, write the updated block to a new empty block and mark the original block for deletion. So far no problem, but those marked blocks have to be deleted so they can be recycled back into the system. That’s handled by garbage collection, which the controller will run in the background to avoid slowing down host reads and writes.

There’s an obvious challenge here when write-traffic becomes significant and scattered. Demand for new blocks to write can exceed the pace at which marked blocks are being deleted, in which case writing stalls waiting for garbage collection to catch up. And the supposed fantastic performance of the SSD takes a hit until the backlog is cleared. Which is not great for XaaS providers who want to claim reliably superior throughput.

In managing this problem, storage technologists have come up with a concept of predictable latency through which long tails in this distribution can be limited or even eliminated. Characterizing for this latency for a new controller design under a wide range of demands obviously requires running with a host model which will faithfully represent realistic datacenter traffic as a driver. Here Mentor have further extended their VirtuaLAB concept for Veloce emulation to provide an SSD reference lab, providing all the necessary virtualized operation components, allowing for a host OS such as Qemu, along with debug interfaces. The controller model runs on the Veloce emulator.

What I find particularly interesting about this is the natural fit of a virtualized version of the production storage interface working together with the emulator based DUT model. In the right contexts I’m a fan of ICE-based modeling, where you connect the emulator to real hardware to get all the real-life variability and odd behavior you will have to accommodate. But dealing with massively complex system loads by building large hardware test systems is impractical and inevitably very incomplete. Here virtualized modeling seems a better solution, given easier scalability to a wide range of applications. This is similar I think to the work VirtuaLAB interface Mentor have with Ixia/Keysight for network testing under a wide range of possible loads.

None of which means you’re going to get everything right pre-silicon in this kind of modeling. I’m not sure the old “first-silicon” goal applies any more in complex system devices. But you can shake out a lot of problems to ensure that validation with that first silicon build will be catching real-life corner-cases and not problems you should have caught in design.

You can read Mentor paper on this capability HERE.