Wear Down Your Virtual Prototype

Just when you think you know all variations of embedded software development you are exposed to another domain of unique and interesting challenges.

This happened to me awhile back when I started to learn about the software for Flash Memory controllers. You can read a lot about Flash market growth predictions or about the physical challenges of the next generation storage technologies here on SemiEngineering. But it’s harder to find many articles that touch on the software aspects of Flash storage. Some interesting facts that you may not know about:

• NAND Flash cells have a certain lifespan and the controller software needs to keep track of the number of reads and writes to distribute the data optimally (called wear leveling).
• The NAND hardware changes (ages) with each software run and so does the tracked software state, which makes it incredibly hard to debug and reproduce software error conditions.

These are perfect software development challenges suited for the use of virtual prototypes. With virtual prototypes:

• The system state can be altered without burning through tons of physical Flash hardware or running through hours of test pre-setup.
• Errors can be injected into Flash cells without breaking them, in addition to reproducing the error conditions deterministically.
• Full visibility into any hardware and software state can be achieved without the need to alter it.

Let’s take a deeper look at the Flash device controller architecture. I knew managed flash storage software development mainly from the embedded host perspective where the actual storage is hidden behind UFS or eMMC interfaces. However, inside the device controllers there is another layer of complex hardware and software at work. The typical components are:

• The Host interface – also called Front-End – connecting the device to the host, for SSDs often based on PCIe or SATA protocols.
• The compute subsystem running the FTL (Flash Translation Layer) Firmware software, tracking the Flash state and reshuffling the data around, performing wear leveling, caching and other kinds of book-keeping.
• The Flash Controller – also called Back-End – communicating with the NAND Flash over e.g. the ONFI protocol.
• The Flash itself, organized depending on its type into LUNs, Planes, Block and pages.

Figure 1 – Virtual Reference SSD Design available with Synopsys Virtualizer

The SSD/Flash device software teams I’ve spoken to understand these challenges and the benefits that virtual prototyping offers. However, when it comes to getting started they can sometimes feel overwhelmed with the first step. Here comes the concept of Virtual Prototype Starting Points, available with Synopsys Virtualizer and Virtualizer Development Kits (VDKs), which I explained in my previous blog post. The new SSD Starting Point provides a completely configurable VDK of a generic SSD architecture together with the basic set of TLM Models and example FTL firmware. This not only takes away the burdens of doing the first step but also demonstrates best practices for unique Flash modeling challenges:

• Modeling huge Flash memories (GB~TB range) in simulation without performance penalties
• Modeling of the ONFI interface carrying relevant timing information
• Out-of-the-box visualization of relevant Flash metrics and Flash controller states
• Building up of scripting interfaces to inject errors, change factory mappings, and perform data corruption.

Figure 2 – Deep Visibility into the Virtual Prototype – Correlation of Function Trace with ONFI States and Erase Statistics

Victor Reyes and Filip Thoen recently presented the Synopsys SSD Starting Point VDK and how it can be used for Fault Injection testing at the SNUG conference in Silicon Valley. Please check the SNUG webpage in the coming weeks to view the proceedings.