Tackling the tradeoffs with using Flash memory in an embedded design
Imagine replacing the family car with a Formula-1 racing car, you may finish the school-run in record time but where would your children sit? Obviously, the mission profile for a family runaround is different from a race car. What are the considerations when embedding flash memory in embedded design? When trying to maximize performance, tradeoffs in reliability, security, safety or cost have to be considered; something has to give.
Embedded applications, an area where tradeoffs exist in abundance, often between power and performance but in some cases it is between performance and reliability. The harder you push some things, the more likely they are to fail, which brings us back to Formula 1 racing. In the case of embedded systems failure it is unlikely to manifest itself as a blown engine but it could be just as catastrophic if the function involved is mission or safety critical. The problem is compounded if the engineering team doesn't fully comprehend the tradeoffs involved and their possible consequences.
Take flash memory as an example. Non-volatile memory is used extensively in embedded systems and Disk-On-Board (DOB) can be used in place of a Solid State Drive; it offers many benefits, including the ability to configure the size and shape of the drive to better meet the application. But this is really where the tradeoffs start.
When using flash in this way it is necessary to map the physical memory locations to logical locations, which is typically handled by a flash controller through what is referred to as the Flash Translation Layer (FTL). The FTL contains all necessary functions and features to manage the shortcomings of a NAND flash. During runtime, the necessary information (e.g. log-to-phys tables) are held in the controller internal RAM for performance reason. This means, in case of a sudden power disruption this critical information is lost. This has to be avoided under any circumstance. To ensure the operation of the system, the controller has to store this information on the flash to have it available for the next power-up. This means that the controller either needs internal pre-cautions or an external power supply to bridge the gap until the critical information is stored on the flash.
Another area to consider is capacity or, more specifically, overprovisioning of capacity. This is the practice of reserving some of the available memory for administrative purposes, such as remapping blocks of defective memory (so called Dynamic Defect Blocks). If the FTL uses page-based mapping, which is the most common type of mapping, overprovisioning can increase both the lifetime and the random write performance of the flash memory. The tradeoff here is that overprovisioning has to consume part of the available capacity; the amount of capacity reserved for overprovisioning is at the discretion of the design team.
Overprovisioning is also used to reserve capacity for functions like Garbage Collection (GC), the use of which also incurs tradeoffs. GC is the SSD equivalent of the defragmentation of a magnetic drive; GC moves data around to overcome the same type of issues with HDDs. The problem comes from the way flash erases data, it happens in blocks, which can render pages obsolete if part of the data they store is no longer valid. GC is used to free up the space taken up by obsolete data, by shuffling data around until the capacity is used in the most efficient way. Clearly, this process takes time, so it needs to be scheduled and this is where the tradeoffs happen. Is GC constrained to periods of inactivity, or will it be necessary to carry out GC on a more frequent basis? This is fully dependent on the application and the amount of memory available.
The tradeoffs covered here all exist because of features inherent in flash memory, but there is another feature that should be considered and addressed. As data ages it becomes unstable, so it is common practice to perform some kind of routine that periodically refreshes the data stored. However, not all controllers perform this function and even those that do, are conducting it in different ways and quality. Some, for example, may only perform a refresh when data is read, which in some applications may not be sufficient.
Many of these tradeoffs can be managed and optimized using the right kind of flash controller. Ultimately, the more the engineering team understands about its application and the more flexible the controller the easier it is to make these and other tradeoffs when using flash memory in an embedded system.