JP4682261B2 - Method for non-volatile memory and class-based update block replacement rules - Google Patents

Description

  The present invention relates generally to non-volatile semiconductor memory, and more particularly to a memory block management system with an improved system for managing the replacement of a pool of open blocks simultaneously for storing data. It relates to what you have.

  Solid state memories that can store charge in a nonvolatile manner, particularly in the form of EEPROM and flash EEPROM packaged as small form factor cards, have recently been used in a variety of mobile and portable devices, especially information equipment. And it has become an option for storage devices in consumer electronic products. Unlike RAM (random access memory), which is also a solid-state memory, flash memory is non-volatile and retains stored data even after the power is turned off. Unlike ROM (read-only memory), flash memory is rewritable in the same way as a disk storage device. Despite the high cost, flash memory is increasingly used when using mass storage devices. Conventional mass storage devices are based on rotating magnetic media such as hard drives and floppy disks and are not suitable for mobile and portable environments. This is because disk drives tend to be bulky, prone to mechanical failure, and have high latency and high power requirements. These undesirable attributes make disk-based storage devices impractical for most mobile and portable uses. On the other hand, flash memory is ideally suited for mobile and portable environments because of its small size, low power consumption, high speed and high reliability, both in the form of embedded and removable cards.

  Flash EEPROM is similar to EEPROM (electrically erasable and programmable read-only memory) in that it is an erasable non-volatile memory and writes or “programs” new data to memory cells. ing. Both use floating (unconnected) conductive gates and are field effect transistor structures that are located over the channel region between the source and drain regions of the semiconductor substrate. A control gate is provided to cover the floating gate. The threshold voltage characteristic of the transistor is controlled by the amount of charge held on the floating gate. That is, for a given level of charge on the floating gate, a response that must be applied to the control gate before the transistor can be turned "on" to allow conduction between the source and drain regions There is a voltage (threshold) to be used. In particular, a flash memory such as a flash EEPROM can simultaneously erase all blocks of memory cells.

  Since the floating gate can hold a range of charges, it can be programmed to any threshold voltage level within the threshold voltage window. The size of the threshold voltage window is delimited by the minimum and maximum threshold levels of the device and further corresponds to the range of charges that can be programmed on the floating gate. The threshold window generally depends on memory device characteristics, operating conditions, and history. Each distinct resolvable threshold voltage level range within the window may in principle be used to specify a limited memory state of the cell. If the threshold voltage is divided into two separate regions, each memory cell will be able to store 1 bit of data. Similarly, if the threshold voltage window is divided into two or more separate regions, each memory cell will be able to store one or more bits of data.

  A transistor that serves as a memory cell is typically programmed to a “programmed” state by one of two mechanisms. In “hot electron injection”, a high voltage applied to the drain accelerates electrons across the substrate channel region. At the same time, the high voltage applied to the control gate draws hot electrons through the thin gate dielectric to the floating gate. In “tunnel implantation”, a high voltage is applied to the control gate for the substrate. In this way, electrons are attracted from the substrate to the intervening floating gate. The term “program” has been used previously to describe writing to the memory by injecting electrons into the charge storage unit that is first erased in the memory cell to change the state of the memory cell. This term is now used interchangeably with more general terms such as “write” or “record”.

  The erasure of the memory device may be performed by a number of mechanisms. For example, for an EEPROM, a high voltage is applied to the substrate associated with the control gate to pass electrons in the floating gate through the thin oxide layer to the substrate channel region (ie, Fowler-Nordheim tunneling). ), The memory cell is electrically erasable. Typically, the EEPROM can be erased byte by byte. For flash EEPROM, the memory can be electrically erasable all at once, or one or more smallest erasable blocks can be electrically erasable at a time, and the smallest erasable block is: It may consist of one or more sectors, and each sector may store 512 bytes or more of data.

  A memory device typically comprises one or more memory chips that may be mounted on a card. Each memory chip comprises an array of memory cells supported by a peripheral circuit such as a decoder or erase, write and read circuit. Higher performance memory devices are also equipped with controllers that perform high function and high level memory operations and interfaces.

  A number of commercially successful non-volatile solid state memory devices are currently in use. These memory devices may be flash EEPROM, or other types of non-volatile memory cells may be used. Examples of flash memory and systems and methods for manufacturing the same are disclosed in US Pat. Nos. 5,070,032 (Patent Document 1), 5,095,344 (Patent Document 2), and 5,315,541 ( Patent Document 3), 5,343,063 (Patent Document 4), and 5,661,053 (Patent Document 5), 5,313,421 (Patent Document 6), and 6,222 762 (Patent Document 7). In particular, flash memory devices having a NAND string structure are disclosed in US Pat. Nos. 5,570,315 (Patent Document 8), 5,903,495 (Patent Document 9), and 6,046,935 (Patent Document 10). )It is described in. Nonvolatile memory devices are also manufactured from memory cells having a dielectric layer for storing charge. A dielectric layer is used instead of the conductive floating gate element described previously. Such memory devices using dielectric storage elements are described by Eitan et al., “NROM: New Localized Trapping, 2-Bit Nonvolatile Memory Cell”, American Institute of Electronics and Electrical Engineers (IEEE) Electronic Device Letter, Volume 21. No. 11, November 2000, pp. 543-545 ("NROM: A Novel Localized Trapping, 2-Bit Nonvolatile Memory Cell", IEEE Electron Device Letter, vol. 21, no. 11, November 2000, pp. 543 -545) (Non-Patent Document 1). An ONO dielectric layer extends across the channel between the source and drain diffusions. The charge for one data bit is localized in the dielectric layer adjacent to the drain, and the charge for the other data bit is localized in the dielectric layer adjacent to the source. For example, US Pat. Nos. 5,768,192 and 6,011,725 describe a non-volatile memory cell having a trapping dielectric sandwiched between two silicon dioxide layers. Disclosure. Multi-state data storage is implemented by separately reading the binary states of spatially distinct charge storage regions within the dielectric.

  To improve read and programming performance, multiple charge storage elements or memory transistors in the array are read or programmed in parallel. Thus, a “page” of memory elements is read or programmed together. In existing memory configurations, a column typically includes several interleaved pages or may constitute a single page. All memory elements of a page may be read or programmed together.

  In a flash memory system, an erase operation may take much longer than a read and programming operation. Thus, it is desirable to have a fairly sized erase block. Thus, the erase time is amortized over a large collection of memory cells.

  The nature of flash memory is based on the fact that data must be written to erased memory locations. If the data at a certain logical address from the host is to be updated, one way is to rewrite the updated data to the same physical memory location. That is, the logical / physical address mapping does not change. However, this means that the entire erase block including this physical position must be erased first and then rewritten with updated data. This update method is inefficient because the entire erase block must be erased and rewritten, and is particularly inefficient when the data to be updated occupies only a small portion of the erase block. In addition, erasure recycling of the memory block occurs at a high frequency, which is undesirable from the viewpoint of the limited durability of this type of memory device.

  Other problems with flash memory systems are related to system control and directory data. Data is generated and accessed during various memory operations. Thus, efficient handling and quick access directly affect performance. Since flash memory is intended for storage devices and is non-volatile, it is desirable to retain this type of data in flash memory. However, data cannot be accessed directly by an intervening file management system between the controller and flash memory. Also, system control and directory data tend to be active and fragmented and are not useful for storage in systems with large block erases. Conventionally, this type of data is set in the controller RAM and can be directly accessed by the controller. After powering on the memory device, the initialization process can scan the flash memory to compile the necessary system control and directory information to be placed in the controller RAM. This processing takes time, and the capacity of the flash memory is increasing, so that more controller RAM capacity is required.

  US Pat. No. 6,567,307 (Patent Document 13) records update data in a plurality of erase blocks that serve as a memo pad, and finally integrates valid sectors in various blocks. And a method of handling sector updates in a large erase block including rewriting the sectors after reconfiguring the sectors in a logical sequential order. In this way, the block does not need to be erased and written every few updates.

  International Patent Application No. WO 03/027828 (Patent Document 14) and International Patent Application No. WO 00/49488 (Patent Document 15) both involve dividing a logical sector address into partitions, within a large erase block. A memory system for handling updates is disclosed. A small partition logical address range is reserved for active system control data, separate from other partitions for user data. Thus, if the system control data is manipulated in its own partition, it will not interact with related user data in other partitions. Updates are at the logical sector level, and the write pointer points to the corresponding physical sector in the block to be written. The mapping information is buffered in the RAM and finally stored in the sector allocation table in the main memory. With the latest version of the logical sector, all previous versions within the existing block will be obsolete, and the existing block will be partially obsolete. Garbage collection is performed to maintain an acceptable number of partially obsolete blocks.

  Prior art systems tend to distribute update data across a number of blocks, or the update data may partially abolish a number of existing blocks. As a result, large amounts of garbage collection are often required for partially obsolete blocks, which is not efficient and results in premature memory aging. Also, there is no systematic and efficient way to handle sequential updates compared to nonsequential updates.

  Therefore, there is a general demand for large capacity and high performance non-volatile memory. In particular, there is a need to have a large capacity non-volatile memory that can perform memory operations in large blocks without the aforementioned problems.

US Pat. No. 5,070,032 US Pat. No. 5,095,344 US Pat. No. 5,315,541 US Pat. No. 5,343,063 US Pat. No. 5,661,053 US Pat. No. 5,313,421 US Pat. No. 6,222,762 US Pat. No. 5,570,315 US Pat. No. 5,903,495 US Pat. No. 6,046,935 US Pat. No. 5,768,192 US Pat. No. 6,011,725 US Pat. No. 6,567,307 International Patent Application No. WO03 / 027828 International Patent Application No. WO00 / 49488 US Published Patent Application No. 2005/0144365 US patent application titled “Adaptive Metablocks” filed on December 30, 2003 by Alan Sinclair US patent application entitled "Adaptive Deterministic Grouping of Blocks into Multi-Block Structures" filed December 30, 2003 by Carlos Gonzales et al.

"NROM: A Novel Localized Trapping, 2-Bit Nonvolatile Memory Cell", IEEE Electron Device Letter, vol. 21, no. 11, November 2000, pp. 543-545

  Non-volatile memory systems are organized into physical groups of physical memory locations. Each physical group (metablock) can be erased as a unit and can be used to store a logical group of data. The memory management system can update the logical group of data by assigning a dedicated metablock for recording the update data of the logical group. The update metablock records the update data in the order in which it was received, and there is no restriction as to whether the records are in the exact logical order as originally stored (sequential) or not (chaotic). Eventually, the update metablock is closed and cannot be recorded further. One of several processes will occur, but in the end will result in a full sequence of metablocks replacing the original metablock. In the chaotic case, directory data is kept in non-volatile memory in a manner that helps with frequent updates. This system supports multiple logical groups being updated in parallel.

  According to one feature of the present invention, data can be updated for each logical group. Therefore, while the logical group is being updated, the range of the distribution of logical units (and the distribution of memory units abolished by the update) is limited. This is especially true when the logical group is normally included in the physical block.

  During a logical group update, typically one or two blocks need to be allocated to buffer the update logical unit. Thus, garbage collection need only be performed over a relatively small number of blocks. Garbage collection of chaotic blocks may be performed by integration or compaction.

  The economics of the update process is even more apparent in the general process of update blocks that ensures that there are no additional blocks that need to be allocated to chaotic (non-sequential) updates compared to sequential updates. All update blocks are assigned as sequential update blocks, and any update block can be changed to a chaotic update block. In fact, changing the update block from sequential to chaotic is arbitrary.

  With efficient use of system resources, multiple logical groups can be updated in parallel. This further increases efficiency and reduces overhead.

  According to one aspect of the invention, improved in a non-volatile memory with a block management system for a system that supports up to a first predetermined maximum number of update blocks that are simultaneously open to record data. A block replacement technique is implemented. An update block is mainly a continuous update block. In the continuous update block, data is recorded in a logically continuous order, but the number of blocks is not recorded in a logically continuous order. Up to a second predetermined maximum number allowed to be a chaotic update block. Whenever a new allocation of update blocks causes the pool of update blocks to exceed the first or second predetermined maximum number, one of the existing update blocks in the pool is closed and deleted to comply with the restriction. Will be. Prior to closing the update block, the data is integrated into a continuous block. This improved approach is to avoid situations where successive updates can result in excessive chaotic block consolidation numbers. This is accomplished by separating the continuous update block and the chaotic update block into their respective replacement or unified pool. In particular, when the number of new update blocks assigned by the continuous update exceeds the first predetermined maximum number, the continuous update block that has not been used for the longest time in the pool is given priority to make a free space.

  In current systems, there are generally two types of data: user data and control data. User data is sent from the host to the memory system, typically in a logically sequential order. Continuous update blocks are allocated to optimally handle continuous write operations from the host. User data may be in a logically discontinuous order, especially if there are subsequent updates to the logical data. Chaotic update blocks are created to optimally handle data in a discontinuous order. Other sources of chaotic or discontinuous data include control data maintained by the file system or memory system, such as file and directory information generated in the process of storing user data.

  The traditional approach, which follows the practical system limit of supporting up to the maximum number of update blocks that are simultaneously open, closes the least recently used update block in the pool, whether continuous or chaotic It was something to do.

  The technique of the present application is an improvement over the conventional technique, and basically it is necessary to close the update blocks in the pool to make room for new allocations during successive write operations. In some cases, the least recently used consecutive update block in the pool is closed. This ensures that the various update blocks are effectively utilized to handle continuous write operations and random write operations. In particular, an inefficient situation is avoided in which a chaotic update block containing FAT and directory information may have to be closed by a large-scale continuous write operation by the host. Additional chaotic blocks will be created in the near future to store FAT and directory information that will be updated again at the end of this massive write operation. By creating an improved replacement policy, the separation of replacement and consolidated pools is specified, and chaotic blocks are removed during sequential writing and consolidation of blocks that can be open continuous blocks or open chaotic blocks. Manages subsequent FAT and directory updates, preventing additional overhead in consolidation.

  Generally speaking, the method of the present application is based on a set of attributes such as whether the update block stores continuous or discontinuous data, or whether it stores a predetermined type of system data. Thus, update blocks are classified. In implementing a limited number of update block pools, each class of update block will have its own rules for replacement if it exceeds the maximum number supported for that class.

  For example, continuous update blocks and discontinuous update blocks are two different classes. The replacement rules for each of these classes are the same, i.e., the least active one is replaced with a new one. Thus, if the pool of continuously updated blocks is exceeded, the least active one in the pool will be closed and deleted before the new one is introduced into the pool. The same applies to the pool of discontinuous update blocks.

  In general, each class has its own replacement rules that are independent of other classes. As an example of the replacement rule, depending on the corresponding class, the one that has not been accessed for the longest time, the one that has been accessed most recently, the one that has not been accessed most frequently, the one that has been accessed most frequently, and the like are replaced.

  Additional features and advantages of the present invention will be understood from the following description of the preferred embodiments, taken in conjunction with the accompanying drawings.

