PDF Version

File I/O Products


smxFFS™ & smxFD™

1. Virtual File System (VFS) provides the standard C library API: fopen(), fread(), fwrite(), fseek(), fclose(),etc. to the application. It also manages File Control Blocks, the File Allocation Table (FAT), and the file cluster cache.
2. Flash Driver implements the block cache, logical to physical address translation, block reclaim, wear leveling, data protection, garbage collection, and error correction.
3. Flash Hardware Interface implements the hardware-dependent routines to provide support for a particular NAND flash device, including: device initialization, device query, page read/write, and block erase.

• Reserved Area is divided into 2 parts: An area used by the Flash Driver and a user area that could store a boot sector or other data.
• File System Signature Area stores a string to identify the flash file system. It is located at the beginning of the next flash block following the reserved area.
• File Control Block (FCB) Area acts like a directory. Each FCB represents one file and contains the following information: status, file name, file extension, first cluster index, and file length.
• File Allocation Table (FAT) Area contains the FAT nodes. Each node represents one data cluster. 16-bit and 32-bit FAT nodes are supported. FAT size can be minimized by increasing cluster size.
• File Data Area stores the file data. It is aligned on a flash block boundary.

•  LRU Block Cache. The LRU (Least Recently Used) block cache contains cache blocks. The number of cache blocks is user-specified, as is their size, which may be as small as one page or as large as a flash block. When it becomes necessary to access a page, that is not cached and the cache is full, the least-recently-used cache block is either flushed to flash, if it has been changed, or discarded, if not. Then, the new cache block, containing the page, is read into the cache from flash. Smaller cache blocks reduce RAM requirements; larger or more cached blocks increase performance. Hence, cache size may be adjusted to achieve optimum RAM vs. performance for a specific application.
• Block Replace Algorithm. When a cached block is flushed to flash, an empty flash block is found and the cached block is written to it. The algorithm finds a spare block that has not been used recently, in order to provide wear leveling. If multiple cache blocks correspond to the same flash block, all are written to the new flash block. Non-cached pages of the block are copied from the old block, in flash.
• Static Wear Leveling. Some files on the flash disk are likely to be permanent or rarely changed. To ensure wear leveling over the entire flash, these static files must be periodically relocated to other flash blocks. This is done during garbage collection (see below). Since moving these files frequently could hurt system performance, they are only moved when the difference between the most-worn and their wear counters exceeds the WEAR_LEVELING_GATE configuration setting. Moving static data, all at once, could hurt system performance, so another setting specifies the maximum number of flash blocks to move at a time. Hence, several iterations may be required to move all of the static data.
• Logical/Physical Address Translation is done through the Block Table. Each location in the Block Table corresponds to a block in the logical address space (i.e. the address space used by the file system). Each entry contains a 14- or 30-bit physical flash memory index and a 2-bit status field. The index multiplied by the block size is the block's physical address in flash memory. The status field indicates if the block is: Valid, Discarded, Spare, or Bad. When a flash block is updated from the Block Cache, the Block Table entry is updated to point to the new flash block. Each Block Table entry is 16-bit by default but can be extended to 32-bit to support a large NAND flash array.
• Block Table Handler. The Block Table is normally stored in the Data Area of the flash and moves through that area just like any other data, so it does not wear out one area of the flash. When the Data Area fills up, the Block Table is written to the first part of the Reserved Area. Since it is usually smaller than a flash block, it can be re-written several times to successive pages in a flash block before it must be moved to a new flash block.
• Data Protection and Recovery. Before flushing the Block Table, its image in flash is marked as being In-Progress. When a new Block Table image is successfully saved in flash, it is marked Valid and the old Block Table image is marked as Discarded (in the first node of the Block Table). Hence, if power is lost there will always be at least a Valid or In-Progress Block Table to start from. (If both are present, the In-Progress Block Table is marked Invalid, and the Valid Block Table is used.) All cached data blocks that have not been flushed will be lost, if power is lost, but the file system will remain intact. The frequency of cache flushes is user-controlled either by closing a file or explicitly flushing the cache. (This is similar to the operation of other file systems.)
• Garbage Collection. When moving data to new blocks of flash, old blocks are marked as being discarded. Garbage collection is the process of erasing discarded blocks so that they can be used again. The user should call this function when the system is idle, after closing a file, or when a data operation is finished. Otherwise, it will be run automatically, during write, if an erased block is needed, but this hurts write performance.
• Bad Block Handler. If the flash hardware interface returns an error for a write or erase function, smxFD will retry a few times. If all retries fail, smxFD marks the block Bad in the Block Table and uses another free block.
• Error Correction. An ECC algorithm is used that can detect and correct any single-bit error in 256 bytes. If enabled, this is run automatically before the data is returned. Multi-bit errors are reported, if detected. (Not all are detectable.) The ECC's are stored in the spare area of each page. Software ECC greatly reduces read/write performance and should be disabled if hardware ECC is available.

• NAND flash only
• At least 8-byte spare area in each page, for flash with 256-byte page size to store the 4-byte logical page address and ECC codes. Larger page sizes need more space for ECC codes. The general formula is: (4 + 4 * page_size/256) bytes of spare area.
• Ability to read/write the spare area of each page independently of the rest of the page
• Does not use interrupt to check R/B signal. (Uses polling to check it, instead.)
• Must support partial programming to a page at least 3 times.
• The maximum flash media size is the lesser of (2exp30 * blocksize) or ((blocksize/8) * blocksize). For example:

From the above table notice that increasing the number of cache blocks does not generally improve read performance but reducing the cache block size does reduce read performance greatly. Increasing the number of cache blocks helps write performance. Using software to implement ECC greatly decreases performance. Because of this, we recommend disabling ECC and enabling the Read Back Check feature, instead.

Notes

1. smxFFS is not for use with SD/MMC, USB thumb drive, or CF flash devices. smxFS supports these devices; see the smxFS datasheet.

For More Information

• Access the manual.
• Try a free evaluation kit.