TargetFTL-NOR™ Flash Translation Layer for NOR Flash Memory

Overview

TargetFTL-NOR makes NOR flash memory behave like a hard drive, with sectors that can be read, written, and re-written freely. In contrast, writing NOR flash can only change ‘1’s to ‘0’. Bits can only change back to ‘1’ by erasing an entire block (typ 64KB or larger). Because pages cannot be rewritten in place, modifications are written to a free page, leaving the old page ‘dirty’. This requires the FTL to maintain a dynamic mapping between virtual sectors and flash pages. It also necessitates garbage collection and wear leveling.

Features

  • Works with TargetXFS™ and TargetFAT™ to implement fast reliable file systems on NOR flash. Use of NOR flash media for the backing store is invisible to application layer. Can be used standalone to provide a block mode driver for third party file systems.

  • Dynamic mapping between file system sectors and flash memory pages. Since flash sectors cannot be overwritten in place, when a file is modified or overwritten, the FTL allocates new flash pages and updates its mapping tables used to translate the file system’s sector numbers to the new flash page numbers.

  • Wear leveling. Because erase cycles cause wear on the flash device (whose lifetime is specified as the number of erase cycles they can endure), FTLs must spread wear evenly on all flash blocks assigned to a volume to prevent premature media failure. Blunk’s FTLs perform both dynamic (low wear blocks are prioritized for writes) and static (cold data is copied to higher wear blocks) wear leveling. Within a limit, no block will have a higher erase count than other blocks.

  • Third-generation virtual to physical page mapping and wear leveling algorithms. Blunk’s FTLs are advanced designs that track whether data is ‘hot’ or ‘cold’ (frequently or rarely updated, respectively) and performs ‘cold data coalescing’ and ‘cold data pasting’ to optimize performance and reduce wear.

  • Because they cannot be rewritten, there is an ongoing need to reclaim ‘dirty’ flash pages by erasing blocks. Before a block is erased, its in-use pages must be copied to another block, reducing the number of free pages gained. Consequently, garbage collection is more efficient if it is easier to find blocks with no or few in-use pages.

    Reserving memory to improve garbage collection efficiency is called ‘overprovisioning’. Some SSDs reserve 12% or more of their available flash. TargetFTL-NOR reserves 6% by default but the overprovisioning amount is configurable to allow management of this utilization-performance tradeoff.

  • Because reading drains a small amount of charge from flash cells, the page read count is recorded per block and at specified limits, the block’s data is copied to new locations, refreshing the flash cell voltage margins. The read-wear limits are configurable.

  • Provides guaranteed power-fail recovery when used with TargetFAT and TargetXFS, ensuring volume integrity across unexpected shutdowns. Only data written after the last synchronizing operation (fflush(), fsync(), etc.) can be lost. Closed files, directory structures, and files open for reading are never at risk.

  • For optimal performance and highest flash utilization, the page number size in FTL map pages is compile-time configurable as 2, 3, or 4 bytes. With a 512 byte page, 2 byte page numbers support volumes up to 32MB in size and 3 byte page numbers support volumes up to 8GB in size.

  • Map table caching provides a configurable memory footprint and tuned performance for volumes ranging from KBs to GBs in size.

  • Optional Hamming error correction provides reliability in the presence of occasional NOR bit errors. Corrects 1 bit error per 512 bytes. The number of corrected bit errors is reported via vstat().

  • Supports all parallel and serial NOR flash types including Single Level Cell (SLC), Multi-Level Cell (MLC), ‘Write Once’ NOR flash, and other variants.

  • Garbage collection, to free dirty pages, is performed just-in-time by default. It may be scheduled for system idle times by calling vclean() from a low priority task. Applications can manually schedule garbage collection by calling vclean() before a planned write for optimum streaming throughput.

  • When used with TargetXFS or TargetFAT, the FTL performs TRIM at file system sequence points. TRIM accounts for deleted files by removing unused entries from FTL mapping tables, making garbage collection more efficient.

  • Worst-case power loss occurs if the free page count is critically low when an in-progress garbage collection is interrupted. The FTL detects this condition during startup and performs a resume option to recover the free pages lost by the interrupted garbage collection, guaranteeing it can restart successfully.

  • To protect against interrupted block erase commands, blocks are never accepted as erased by reading page contents. Unless it has been erased since startup or is reliably marked as an erased block, every block is erased before being used for page writes.

  • The best way to measure FTL memory footprint (and performance) is using your own hardware and development environment. Blunk supports source code evaluations for that purpose. For estimation, footprint measurements using an ARM Cortex-A9 on a 128MB volume with 512B pages and 64KB blocks are shown below.

    Cached Map Pages Code RAM
    1 27KB 22KB
    10 27KB 27KB
    50 27KB 49KB
  • Supports reentrant use in multitasking environments via one global semaphore and one semaphore per volume.

  • Optimized for fast mounts. Typical mount time for a 64MB volume is under 50 milliseconds.

  • A single flash device can support multiple FTL volumes or a single volume can be implemented using multiple flash devices. FTL volumes can be permanently installed or added and deleted as needed.

  • Extensive scripted testing of error handling, multitasking reentrancy, memory allocation failure, powerfail recovery, and regression tests ensure reliability. Tested on big and little-endian CPUs. Automated continuous 247 powerfail recovery testing on physical hardware.

  • ‘Thin’ driver layer. The driver interface is stateless and consists of just the basic NOR flash operations: read, program, and erase block. Provided sample drivers are easily ported to any device. Includes driver test program that has proven useful in detecting software driver errors and hardware interface errors.

  • Optional copy_page() driver routine for faster garbage collection on flash devices that can perform on-chip transfers, to avoid copying data on and off the chip during garbage collection and wear-leveling, for higher performance.

  • For efficient DMA use, all buffers passed to the driver are aligned on CPU cache line boundaries.

  • Developed using TargetOS™-Lite, Blunk’s free RTOS. Easily ported to other RTOSes or used in polled mode, without a kernel.

  • Source code is 100% Standard C and has been tested using PC-lint and multiple Standard C compilers.

  • Royalty-free license. Includes complete source code, sample applications, sample drivers, user’s manual, and one year of technical support. Electronic delivery via customer-specific web portal.

  • Bundled in liteFS-NOR