1 schematically illustrates major hardware components of a memory system suitable for implementing the present invention. FIG. 6 illustrates memory organized into physical groups of sectors (or metablocks) and managed by a controller memory manager, in accordance with a preferred embodiment of the present invention. (I)-(iii) schematically illustrates the mapping between logical groups and metablocks, according to a preferred embodiment of the present invention. Fig. 4 schematically shows a mapping between logical groups and metablocks. Fig. 5 shows an arrangement of metablocks containing structures in physical memory. Fig. 6 shows a metablock composed of linking of minimum erasure units of different planes. FIG. 6 illustrates an embodiment where one minimal erasure unit (MEU) is selected from each plane for linking to a metablock. FIG. FIG. 6 illustrates another embodiment in which more than one minimum erasure unit (MEU) is selected from each plane for linking to a metablock. 1 is a schematic block diagram of a metablock management system as implemented in a controller and flash memory. FIG. An example of a sector in a logical group that is written sequentially into a sequential update block is shown. Fig. 5 shows an example of sectors in a logical group that are written into a chaotic update block in chaotic order. FIG. 6 illustrates an example of sectors in a logical group that are written sequentially to sequential update blocks with discontinuities in logical addresses as a result of two separate host write operations. FIG. 5 is a flow diagram illustrating a process by an update block manager to update a logical group of data, according to one general embodiment of the invention. FIG. 6 is a flow diagram illustrating processing by an update block manager for updating a logical group of data, in accordance with a preferred embodiment of the present invention. FIG. 11 is a flow diagram showing in more detail the integration process for closing the chaotic update block shown in FIG. 10. FIG. 11 is a flow diagram illustrating in more detail the compacting process for closing the chaotic update block shown in FIG. 10. Fig. 4 shows all the expected states of a logical group and the expected transitions between the states under various operations. It is a table listing the expected states of a logical group. Fig. 5 shows all the expected states of the metablock and the expected transitions between the states under various actions. A metablock is a physical group corresponding to a logical group. It is a table which enumerates the expected state of a metablock. FIG. 6 is a state diagram showing the effect of various operations on the state of logical groups and physical metablocks. FIG. 6 is a state diagram showing the effect of various operations on the state of logical groups and physical metablocks. FIG. 6 is a state diagram showing the effect of various operations on the state of logical groups and physical metablocks. FIG. 6 is a state diagram showing the effect of various operations on the state of logical groups and physical metablocks. FIG. 6 is a state diagram showing the effect of various operations on the state of logical groups and physical metablocks. FIG. 6 is a state diagram showing the effect of various operations on the state of logical groups and physical metablocks. FIG. 6 is a state diagram showing the effect of various operations on the state of logical groups and physical metablocks. FIG. 6 is a state diagram showing the effect of various operations on the state of logical groups and physical metablocks. FIG. 6 is a state diagram showing the effect of various operations on the state of logical groups and physical metablocks. FIG. 6 is a state diagram showing the influence of various operations on the state of logical groups and physical metablocks. Fig. 3 shows a preferred embodiment of the structure of an allocation block list (ABL) for tracking the status of open and closed update blocks and erase blocks for allocation. Fig. 4 shows a data field of a chaotic block index (CBI) sector. An example is shown in which a chaotic block index (CBI) sector is recorded in a dedicated metablock. It is a flowchart which shows the access with respect to the data of the logical sector of the predetermined | prescribed logical group which is receiving chaotic update. FIG. 7 is a flow diagram illustrating access to data in logical sectors of a given logical group undergoing chaotic updates, according to an alternative embodiment in which the logical group is divided into subgroups. FIG. 4 illustrates an example of a chaotic block indexing (CBI) sector and its function for an embodiment where each logical group is divided into multiple subgroups. The data field of a group address table (GAT) sector is shown. An example in which a group address table (GAT) sector is recorded in a GAT block is shown. FIG. 5 is a schematic block diagram illustrating the distribution and flow of control and directory information for use and recycling of erased blocks. It is a flowchart which shows the process of logical / physical address conversion. Fig. 4 illustrates a hierarchy of operations performed on a control data structure during a memory management operation. 2 schematically shows two typical examples of two predetermined restrictions on the number of update blocks for a block management system. A typical example of a combination of two regulations optimized for various memory devices is shown. FIG. 23 schematically illustrates an update pool having a “5-2” configuration as described in FIG. 22. Fig. 6 schematically shows closing the least active update block to make room for a new update block, according to the conventional approach. Fig. 4 schematically shows the introduction of a newly allocated update block into the pool after an update block that has been closed to make room is deleted. FIG. 23 schematically illustrates an update pool having a “5-2” configuration as described in FIG. 22. Fig. 6 schematically shows closing the least active update block to make room for a new update block, according to the conventional approach. Fig. 4 schematically shows the introduction of a newly allocated update block into the pool after an update block that has been closed to make room is deleted. The technique shown previously in step 410 of FIG. 10 and FIGS. 23B and 24B, in which the least recently accessed update block is closed whenever a new allocation exceeds a predetermined limit. Indicates. The method shown in step 370 of FIG. 10, wherein a chaotic (discontinuous) update block that has not been accessed for the longest time is closed whenever the number of chaotic update blocks exceeds a predetermined limit. Indicates. FIG. 23 schematically illustrates an update pool having a “5-2” configuration as described in FIG. 22. FIG. 6 schematically illustrates closing one of the update blocks in the pool to make room for a new update block, according to the improved approach of the present application. Fig. 4 schematically shows the introduction of a newly allocated update block into the pool after an update block that has been closed to make room is deleted. FIG. 23 schematically illustrates an update pool having a “5-2” configuration as described in FIG. 22. FIG. 6 schematically illustrates closing one of the update blocks in the pool to make room for a new update block, according to the improved approach of the present application. Fig. 4 schematically shows the introduction of a new chaotic update block into the pool after other chaotic update blocks have been closed and deleted to make room. 6 is a flowchart illustrating the improved technique of the present application for managing a limited set of update blocks during a continuous update, according to a first embodiment. 6 is a flowchart illustrating the improved technique of the present application for managing a limited set of update blocks having two predetermined limits, according to a second embodiment. FIG. 6 is a flowchart illustrating the improved technique of the present application for managing a limited set of update blocks with class-based replacement rules.

  1-20 illustrate examples of memory systems with block management in which various aspects of the present application may be implemented. A similar memory system is described in US Published Patent Application No. 2005/0144365 (Non-Volatile Memory and Method with Control Data Management) by Gorobets et al.

  FIG. 1 schematically illustrates the major hardware components of a memory system suitable for implementing the present invention. The memory system 20 typically operates with the host 10 through a host interface. The memory system typically takes the form of a memory card or is an embedded memory system. The memory system 20 includes a memory 200 whose operation is controlled by the controller 100. Memory 200 consists of one or more arrays of non-volatile memory cells distributed across one or more integrated circuit chips. The controller 100 includes an interface 110, a processor 120, an optional coprocessor 121, a ROM 122 (read only memory), a RAM 130 (random access memory), and an optional programmable non-volatile memory 124. The interface 110 interfaces certain components from the controller to the host and other components with the memory 200. Firmware stored in non-volatile ROM 122 and / or optional non-volatile memory 124 provides codes to processor 120 to perform the functions of controller 100. The error correction code may be processed by processor 120 or optional coprocessor 121. In an alternative embodiment, controller 100 is implemented by a state machine (not shown). In yet other embodiments, the controller 100 is implemented within a host.

Logical and Physical Block Structure FIG. 2 shows memory organized into physical groups of sectors (or metablocks) and managed by the controller's memory manager, according to a preferred embodiment of the present invention. The memory 200 is organized into metablocks, each metablock having a physical sector S ₀ ,. . . , S _N-1 .

  The host 10 accesses the memory 200 when executing an application under a file system or an operating system. Typically, the host system addresses data in units of logical sectors, for example, each sector may contain 512 bytes of data. The host normally reads or writes data from / to the memory system in units of logical clusters, and each cluster includes one or more logical sectors. Some host systems may have an optional host-side memory manager to perform lower level memory management on the host side. In many cases, during a read or write operation, the host 10 substantially issues a command to the memory system 20 to read or write a segment containing a string of logical sectors of data with consecutive addresses. .

  A memory-side memory manager is implemented in the controller 100 of the memory system 20 to manage the storage and retrieval of host logical sector data within the metablock of the flash memory 200. In the preferred embodiment, the memory manager includes a number of software modules for managing metablock erase, read, and write operations. The memory manager also holds system control and directory data related to operations between the flash memory 200 and the controller RAM 130.

3A (i)-(iii) schematically illustrate the mapping between logical groups and metablocks, according to a preferred embodiment of the present invention. The metablock of the physical memory has N physical sectors for storing N logical sectors of logical group data. FIG. 3A (i) shows data from logical group LG _i , where logical sectors are in consecutive logical order 0, 1,. . . , N−1. FIG. 3A (ii) shows the same data stored in metablocks in the same logical order. When stored in this way, metablocks are said to be “sequential”. In general, a metablock may have data stored in a different order, in which case the metablock is said to be “non-sequential” or “chaotic”.

  There may be an offset between the lowest address of the logical group and the lowest address of the metablock to which it is mapped. In this case, the logical sector address is looped back as a loop from the end of the logical group in the metablock to the beginning. For example, in FIG. 3A (iii), the metablock stores such that its first position begins with data in logical sector k. When the final logical sector N-1 is reached, the process returns to the sector 0. Finally, data related to the logical sector k-1 is stored in the final physical sector. In the preferred embodiment, a page tag is used to identify any offset, such as identifying the first logical sector address of the data stored in the first physical sector of the metablock. Two blocks are considered to store their logical sectors in the same order when only the page tag is different.

  FIG. 3B schematically shows the mapping between logical groups and metablocks. Each logical group is mapped to a unique metablock, except for a small number of logical groups whose data is currently being updated. After the logical group is updated, it may be mapped to another metablock. The mapping information is maintained in a set of logical / physical directories, which will be described in detail later.

  Other types of logical groups for metablock mapping are also expected. For example, variable-size metablocks are disclosed in a co-pending US patent application (patent document 17) entitled “Adaptive Metablocks” filed by Alan Sinclair on the same day as this application. The entire disclosure of the co-pending application is incorporated herein by reference.

  One feature of the present invention is that the system operates in a single logical partition, and groups of logical sectors across the logical address range of the memory system are treated identically. For example, sectors containing system data and sectors containing user data can be distributed anywhere in the logical address space.

  Unlike prior art systems, system sectors (ie, sectors, directories associated with file allocation tables) to localize to logical address space sectors that are likely to contain data with frequent and small size updates , Or sub-directories). Instead, this approach of updating a logical group of sectors effectively handles the access pattern typical for system sectors and the access pattern typical for file data.

  FIG. 4 shows an arrangement of metablocks including structures in physical memory. The flash memory comprises a block of memory cells that can be erased together as a unit. Such an erase block is a minimum unit of erase of a flash memory or a minimum erase unit (MEU) of a memory. The minimum erase unit is a hardware design parameter of the memory, but depending on the memory system that supports erasure of multiple MEUs, a “super MEU” comprising one or more MEUs can be configured. For flash EEPROM, the MEU may comprise one sector, but multiple sectors are preferred. In the example shown in the figure, it has M sectors. In the preferred embodiment, each sector can store 512 bytes of data and has a user data portion and a header portion for storing system or overhead data. If a metablock is composed of P MEUs, each MEU contains M sectors, and each metablock will have N = P * M sectors.

  A metablock represents a group of memory locations, such as sectors that can be erased together, at the system level. The physical address space of the flash memory is treated as a set of metablocks with the metablock as a minimum unit for erasure. In this specification, the terms “metablock” and “block” are used as synonyms to define a minimum unit of erase at the system level for media management, and “minimum erase unit” or MEU is Used to indicate the smallest unit of erasure.

In order to maximize the link programming speed and erase speed of the minimum erase unit (MEU) to form the metablock , information on multiple pages in multiple MEUs is programmed in parallel, and multiple By making sure that the MEUs are erased in parallel, parallel processing is utilized as much as possible.

  In flash memory, a page is a collection of memory cells that can be programmed together in a single operation. A page may comprise one or more sectors. Also, the memory array may be divided into one or more planes, and only one MEU in one plane may be programmed or erased at a time. Finally, the plane may be distributed across one or more memory chips.

  In flash memory, the MEU may comprise one or more pages. The MEUs in the flash memory chip may be organized in a plane. Since one MEU from each plane may be programmed or erased in parallel, it is a good idea to form multiple MEU metablocks by selecting one MEU from each plane (see FIG. 5B below). ).

