Patent Application
20100174845
This invention relates generally to the operation of non-volatile flash memory systems, and, more specifically, to techniques of even usage among different blocks or other portions of the memory, particularly in memory systems having large memory cell blocks.
There are many commercially successful non-volatile memory products being used today, particularly in the form of small form factor cards, which employ an array of flash EEPROM (Electrically Erasable and Programmable Read Only Memory) cells formed on one or more integrated circuit chips. A memory controller, usually but not necessarily on a separate integrated circuit chip, interfaces with a host to which the card is removably connected and controls operation of the memory array within the card. Such a controller typically includes a microprocessor, some non-volatile read-only-memory (ROM), a volatile random-access-memory (RAM) and one or more special circuits such as one that calculates an error-correction-code (ECC) from data as they pass through the controller during the programming and reading of data. Some of the commercially available cards are CompactFlash™ (CF) cards, MultiMedia cards (MMC), Secure Digital (SD) cards, SmartMedia cards, miniSD cards, TransFlash cards, Memory Stick and Memory Stick Duo cards, all of which are available from SanDisk Corporation, assignee hereof. Each of these cards has a particular mechanical and electrical interface with host devices to which it is removably connected. Another class of small, hand-held flash memory devices includes flash drives that interface with a host through a standard Universal Serial Bus (USB) connector. SanDisk Corporation provides such devices under its Cruzer trademark. Hosts include personal computers, notebook computers, personal digital assistants (PDAs), various data communication devices, digital cameras, cellular telephones, portable audio players, automobile sound systems, and similar types of equipment. Besides the memory card implementation, this type of memory can alternatively be embedded into various types of host systems.
Two general memory cell array architectures have found commercial application, NOR and NAND. In a typical NOR array, memory cells are connected between adjacent bit line source and drain diffusions that extend in a column direction with control gates connected to word lines extending along rows of cells. A memory cell includes at least one storage element positioned over at least a portion of the cell channel region between the source and drain. A programmed level of charge on the storage elements thus controls an operating characteristic of the cells, which can then be read by applying appropriate voltages to the addressed memory cells. Examples of such cells, their uses in memory systems and methods of manufacturing them are given in U.S. Pat. Nos. 5,070,032, 5,095,344, 5,313,421, 5,315,541, 5,343,063, 5,661,053 and 6,222,762.
The NAND array utilizes series strings of more than two memory cells, such as 16 or 32, connected along with one or more select transistors between individual bit lines and a reference potential to form columns of cells. Word lines extend across cells within a large number of these columns. An individual cell within a column is read and verified during programming by causing the remaining cells in the string to be turned on hard so that the current flowing through a string is dependent upon the level of charge stored in the addressed cell. Examples of NAND architecture arrays and their operation as part of a memory system are found in U.S. Pat. Nos. 5,570,315, 5,774,397, 6,046,935, 6,373,746, 6,456,528, 6,522,580, 6,771,536 and 6,781,877.
The charge storage elements of current flash EEPROM arrays, as discussed in the foregoing referenced patents, are most commonly electrically conductive floating gates, typically formed from conductively doped polysilicon material. An alternate type of memory cell useful in flash EEPROM systems utilizes a non-conductive dielectric material in place of the conductive floating gate to store charge in a non-volatile manner. A triple layer dielectric formed of silicon oxide, silicon nitride and silicon oxide (ONO) is sandwiched between a conductive control gate and a surface of a semi-conductive substrate above the memory cell channel. The cell is programmed by injecting electrons from the cell channel into the nitride, where they are trapped and stored in a limited region, and erased by injecting hot holes into the nitride. Several specific cell structures and arrays employing dielectric storage elements and are described in United States patent application publication no. US 2003/0109093 of Harari et al.
As in most all integrated circuit applications, the pressure to shrink the silicon substrate area required to implement some integrated circuit function also exists with flash EEPROM memory cell arrays. It is continually desired to increase the amount of digital data that can be stored in a given area of a silicon substrate, in order to increase the storage capacity of a given size memory card and other types of packages, or to both increase capacity and decrease size. One way to increase the storage density of data is to store more than one bit of data per memory cell and/or per storage unit or element. This is accomplished by dividing a window of a storage element charge level voltage range into more than two states. The use of four such states allows each cell to store two bits of data, eight states stores three bits of data per storage element, and so on. Multiple state flash EEPROM structures using floating gates and their operation are described in U.S. Pat. Nos. 5,043,940 and 5,172,338, and for structures using dielectric floating gates in aforementioned United States patent application publication no. US 2003/0109093. Selected portions of a multi-state memory cell array may also be operated in two states (binary) for various reasons, in a manner described in U.S. Pat. Nos. 5,930,167 and 6,456,528.
Memory cells of a typical flash EEPROM array are divided into discrete blocks of cells that are erased together. That is, the block is the erase unit, a minimum number of cells that are simultaneously erasable. Each block typically stores one or more pages of data, the page being the minimum unit of programming and reading, although more than one page may be programmed or read in parallel in different sub-arrays or planes. Each page typically stores one or more sectors of data, the size of the sector being defined by the host system. An example sector includes 512 bytes of user data, following a standard established with magnetic disk drives, plus some number of bytes of overhead information about the user data and/or the block in which they are stored. Such memories are typically configured with 16, 32 or more pages within each block, and each page stores one or just a few host sectors of data.
In order to increase the degree of parallelism during programming user data into the memory array and read user data from it, the array is typically divided into sub-arrays, commonly referred to as planes, which contain their own data registers and other circuits to allow parallel operation such that sectors of data may be programmed to or read from each of several or all the planes simultaneously. An array on a single integrated circuit may be physically divided into planes, or each plane may be formed from a separate one or more integrated circuit chips. Examples of such a memory implementation are described in U.S. Pat. Nos. 5,798,968 and 5,890,192.
To further efficiently manage the memory, blocks may be linked together to form virtual blocks or metablocks. That is, each metablock is defined to include one block from each plane. Use of the metablock is described in U.S. Pat. No. 6,763,424. The metablock is identified by a host logical block address as a destination for programming and reading data. Similarly, all blocks of a metablock are erased together. The controller in a memory system operated with such large blocks and/or metablocks performs a number of functions including the translation between logical block addresses (LBAs) received from a host, and physical block numbers (PBNs) within the memory cell array. Individual pages within the blocks are typically identified by offsets within the block address. Address translation often involves use of intermediate terms of a logical block number (LBN) and logical page.
Data stored in a metablock are often updated, the likelihood of updates as the data capacity of the metablock increases. Updated sectors of one metablock are normally written to another metablock. The unchanged sectors are usually also copied from the original to the new metablock, as part of the same programming operation, to consolidate the data. Alternatively, the unchanged data may remain in the original metablock until later consolidation with the updated data into a single metablock again.
It is common to operate large block or metablock systems with some extra blocks maintained in an erased block pool. When one or more pages of data less than the capacity of a block are being updated, it is typical to write the updated pages to all erased block from the pool and then copy data of the unchanged pages from the original block to erase pool block. Variations of this technique are described in aforementioned U.S. Pat. No. 6,763,424. Over time, as a result of host data files being re-written and updated, many blocks can end up with a relatively few number of its pages containing valid data and remaining pages containing data that is no longer current. In order to be able to efficiently use the data storage capacity of the array, logically related data pages of valid data are from time-to-time gathered together from fragments among multiple blocks and consolidated together into a fewer number of blocks. This process is commonly termed “garbage collection.”
In some memory systems, the physical memory cells are also grouped into two or more zones. A zone may be any partitioned subset of the physical memory or memory system into which a specified range of logical block addresses is mapped. For example, a memory system capable of storing 64 Megabytes of data may be partitioned into four zones that store 16 Megabytes of data per zone. The range of logical block addresses is then also divided into four groups, one group being assigned to the physical blocks of each of the four zones. Logical block addresses are constrained, in a typical implementation, such that the data of each are never written outside of a single physical zone into which the logical block addresses are mapped. In a memory cell array divided into planes (sub-arrays), which each have their own addressing, programming and reading circuits, each zone preferably includes blocks from multiple planes, typically the same number of blocks from each of the planes. Zones are primarily used to simplify address management such as logical to physical translation, resulting in smaller translation tables, less RAM memory needed to hold these tables, and faster access times to address the currently active region of memory, but because of their restrictive nature can result in less than optimum wear leveling.
Individual flash EEPROM cells store an amount of charge in a charge storage element or unit that is representative of one or more bits of data. The charge level of a storage element controls the threshold voltage (commonly referenced as VT) of its memory cell, which is used as a basis of reading the storage state of the cell. A threshold voltage window is commonly divided into a number of ranges, one for each of the two or more storage states of the memory cell. These ranges are separated by guardbands that include a nominal sensing level that allows determining the storage states of the individual cells. These storage levels do shift as a result of charge disturbing programming, reading or erasing operations performed in neighboring or other related memory cells, pages or blocks. Error correcting codes (ECCs) are therefore typically calculated by the controller and stored along with the host data being programmed and used during reading to verify the data and perform some level of data correction if necessary. Also, shifting charge levels can be restored back to the centers of their state ranges from time-to-time, before disturbing operations cause them to shift completely out of their defined ranges and thus cause erroneous data to be read. This process, termed data refresh or scrub, is described in U.S. Pat. Nos. 5,532,962 and 5,909,449, and U.S. patent application Ser. No. 10/678,345, filed Oct. 3, 2003.
The responsiveness of flash memory cells typically changes over time as a function of the number of times the cells are erased and re-programmed. This is thought to be the result of small amounts of charge being trapped in a storage element dielectric layer during each erase and/or re-programming operation, which accumulates over time. This generally results in the memory cells becoming less reliable, and may require higher voltages for erasing and programming as the memory cells age. The effective threshold voltage window over which the memory states may be programmed can also decrease as a result of the charge retention. This is described, for example, in U.S. Pat. No. 5,268,870. The result is a limited effective lifetime of the memory cells; that is, memory cell blocks are subjected to only a preset number of erasing and re-programming cycles before they are mapped out of the system. The number of cycles to which a flash memory block is desirably subjected depends upon the particular structure of the memory cells, the amount of the threshold window that is used for the storage states, the extent of the threshold window usually increasing as the number of storage states of each cell is increased. Depending upon these and other factors, the number of lifetime cycles can be as low as 10,000 and as high as 100,000 or even several hundred thousand.
In order to keep track of the number of cycles experienced by the memory cells of the individual blocks, a count can be kept for each block, or for each of a group of blocks, that is incremented each time the block is erased, as described in aforementioned U.S. Pat. No. 5,268,870. This count may be stored in each block, as there described, or in a separate block along with other overhead information, as described in U.S. Pat. No. 6,426,893. In addition to its use for mapping a block out of the system when it reaches a maximum lifetime cycle count, the count can be earlier used to control erase and programming parameters as the memory cell blocks age. And rather than keeping an exact count of the number of cycles, U.S. Pat. No. 6,345,001 describes a technique of updating a compressed count of the number of cycles when a random or pseudo-random event occurs.
The cycle count can also be used to even out the usage of the memory cell blocks of a system before they reach their end of life. Several different wear leveling techniques are described in U.S. Pat. No. 6,230,233, United States patent application publication no. US 2004/0083335, and in the following United States patent applications filed Oct. 28, 2002: Ser. No. 10/281,739 (now published as WO 2004/040578), Ser. No. 10/281,823 (now published as no. US 2004/0177212), Ser. No. 10/281,670 (now published as WO 2004/040585) and Ser. No. 10/281,824 (now published as WO 2004/040459). The primary advantage of wear leveling is to prevent some blocks from reaching their maximum cycle count, and thereby having to be mapped out of the system, while other blocks have barely been used. By spreading the number of cycles reasonably evenly over all the blocks of the system, the full capacity of the memory can be maintained for an extended period with good performance characteristics.
In another approach to wear leveling, boundaries between physical zones of blocks are gradually migrated across the memory cell array by incrementing the logical-to-physical block address translations by one or a few blocks at a time. This is described in United States patent application publication no. 2004/0083335.
A principal cause of a few blocks of memory cells being subjected to a much larger number of erase and re-programming cycles than others of the memory system is the host's continual re-writing of data sectors in a relatively few logical block addresses. This occurs in many applications of the memory system where the host continually updates certain sectors of housekeeping data stored in the memory, such as file allocation tables (FATs) and the like. Specific uses of the host can also cause a few logical blocks to be re-written much more frequently than others with user data. In response to receiving a command from the host to write data to a specified logical block address, the data are written to one of a few blocks of a pool of erased blocks. That is, instead of re-writing the data in the same physical block where the original data of the same logical block address resides, the logical block address is remapped into a block of the erased block pool. The block containing the original and now invalid data is then erased either immediately or as part of a later garbage collection operation, and then placed into the erased block pool. The result, when data in only a few logical block addresses are being updated much more than other blocks, is that a relatively few physical blocks of the system are cycled with the higher rate. It is of course desirable to provide the capability within the memory system to even out the wear on the physical blocks when encountering such grossly uneven logical block access, for the reasons given above.
In a first set of aspects, a non-volatile memory system including a memory circuit having a plurality of non-volatile memory cells formed into a plurality of multi-cell erase blocks and control circuitry managing the storage of data on the memory circuit is presented. Blocks to be written with data content are selected from a list of free blocks and the system returns blocks whose data content is obsolete to a pool of free blocks, where the list of free blocks formed from members of the pool of free blocks. When selecting a block from the free block list, a block with a low experience count is selected. In a first set of embodiments, the system orders the list of free blocks in increasing order of the number of erase cycles the blocks of the list have experienced, where when selecting a block from the free block list, the selection is made from the list according to the ordering. In a second set of embodiments, the system searches the free block list to determine a first block having an experience count that is relatively low with respect to others of the blocks and, in response to determining the first block having a relatively low experience count, discontinues the search and selects the first block.
According to other aspects, a non-volatile memory system including a memory circuit having a plurality of non-volatile memory cells formed into a plurality of multi-cell erase blocks and control circuitry managing the storage of data on the memory circuit is presented. A wear leveling operation includes selecting a first block containing valid data content from which to copy said valid data content and selecting a second block not containing valid data content to which to copy said valid data content. For the plurality of blocks, a corresponding experience count is maintained. The selecting of a first block includes: searching a plurality of blocks containing valid data content to determine a block having an experience count that is relatively low with respect to others of the blocks; and, in response to determining said block having a relatively low experience count, discontinuing the searching and selecting said block having a relatively low experience count as the first block.
According to further aspects, a non-volatile memory system is presented that includes a memory circuit having a plurality of non-volatile memory cells formed into a plurality of multi-cell erase blocks and control circuitry. The control circuitry manage the storage of data on the memory circuit, where the control circuitry tracks a corresponding experience count of the blocks and maintains the experience counts as an attribute associated and stored with the corresponding block's physical address in data structures, including address tables, and updates a given block's experience count in response to performing an erase cycle on corresponding block.
Various aspects, advantages, features and embodiments of the present invention are included in the following description of exemplary examples thereof, which description should be taken in conjunction with the accompanying drawings. All patents, patent applications, articles, other publications, documents and things referenced herein are hereby incorporated herein by this reference in their entirety for all purposes. To the extent of any inconsistency or conflict in the definition or use of terms between any of the incorporated publications, documents or things and the present application, those of the present application shall prevail.
The various aspects and features of the present invention may be better understood by examining the following figures, in which:
Memory Architectures and their Operation
Referring initially to
A typical controller 19 includes a microprocessor 21, a read-only-memory (ROM) 23 primarily to store firmware and a buffer memory (RAM) 25 primarily for the temporary storage of user data either being written to or read from the memory chips 11 and 13. Circuits 27 interface with the memory array chip(s) and circuits 29 interface with a host though connections 31. The integrity of data is in this example determined by calculating an ECC with circuits 33 dedicated to calculating the code. As user data is being transferred from the host to the flash memory array for storage, the circuit calculates an ECC from the data and the code is stored in the memory. When that user data are later read from the memory, they are again passed through the circuit 33 which calculates the ECC by the same algorithm and compares that code with the one calculated and stored with the data. If they compare, the integrity of the data is confirmed. If they differ, depending upon the specific ECC algorithm utilized, those bits in error, up to a number supported by the algorithm, can be identified and corrected.
The connections 31 of the memory of
The memory of
The wear leveling techniques herein may be implemented in systems having various specific configurations, examples of which are given in
The size of the individual memory cell blocks of
The parameters 55 may include a quantity related to the number of program/erase cycles experienced by the block, this quantity being updated after each cycle or some number of cycles. When this experience quantity is used in a wear leveling algorithm, logical block addresses are regularly re-mapped to different physical block addresses in order to even out the usage (wear) of all the blocks. Another use of the experience quantity is to change voltages and other parameters of programming, reading and/or erasing as a function of the number of cycles experienced by different blocks.
The parameters 55 may also include an indication of the bit values assigned to each of the storage states of the memory cells, referred to as their “rotation”. This also has a beneficial effect in wear leveling. One or more flags may also be included in the parameters 55 that indicate status or states. Indications of voltage levels to be used for programming and/or erasing the block can also be stored within the parameters 55, these voltages being updated as the number of cycles experienced by the block and other factors change. Other examples of the parameters 55 include an identification of any defective cells within the block, the logical address of the block that is mapped into this physical block and the address of any substitute block in case the primary block is defective. The particular combination of parameters 55 that are used in any memory system will vary in accordance with the design. Also, some or all of the overhead data can be stored in blocks dedicated to such a function, rather than in the block containing the user data or to which the overhead data pertains.
Different from the single data sector block of
Re-writing the data of an entire block usually involves programming the new data into an erased block of an erase block pool, the original block then being erased and placed in the erase pool. When data of less than all the pages of a block are updated, the updated data are typically stored in a page of an erased block from the erased block pool and data in the remaining unchanged pages are copied from the original block into the new block. The original block is then erased. Variations of this large block management technique include writing the updated data into a page of another block without moving data from the original block or erasing it. This results in multiple pages having the same logical address. The most recent page of data is identified by some convenient technique such as the time of programming that is recorded as a field in sector or page overhead data.
A further multi-sector block arrangement is illustrated in
Yet another memory cell arrangement is illustrated in
There are many different memory array architectures, configurations and specific cell structures that may be employed to implement the memories described above with respect to
Each row of charge storage transistors (memory cells) of the block forms a page that is programmed and read together. An appropriate voltage is applied to the word line (WL) of such a page for programming or reading its data while voltages applied to the remaining word lines are selected to render their respective storage transistors conductive. In the course of programming or reading one row (page) of storage transistors, previously stored charge levels on unselected rows can be disturbed because of voltages applied across all the strings and to their word lines.
Addressing the type of memory described above is schematically illustrated by
In order to illustrate the concentration of use of physical blocks that can result when the data of a small number of logical block addresses are repetitively updated, an example sequence of five consecutive programming operations is described with respect to
Assume a programming operation where the data at logical address LBA 2 is to be re-written. Of the two blocks 3 and 9 in the erase pool, as shown in
In a next programming operation illustrated in
What this example sequence of
Wear Leveling without Maintaining Block Experience Counts
An example of a process to level out this uneven wear on the physical blocks is given in
Thereafter, a new programming step would normally be carried out, an example being shown in
Another programming operation is illustrated in
After the two write operations illustrated in
In a final operation of this example, another programming operation is performed, shown in
It can be seen, as a result of the two wear leveling exchanges in this example, that two heavily used blocks have been removed from the sequence of being cycled to the erase pool, being written with new data, again being moved to the erase pool, and again being written with new data, and so on. In their place, two blocks with low usage (no usage in this example) replace them in this potential heavy use cycle. The result, as further wear leveling exchanges occur in sequence with blocks 2, 3, 4 etc. in order, is that all the blocks of the memory 91 more evenly share the duty of being erase pool blocks. The designated erase pool blocks are moved throughout the entire memory space.
In this example, a wear leveling exchange has been caused to occur once every two programming cycles, in order to explain the concepts involved. But in actual implementations, this may be made to occur at intervals of 50, 100, 200 or more instances of programming data into an erase block. Any other data programming operations that do not use a block from the erase pool, such as when data are written into one or a few pages of a block not in the erase pool, can be omitted from the count since they do not contribute directly to the uneven wear that is sought to be remedied. Since the wear leveling process adds some overhead to the operation of the memory system, it is desirable to limit its frequency to that necessary to accomplish the desired wear leveling. The interval at which a wear leveling exchange takes place can also be dynamically varied in response to patterns of host data updates, which host patterns can be monitored. Further, some other parameter of operation of the memory system other than the number of programming operations may be used instead to trigger the wear leveling exchange.
The wear leveling process illustrated in the example of
As an alternative to using the physical block address for selecting the source block, according to a sequential progression or otherwise, the logical address of a block of data may be used instead. This makes no real difference of the effectiveness of the wear leveling, but it has some implementation advantages.
It may be noted that these relocations of data also have the effect of refreshing the data. That is, if the threshold levels of some of the memory cells have drifted from their optimum levels for their programmed states by disturbing operations on neighboring cells, rewriting the data into another block restores the threshold levels to their optimum levels before they have drifted so far as to cause read errors. But if some threshold levels of data in a block have drifted that far before the wear leveling exchange, the controller can perform an error correction operation on the read data to correct a limited number of errors within the capability of such error correction before the data are rewritten into the erase pool block.
A principal advantage of the wear leveling process described above with respect to
A system capable of maintaining individual block physical and/or logical experience counts is illustrated in
The host address space 125 is illustrated in
A specific example of the fields included in individual data sectors as programmed into the memory 127 is given in
In addition to the data 137, overhead data, typically but not necessarily 16 bytes total, is also stored as part of each sector. In the example of
A time stamp 149 may also be included in the overhead data to provide an indication of how long it has been since the particular data sector has been rewritten into the memory. This can be in the form of a value of a running clock at the time of the last programming of the sector which value can then be compared to the current clock time to obtain the time since the sector was last programmed. Alternatively, the time stamp 149 can be a value of a global counter of the number of data sectors programmed at the time the data sector was last programmed. Again, the relative time of the last programming is obtained by reading and comparing this number with the current value of such a global counter. One or more flags 151 may also be included in the header. Finally, an ECC 153 calculated from the header is also usually included.
One example of a beneficial use of experience counts is in the selection of a block or blocks to be exchanged. Instead of stepping through each of the blocks individually in a preset order, groups of a number of blocks each, physically contiguous or otherwise, are considered at a time. The number of blocks in each group is in excess of the one or more blocks that can be selected for the wear leveling exchange. The experience counts of each group of blocks are read and one or more of the blocks with the lowest counts of the group are selected for the exchange. The remaining blocks are not exchanged. This technique allows the wear leveling to be more effective by targeting certain blocks, and thus allows the exchanges to be made less frequently. This reduces the amount of overhead added to the memory system operation by the wear leveling.
Another way to omit unnecessary wear leveling exchanges involves selecting the erase pool block(s) as discussed above, not using experience counts, but then compare the count of the selected block(s) with an average of the experience counts of the blocks of some large portion or all of the memory that use the particular erase pool. Unless this comparison shows the selected erased block to have a count in excess of a preset number over the average, a scheduled erase exchange does not take place. When this difference is small, there is no imbalance in wear of the various involved blocks that needs correcting. The preset number may be changed over the life of the card in order to increase the frequency of the wear leveling operations as the cumulative use of the card increases.
Counts of the number of times data are programmed into the LBAs of the system, either individually or by groups of LBAs, can be maintained in place of, or in addition to, maintaining physical block experience counts. If such logical experience counts are available, they can also be used to optimize the erase algorithm. When the count for a particular LBA is low, for example, it can be assumed that the physical block into which this LBA is mapped will, at least in the near future, receive little wear. A scheduled wear leveling exchange with an erase pool block can be omitted when the LBA count for the data stored in the physical block selected in the step 101 is higher than an average by some preset amount. A purpose of the wear leveling algorithm illustrated in
In an example of the use of block experience counts that enhances the process described above, the counts of the blocks in the erase pool may be used to select the one or more destination blocks to take part in the exchange. The erase pool block(s) with the highest count are selected.
An example wear leveling process that may incorporate the various wear leveling features described above is illustrated in the flow chart of
In a next step 173, parameters relevant to determining whether a wear leveling exchange should take place are monitored, and, in a companion step 175, it is determined whether one or more criteria have been satisfied to initiate wear leveling. One such parameter is the number blocks from the erase pool that have received new data since the last wear leveling exchange, either data written for any reason or only user data provided by the host. This requires some form of counting the overall activity of programming the memory but does not require individual block experience counts to be maintained. A wear leveling exchange may then be determined in the step 175 to take place after each N number of blocks from the erase pool into which data have been written.
Alternatively for steps 173 and 175, if block experience counts are available, the counts of the blocks may be monitored and a wear leveling exchange initiated when the next block made available in the erase pool to receive data, such as in the FIFO order mentioned above, has an experience count that is higher than other blocks, such as higher than an average experience count of all or substantially all other blocks in the system.
It may be desirable that wear leveling exchanges do not take place during the early life of the memory system, when there is little need for such leveling. If a total count of the number of blocks erased and reprogrammed during the life of the memory is available, a wear leveling exchange can be initiated with a frequency that increases as the total usage of the memory system increases. This method is particularly effective if experience counts are used to target the selection of the source block. If the number N of blocks used since the last wear leveling exchange is used as a criterion, that number can be decreased over the life of the memory. This decrease can be a linear function of the total number of block erase or programming cycles experienced by the memory, or some non-linear function including a sharp decrease after the memory has been used for a significant portion of its total life. That is, no wear leveling exchanges take place until the memory has been used a substantial amount, thereby not to adversely impact system performance when there is little to be gained by doing so.
If the criteria are not met in the step 175, a next step 177 causes the system to wait until the host requests that data be written into the memory. When such a request is received, data supplied by the host is written by a step 179 into the erase pool block identified by the step 171 above. In a next step 181, a block with data that has become obsolete as a result of the host write is erased. Data in one block are rendered obsolete when the host causes new data to be written into another block that updates and replaces the data in the one block. If the host causes data to be written that do not update or replace existing data stored in the memory, step 181 is skipped.
After writing the new data and erasing any obsolete data, as indicated by a step 183, the address translation table (table 93 of
Returning to the decision step 175, if the criteria have been met to initiate a wear leveling operation, a next step 185 determines whether there is a wear leveling data transfer from one or more blocks to one or more other blocks that is currently in process. This can occur if the wear leveling operation transfers only a portion of the data involved at one time. Such partial data copy is generally preferred since it does not preclude other operations of the memory, such as data programming, for the longer period that is required to copy an entire block of data without interruption. By transferring the data in parts, the memory may execute other operations in between the transfers. This is what is shown in
Alternatively, all of the data from the source block may be transferred into the destination erased pool block as part of one operation. This is preferred if the amount of data to be copied is small since the time necessary for the transfer is then also small. The transfer continues without interruption until it is completed. In such a case, the next step after step 175 is a first step 187 of selecting one or more blocks for a wear leveling transfer. This is because there will be no partially completed data transfer that needs to be resumed.
In the case where a copying operation is in progress, a next step 189 causes the specified portion of the data to be transferred to be copied from the previously identified source block(s) to the erase pool destination block(s). A break is then taken to inquire, at a step 191, whether the host has a data write operation pending. This is the same decision that is made in the step 177. If the host does want to have data written into the memory, the processing proceeds to the step 179, where it is done. But if there is not host write command pending, a next step 193 determines whether the data copying of the pending wear leveling operation is now complete. If it is not, the processing returns to the step 189 to continue the data copying until complete. When the copying is complete, the source block(s) from which the data was copied are erased, as indicated by the step 195. The step 183 is then next, where the translation table and erased block pool list are updated.
Back at the step 185, if there is no data copying in progress, a source block of data to be transferred is next identified, in a series of steps 187-205. In the step 187, a first candidate block is selected for review. As previously described, this most simply involves selecting the one block next in order without the need for knowing the relative experience counts of the blocks. A pointer can be caused to move through the blocks in a designated order, such as in the order of the addresses of the physical blocks. Alternatively, a next block for a wear leveling operation may be selected by use of a random or pseudo-random address generator.
If block experience counts are being maintained, however, the candidate source block identified in the step 187 is the first of a group or all of the blocks of an array whose experience counts are to be read. One goal is to always select the block in the entire array that has the smallest experience count; that is, the coldest block. Another alternative is to step through addresses of a designated group of blocks in some predetermined order and then identify the block within a designated group that is the coldest. Although these alternatives are used with physical block experience counts, another alternative is to step through the logical addresses of a group or all the blocks to determine that having the coldest logical experience count.
Once a candidate source block has been identified by the step 187 in one of these ways, a next step 197 determines whether the candidate is erased. If so, the step 187 then selects another candidate. If not, a step 199 then determines whether there is a pending host operation to write data to the candidate block. If there is, the processing returns to the step 187 but, if not, proceeds to a step 201 to note the experience count of the block if experience counts are being used.
A next step 203 determines whether all the blocks in the group or array, as designated, have been reviewed by the steps 187-201. If not, a next candidate block is identified by the step 187 and the steps 197-203 repeated with respect to it. If all blocks have been reviewed, a step 205 selects a block or blocks meeting the set criteria, such as the block(s) having the lowest experience count. It is those blocks to which data are copied in a next step 189.
The steps 201, 203 and 205 are utilized when the experience counts or some other parameter are utilized to make the block selection from a group of blocks being considered. In the case where no such parameter is used, namely where the source block(s) is selected by proceeding to the next block address in some designated or random order, that single block or blocks are identified in the step 187 by use of the address pointer discussed above. Nothing then happens in the step 201, since block parameters are not being considered, and the decision of the step 203 will always be “yes.” The resulting selection in this case is a block(s) selected by the step 187 and which survives the inquires of the steps 197 and 199.
The process illustrated by
As mentioned above, logical block addresses may be used to select the source block for a wear leveling exchange. When physical blocks are used, a sector in the selected block has to be read to determine the logical address of the data (so that the translation tables can be subsequently updated), to determine if the block contains control data, or to determine if the block is erased. If the block is erased, it is a “selection miss” and the process must be repeated on another block, as per
When logical blocks are used, an address table sector is read to determine the physical block address corresponding to the selected logical block address. This will always result in selection of a block that is not erased, and does not contain control data. This eliminates the selection miss, as above, and can allow steps 197 and 199 of
The wear leveling process illustrated in
If the host tries to access data in the source block(s) before all the data has been transferred and the logical-to-physical address translation table is updated, the current wear leveling operation is abandoned. Since the data remains intact in the source block(s) until these steps are taken, the host has access to the partially transferred data in the source blocks. Such access remains the same as if the wear leveling exchange had not been initiated.
The following outline provides a summary of the various features of wear leveling described above.
The previously described methods of wear leveling can be described as “active”, involving an exchange of blocks such as is described in
In general terms, when a block is needed for a data write, rather than arranging the erased block pool (123,
In many non-volatile systems, such as those of the exemplary embodiment as just cited or other systems mentioned above, the memory will manage a pool of free blocks, from which blocks are selected when data needs to be written and to which blocks are returned when they are freed up. Rather than use a FIFO type arrangement, memory block wear can be evened up by instead taking the coolest (i.e., lowest experience or “hot” count) blocks available. The first embodiment does this by sort the free block list according to experience count. Consequently, such an arrangement requires the experience count of the blocks be tracked, as can be done as described above, such as maintaining the hot count for each block in its header or in a block assigned for such overhead, or as described in the next section below.
Although the exemplary embodiments are for systems that manage the memory on a meta-block basis, the techniques can also be used when the memory is operated on an individual block basis. When the system uses static meta-blocks, the ordering of blocks in the free block list will be for these fixed meta-blocks. For dynamically linked meta blocks, where the meta-block linking is broken down when the blocks are freed up, the sorting can be applied to each plane, die, chip, or whatever level that blocks are broken down to, which a sorting of free blocks being done at the corresponding level. Thus, if the memory is made up of blocks that the controller forms into multi-block logical structures (the meta-blocks), when forming a meta-block, the controller selects blocks from the list free blocks. When a meta-block no longer contains valid data, the blocks are returned to the free block pool or pools, where they are ordered based upon their hot count and when blocks are selected for forming a meta-block, they are selected based on this ordering.
In the following discussion, the terminology “hot count” and “experience count” will be used largely interchangeably with each other to have their usual meaning of the number of erase-program cycles that a block has experienced. However, it should be noted that the experience count of a block should more generally be taken to be an indicator of a block's age. This may be the common measure of the number of erase cycles, but other metrics can also be used. Other indicators of age, and consequently bases for the experience count, can be values such as the time or number of pulses that it takes to program or erase a block. For example, one alternate experience count could be take as the number of erase pulse determined to be used after an erase, where, if the system has a power cycle before being updates with a new value, the previous value can be used, as this will only delay the update until the next erase following the update.
An implementation of sorting the free block list based on hot count can illustrated with respect to
Although the ordering in the example of
Also, it should be noted that the pool to which free blocks are returned and the list from which they are selected need not be the same, with one just being some sort of ordering of the other. More generally, the list from which free blocks are selected my be all of the pool or only a portion of the free block pool. Similarly, the sorting of the list or searching of the list may be for the entirety of the list or a portion (or short list). The selection of the list from the pool (or short list from the list), when these two are not equivalent, can be effect in a number of ways, such as on some sort cyclic choice, random/pseudo-random selection, and so on. Consequently, for both the order and searching of blocks, the list can be taken as all or part of a fill list of free blocks, which in term may be all or part of entirety of the free block pool. Particularly when the memory has a large capacity, such a limiting of the list from which free blocks are selected can help expedite the selection process.
In another set of embodiments, free blocks are against selected from the free block pool in a way that will provide blocks with a relatively low experience count, but rather than order the free block list, when a block is needed the free blocks are searched based on hot count. A search could be made for the absolute coldest block; however, as this may be fairly time consuming, it may often be preferred to find a block that is just “cold enough”. (In some respects, this can be similar to the method described above for selecting when a block becomes hot enough to under go a wear leveling exchange, except that instead of determining if the block is hot enough, it is instead used to determine whether a block is cold enough.) What qualifies as “cold enough” can be variously determined by the system, usually based on the average hot count that can be maintained by a counter used to keep track of the average number of erases per block in the card and possibly other such statistics maintained on the system. For example, determination could just be whether a block is one of the colder blocks, colder than average or the average minus some amount; or more nuanced, such as a certain percentage or number of standard deviations below average. The average can be for the population of blocks as a whole, or some other population such as that of the free block list itself. In some embodiments, the selection process may be skipped when the average experience count is low and then introduced as it increases. And as with the sorted free block list, this method can used with binary or multi-state memory or for one or both sections of memories having both.
A simple example of the concept can be illustrated by the flow of
As with the embodiments for ordering the free block list based on hot count, the search method can be used for a memory operated on an individual block basis, as well as when the system uses meta-blocks, whether static or dynamic. Thus, for example, if the memory is made up of blocks that the controller forms into multi-block logical structures (meta-blocks, when forming a meta-block, the controller selects blocks from a list free blocks. When a meta-block no longer contains valid data, the blocks are returned to the free block list. A hot count is maintained for each block and when blocks are selected for forming a meta-block, or, more generally, for writing data, they are selected based on the hot count being less than a value dependent upon an average value of the hot count for the blocks in the free block list.
The techniques of finding a “cold enough” block can also be applied to finding a relatively cold written block, with valid data, to serve as a source block for a wear leveling operation. Under this arrangement, data is copied from a “cold” block to a free block, which can be taken as a hot block; that is, the techniques described here for selecting a “cold enough” free block can be applied to the selection of a source block in the type of wear leveling operation presented in early sections, like those summarized in the “Outline of Wear Leveling Features” section above. In this case, a process similar to
Many of the techniques described above use block experience counts.
The use and maintenance of the experience count is again presented in the context of the exemplary embodiments of United States patent applications: “SPARE BLOCK MANAGEMENT IN NON-VOLATILE MEMORIES”, by Gorobets, Sergey A. et al.; “NONVOLATILE MEMORY AND METHOD WITH WRITE CACHE PARTITIONING”, by Paley, Alexander et al.; “NONVOLATILE MEMORY WITH WRITE CACHE HAVING FLUSH/EVICTION METHODS”, by Paley, Alexander et al.; “NONVOLATILE MEMORY WITH WRITE CACHE PARTITION MANAGEMENT METHODS”, by Paley, Alexander et al.; and MAPPING ADDRESS TABLE MAINTENANCE IN A MEMORY DEVICE, by Gorobets, Sergey A. et al.; and Provisional application “NONVOLATILE MEMORY AND METHOD WITH IMPROVED BLOCK MANAGEMENT SYSTEM”, Gorobets, Sergey A. et al., all being filed concurrently herewith, where the life of the system can be increased by the memory management layer of the controller using both “active” and “passive” wear leveling methods to equalize the amount of usage the blocks receive. To do this, a number of different methods can used. The exemplary embodiment includes both binary and multi-level blocks. For binary blocks, intact data blocks can be periodically cycled or copied to a free block. Intact multi-level blocks can also be periodically cycled, but the selection of a block to copy from can be based on analysis of the experience count. Free blocks can also be allocated from the free block pool based on experience count, as described in the last section on “passive” wear leveling, to attempt only to allocate the “coldest” blocks from the free block pool. The system can also perform block exchange of hot blocks with cold blocks after a predefined number of erases have been performed, including the swapping of free blocks with spare blocks as described in United States patent application “SPARE BLOCK MANAGEMENT IN NON-VOLATILE MEMORIES”, by Gorobets, Sergey A. et al., filed concurrently herewith. Typically, any of these wear leveling operation which are implemented will be a lower priority operation relative to other types of operations of the memory management.
As noted, the exemplary embodiment uses both binary blocks and multi-level blocks. These are treated differentially with respect to wear leveling. For the binary blocks, the system can store a wear leveling count, a wear leveling pointer, and an average hot count to assist in wear leveling. The binary wear leveling count can be a 16-bit, for example, count of binary block erases between wear leveling operations. It could start with zero value at format time and is incremented by number of erases of binary blocks done since the last Master Index update of the systems master index. It is reset after a wear leveling operation.
The binary wear leveling pointer is a, say, 16-bit number of the next block to be accessed as a source block for wear leveling operation and is updated in a cyclic manner to point to the next binary block after previously selected source block. The binary average hot count is a 16-bit, for example, integer number of the average number of erases per binary block in the card and is typically only used for statistics. A wear leveling operation can be performed at the first convenient time after the binary wear leveling count reaches the set maximum value. Starting with a binary block pointed to by the binary wear leveling pointer, blocks are searched to select a source block. Control blocks can be excluded. All data from the selected block can be copied to the first block in the binary free block pool, called destination block. The source block can then be added to binary free block list.
For multi-level (MLC) blocks, to assist in wear leveling the system can again maintain a wear leveling count, wear leveling pointer, and average experience count as well as keeping the number of multi-level blocks on the system and the block experience count within the device cycle. As multi-level cells are generally more sensitive than binary one, the multi-level wear level counter can be taken with less bits than the corresponding binary counter, say a 12-bit MLC counter versus a 16-bit counter for binary. It starts with zero value at format time and is incremented by number of erases of MLC blocks done since the last master index update. It is reset after a wear leveling operation. The multi-level wear leveling count is the count of multi-level block erases between wear leveling operations.
MLC wear leveling pointer can be a, say, 16-bit number of the next block to be accessed as a source block for wear leveling operation and is updated in a cyclic manner to point to the next MLC block after previously selected source block. MLC Average Hot Count can be a 12-bit integer number of the average number of erases per MLC block in the card, whose value is incremented when MLC block hot count within the card cycle exceeds number of MLC Blocks on the card. The number of MLC blocks on the card can be a, say, 16-bit number that is decremented every time a block is removed from the MLC block pool due to a failure. The MLC Block Hot Count within the card cycle is a, say, 16-bit number of the MLC block erases since the MLC average hot count was incremented last time.
For the multi-level portion of the memory, wear leveling operation can be performed at the first convenient time (which can be defined on per product basis) after MLC wear leveling count reaches a set maximum value. Starting with an MLC block pointed to by the MLC wear leveling pointer, blocks are searched to select a source block, which can be a first intact block with hot count equal to MLC average hot count minus, say, 5, or less. The search can be limited to some subset of the address table pages. If no such block is found, the wear leveling operation can be skipped. All data from the selected block can be copied to the first block in MLC free block list, called the destination block. The source block can then be added to MLC free block list.
Block exchange is a copy of all data from a source block to the destination blocks, which can be the hottest free block in free block pool. Just before wear leveling, the master index can be updated with the last, hottest block put at the beginning of FBL, so that it becomes the block to be used as destination block. Corresponding data structures addressing the source block need to be updated to address the new block instead.
Placing the hottest block at the beginning of the free block list is just an example of a convenient design for the sort of “active” wear leveling described earlier on. In more detail, under this arrangement the system chooses a hot (heavily rewritten) destination block for data from a cold block. The system also preferably can use the standard write mechanism, which writes to the first block in the free block list. Therefore, just before the wear leveling operation, the system puts a hot block in front of free block lists, and then starts off the wear leveling operation. In this way, if the system has to do wear leveling in phases, or there is a power loss, then initialization code will try to reconstruct the sequence of writes after the last free block list update. The reconstruction is done by scanning free block list, as blocks are allocated in the same order from the start of free block list onwards. By, putting a hot block to the front of free block list, this will make it the first block to scan. Otherwise, if it is not in the front of free block list, it will have to scan up to all blocks in FBL, or also scan it backwards, or create a special handling case. Arrangements other than putting the hottest block on top of the list can be use, but it is one way to use existing code so that if the system does not complete wear leveling by the next power cycle, the incomplete wear leveling process will be detected in the same way as a new update block.
Returning to the storage and maintenance of the experience or hot count, for all of these uses just described and also for the uses in the previous sections, the experience count can be stored as a 12-bit, say, count stored as a meta-block attribute for all MLC blocks in control data structures. (In the exemplary embodiment, no hot count will be stored for blocks in the binary block pool, as wear leveling it typically of greater importance for multi-level memory sections.) For example, in the tables for storing the physical to address conversion information (the group access tables, or GATs), the hot count can be appended to the block's address along with other block attributes, migrating with address as it is entered in the various data structures.
The exemplary embodiment logical organizes the logical blocks into a group structure. The group access table, or GAT, is a look up table with an entry for each logical group. Each GAT entry stores the meta-block address for an intact block for the logical group. The GAT is stored in the non-volatile memory in special control blocks, or GAT blocks, in GAT pages. Some of the CAT can be cached in SRAM to reduce reads of the non-volatile memory. This is typically one entry in the GAT for each logical group. A master index page can store the latest location of the GAT pages. The GAT can also store spare block within the GAT structure, as described in United States patent applications “SPARE BLOCK MANAGEMENT IN NON-VOLATILE MEMORIES”, by Gorobets, Sergey A. et al. and MAPPING ADDRESS TABLE MAINTENANCE IN A MEMORY DEVICE, by Gorobets, Sergey A. et al., filed concurrently herewith.
GAT blocks are used to store GAT pages and a master index page. At any given point of time the GAT Blocks can be fully written, erased, or partially written. The partially written GAT Block is the only block which can be updated; hence, it is called an active GAT block and is pointed to by a boot page. The GAT blocks contain multiple GAT pages and master index page, including obsolete pages as well. Only the last written master index page in the active GAT block is valid and it contains indices to the valid GAT Pages.
GAT pages are used for logical to meta-block address translation (LBA→MBA.) The set of all valid GAT pages in all GAT blocks covers the entire logical address space of the system. For the exemplary memory system, each valid GAT page can map a 416*n address chunk of the logical address space, where 416 is the number of GAT entries and n is the Logical Group size. The GAT pages are uniquely indexed, with GAT Page 0 covering logical addresses 0 to (416*n)−1, CAT Page 1 covering logical addresses 416*n to (416*2*n)−1, etc.
GAT pages can be stored in up to 32 GAT blocks in a form of shared cyclic buffer. Only one, “active” GAT Block at a time can be updated. Other blocks are fully written and contain a mix of valid and obsolete GAT Pages. The ratio of initial GAT Pages to updated GAT Pages area varies between configurations and can be set during system low-level format. For example, one preferable ratio is 1:16. When an update of a GAT Page is required, the page is copied to SRAM, then the update is made, and the page is written back to the first erased page in the GAT block as an updated GAT. The pointed GAT pages should be used instead of previously written GAT pages, which are now obsolete. The last written GAT page contains the valid data regarding which GAT pages are valid. When the GAT block becomes full, another is block is used. In order to get an erased block, one of the GAT blocks is re-written. Note that only valid GAT pages are rewritten (using the data from the last written GAT page to determine the valid sectors).
In the exemplary format for a GAT entry, each GAT entry has four fields. The first in the Meta-Block Number, the number of the meta-block storing data for the logical group or pre-assigned to it. A free block (pre-assigned) referenced by the entry can be recognized by a page tag value (e.g., 0×3F), which will be an impossible, not supported, value in the system. Re-Link Flag field (RLF) bit is the re-linked flag which is used to mark re-linked meta-blocks which addresses are stored in the corresponding GAT entries. The next field is the meta-block hot count. According to this aspect, the hot (or erase) count for the meta-block which address is stored in the corresponding GAT entries. This is distinct from previous approaches such as keeping the hot count in the header of the block itself (as in
With respect to the master Index page's format, the master index page can contain information about GAT blocks, free blocks, binary cache blocks and update blocks. Different master index page layouts can be used for different system applications; for example, embeddable solid state storage type devices may use a different format than a portable device.
By storing the experience count as a block attribute appearing in a GAT entry field, unlike using a special, dedicated tables to store hot counts, the hot count can be passed around from one set of control data to another as a block attribute, say, along with the block's address. Loosely speaking, the hot count can be treated as a suffix to the address. By storing and updating the hot count along with block address, so that no extra updates are ever required to maintain hot count, as would be the case if they were maintained as a separate table or in the blocks overhead. For unassigned blocks, the free block list will contain the physical block address (meta-block address) and the corresponding hot count. When the block assignments are updated, the block address and associated hot count can then be moved into an “update” block information section, and, once a block becomes intact to “GAT delta” and then on the GAT page. (More details on the data management structure of the exemplary embodiment, including the use of a “GAT delta” for updates to the group access table are given in United States Provisional patent application “NONVOLATILE MEMORY AND METHOD WITH IMPROVED BLOCK MANAGEMENT SYSTEM”, by Gorobets, Sergey A. et al. and US patent application MAPPING ADDRESS TABLE MAINTENANCE IN AS MEMORY DEVICE, by Gorobets, Sergey A. et al., filed concurrently herewith.)
As noted above, in addition to the hot count, other block attributes can include the re-link flag and a time stamp (1-bit, say). During initialization, the blocks in the free block list can be scanned and if the time stamp in a block does not match the one in the free block list, the system can recognize the block as recently written, after the last update of the free block list.
Consequently, under the arrangement describe in this section, the experience count migrates with address with the physical address of the unit of erase. Where the memory is operated on an individual block level, this would be the for the block; when operated based on composite structures, such as the meta-block, this would be the abstract physical block address of the meta-block, where only a single hot count needs to be maintained for fixed hot meta-blocks. (In dynamic meta-blocks, where the meta-block is broken down when unassigned, a record of the count for the individual blocks would be maintained.) The hot count can be passed in the same way as other attributes, such as is described for the passing of the Re-Link flag in the exemplary embodiments of United States patent applications: “SPARE BLOCK MANAGEMENT IN NON-VOLATILE MEMORIES”, by Gorobets, Sergey A. et al.; “NONVOLATILE MEMORY AND METHOD WITH WRITE CACHE PARTITIONING”, by Paley, Alexander et al.; “NONVOLATILE MEMORY WITH WRITE CACHE HAVING FLUSH/EVICTION METHODS”, by Paley, Alexander et al.; “NONVOLATILE MEMORY WITH WRITE CACHE PARTITION MANAGEMENT METHODS”, by Paley, Alexander et al.; and MAPPING ADDRESS TABLE MAINTENANCE IN A MEMORY DEVICE, by Gorobets, Sergey A. et al.; and Provisional application “NONVOLATILE MEMORY AND METHOD WITH IMPROVED BLOCK MANAGEMENT SYSTEM”, by Gorobets, Sergey A. et al., all being filed concurrently herewith. When a meta-block is used to store logical group, or pre-assigned to an erased logical group, then access table (GAT) will contains its hot count. In other cases, hot count would be stored in either the free block list, along with addresses and re-linking flags, or in an update block information section describing update blocks. Thus, hot count/re-link flag/address will migrate between the various data management structure for address conversion and keeping track of free and spare blocks. In this way, the attribute data will always be referenced somewhere to keep it from getting lost. Every time the structure (block, meta-block) is erased, the system increments the hot count. (In practice, there may be some delay between executing the erase and updating the corresponding structuring currently tracking the block.)
Although the invention has been described with reference to particular embodiments, the description is only an example of the invention's application and should not be taken as a limitation. Consequently, various adaptations and combinations of features of the embodiments disclosed are within the scope of the invention as encompassed by the following claims.
This application is also related to United States patent applications: “SPARE BLOCK MANAGEMENT IN NON-VOLATILE MEMORIES”, by Gorobets, Sergey A. et al.; “NONVOLATILE MEMORY AND METHOD WITH WRITE CACHE PARTITIONING”, by Paley, Alexander et al.; “NONVOLATILE MEMORY WITH WRITE CACHE HAVING FLUSH/EVICTION METHODS”, by Paley, Alexander et al.; “NONVOLATILE MEMORY WITH WRITE CACHE PARTITION MANAGEMENT METHODS”, by Paley, Alexander et al.; and MAPPING ADDRESS TABLE MAINTENANCE IN A MEMORY DEVICE, by Gorobets, Sergey A. et al; and Provisional application “NONVOLATILE MEMORY AND METHOD WITH IMPROVED BLOCK MANAGEMENT SYSTEM”, by Gorobets, Sergey A. et al., all being filed concurrently herewith. Any and all patents, patent applications, articles, and other publications and documents referenced herein are hereby incorporated herein by those references in their entirety for all purposes. To the extent of any inconsistency or conflict in the definition or use of terms between the present provisional application and any incorporated patents, patent applications, articles or other publications and documents, those of the present application shall prevail.
