The write levelling conundrum

阅读模式 · 发表于 2007-7-14 00:01:49

Assuming we can solve the physical access problems to NAND and NOR devices for recovery (that is with a controller failure), as my previous post mentioned, the next challenge is resolving the block mapping.

Block mapping is essential to prolong the life of FLASH where the cells can fail after a few 100k write cycles. Imagine a hefty telecom call data record, or temporary database with millions of 1k files; contiually being processed. [Admittedly you'd be better off with DRAM based solid state disk for that...] a few 100k writes to the same block would undoutedly happen within a week and CAPUT!

Write levelling or staggering implemented as an alogrithm will stagger writes across the drive.

We're doing some testing to try and predict the write levelling methodology, but it takes time!

匿名 *发表于 2007-7-14 00:02:19* · 发表于 2007-7-14 00:02:19

What you say is correct, but we should need the datasheets of the controller used in the flash device.
Then we can see what algoritm is used.
However, these datasheets are difficult to get.
Do you know a good source ?

Best regards,

匿名 *发表于 2007-7-14 00:02:48* · 发表于 2007-7-14 00:02:48

If you look at the EPROM/NAND flash programmer sites, they often have a database of links or even the database sheets themselves.

Companies such as Advin, Xeltek to name a few (plus others).

匿名 *发表于 2007-7-14 00:03:03* · 发表于 2007-7-14 00:03:03

These are the datasheets of the memories themselves, but not of the controller that handles the access to the memories.

Or am i mistaken ?

Regards,

匿名 *发表于 2007-7-14 00:03:33* · 发表于 2007-7-14 00:03:33

Over the lifetime of NAND, flash management has migrated from the host to the device itself...making it more interesting from recovery perspective.

---
The latest NAND based device that we have had in our lab today has a bespoke ARM microcontroller as a component of the ASIC/FPGA which includes the host interface circuitry. These will have different revisions of firmware depending on the laser etching, and/or the serial no tag on the actual FLASH device. Most manufacturers have a translation table between the part number and chipset and firmware.

So we're almost at the same stage as with hard disks - getting the right firmware modules.

Write Levelling / Wear Level / is more pronounced on more expensive NAND devices (less so on MP3 players/cameras. CRC checking ensures the virtual block mapping will spread writes across cells/blocks.

In some NAND Flash IDE drives there is a WEAR LEVEL Command Register (F5h) which uses Head Select and Features Register (ATA).

---
On Flash Memory Controllers (do a google search USB Flash Memory Controller)....the wear level management will probably be stored in ROM along with the NAND programming algorithm.

However the vectors that hold the wear levelling (which will be different from device to device, even of the same product) must be stored in non-volatile memory - i.e. flash itself.

In our research we have found the following algorithms in use:

BASIC Free blocks that have had fewest write cycles using
(1) Chain Method - all free physical blocks held in a pool. Chain of physical blocks are assigned to every virtual block; and every time a virtual block needs to be allocated, a physical block is selected from the chain. Mostly round-robin (as per RAID read)...

(2) Array Method - measures program/erase cycles by block, and this information or vector is loaded into RAM

ADVANCED Long lived data is held in older blocks. Basically the algorithm ensues that the average wear on each block is the same.

--

In addition to wear levelling, you also need to manage the bad-blocks that appear in the device and grow over time...

--

You may want to look at Intel's Virtual Small Block technology for additional ideas...

---
And another point... a number of US and other patents have been granted in this paticular area. Lookup assignees=Storage Technology Corporation, for example 10672786...

physical block<->virtual block addressing is often held in the physical block.