FIG. 5A shows a metablock composed of linking of the smallest erasure units of different planes. MB0, MB1,. . . Each metablock is composed of MEUs from different planes of the memory system, and the different planes may be distributed across one or more chips. The metablock link manager 170 shown in FIG. 2 manages MEU linking for each metablock. Each metablock is configured during the initial formatting process and retains its constituent MEUs for the lifetime of the system until one of the MEUs fails.
FIG. 5B shows an embodiment where one minimal erasure unit (MEU) is selected from each plane for linking to metablocks.

  FIG. 5C shows another embodiment in which more than one minimum erasure unit (MEU) is selected from each plane for linking to metablocks. In another embodiment, more than one MEU may be selected from each plane to form a super MEU. For example, a super MEU may be formed from two MEUs. In this case, more than one pass may be used for read or write operations.

  Linking or relinking MEUs to metablocks is a co-pending US patent application entitled “Adaptive Deterministic Grouping of Blocks into Multi-Block Structures” filed by Carlos Gonzales et al. (Patent Document 18). The entire disclosure of the co-pending application is incorporated herein by reference.

Metablock Management FIG. 6 is a schematic block diagram of a metablock management system as implemented in the controller and flash memory. The metablock management system includes various functional modules implemented in the controller 100, and holds various control data (including directory data) in tables and lists hierarchically distributed in the flash memory 200 and the controller RAM 130. . The functional modules implemented in the controller 100 include an interface module 110, a logical / physical address translation module 140, an update block manager module 150, an erase block manager module 160, and a metablock link manager module 170.

  Interface 110 allows the metablock management system to interface with the host system. The logical / physical address translation module 140 maps logical addresses from the host to physical memory locations. The update block manager module 150 manages data update operations in memory for a given logical group of data. The erase block manager module 160 manages metablock erase operations and metablock allocation for storing new information. The metablock link manager module 170 manages the linking of the subgroups of the smallest erasable block of the sector to form a predetermined metablock. Detailed descriptions of these modules are given in the respective columns.

  During operation, the metablock management system generates and operates with control data such as address, control and status information. Since most of the control data is often small and frequently changing data, it cannot be stored and held easily and efficiently in a flash memory having a large block structure. More efficient updates and accesses are performed by using a hierarchical distributed approach where more static control data is stored in non-volatile flash memory and a smaller amount of changing control data is located in the controller RAM. In the event of a power failure or failure, this approach allows the control data in the volatile controller RAM to be quickly reconstructed by scanning a small set of control data in the non-volatile memory. This is possible because the present invention limits the number of blocks associated with the expected operation of a given logical group of data. In addition, some of the control data that needs to be persisted is stored in a nonvolatile metablock that can be updated sector by sector, and each update that results in a new sector is recorded in place of the previous update. . A sector indexing technique is used for control data to track updates for each sector in the metablock.

  The nonvolatile flash memory 200 stores a large amount of control data that is relatively static. This includes a group address table (GAT) 210, a chaotic block index (CBI) 220, an erased block list (EBL) 230, and a MAP 240. GAT 210 tracks the mapping between a logical group of sectors and its corresponding metablock. The mapping is unchanged except for those that receive updates. CBI 220 tracks the mapping of logical non-sequential sectors that are being updated. The EBL 230 keeps track of the pool of erased metablocks. The MAP 240 is a bitmap indicating the erased state of all metablocks in the flash memory.

  Volatile controller RAM 130 stores a small portion of control data that is frequently changed and accessed. This includes an allocated block list (ABL) 134 and a cleared block list (CBL) 136. ABL 134 tracks metablock assignments to record update data, and CBL 136 tracks deallocated and erased metablocks. In the preferred embodiment, RAM 130 serves as a cache for control data stored in flash memory 200.

Update Block Manager (shown in FIG. 2) The update block manager 150 handles logical group updates. According to one aspect of the invention, a dedicated update metablock is assigned to each logical group of sectors undergoing update in order to record update data. In the preferred embodiment, any segment of one or more sectors of the logical group will be recorded in the update block. Update blocks are managed to receive update data in either a sequential order or a non-sequential (also known as chaotic) order. In a chaotic update block, sector data can be updated in any order within a logical group, and there can be any repetition of individual sectors. In particular, a sequential update block can be a chaotic update block without the need to transfer any data sectors. Chaotic data updates do not require a predetermined allocation of blocks. Non-sequential writing at any logical address is automatically handled. Thus, unlike prior art systems, there is no special processing whether the various update segments of a logical group are in logical sequential or non-sequential order. A generic update block will simply be used to store the various segments in the order requested by the host. For example, even when the host system data or system control data is apt to be updated chaotically, it is not necessary to treat the logical address space area corresponding to the host system data separately from the area with the host user data.

  The data of a complete logical group of sectors is preferably stored in a logical sequential order within one metablock. Thus, the index for the stored logical sector is defined in advance. If a metablock stores all sectors of a given logical group in a given order, this is said to be “intact”. With respect to the update block, when the update data is finally filled in a logical sequential order, the update block becomes an updated unchanged metablock that easily replaces the original metablock. On the other hand, if the update block fills the update data in a different logical order than the unchanged block, the update block is a non-sequential or chaotic update block, and a segment that is out of order is an unchanged block. Must be further processed so that the update data of the logical group is finally stored in the same order. In the preferred case, this segment is a logical sequential order within one metablock. Further processing involves integrating the updated sectors in the update block with unchanged sectors in the original block into further update metablocks. The integrated update block is then in logical sequential order and can be used to replace the original block. Under some predetermined conditions, there is one or more compaction processes prior to the integration process. The compacting process simply re-records the sectors of the chaotic update block into the replacing chaotic update block and does not delete duplicate logical sectors that have been obsoleted by previous updates of the same logical sector.

  With the update method, a plurality of update threads can be executed in parallel up to a predetermined maximum. Each thread is a logical group that is being updated using a dedicated update metablock.

When data belonging to a logical group with sequential data update is first updated, a metablock is allocated exclusively as an update block for the update data of the logical group. An update block is allocated when a command is received from the host and writes a segment of one or more sectors of a logical group in which an existing metablock stores all its sectors unchanged. For the first host write operation, the first segment of data is recorded in the update block. Since each host write is a segment of one or more sectors with sequential logical addresses, the initial update will always be sequential in nature. In subsequent host writes, update segments within the same logical group are recorded in the update block in the order received from the host. Blocks continue to be managed as sequential update blocks, while sectors updated by the host in the associated logical group remain logically sequential. All sectors updated in this logical group are written to this sequential update block until this block is either closed or converted to a chaotic update block.

  FIG. 7A shows an example of a sector in a logical group that is written sequentially into a sequential update block as a result of two separate host write operations, with the corresponding sector in the original block for this logical group being obsolete. In host write operation # 1, data in logical sectors LS5 to LS8 is being updated. The data updated as LS5 'to LS8' is recorded in a newly assigned dedicated update block.

  For convenience, the first sector to be updated in the logical group is recorded in a dedicated update block starting from the first physical sector position. In general, the first logical sector to be updated is not necessarily the logical first sector of the group, so there may be an offset between the beginning of the logical group and the beginning of the update block. . This offset is known as the page tag, as previously described in connection with FIG. 3A. Subsequent sectors are updated in a logical sequential order. When the last sector of the logical group is written, the group address wraps around and the write sequence continues with the first sector of the group.

  In host write operation # 2, the segment of data in logical sectors LS9 to LS12 is being updated. The data updated as LS9 'to LS12' is recorded at a position in the dedicated update block that directly follows the location where the last writing has been completed. Two host writes can be understood as if the update data was recorded in the update block in a logical sequential order, ie LS5'-LS12 '. Update blocks are considered sequential update blocks because they are filled in a logical sequential order. The corresponding data in the original block is abolished by the update data recorded in the update block.

Chaotic data update Chaotic update block management is started for an existing sequential update block when any sector updated by the host in the associated logical group is logically non-sequential. A chaotic update block takes the form of a data update block in which logical sectors in the associated logical group may be updated in any order and with any amount of repetition. This is created by conversion from the sequential update block if the sector written by the host is logically non-sequential to the previously written sector in the logical group being updated. All subsequent updated sectors in this logical group are written to the next available sector location in the chaotic update block, whatever the logical sector address in the group.

  FIG. 7B shows an example of a sector in a logical group that is written in chaotic order to a chaotic update block as a result of five separate host write operations, and a replaced sector in the original block for this logical group; The duplicate sector in the chaotic update block is abolished. In host write operation # 1, logical sectors LS10 to LS11 of a predetermined logical group stored in the original metablock are updated. The updated logical sectors LS10 'to LS11' are stored in the newly allocated update block. In this regard, the update block is sequential. In the host write operation # 2, the logical sectors LS5 to LS6 are updated to LS5 'to LS6' and recorded at positions immediately following the last write in the update block. As a result, the update block is converted from sequential to chaotic. In the host write operation # 3, the logical sector LS10 is being updated again, and is recorded as LS10 '' at the next position of the update block. At this point, the LS 10 ″ in the update block replaces the LS 10 ′ in the previous record that replaces the LS 10 in the original block. In host write operation # 4, the data in the logical sector LS10 is updated again and recorded as LS10 "" at the next position of the update block. Therefore, the LS 10 ″ ″ is the latest and only valid data at present regarding the logical sector LS 10. In host write operation # 5, the data in the logical sector LS30 is being updated and is recorded as LS30 'in the update block. Thus, this example shows that sectors in a logical group can be written to chaotic update blocks in any order and any repetition.

Forced Sequential Update FIG. 8 shows an example of sectors in a logical group that are written sequentially to sequential update blocks with discontinuities in logical addresses as a result of two separate host write operations. In host write # 1, update data in logical sectors LS5 to LS8 are recorded in dedicated update blocks as LS5 ′ to LS8 ′. In host write # 2, the update data in logical sectors LS14 to LS16 are recorded as LS14 ′ to LS16 ′ in the update block following the last write. However, there is an address jump between LS8 and LS14, and host write # 2 will typically make the update block non-sequential. Since address jumps are not important, one option is to first perform the padding operation (# 2A) by copying the intervening sector data from the original block to the update block before executing host write # 2. It is. In this way, the sequential nature of the update block is maintained.

FIG. 9 is a flow diagram illustrating processing by an update block manager to update a logical group of data, according to a general embodiment of the invention. The update process includes the following steps.
Step 260: The memory is organized into blocks, each block being divided into erasable memory units, each memory unit for storing a logical unit of data.
Step 262: The data is organized into logical groups, and each logical group is divided into logical units.
Step 264: In the standard case, all logical units of the logical group are stored in the memory units of the original block according to a first predetermined order, preferably a logical sequential order. In this way, an index for accessing each logical unit in the block is known.
Step 270: For a given logical group of data (eg, LG _x ), a request is made to update a logical unit in LG _x (an example is a logical unit update. , A segment of one or more consecutive logical units in LG _x ).
Step 272: The requested update logical unit will be stored in a second block dedicated to recording LG _x updates. The recording order is the second order and typically follows the order in which updates were requested. One feature of the present invention allows an update block to be generally set initially to record data in a logical sequential or chaotic order. Depending on the second order, the second block may be sequential or chaotic.
Step 274: As the process loops back to step 270, the second block continues to request that the logical unit be recorded. Once the predetermined condition for closure is materialized, the second block is closed and no further updates are received. In this case, the process proceeds to 276.
Step 276: A determination is made as to whether the closed second block has recorded its updated logical units in the same order as the original block. As described with respect to FIG. 3A, when recording logical units that differ by the page tag, the two blocks are considered to be in the same order. If the two blocks are in the same order, processing proceeds to step 280, otherwise some garbage collection needs to be done at step 290.
Step 280: Since the second block is in the same order as the first block, the second block is used to replace the first block that is the original block. The update process then ends at step 299.
Step 290: The latest version of each logical unit of a given logical group is collected from the second block (update block) and the first block (original block). The integrated logical units of a given logical group are then written to the third block in the same order as the first block.
Step 292: Since the third block (integrated block) is in the same order as the first block, the third block is used to replace the first block which is the original block. The update process then ends at step 299.
Step 299: Once the unchanged update block is created by the closure process, this becomes the new standard block for a given logical group. The update thread for the logical group is terminated.

FIG. 10 is a flow diagram illustrating processing by an update block manager to update a logical group of data, according to a preferred embodiment of the present invention. The update process includes the following steps.
Step 310: For a given logical group of data (eg, LG _x ), a request is made to update a logical sector in LG _x (an example is sector update. A segment of one or more consecutive logical sectors in LG _x ).
Step 312: If LG _x does not yet have a dedicated update block, go to step 410 to start a new update thread for the logical group. This will be accomplished by allocating dedicated update blocks to record logical group update data. If there is already an update block that has been released, the process proceeds to step 314, and recording of the update sector for the update block is started.
Step 314: If the current update block is already chaotic (ie non-sequential), proceed to step 510 and record the requested update sector in the chaotic update block. If the current update block is sequential, the process proceeds to step 316 to process the update block sequentially.
Step 316: One feature of the present invention allows the update block to be generally initially set to record data in a logical sequential or chaotic order. However, since logical groups eventually store their data in metablocks in a logical sequential order, it is desirable to keep update blocks as sequential as possible. That way, if the update block is closed and no further updates are possible, garbage collection is not required and therefore less processing is required.

A determination is made as to whether the requested update follows the current sequential order of the update blocks. If the updates follow sequentially, proceed to step 510 where the sequential updates are made and the update blocks remain sequential. On the other hand, if the updates do not follow sequentially (chaotic updates), then if no other action is taken, the sequential update blocks are converted to chaotic.
In one embodiment, no further action is taken to protect the situation, and processing proceeds directly to step 370 where updates are allowed to make the update block chaotic.

Optional Forced Sequential Processing In another embodiment, a forced sequential processing step 320 is optionally performed to preserve as many sequential update blocks as possible in terms of pending chaotic updates. There are two situations, both of which copy the missing sectors from the original block and maintain the sequential order of the logical sectors recorded on the update block. The first situation is that the update causes a short address jump. The second situation is to close the update blocks early to keep the update blocks sequentially. The forced sequential processing step 320 includes the following sub-steps.
Step 330: If the update results in a logical address jump greater than the predetermined amount C _B , the process proceeds to the forced sequential update process of step 350, otherwise the process proceeds to step 340 to force Consider whether it is eligible for sequential closure.
Step 340: If the number of unfilled physical sectors exceeds a predetermined configuration parameter C _C where half of the size of the update block is a typical value, the update block is relatively unused and will be closed early. There is no. Processing proceeds to step 370, where the update block becomes chaotic. On the other hand, if the update block is almost filled, it is considered that it is already fully used, so the process proceeds to step 360, where a forced sequential closure is performed.
Step 350: Forced sequential update allows the current sequential update block to remain sequential as long as the address jump does not exceed a predetermined amount C _B. Basically, the sector from the related original block of the update block is copied to fill the gap due to the address jump. Thus, the sequential update block will be filled with data in the intervening address before proceeding to step 510 to sequentially record the current update.
Step 360: Forced sequential closure allows the current sequential update block to be closed if it is already mostly filled by pending chaotic updates rather than converting it into chaotic ones. Chaotic or non-sequential updates are defined as involving forward address transitions, not subject to the address jump exceptions, backward address transitions, or address repetitions described above. To prevent sequential update blocks from being converted by chaotic updates, the unwritten sector position of the update block is filled by copying sectors from the associated original partially obsolete block of the update block Is done. The original block is then completely abolished and can be erased. Since the current update block now has a full set of logical sectors, it is closed as an unchanged metablock that replaces the original metablock. The process proceeds to step 430 and assigns a new update block to that position in order to accept the pending sector update record initially requested in step 310.

Convert to Chaotic Update Block Step 370: If pending updates are not in sequential order and, optionally, forced sequential conditions are not met, pending processing with non-sequential addresses when processing proceeds to step 510 In order for the update sector to be recorded in the update block, the sequential update block is allowed to be converted into a chaotic one. When the maximum number of chaotic update blocks exists, it is necessary to close the least recently accessed chaotic update block before the conversion proceeds. Therefore, the maximum number of chaotic update blocks should not be exceeded. The identification of the least recently accessed chaotic update block is the same as the general case described in step 420, but is limited to only chaotic update blocks. Closing the chaotic update block at this time is accomplished by integration as described in step 550.

Assign new update block subject to system constraints Step 410: The process of assigning an erase metablock as an update block begins with determining whether a predetermined system constraint is exceeded. Because resources are finite, memory management systems typically allow a predetermined maximum number U _MAX of update blocks to exist in parallel. This limitation is the sum of sequential update blocks and chaotic update blocks, and is a design parameter. In a preferred embodiment, this limit is, for example, a maximum of 8 update blocks. Also, due to the higher demand for system resources, there may be a corresponding predetermined limit on the maximum number of chaotic update blocks that are released in parallel (eg 4).
Thus, if U _MAX update blocks have already been allocated, the next allocation request can be satisfied only after one of the existing allocations is closed. Processing proceeds to step 420. If the number of open update blocks is below C _A, the process proceeds directly to step 430.

Step 420: if it exceeds the maximum number of update blocks C _A is update block that has not been recently most accessible is closed, garbage collection is performed. The least recently accessed update block is identified as the update block associated with the least recently accessed logical block. In order to determine the least recently accessed block, access includes writing logical sectors and optionally reading. The list of released update blocks is held in the order of access, and no access order is assumed at the time of initialization. Closing the update block follows a similar process as described in connection with steps 360 and 530 when the update block is sequential and step 540 when the update block is chaotic. Closing allows room to allocate a new update block in step 430.
Step 430: allocation request is satisfied by assigning as an update block dedicated to the new metablock in the given logical group LG _x. Thereafter, the process proceeds to step 510.

Record update data to update block 510: The requested update sector is recorded on the next available physical location of the update block. Thereafter, the process proceeds to step 520 where it is determined whether the time to close the update block is ripe.

Update block closure step 520: If there is still space in the update block to accept further updates, go to step 570. Otherwise, go to step 522 and close the update block. There are two implementations that fill the update block when the current requested write is to write more logical sectors than the block has. In the first implementation, the write request is divided into two parts, and the first part writes up to the last physical sector of the block. Thereafter, the block is closed and the second part of the write will be treated as the next requested write. In the other implementation, the requested write is deferred while the block is closed with the remaining sectors padded. The requested write will be treated as the next requested write.
Step 522: If the update block is sequential, proceed to Step 530 and close sequentially. If the update block is chaotic, the process proceeds to step 540 and becomes a chaotic closure.

Close sequential update block step 530: Since the update block is sequential and full, there is no change in the logical group stored there. The metablock is unchanged and replaces the original one. At this time, the original block may be completely abolished and deleted. Thereafter, the process proceeds to step 570, and the update thread for the predetermined logical group ends.

Chaotic update block closure step 540: Since the update block is filled non-sequentially and may contain multiple updates of several logical sectors, garbage collection is performed to rescue the internal valid data. Chaotic update blocks will either be compacted or integrated. Which process is to be performed is determined in step 542.
Step 542: Whether compactification or integration is performed depends on the overlapping state of update blocks. If a logical sector has been updated multiple times, its logical addresses are very overlapping. There will be multiple versions of the same logical sector recorded in the update block, and only the last recorded version is valid for this logical sector. In an update block that includes logical sectors having multiple versions, the number of distinct logical sectors will be much less than the number of logical groups.

In the preferred embodiment, the closure process is integrated in step 550 if the number of distinct logical sectors in the update block exceeds a predetermined design parameter CD, which is a typical value of half the logical group size. Otherwise, the process compacts at step 560.
Step 550: If the chaotic update block is to be integrated, the original block and the update block will be replaced with a new standard metablock containing the integrated data. After integration, the update thread ends at step 570.
Step 560: If the chaotic update block is to be compacted, it will be replaced with a new update block holding the compacted data. After compacting, processing of the compacted update block ends at step 570. Alternatively, compaction can be delayed until the update block is written again, thereby eliminating the possibility of compaction following integration without any intervening updates. The new update block will then be used in making further updates to a given logical block when the next request for update in LG _x occurs in step 502.
Step 570: If the closed process creates an unchanged update block, it becomes the new standard block for the given logical group. This logical group update thread will be terminated. If the closure process creates a new update block that replaces the existing one, this new update block shall be used to record the next update required for a given logical group. become. If the update block is not closed, processing continues when the next request for an update in LG _x occurs at step 310.

  As can be seen from the processing described above, when a chaotic update block is closed, the update data recorded therein is further processed. In particular, garbage collection is performed on the valid data by a process of compacting into another chaotic block or a process of integrating the related original block to form a new standard sequential block.

FIG. 11A is a flow diagram illustrating in more detail the integration process for closing the chaotic update block shown in FIG. Chaotic update block integration is one of two possible processes that occur when an update block is closed, for example, when the update block is full with the last physical sector location written. It is one of. Integration is chosen when the number of distinct logical sectors written in the block exceeds a predetermined design parameter C _D. The integration processing step 550 shown in FIG. 10 includes the following sub-steps.
Step 551: If a chaotic update block is closed, a new metablock will be assigned to replace it.
Step 552: Collect the latest version of each logical sector in the chaotic update block and its associated original block, ignoring all obsolete sectors.
Step 554: Record the collected valid sectors in a new metablock in logical sequential order to form an unchanged block, ie a block in which all logical sectors of a logical group are recorded in sequential order. To do.
Step 556: Replace the original block with a new unchanged block.
Step 558: Erase the closed update block and the original block.

FIG. 11B is a flow diagram illustrating in more detail the compaction process for closing the chaotic update block shown in FIG. Compaction is chosen when the number of distinct logical sectors in the block is below a predetermined design parameter C _D. The compacting process step 560 shown in FIG. 10 includes the following sub-steps.
Step 561: While the chaotic update block is being compacted, a new metablock is assigned to replace it.
Step 562: Collect the latest version of each logical sector in the existing chaotic update block to be compacted.
Step 564: Record the collected sectors in a new update block to form a new update block with compacted sectors.
Step 566: Replace existing update block with new update block with compacted sectors.
Step 568: Erase the closed update block.

Logic and metablock state diagram 12A shows all the expected states of a logical group and the expected transitions between the states under various operations.
FIG. 12B is a table listing the expected states of the logical group. The state of the logical group is defined as follows.
1. No change: All logical sectors in a logical group are written in one metablock, using page tag wrapping, etc., in a logical sequential order.
2. Unwritten: No logical sector in the logical group has been written. The logical group is marked as unwritten in the group address table and there is no assigned metablock. In response to host reads for all sectors in this group, a predetermined data pattern is returned.
3. Sequential update: Some sectors in a logical group are written to metablocks in a logical sequential order, using page tags etc., which correspond from the previous unchanged state of this group A logical sector is replaced.
4). Chaotic update: some sectors in a logical group are written to metablocks in a logical non-sequential order, using page tags etc., and these sectors cause this group from its previous unchanged state The corresponding logical sector is replaced. Sectors in the group may be written more than once, and the latest version will replace all previous versions.

FIG. 13A shows all the expected states of the metablock and the expected transitions between the states under various operations.
FIG. 13B is a table listing the expected states of the metablock. The metablock state is defined as follows.
1. Erased: All sectors in the metablock are erased.
2. Sequential update: In the metablock, sectors are partially written using page tags or the like in a logical sequential order. All sectors belong to the same logical group.
3. Chaotic update: In a metablock, sectors are written partially or completely in a logical non-sequential order. Any sector can be written more than once. All sectors belong to the same logical group.
4). No change: Metablocks are written full using page tags etc. in a logical sequential order.
5. Original: The metablock was previously unchanged, but at least one sector has been obsoleted by host data updates.

14A to 14J are state diagrams showing the effects of various operations on the state of the logical group and the physical metablock.
FIG. 14A is a state diagram corresponding to logical group and metablock transitions for the first write operation. The host writes one or more sectors of the logical group still unwritten to the newly allocated erased metablock in a logical sequential order. Logical groups and metablocks are sequentially updated.
FIG. 14B is a state diagram corresponding to the logical group and metablock transitions for the first no-change operation. A previously unwritten sequential update logical group becomes unchanged when all sectors are sequentially written by the host. This transition can also occur when the card fills a group by filling the remaining unwritten sectors with a predetermined data pattern. The metablock is unchanged.
FIG. 14C is a state diagram corresponding to the logical group and metablock transitions for the first chaotic operation. A previously unwritten sequential update logical group becomes chaotic when at least one sector is written non-sequentially by the host.
FIG. 14D is a state diagram corresponding to logical group and metablock transitions for the first compacting operation. All valid sectors in the previously unwritten chaotic update logical group are copied from the old block to the new chaotic metablock, and the old block is then erased.
FIG. 14E is a state diagram corresponding to the logical group and metablock transitions for the first integration operation. All valid sectors in the previously unwritten chaotic update logical group are moved from the old chaotic block and filled into the newly allocated blocks in logical sequential order. A sector not written by the host is filled with a predetermined data pattern. The old chaotic block is then erased.

FIG. 14F is a state diagram corresponding to logical group and metablock transitions for sequential write operations. The host writes one or more sectors of the unchanged logical group into the newly allocated erased block in a logical sequential order. The logical group and metablock are sequentially updated. A metablock that has not been changed before becomes an original metablock.
FIG. 14G is a state diagram corresponding to logical groups and metablock transitions for sequential fill operations. A sequential update logical group becomes unchanged when all its sectors are written sequentially by the host. This can also occur when filling a sequential update logical group with valid sectors from the original block, after which the original block is erased.
FIG. 14H is a state diagram corresponding to logical group and metablock transitions for non-sequential write operations. A sequential update logical group becomes chaotic when at least one sector is written non-sequentially by the host. Non-sequential sector writes may abolish valid sectors in either the update block or the corresponding original block.
FIG. 14I is a state diagram corresponding to logical group and metablock transitions for compacting operations. All valid sectors in the chaotic update logical group are copied from the old block to the new chaotic metablock, and the old block is then erased. The original block is not affected.
FIG. 14J is a state diagram corresponding to the logical group and metablock transition for the integration operation. All valid sectors in the chaotic update logical group are copied from the old chaotic block and the original block, and the newly allocated erase block is filled in logical sequential order. Thereafter, the old chaotic block and the original block are erased.

Update Block Tracking and Management FIG. 15 shows a preferred embodiment of the structure of an allocation block list (ABL) for tracking the status of open and closed update blocks and erase blocks for allocation. An Allocation Book List (ABL) 610 is maintained in the controller RAM 130 and can manage the allocation of erased blocks, allocated update blocks, associated blocks, and control structures, and accurate logical / physical addresses. Enable conversion. In the preferred embodiment, the ABL includes a list of erased blocks, an open update block list 614 and a closed update block list 616.

The open update block list 614 is a set of block entries in the ABL with the attributes of the open update block. The released update block list has one entry for each data update block currently released. Each entry holds the following information. LG is a logical group address to which the current update metablock is dedicated. Sequential / chaotic is a state that indicates whether an update block is filled with sequential or chaotic update data. MB is the metablock address of the update block. The page tag is the starting logical sector recorded at the first physical position of the update block. The number of sectors written indicates the number of sectors currently written to the update block. MB ₀ is the metablock address of the associated original block. Page tag ₀ is the page tag of the related original block.

The closed update block list 616 is a subset of the allocated block list (ABL). A set of block entries in an ABL with the attributes of a closed update block. The closed update block list has one entry for each closed data update block, but that entry has not been logically updated to the main physical directory. Each entry holds the following information. LG is a logical group address to which the current update block is dedicated. MB is the metablock address of the update block. The page tag is the starting logical sector recorded at the first physical position of the update block. MB ₀ is the metablock address of the associated original block.

An indexed sequential update block of chaotic blocks stores data in a logical sequential order so that any logical sector within the block can be easily located. A chaotic update block may store its logical sectors out of order and may store multiple update products of logical sectors. Additional information must be maintained to keep track of where each valid logical sector is in the chaotic update block.

  In the preferred embodiment, the chaotic block indexing data structure allows tracking and fast access of all valid sectors in the chaotic block. Chaotic block indexing manages a small area of the logical address space independently, and efficiently handles hot areas of system data and user data. The indexing data structure allows essentially indexing information to be kept in flash memory with the requirement that updates are rare so that performance is not significantly affected. On the other hand, the list of sectors currently written in the chaotic block is kept in the chaotic sector list in the controller RAM. A cache of index information from the flash memory is held in the controller RAM in order to minimize the number of flash sector accesses for address conversion. An index for each chaotic block is stored in a chaotic block index (CBI) in flash memory.

  FIG. 16A shows the data field of a chaotic block index (CBI) sector. The chaotic block index sector (CBI sector) contains an index for each sector in the logical group mapped to the chaotic update block, and identifies the location of each sector of the logical group in the chaotic update block or its associated original block. Stipulate. The CBI sector includes a chaotic block index field for tracking a valid sector in a chaotic block, a chaotic block information field for tracking an address parameter for the chaotic block, and a metablock (CBI block for storing the CBI sector). ) Includes a sector index field for tracking valid CBI sectors.

FIG. 16B shows an example where a chaotic block index (CBI) sector is recorded in a dedicated metablock. The dedicated metablock is referred to as CBI block 620. When the CBI sector is updated, it is written to the next available physical sector location in the CBI block 620. Therefore, multiple copies of the CBI sector exist in the CBI block, and only the last written copy is valid. For example, the CBI sector for logical group LG ₁ is updated three times and only the last written copy is valid. The position of each valid sector in the CBI block is identified by the set of indexes in the last written CBI sector in the block. In this example, the last CBI sector written in the block is the CBI sector for LG ₁₃₆ , and its index set is valid to replace all previous ones. When a CBI block eventually fills with CBI sectors, the block is compacted by rewriting all valid sectors to new block locations during a control write operation. The full block is then erased.

  The chaotic block index field in the CBI sector contains an index entry for each logical sector in the logical group or subgroup mapped to the chaotic update block. Each index entry indicates an offset within the chaotic update block where valid data for the corresponding logical sector is located. The reserved index value indicates that valid data for the logical sector does not exist in the chaotic update block, and indicates that the corresponding sector in the associated original block is valid. A cache of several chaotic block index field entries is maintained in the controller RAM.

  The chaotic block information field in the CBI sector contains one entry for each chaotic update block present in the system and records address parameter information for the block. The information in this field is only valid in the last sector written in the CBI block. This information is also present in the data structure in the RAM.

  The entry for each chaotic update block includes three address parameters. The first is the logical address (or logical group number) of the logical group associated with the chaotic update block. The second is the metablock address of the chaotic update block. The third is the offset of the physical address of the sector written last in the chaotic update block. The offset information sets the starting point for scanning the chaotic update block being initialized in order to reconstruct the data structure in RAM.

  The sector index field includes an entry for each valid CBI sector in the CBI block. Defines the offset within the CBI block where the most recently written CBI sector for each authorized chaotic update block is located. The reserved value of the offset in the index indicates that there are no allowed chaotic update blocks.

FIG. 16C is a flow diagram illustrating access to data in logical sectors of a given logical group undergoing chaotic updates. During the update process, the update data records the update data in a chaotic update block, and the unchanged data remains in the original metablock associated with the logical group. The process of accessing a logical sector of a logical group under chaotic update is as follows.
Step 650: Start position determination of a predetermined logical sector of a predetermined logical group.
Step 652: Locate the last written CBI sector in the CBI block.
Step 654: Locate the chaotic update block or original block associated with the given logical group by searching the chaotic block information field of the last written CBI sector. This step can be done at any time before step 662.
Step 658: If the last written CBI sector is addressed to a predetermined logical group, the CBI sector is located. Proceed to step 662. Otherwise, go to step 660.
Step 660: Locate the CBI sector for a given logical group by searching the sector index field of the last written CBI sector.
Step 662: Locate a given logical sector within a chaotic block or original block by searching a chaotic block index field of the located CBI sector.

FIG. 16D is a flow diagram illustrating access to data in logical sectors of a given logical group undergoing chaotic updates, according to an alternative embodiment in which the logical group is divided into subgroups. Since the capacity of the CBI sector is finite, only a predetermined maximum number of logical sectors can be tracked. If a logical group has more logical sectors than a single CBI sector can handle, the logical group is divided into a plurality of subgroups each assigned a CBI sector. In one example, each CBI sector has sufficient capacity to track a logical group of 256 sectors and up to 8 chaotic update blocks. If the logical group has a size greater than 256 sectors, there is a separate CBI sector in the logical group for each of the 256 sector subgroups. CBI sectors for up to 8 subgroups may exist in a logical group, providing support for logical groups of up to 2048 sectors in size.
In the preferred embodiment, an indirect indexing approach is taken to facilitate index management. Each entry in the sector index has direct and indirect fields.

  The direct sector index defines an offset within the CBI block where all expected CBI sectors associated with a particular chaotic update block are located. The information in this field is only valid in the last written CBI sector associated with this particular chaotic update block. The reserved value of the offset in the index indicates that no CBI sector exists. This is because the corresponding logical subgroup associated with the chaotic update block does not exist or has not been updated since the update block was assigned.

  The indirect sector index defines the offset within the CBI block where the most recently written CBI sector associated with each granted chaotic update block is located. The reserved value of the offset in the index indicates that there are no permitted update blocks.

FIG. 16D shows the process of accessing logical sectors of a logical group under chaotic update as follows.
Step 670: Divide each logical group into a plurality of subgroups and assign CBI sectors to each subgroup.
Step 680: Start positioning of a predetermined logical sector in a predetermined subgroup of a predetermined logical group.
Step 682: Locate the last written CBI sector in the CBI block.
Step 684: Locate the chaotic update block or original block associated with the given subgroup by searching the chaotic block information field of the last written CBI sector. This step can be done anytime before step 696.
Step 686: If the last written CBI sector is addressed to a predetermined logical group, the process proceeds to step 691. Otherwise, go to step 690.
Step 690: Locate last write of multiple CBI sectors for a given logical group by searching the indirect sector index field of the last write CBI sector.
Step 691: At least a CBI sector associated with one of the subgroups for a given logical group has been located. Continue.
Step 692: If the located CBI sector is destined for a given subgroup, the CBI sector for this given subgroup is located. Proceed to step 696. Otherwise, go to step 694.
Step 694: Locate the CBI sector for a given subgroup by searching the direct sector field of the currently located CBI sector.
Step 696: Locate a given logical sector within a chaotic block or original block by searching the chaotic block index field of the CBI sector for the given subgroup.

  FIG. 16E shows an example of a chaotic block indexing (CBI) sector and its function for an embodiment where each logical group is divided into multiple subgroups. The logical group 700 stores the unchanged data in the original metablock 702. Thereafter, the logical group receives an update with the assignment of a dedicated chaotic update block 704. In this example, logical group 700 is divided into subgroups such as subgroups A, B, C, and D, with each subgroup having 256 sectors.

  In order to locate the i th sector in subgroup B, the last written CBI sector in CBI block 620 is located first. The chaotic block information field of the last written CBI sector provides an address for locating the chaotic update block 704 for a given logical group. At the same time, this also provides the location of the last sector written in the chaotic block. This information is useful during scanning and reconstruction.

  If it is found that the last written CBI sector is one of the four CBI sectors of a given logical group, then it is determined whether this sector is indeed a CBI sector for a given subgroup B containing the i th logical sector. Further confirmation will be made. If so, the chaotic block index of the CBI sector will point to the metablock location that stores the data for the i-th logical sector. The sector location can be either a chaotic update block 704 or an original block 702.

  If it is found that the last written CBI sector is one of the four CBI sectors of a given logical group but is not exactly the CBI sector for subgroup B, its direct sector index is searched to Locate the CBI sector for group B. Once this exact CBI sector is located, its chaotic block index is searched to locate the i th logical sector in the chaotic update block 704 and the original block 702.

  If it is found that the last written CBI sector is not one of the four CBI sectors of a given logical group, its indirect sector index is searched to locate one of the four. In the example shown in FIG. 16E, the CBI sector for subgroup C is located. This CBI sector for subgroup C then searches its direct sector index to locate the correct CBI sector for subgroup B. In the example shown in the figure, searching the chaotic block index reveals that the i-th logical sector has not changed and its valid data is located in the original data.

  Similar considerations apply to locating the jth logical sector in subgroup C of a given logical group. In the example shown in the figure, it can be seen that the last written CBI sector is not any of the four CBI sectors of the predetermined logical group. The indirect sector index points to one of the four CBI sectors for a given group. Also, it can be seen that the last written portion of the four is certainly a CBI sector for subgroup C. Searching for the chaotic block index reveals that the jth logical sector is located at a specified location in the chaotic update block 704.

  A list of chaotic sectors is in the controller RAM for each chaotic update block in the system. Each list includes a record of the sectors written in the chaotic update block since the associated CBI sector was last updated in flash memory. The number of logical sector addresses for a particular chaotic update block can be kept in the chaotic sector list, with 8 to 16 being a typical value of design parameters. The optimal size of this list is determined by adjusting the overhead impact for chaotic data write operations and the sector scan time during initialization.

  During system initialization, each chaotic update block is scanned as necessary to identify valid sectors that have been written since a previous update for one of the associated CBI sectors. A chaotic sector list in the controller RAM for each chaotic update block is constructed. Each block may be scanned from the last sector address defined in the chaotic block information field in the last written CBI sector.

When a chaotic update block is allocated, CBI sectors are written to correspond to all updated logical subgroups. The logical and physical addresses for the chaotic update block are written in the available chaotic block information field in the sector, with a blank entry in the chaotic block index field. The chaotic sector list is released in the controller RAM.
When a chaotic update block is closed, the CBI sector is written with the logical and physical address of the block removed from the chaotic block information field in the sector. The corresponding chaotic sector list in RAM will not be used.

The corresponding chaotic sector list in the controller RAM is modified to include a record of the sectors written in the chaotic update block. If the chaotic sector list in the controller RAM does not have space available for recording further sector writes to the chaotic update block, the updated CBI sector is the logical sub-group associated with the sector in the list. Written for the group and the list is cleared.
When CBI block 620 is full, valid CBI sectors are copied to the allocated erased block and the previous CBI block is erased.

Address Table The logical / physical address conversion module 140 shown in FIG. 2 is responsible for associating the logical address of the host with the corresponding physical address in the flash memory. The mapping between logical groups and physical groups (metablocks) is stored in a set of tables and lists distributed in non-volatile flash memory 200 and volatile but fast running RAM 130 (see FIG. 1). The address table is held in flash memory and includes a metablock address for each logical group in the memory system. In addition, logical / physical address records for recently written sectors are temporarily held in RAM. These volatile records can be reconstructed from the block list and data sector header in flash memory when the system is initialized after power-up. Therefore, the address table in the flash memory only needs to be updated occasionally, and the ratio of the overhead write operation for the control data is reduced.

The hierarchy of address records for a logical group includes an open update block list, a closed update block list in RAM, and a group address table (GAT) held in flash memory.
The released update block list is a list in the controller RAM of data update blocks that are currently released for updated host sector data. Entries for a block are moved to the closed update block list when the block is closed. The closed update block list is a list in the controller RAM of data update blocks that are closed. A subset of the entries in the list are moved to sectors in the group address table during a control write operation.

  The group address table (GAT) is a list of metablock addresses for all logical groups of host data in the memory system. The GAT includes one entry for each logical group, arranged sequentially according to the logical address. The nth entry in the GAT contains the metablock address for the logical group at address n. In the preferred embodiment, this table is in flash memory and includes a set of sectors (referred to as GAT sectors) with entries that define metablock addresses for all logical groups in the memory system. The GAT sector is in one or more dedicated control blocks (referred to as GAT blocks) in the flash memory.

  FIG. 17A shows a data field of a group address table (GAT) sector. A GAT sector may have sufficient capacity to contain, for example, GAT entries for a set of 128 consecutive logical groups. Each GAT sector includes two components: a set of GAT entries for the metablock address of each logical group within a range, and a GAT sector index. The first component includes information for locating the metablock associated with the logical address. The second component includes information for locating all valid GAT sectors in the GAT block. Each GAT entry has three fields: a metablock number, a page tag as previously defined in connection with FIG. 3A (iii), and a flag indicating whether the metablock has been relinked. The GAT sector index lists the positions of valid GAT sectors within the GAT block. This index is in each GAT sector, but is replaced by the next written version of the GAT sector in the GAT block. Therefore, only the version in the last written GAT sector is valid.

  FIG. 17B shows an example in which a group address table (GAT) sector is recorded in one or more GAT blocks. The GAT block is a dedicated metablock for recording a GAT sector. When a GAT sector is updated, it is written to the next available physical sector location in GAT block 720. Thus, multiple copies of a GAT sector may exist in a GAT block, and only the last written copy is valid. For example, the GAT sector 45 has been updated at least twice and the final version is valid. The position of each valid sector in the GAT block is identified by a set of indexes in the last written GAT sector in the block. In this example, the last written GAT sector in the block is GAT sector 56, and its set of indexes is a valid alternative to all previous ones. If a GAT block eventually becomes full of GAT sectors, the block is compacted during a control write operation by rewriting all valid sectors to new block locations. The full block is then erased.

  As previously described, the GAT block includes entries for a logically contiguous set of groups in a region of the logical address space. Each GAT sector in the GAT block includes logical / physical mapping information for 128 consecutive logical groups. The large number of GAT sectors required to store entries for all logical groups within the address range covered by the GAT block occupy only a few of the total sector positions in the block. Thus, a GAT sector may be updated by writing to the next available sector location in the block. An index of all valid GAT sectors and their positions in the GAT block is kept in the index field in the most recently written GAT sector. The few total sectors in the GAT block occupied by valid GAT sectors is a system design parameter, typically 25%. However, there are a maximum of 64 valid GAT sectors per GAT block. In systems with large logical capacity, it may be necessary to store GAT sectors in one or more GAT blocks. In this case, each GAT block is associated with a fixed range of logical groups.

  A GAT update is performed as part of a control write operation and is triggered when there are no more blocks for allocation in the ABL (see FIG. 18). This is performed in parallel with the ABL filling operation and the CBL emptying operation. During a GAT update operation, one GAT sector has an entry updated with information from the corresponding entry in the closed update block list. When a GAT entry is updated, any corresponding entries are removed from the closed update block list (CUBL). For example, the GAT sector to be updated is selected based on the first entry in the closed update block list. The updated sector is written to the next available sector location in the GAT block.

  A GAT rewrite operation occurs during a control write operation when there are no available sector positions in the updated GAT sector. A new GAT block is allocated and valid GAT sectors defined by the GAT index are copied from a full GAT block in sequential order. Thereafter, the full GAT block is erased.

  The GAT cache is a copy in controller RAM 130 of entries in the subdivision portion of 128 entries in the GAT sector. The number of GAT cache entries is a system design parameter, with a typical value of 32. The GAT cache for the subdivision portion of the sector is created every time an entry is read from the GAT sector. Multiple GAT caches are maintained. The number is a design parameter and a typical value is four. The GAT cache is overwritten with entries for the subdivision portions of different sectors based on the least recently used.

Erased Metablock Management The erase block manager 160 shown in FIG. 2 manages erase blocks using a set of lists to hold directory and system control information. These lists are distributed in the controller RAM 130 and the flash memory 200. If the erased metablock must be allocated for storage of user data or for storage of system control data structures, in the allocation block list (ABL) (see FIG. 15) held in the controller RAM The next available metablock number is selected. Similarly, when a metablock is erased after discarding, its number is added to the cleared block list (CBL) also held in the controller RAM. A relatively static directory and system control data is stored in flash memory. These include an erased block list and an erased state bitmap (MAP) list of all metablocks in the flash memory. The erased block list and MAP are stored in separate sectors and recorded in a dedicated metablock known as a MAP block. These lists are distributed in the controller RAM and flash memory to provide a hierarchy of erased block records for efficiently managing the use of erased metablocks.

  FIG. 18 is a schematic block diagram illustrating the distribution and flow of control and directory information for use and recycling of erased blocks. Control and directory data is maintained in a list maintained either in the controller RAM 130 or in the MAP block 750 that resides in the flash memory 200.

  In the preferred embodiment, the controller RAM 130 maintains an allocated block list (ABL) 610 and a cleared block list (CBL) 740. As previously described in connection with FIG. 15, the allocation block list (ABL) tracks which metablocks have been recently allocated for storage of user data or for storage of system control data structures. To do. If a new erased metablock needs to be allocated, the next available metablock number in the allocated block list (ABL) is selected. Similarly, a cleared block list (CBL) is used to keep track of deallocated and erased updated metablocks. ABL and CBL are maintained in controller RAM 130 (see FIG. 1) for quick access and easy operation in tracking relatively active update blocks.

  The allocation block list (ABL) keeps track of the pool of erased metablocks and the assignments that make the erased metablock an update block. Thus, each of these metablocks may be described by an attribute that specifies whether it is an erased block of ABL pending allocation, an open update block, or a closed update block. FIG. 18 shows an ABL that includes an erased ABL list 612, an open update block list 614, and a closed update block list 616. In addition, associated with the open updated block list 614 is the associated original block list 615. Similarly, associated with the closed updated block list is an associated erased original block list 617. As previously indicated in FIG. 15, these related lists are subsets of the open update block list 614 and the closed update block list 616, respectively. The erased ABL block list 612, the open update block list 614, and the closed update block list 616 are all subsets of the allocated block list (ABL) 610, and the entries in each have corresponding attributes.

  The MAP block 750 is a metablock dedicated for storing the erasure management record in the flash memory 200. The MAP block stores a time-series MAP block sector, and each MAP sector is either an erase block management (EBM) sector 760 or a MAP sector 780. As metablocks are discarded and erased blocks are used up in allocation and recycled, the associated control and directory data is preferably included in the logical sector that is updated in the MAP block, and each update data The instance is recorded in a new block sector. Multiple copies of EBM sector 760 and MAP sector 780 may exist in MAP block 750, only the latest version is valid. An index to the position of the valid MAP sector is included in the field in the EMB block. A valid EMB sector is always written last in the MAP block during a control write operation. When the MAP block 750 is full, it is compacted during a control write operation by rewriting all valid sectors to new block positions. The full block is then erased.

  Each EBM sector 760 includes an erased block list (EBL) 770, which is a list of addresses of a subset of the population of erased blocks. The erased block list (EBL) 770 serves as a buffer containing erased metablock numbers, and the metablock numbers are periodically retrieved from the EBL to refill the ABL and Numbers are added periodically to empty the CBL again. EBL 770 serves as a buffer for available block buffer (ABB) 772, erased block buffer (EBB) 774, and erased block buffer (CBB) 776.

The available block buffer (ABB) 772 contains a copy of the entry in ABL 610 that immediately follows the previous ABL fill operation. This is essentially a backup copy of ABL immediately after the ABL filling operation.
The erased block buffer (EBB) 774 is transferred first from either the MAP sector 780 or from the CBB list 776 (described below) and is available for transfer to the ABL 610 during an ABL fill operation. Contains an address.
A cleared block buffer (CBB) 776 contains the addresses of erased blocks that were transferred from CBL 740 during CBL emptying operations and later transferred to MAP sector 780 or EBB list 774.

  Each MAP sector 780 includes a bitmap structure called MAP. MAP uses one bit for each metablock in the flash memory, which is used to indicate the erased state of each block. Bits corresponding to block addresses listed in the erased block list in ABL, CBL, or EBM are not set to the erased state in MAP.

  Any block that does not contain a valid data structure and is not designated as an erased block, erased block list, ABL, or CBL in the MAP is never used by the block allocation algorithm and is therefore a host or control data structure It cannot be accessed for storage. This provides a simple mechanism for excluding the faulty block from the accessible flash memory address space.

  The hierarchy shown in FIG. 18 allows for the efficient management of erased block records and provides complete security of the block address list stored in the controller's RAM. Erased block entries are rarely exchanged between these block address lists and one or more MAP sectors 780. These lists are stored in the erased block list and address translation table information stored in sectors in the flash memory and a small number of references in the flash memory during system initialization after the power is turned off. Reconstructed via limited scanning of the data block.

  The algorithm employed to update the hierarchy of erased metablock records allows the erased block to reflect the burst of addresses in order from the MAP block 750 and the order from which the block was updated by the host. The result is that the block address bursts are allocated for use in the order of interleaving. For most metablock sizes and system memory capacity, one MAP sector provides a bitmap for all metablocks in the system. In this case, the erased block is always allocated for use in the address order as recorded in this MAP sector.

As described before the erase block management operation , the ABL 610 is a list with address entries for erased metablocks that will be allocated for use and metablocks recently allocated as data update blocks. The actual number of block addresses in the ABL is between system design variables, upper and lower limits. The number of ABL entries formatted during manufacture is a function of card type and capacity. In addition, the number of entries in the ABL decreases as the end of life of the system approaches, because the number of available erased blocks decreases due to block failures within the lifetime. For example, after a fill operation, an entry in the ABL may specify a block that can be used for the following purposes: An entry for a partially written data update block with one entry per block that does not exceed the system limit on the maximum number of update blocks that are simultaneously open. Between 1 and 12 entries for erased blocks for allocation as data update blocks. Four entries for erased blocks to assign as control blocks.

When the ABL fill operation ABL 610 is used up by allocation, it will need to be refilled. The operation of filling the ABL occurs during a control write operation. This is triggered when a block must be allocated, but the ABL has enough erased block entries available for allocation as a data update block or for some other control data update block. Is not included. During the control write, the ABL filling operation is performed in parallel with the GAT update operation.

The following operations occur during the ABL filling operation.
1. ABL entries with the attributes of the current data update block are retained.
2. An ABL entry having the attribute of a closed data update block is retained if the entry for this block is not being written in a concurrent GAT update operation, and if it is being written, this entry is removed from the ABL.
3. ABL entries for erase blocks that are not allocated are retained.
4). The ABL is compacted to remove gaps caused by entry removal and the order of entries is maintained.
5. The ABL is completely filled by making the next available entry from the EBB list.
6). The ABB list is overwritten with the current entry in the ABL.

Empty CBL The operation CBL is a list of erased block addresses in the controller RAM that have the same restrictions as ABL on the number of erased block entries. The operation of emptying CBL occurs during a control write operation. Therefore, this operation is performed in parallel with the ABL filling / GAT update operation or the CBI block write operation. In the operation of emptying the CBL, the entry is removed from the CBL 740 and written to the CBB list 776.

MAP Exchange Operation MAP exchange operation between erase block information in MAP sector 780 and EBM sector 760 may occur periodically during a control write operation when EBB list 774 is empty. All erased metablocks in the system are recorded in EBM sector 760, there is no MAP sector 780, and no MAP exchange takes place. During the MAP exchange operation, the MAP sector that inputs the erased block to the EBB 774 is considered the source MAP sector 782. Conversely, a MAP sector that receives an erased block from CBB 776 is considered a destination MAP sector 784. If there is only one MAP sector, it serves as both a source and destination MAP sector as defined below.

The following operations are performed during MAP exchange.
1. A source MAP sector is selected based on the incremental pointer.
2. The destination MAP sector is selected based on the block address in the first CBB entry that is not in the source MAP sector.
3. The destination MAP sector is updated as defined by the corresponding entry in the CBB, and the entry is removed from the CBB.
4). If there is no separate source MAP sector, the updated destination MAP sector is written to the MAP block.
5. The source MAP sector is updated as defined by the corresponding entry in the CBB, and the entry is removed from the CBB.
6). The remaining entries in the CBB are added to the EBB.
7). The EBB is filled with erased block addresses defined from the transmission source MAP sector as much as possible.
8). The updated source MAP sector is written in the MAP block.
9. The updated EBM sector is written into the MAP block.

List Management FIG. 18 shows the distribution and flow of control and directory information between the various lists. For convenience, the operation of moving an entry between elements of a list or changing the attribute of an entry is shown in FIG. 18 as [A] to [O] and is as follows.
[A] When an erased block is assigned as an update block for host data, the attribute in the ABL of that entry is changed from an erased ABL block to a free update block.
[B] If the erased block is assigned as a control block, its entry in the ABL is removed.
[C] When an ABL entry is created with an open update block attribute, an associated original block field is added to the entry to record the original metablock address for the logical group being updated. This information is obtained from the GAT.
[D] When an update block is closed, the attributes in the ABL of the entry are changed from the open update block to the closed update block.
[E] When an update block is closed, its associated original block is erased and the attribute of the associated original block field in that entry in the ABL is changed to the erased original block.
[F] During an ABL fill operation, any closed update block whose address has been updated in the GAT during the same control write operation will have its entry removed from the ABL.
[G] During an ABL fill operation, when an entry for a closed update block is removed from the ABL, the entry for its associated erased original block is moved to the CBL. [H] When a control block is erased, an entry for it is added to the CBL.
[I] During an ABL fill operation, the erased block entry is moved from the EBB list to the ABL and given the attributes of the erased ABL block.
[J] After correcting all relevant ABL entries during an ABL fill operation, the block address in the ABL replaces the block address in the ABB list.
[K] During the control write, in parallel with the ABL filling operation, the entry for the erased block in the CBL is moved to the CBB list.
[L] During the MAP exchange operation, all relevant entries are moved from the CBB list to the MAP destination sector.
[M] During the MAP exchange operation, all relevant entries are moved from the CBB list to the MAP source sector.
[N] Following [L] and [M] during the MAP exchange operation, all remaining entries are moved from the CBB list to the EBB list.
[O] Following [N] during MAP exchange operation, if possible, entries other than those moved in [M] are moved from the MAP source sector to fill the EBB list.

Logical / Physical Address Translation To locate the physical location of a logical sector in the flash memory, the logical / physical address translation module 140 shown in FIG. 2 performs logical / physical address translation. Except for recently updated logical groups, a large amount of translation may be done using a group address table (GAT) in the GAT cache in flash memory 200 or controller RAM 130. Address translation for the recently updated logical group will mainly require searching the address list for the updated block in the controller RAM 130. Accordingly, the processing for logical / physical address conversion for the logical sector address depends on the type of block associated with the logical group in which the sector is located. Block types include blocks that do not change, sequential data update blocks, chaotic data update blocks, and closed data update blocks.

FIG. 19 is a flowchart showing logical / physical address conversion processing. Basically, corresponding metablocks and physical sectors are located by first searching various update directories, such as open update block list and closed update block list, using logical sector addresses. . If the associated metablock is not part of the update process, directory information is provided by the GAT. The logical / physical address translation includes the following steps.
Step 800: A logical sector address is given.
Step 810: A predetermined logical address in the free update block list 614 (see FIGS. 15 and 18) in the controller RAM is searched. If the search fails, go to step 820, otherwise go to step 830.
Step 820: A predetermined logical address in the closed update block list 616 is searched. If the search fails, the predetermined logical address is not part of any update process and the process proceeds to step 870 for GAT address translation. Otherwise, go to step 860 for closed update block address translation.
Step 830: If update blocks including a predetermined logical address are sequential, the process proceeds to step 840 for sequential update block address conversion. Otherwise, go to step 850 for chaotic update block address translation.
Step 840: Obtain the metablock address using sequential update block address translation. Proceed to step 880.
Step 850: Obtain a metablock address using chaotic update block address translation. Proceed to step 880.
Step 860: Get metablock address using closed update block address translation. Proceed to step 880.
Step 870: Obtain a metablock address using group address table (GAT) translation. Proceed to step 880.
Step 880: Convert the metablock address to a physical address. The conversion method depends on whether the metablock is relinked.
Step 890: A physical sector address is obtained.

Various address translation processes are described in more detail below.
Sequential update block address conversion (step 840)
Address translation for the target logical sector address in the logical group associated with the sequential update block is accomplished directly from the information in the free update block list 614 as follows (FIGS. 15 and 18).
1. From the “page tag” field and the “number of write sectors” field in the list, it is determined whether the target logical sector is in the update block or its associated original block.
2. The metablock address appropriate for the target logical sector is read from the list.
3. The sector address in the metablock is determined from the appropriate “page tag” field.

Chaotic update block address translation (step 850)
The address translation sequence for the target logical sector address in the logical group associated with the chaotic update block is as follows.
1. If the chaotic sector list in RAM determines that the sector is a recently written sector, address translation may be accomplished directly from that position in this list.
2. The most recently written sector in the CBI block includes the physical address of the chaotic update block corresponding to the target logical sector address in its chaotic block data field. Also included in the indirect sector index field is the offset in the CBI block of the last written CBI sector associated with this chaotic update block (see FIGS. 16A-16E).
3. The information in these fields is cached in RAM, eliminating the need to read sectors during subsequent address translation.
4). The CBI sector identified in step 3 by the indirect sector index field is read.
5. The direct sector index field for the most recently accessed chaotic update subgroup is cached in RAM, eliminating the need to read in step 4 for repeated access to the same chaotic update block.
6). The direct sector index field read in step 4 or 5 identifies the CBI sector associated with the logical subgroup containing the target logical sector address.
7). The chaotic block index entry for the target logical sector address is read from the CBI sector identified in step 6.
8). The most recently read chaotic block index field may be cached in the controller RAM, eliminating the need to read in step 4 and step 7 for repeated access to the same logical subgroup.
9. The chaotic block index entry defines the location of the target logical sector within either a chaotic update block or an associated original block. If a valid copy of the target logical sector is in the original block, it is located using the original metablock and page tag information.

Closed update block address translation (step 860)
Address translation for the target logical sector address in the logical block loop associated with the closed update block can be accomplished directly from the information in the closed block update list as follows (see FIG. 18).
1. The metablock address assigned to the target logical group is read from the list.
2. The sector address in the metablock is determined from the “page tag” field in the list.

GAT address translation (step 870)
If a logical group is not referenced by either an open or closed block update list, that entry in the GAT is valid. The address translation sequence for the target logical sector address in the logical group referenced by the GAT is as follows.
1. The range of available GAT cache in RAM is evaluated to determine whether an entry for the target logical group is included in the GAT cache.
2. If the target logical group is found in step 1, the GAT cache includes all group address information including the metablock address and page tag, and the target logical sector address can be converted.
3. If the target address is not in the GAT cache, the GAT index must be read for the target GAT block to identify the location of the GAT sector with respect to the target logical group address.
4). The GAT index for the last accessed GAT block is kept in the controller RAM and may be accessed without having to read the sector from the flash memory.
5. A list of metablock addresses for each GAT block and the number of sectors written in each GAT block are maintained in the controller RAM. If the required GAT index is not available in step 4, it may be read immediately from flash memory.
6). The GAT sector related to the target logical group address is read from the sector position in the GAT block defined by the GAT index acquired in Step 4 or Step 6. The GAT cache is updated with the subdivision portion of the sector containing the target entry.
7). The target sector address is obtained from the metablock address and the “page tag” field in the target GAT entry.

Metablock / physical address translation (step 880)
If the flag related to the metablock address indicates that the metablock is relinked, the corresponding LT sector is read from the BLM block and determined as the erase block address for the target sector address. Otherwise, the erase block address is determined directly from the metablock address.

Control Data Management FIG. 20 shows the hierarchy of operations performed on the control data structure during memory management operations. Data update management operations operate on various lists in RAM. Control write operations operate on various control data sectors and dedicated blocks in flash memory, and exchange data with lists in RAM.

  Data update management operations are performed on the ABL, CBL, and chaotic sector lists in RAM. The ABL is updated when the erased block is assigned as an update block or control block, or when the update block is closed. The CBL is updated when the control block is erased or when an entry for the closed update block is written to the GAT. The updated chaotic sector list is updated when a sector is written into a chaotic update block.

  The control write operation writes information from the control data structure in the RAM to the control data structure in the flash memory, resulting in updating the flash memory and other auxiliary control data structures in the RAM if necessary. This is triggered when the ABL does not contain any more entries for erased blocks to be allocated as update blocks, or when the CBI block is rewritten.

  In the preferred embodiment, an ABL fill operation, an empty CBL operation, and an EBM sector update operation are performed during each control write operation. When the MAP block containing the EBM sector is full, the valid EBM and MAP sectors are copied to the allocated erased block and the previous MAP block is erased.

During each control write operation, one GAT sector is written and the closed update block list is modified accordingly. When the GAT block is full, a GAT rewrite operation is performed.
The CBI sector is written after a chaotic sector write operation, as previously described. When the CBI block is full, valid CBI sectors are copied to the allocated erased block and the previous CBI block is erased.
A MAP exchange operation is performed when there are no more erased block entries in the EBB list in the EBM sector, as previously described.

The MAP address (MAPA) sector records the current address of the MAP block, and is written in a dedicated MAPA block every time the MAP block is rewritten. When the MAPA block is full, valid MAPA sectors are copied to the allocated erase block and the previous MAPA block is erased.
The boot sector is written into the current boot block every time the MAPA block is rewritten. When the boot block is full, a valid boot sector is copied from the current version of the boot block to the backup version and then becomes the current version. The previous current version is erased and becomes the backup version, where the valid boot sector is written back.

Examples of control data consistency and management control data include directory information and block allocation information relating to the memory block management system as described with reference to FIG. As described above, control data is held in both the high speed RAM and the slower non-volatile memory block. Any frequently changing control data is held in RAM with periodic control writes to update the corresponding information stored in the non-volatile metablock. Thus, the control data is stored in a non-volatile but low speed flash memory that does not require frequent access. A hierarchy of control data structures such as GAT, CBI, MAP, and MAPA shown in FIG. 20 is held in the flash memory. Thus, due to the control write operation, information from the control data structure in the RAM updates the corresponding control data structure in the flash memory.

  As described with respect to FIG. 20, the block management system maintains a set of control data in the flash memory during its operation. This set of control data is stored in a metablock, similar to host data. As described above, the control data itself is managed in blocks, and is updated, so that the garbage collection operation is also received.

  Further, it has been explained that there is a control data hierarchy in which low-level data is updated more frequently than high-level data. For example, assuming that all control blocks have N control sectors to write, the following sequence of control updates and control block transfers usually happens by chance. Referring back to FIG. 20, each N CBI updates fills the CBI block and triggers CBI transfer (rewrite) and MAP update. When the chaotic block is closed, a GAT update is also triggered. Each GAT update triggers a MAP update. Each N GAT update fills the block and triggers a GAT block transfer. In addition, when the MAP block is full, a MAP block transfer and MAPA block (if there is a MAPA block, otherwise a BOOT block points directly to the MAP) is also triggered. In addition, when the MAPA block is full, a MAPA block transfer, BOOT block update, and MAP update are also triggered. In addition, when a BOOT block is full, an active BOOT block transfer to another BOOT block is triggered.

Update Block Replacement Technique According to another aspect of the present invention, in a non-volatile memory with a block management system, for a system that supports up to a first predetermined maximum number of update blocks that are simultaneously open to record data. An improved block replacement technique is implemented. An update block is mainly a continuous update block. In the continuous update block, data is recorded in a logically continuous order, but the number of blocks is not recorded in a logically continuous order. Up to a second predetermined maximum number allowed to be a chaotic update block. Whenever a new allocation of update blocks causes the pool of update blocks to exceed the first or second predetermined maximum number, one of the existing blocks in the pool is closed and deleted to comply with the restriction. Will be. Prior to closing the update block, the data is integrated into a continuous block. This improved approach is to avoid situations where successive updates can result in excessive chaotic block consolidation numbers. This is accomplished by separating the continuous update block and the chaotic update block into their respective replacement or unified pool. In particular, when the number of new update blocks assigned by the continuous update exceeds the first predetermined maximum number, the continuous update block that has not been used for the longest time in the pool is given priority to make a free space.

  In current systems, there are generally two types of data: user data and control data. User data is sent from the host to the memory system, typically in a logically sequential order. Continuous update blocks are allocated to optimally handle continuous write operations from the host. User data may be in a logically discontinuous order, especially if there are subsequent updates to the logical data. Chaotic update blocks are created to optimally handle data in a discontinuous order. Other sources of chaotic or discontinuous data include control data maintained by the file system or memory system, such as file and directory information generated in the process of storing user data.

  The traditional approach, which follows the practical system limit of supporting up to the maximum number of update blocks that are simultaneously open, closes the least recently used update block in the pool, whether continuous or chaotic It was something to do.

  The technique of the present application is an improvement over the conventional technique, and basically it is necessary to close the update blocks in the pool to make room for new allocations during successive write operations. In some cases, the least recently used consecutive update block in the pool is closed. This ensures that the various update blocks are effectively utilized to handle continuous write operations and random write operations. In particular, an inefficient situation is avoided in which a chaotic update block containing FAT and directory information may have to be closed by a large-scale continuous write operation by the host. Additional chaotic blocks will be created in the near future to store FAT and directory information that will be updated again at the end of this massive write operation. By creating an improved replacement policy, the separation of replacement and consolidated pools is specified, and chaotic blocks are removed during sequential writing and consolidation of blocks that can be open continuous blocks or open chaotic blocks. Manages subsequent FAT and directory updates, preventing additional overhead in consolidation.

The practical system limit of supporting up to the maximum number of update blocks that are freed simultaneously is mentioned above. For example, in one embodiment described in connection with FIG. 10, step 410 tests whether the maximum number of update blocks U _MAX that can be simultaneously released to accept update data is exceeded. If U _MAX is exceeded, it will be closed in step 420 regardless of whether the least active update block is a continuous update block or a chaotic update block. Keep the system within limits.

FIG. 21 schematically shows two predetermined restrictions on the number of update blocks for a block management system. There is a comprehensive regulation of updating the total number of blocks (U _MAX), which is given by the sum of the number of number and sequential update block N _S chaotic update block N _C. There is also a restriction on the maximum number of chaotic update blocks (“U _CMAX ”) because chaotic update blocks require more resources and require further holding of a chaotic block index (CBI). Therefore, the first restriction requires that the total number of update blocks N _C + N _S ≦ U _MAX . The second restriction requires that the number of chaotic update blocks N _C ≦ U _CMAX .

FIG. 22 shows a typical example of a combination of two constraints optimized for various memory devices. Certain combinations are specified by U _MAX "dash" U _CMAX . For example, “3-1” specifies a block management system that allows a maximum of three update blocks in the update pool, and only one of them is a chaotic update block. Similarly, “7-3” specifies a block management system that supports up to seven update blocks, of which up to three can be chaotic update blocks. In general, the simpler the memory system with a smaller memory capacity, the tighter the limit and the smaller the maximum number.

FIGS. 23A, 23B and 23C schematically illustrate a sequence of events for introducing a new update block into a pool of update blocks, according to a first situation in the conventional replacement technique.
FIG. 23A schematically illustrates an update pool with a “5-2” configuration as described in FIG. In this example, the update pool is completely filled with up to five allowed update blocks. The update pool is further divided into a continuous pool 1200 containing three consecutive update blocks S1, S2 and S3 and a chaotic pool 1300 containing up to two chaotic or discontinuous update blocks C4 and C5. This example shows a first situation where the least active block happens to be a continuous update block like S3 in 1201.

  If a new update block needs to be allocated, one of the existing update blocks in the update pool will need to be closed to make room. For example, if the host writes continuous data for a logical group of sectors that are not serviced by an existing update block in the pool, it is necessary to allocate a new update block to record that data.

  FIG. 23B schematically illustrates closing the least active update block to make room for a new update block, according to a conventional approach. The least active block happens to be S3 of 1201 in this case and will be closed and removed from the update block pool.

FIG. 23C schematically illustrates introducing a newly allocated update block into the pool after an update block that has been closed to make room is deleted. In this case, in order to record data in a logically continuous order, the newly allocated update block 1212 S6 is introduced into the continuous pool 1200. Thus, the maximum number of allowed update blocks, U _MAX , is not exceeded.

FIGS. 24A, 24B, and 24C schematically illustrate a sequence of events for introducing a new update block into a pool of update blocks, according to a second situation in the conventional replacement technique.
FIG. 24A schematically shows an update pool with a “5-2” configuration as described in FIG. In this example, the update pool is completely filled with up to five allowed update blocks. The update pool is further divided into a continuous pool 1200 containing three consecutive update blocks S1, S2 and S3 and a chaotic pool 1300 containing up to two chaotic or discontinuous update blocks C4 and C5. This example shows a second situation where the least active block happens to be a chaotic update block like C4 at 1301.

  FIG. 24B schematically illustrates closing the least active update block to make room for a new update block, according to a conventional approach. The least active block is in this case by chance C1 1301 and will be closed and removed from the pool of update blocks.

FIG. 24C schematically illustrates introducing a newly allocated update block into the pool after an update block that has been closed to make room is deleted. In this case, in order to record data in a logically continuous order, the newly allocated update block 1212 S6 is introduced into the continuous pool 1200. Thus, the maximum number of allowed update blocks, U _MAX , is not exceeded.

FIGS. 25A and 25B illustrate retention of U _MAX and U _CMAX limits in the approach described above in FIGS. 10, 23B, and 24B, respectively. Two restrictions are typically imposed simultaneously.

FIG. 25A is the approach shown previously in step 410 of FIG. 10 and FIGS. 23B and 24B, where the updated block that has not been accessed for the longest time whenever a new allocation exceeds a predetermined limit. Indicates the method to be closed.
Step 1252: Organize non-volatile memory into blocks, each block for storing erasable data together.
Step 1254: Allocate up to a first predetermined number of open update blocks simultaneously to store data logical unit updates.
Step 1256: Whenever the allocation of new update blocks exceeds the predetermined number, one of the most recently accessed update blocks is closed to make room for the new update block.

FIG. 25B is the technique shown above in step 370 of FIG. 10 where the chaotic (discontinuous) update block that has not been accessed for the longest time whenever the number of chaotic update blocks exceeds a predetermined limit. Indicates the method to be closed.
Step 1354: Allocate up to a second predetermined number of update blocks among the open update blocks for storing logical units of data in a logically discontinuous order.
Step 1356: Whenever the number of discontinuous update blocks exceeds a second predetermined number, one of the discontinuous update blocks that have not been accessed for the longest time is closed to the second predetermined number. Do not exceed the number.

  One disadvantage of this conventional approach is that, depending on the situation, chaotic update blocks can be overly closed. This is particularly inefficient when chaotic blocks containing control data are closed early due to continuous writing to make room in the pool for newly allocated consecutive blocks. For example, if 1310 C4, a closed chaotic update block, recorded FAT and directory information, a replacement would be required immediately to service the function as soon as successive writes were made . This would again close the least active update block currently in the pool to make room for the replacement update block for recording control data.

  According to this aspect of the invention, this approach of closing update blocks so as not to exceed a predetermined maximum number of update blocks simply selects the update block that has not been used for the longest time, so chaotic update blocks Has been further refined to reduce the number of cases of excessive closure. In a preferred embodiment, when an update block is allocated to record continuous data and one in the pool of update blocks is closed to make room, the least active continuous update block in the pool is closed. Is done.

FIGS. 26A, 26B, and 26C schematically illustrate a sequence of events for introducing a new update block to a pool of update blocks, according to an improved replacement technique of the present application.
FIG. 26A schematically shows an update pool having a “5-2” configuration as described in FIG. In this example, the update pool is completely filled with up to five allowed update blocks. The update pool is further divided into a continuous pool 1200 containing three consecutive update blocks S1, S2 and S3 and a chaotic pool 1300 containing up to two chaotic or discontinuous update blocks C4 and C5. This example shows a situation similar to that in FIG. 24A where the least active block happens to be a chaotic update block like C4 at 1301. Furthermore, this example shows that S3 of the continuous block 1202 is least active in the continuous pool 1200.

  FIG. 26B schematically illustrates closing one of the update blocks in the pool to make room for a new update block, according to the improved technique of the present application. One of the update blocks in the pool to make room for the newly assigned update block if the number of update blocks in the pool is already the maximum for a new assignment related to continuous update Will have to be closed. However, in this case, the least active block is C4 of 1301, which is a chaotic block and will be passed. Instead, the most active update block in the continuous pool 1200 will be closed. In this example, it is S3 of 1202 that will be closed and deleted from the update block pool.

FIG. 26C schematically illustrates introducing a newly allocated update block into the pool after an update block that has been closed to make room is deleted. In this case, in order to record the data in a logically continuous order, the newly assigned update block 1212 S6 is introduced into the continuous pool 1200. Thus, the maximum number of allowed update blocks, U _MAX , is not exceeded.

FIGS. 27A, 27B, and 27C schematically illustrate a sequence of events for introducing a new chaotic update block into a pool of update blocks according to the improved replacement technique of the present application.
FIG. 27A schematically shows an update pool with a “5-2” configuration as described in FIG. In this example, the update pool is completely filled with up to five allowed update blocks. The update pool is further divided into a continuous pool 1200 containing three consecutive update blocks S1, S2 and S3 and a chaotic pool 1300 containing up to two chaotic or discontinuous update blocks C4 and C5. This example shows that the least active block happens to be a continuous update block like S6 in 1201. Furthermore, this example shows that the chaotic block 1304 C4 is the least active of the chaotic pool 1300.

  FIG. 27B schematically illustrates closing one of the update blocks in the pool to make room for a new update block, according to the improved technique of the present application. If a new chaotic update block is already introduced into a full chaotic pool 1300, one of the update blocks in the chaotic pool must be closed to make room. In this example, chaotic pool 1300 already contains a maximum of two chaotic update blocks. When a further chaotic update block is created, for example, when converting an existing continuous update block 1220 S1 into a chaotic block, if one of the chaotic blocks is not deleted, the chaotic block The maximum number of is exceeded. In this case, C4 of 1302, which is the least active chaotic block, is closed and deleted from the chaotic pool 1300 to make room.

FIG. 27C schematically illustrates introducing a new chaotic update block into the pool after other chaotic update blocks have been closed and deleted to make room. In this case, S1 is converted from the continuous update block 1220 in the continuous pool 1200 to C20 of 1320 which is a chaotic block in the chaotic pool 1300. Thus, U _CMAX , which is the maximum number of allowed chaotic update blocks, is not exceeded.

FIG. 28 is a flowchart illustrating the improved technique of the present application for managing a limited set of update blocks during a continuous update, according to the first embodiment.
Step 1400: Organize non-volatile memory into blocks, each block for storing erasable data together.
Step 1402: Allocate up to a first predetermined number of open update blocks simultaneously to store data logical unit updates.
Step 1406: Write logical units of data into the update block in sequential order in response to a write command for writing continuous data.
Step 1408: According to a predetermined condition satisfied for an update block that is closed to further write successive logical units of data, a new update block is allocated and writing continues, and the new allocation is a first predetermined number. , The sequential order update blocks that have not been accessed for the longest time are preferentially closed over any of the discontinuous order update blocks that have not been accessed for the longest time.

FIG. 29 is a flowchart illustrating the improved technique of the present application for managing a limited set of update blocks having two predetermined limits, according to a second embodiment.
Step 1410: Organize non-volatile memory into blocks, each block for storing erasable data together.
Step 1412: Allocate up to a first predetermined number of open update blocks simultaneously for storing logical unit updates of data.
Step 1416: Allocate up to a second predetermined number of update blocks among the open update blocks for storing logical units of data in a logically discontinuous order.
Step 1418: Whenever the introduction of an update block for storing data in a logically sequential order exceeds the first predetermined number, the longest access that includes the logically sequential order of data Close unused update blocks to make room for installed update blocks.
Step 1420: Whenever the introduction of an update block for storing data in a logically discontinuous order exceeds the second predetermined number, the longest containing data in a logically discontinuous order Close update blocks that have not been accessed in time to make room for installed update blocks.

  Generally speaking, the method of the present application is based on a set of attributes such as whether the update block stores continuous or discontinuous data, or whether it stores a predetermined type of system data. Thus, update blocks are classified. In implementing a limited number of update block pools, each class of update block will have its own rules for replacement if it exceeds the maximum number supported for that class.

  For example, continuous update blocks and discontinuous update blocks are two different classes. The replacement rules for each of these classes are the same, i.e., the least active one is replaced with a new one. Thus, if the pool of continuously updated blocks is exceeded, the least active one in the pool will be closed and deleted before the new one is introduced into the pool. The same applies to the pool of discontinuous update blocks.

  In general, each class has its own replacement rules that are independent of other classes. As an example of the replacement rule, depending on the corresponding class, the one that has not been accessed for the longest time, the one that has been accessed most recently, the one that has not been accessed most frequently, the one that has been accessed most frequently, and the like are replaced.

FIG. 30 is a flowchart illustrating the present improved technique for managing a limited set of update blocks with class-based replacement rules.
Step 1430: Organize non-volatile memory into blocks, each block for storing erasable data together.
Step 1432: Providing a pool up to a first predetermined maximum number of update blocks being released simultaneously to store logical unit updates of data.
Step 1436: Provide a predetermined set of classes for classifying update blocks based on a set of attributes, each class supporting a subpool up to a predetermined maximum number of update blocks associated with it.
Step 1438: Providing a set of replacement rules corresponding to a predetermined set of classes to identify the update block to be replaced in each subpool.
Step 1440: Group update blocks in a pool into corresponding sub-pools.
Step 1442: Whenever another update block of the same class is being introduced, close and delete the least active update block in the subpool that contains the associated predetermined maximum number of update blocks.

  All patents, patent applications, papers, books, specifications, other publications, documents, and things referenced in this application are hereby incorporated by reference in their entirety for all purposes. . In the event of any inconsistency or inconsistency in the definition or usage of terms between any incorporated publication, document, and thing and the text of this specification, the definition or usage of the terms herein shall be followed.

  While various aspects of the invention have been described with respect to certain embodiments, it will be understood that the invention is entitled to protection within the full scope of the appended claims.

Claims (23)

A method of storing data in said memory in a non-volatile memory organized into a plurality of blocks, each comprising blocks for storing logical units of data that can be erased together,
Allocating up to a first predetermined number of blocks as simultaneously open update blocks for storing logical unit updates of data;
Providing a pool of up to a first predetermined maximum number of open update blocks simultaneously to store logical unit updates of data;
Providing a predetermined set of classes for classifying update blocks based on a set of attributes, each class supporting sub-pools up to a predetermined maximum number of associated update blocks;
Providing a corresponding set of replacement rules to the predetermined set of classes to identify the update block to be replaced in each sub-pool;
Grouping the updated blocks in the pool into corresponding sub-pools;
Whenever another update block of the same class is being introduced, the step of closing and deleting the least active update block in the sub-pool containing the associated predetermined maximum number of update blocks, the deletion The update block to be performed is selected according to the corresponding replacement rule for the same class;
Including methods. The method of claim 1, wherein
The method wherein the set of attributes includes blocks that store data in a logically sequential order. The method of claim 1, wherein
The method wherein the set of attributes includes blocks that store data in a logically discontinuous order. The method of claim 1, wherein
The method wherein the set of attributes includes a block for storing system data associated with operating the memory. The method of claim 1, wherein
The method wherein the memory is a flash EEPROM. The method of claim 1, comprising:
The method wherein the memory has a NAND structure. The method of claim 1, wherein
The method wherein the memory is on a removable memory card. The method of claim 1, wherein
The nonvolatile memory includes a memory cell having a floating gate structure. The method of claim 1, wherein
The non-volatile memory includes a memory cell having a dielectric layer structure. The method according to any one of claims 1 to 9, wherein
The memory has a memory cell for storing 1-bit data. The method according to any one of claims 1 to 9, wherein
The memory has a memory cell for storing data of 1 bit or more. Non-volatile memory,
Memory organized into blocks, each block being divided into erasable memory units, each memory unit being for storing a logical unit of data;
A pool of up to a first predetermined maximum number of update blocks that are simultaneously open to store logical unit updates of data;
A set of predefined classes for classifying update blocks based on a set of attributes, each class supporting a subpool up to a predetermined maximum number of associated update blocks;
A set of replacement rules corresponding to the predetermined set of classes to identify the update block to be replaced in each sub-pool;
A set of subpools containing update blocks for each class;
A controller for controlling the operation of the block, wherein the operation is:
Whenever another update block of the same class is being introduced, it closes and deletes the update block in the sub-pool that contains the associated predetermined maximum number of update blocks, and the deleted update block is the same A controller comprising being selected according to the corresponding replacement rule for a class of
A non-volatile memory comprising: The memory of claim 12,
The set of attributes is a memory that includes blocks that store data in a logically sequential order. The memory of claim 12,
The set of attributes is a memory that includes blocks that store data in a logically discontinuous order. The memory of claim 12,
The set of attributes is a memory that includes a block that stores system data associated with operating the memory. The memory of claim 12, comprising:
The memory is a flash EEPROM. The memory of claim 12,
The memory is a memory having a NAND structure. The memory of claim 12,
The memory is a memory on a removable memory card. The memory of claim 12,
The nonvolatile memory includes a memory cell having a floating gate structure. The memory of claim 12,
The nonvolatile memory includes a memory cell having a dielectric layer structure. Non-volatile memory,
Memory organized into blocks, each block being divided into erasable memory units, each memory unit being for storing a logical unit of data;
A pool of up to a first predetermined maximum number of update blocks that are simultaneously open to store logical unit updates of data;
A set of predefined classes for classifying update blocks based on a set of attributes, each class supporting a subpool up to a predetermined maximum number of associated update blocks;
A set of replacement rules corresponding to the predetermined set of classes to identify the update block to be replaced in each sub-pool;
A set of subpools containing update blocks for each class;
Means for closing and deleting an update block in a sub-pool containing the predetermined maximum number of update blocks associated with it, whenever another update block of the same class is being introduced Means for selecting an update block according to the corresponding replacement rule for the same class;
A non-volatile memory comprising: The memory according to any one of claims 12 to 21,
The memory includes memory cells each storing 1-bit data. The memory according to any one of claims 12 to 21,
The memory includes memory cells each storing data of 1 bit or more.

Images