KR20090079197A - Non-volatile memory and method for class-based update block replacement rules - Google Patents

Abstract

In a nonvolatile memory with block management system, data are written to blocks and are erasable block by block. At any time a pool of blocks are open for storing data concurrently. The number of blocks in the pool is limited. A replacement system allows new blocks to be introduced into the pool without exceeding the limit. In particular, different classes of blocks in the pool each has its own replacement rule, such as closing a least active block before being replaced. In this way, possible inefficiency and premature closure of blocks in the pool can be avoided.

Description

NON-VOLATILE MEMORY AND METHOD FOR CLASS-BASED UPDATE BLOCK REPLACEMENT RULES}

This invention relates generally to nonvolatile semiconductor memory, and more particularly to having a memory block management system with an improved system that manages the replacement of concurrently open block pools for storing data. .

Non-volatile storage of solid state memory, especially in the form of EEPROM and Flash EEPROM packaged as small form factor cards, has recently been used in a variety of mobile and portable devices, especially information devices and consumer electronics. It is the storage device of choice. Unlike RAM (random access memory), which is also a solid state memory, flash memory is nonvolatile, preserving its stored data even after power is turned off. Also, unlike ROM (Read Only Memory), flash memory is rewritable, similar to disk storage. Despite the higher cost, flash memory is increasingly used in mass storage applications. Conventional mass storage devices based on rotating magnetic media such as hard drives and floppy disks are not suitable for mobile and portable environments. This is because disk drives are bulky and prone to mechanical failure, and tend to have large latency and high power requirements. These undesirable attributes prevent disk-based storage from being used in most mobile and portable applications. On the other hand, embedded and removable card-type flash memories are ideally suited for mobile and portable environments because of their small size, low power consumption, high speed and high reliability features.

Flash EEPROMs are similar to EEPROMs (electrically erasable and programmable read-only memory) in that they are nonvolatile memory that can be erased and have new data written or "programmed" into their memory cells. Both utilize a floating (unconnected) conductive gate in the field effect transistor structure, located on the channel region in the semiconductor substrate, between the source and drain regions. The control gate is provided on the floating gate. The threshold voltage characteristic of the transistor is controlled by the amount of charge retained on the floating gate. That is, for a given level of charge on the floating gate, there is a corresponding voltage (threshold) that must be applied to the control gate before the transistor is turned “on” to allow conduction between its source and drain regions. In particular, flash memory, such as flash EEPROM, allows memory cells of all blocks to be erased simultaneously.

The floating gate can hold a range of charges and can therefore be programmed to any threshold voltage level within the threshold voltage window. The size of the threshold voltage window is bounded by the minimum and maximum threshold levels of the device that will correspond to the range of charges that can be programmed into the floating gate. The threshold window generally depends on the characteristics, operating conditions and history of the memory device. Each distinct resolvable threshold voltage level range within the window can in principle be used to specify the determined memory state of the cell. When the threshold voltage is divided into two distinct regions, each memory cell may store one bit of data. Likewise, when the threshold voltage window is divided into two or more distinct regions, each memory cell may store one or more bits of data.

Transistors that act as memory cells are typically programmed to a "programmed" state by one of two mechanisms. In "hot electron injection", the 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 brings hot electrons through the thin gate dielectric to the floating gate. In "tunneling injection", a high voltage is applied to the control gate to the substrate. Accordingly, electrons are pulled from the substrate to the interposed floating gate. While the term "program" has been used to describe writing to memory by injecting electrons into an initially erased charge storage unit of a memory cell to change the memory state, now more such as "write" or "write" It is used interchangeably with general terms.

The memory device may be erased by a number of mechanisms. In an EEPROM, the memory cell can be electrically erased by applying a high voltage to the substrate relative to the control gate in order to allow the electrons in the floating gate to be tunneled through the thin oxide into the substrate channel region (ie, Fowler-Nodymim tunneling). . Typically, the EEPROM can be erased one byte. In a flash EEPROM, the memory may be electrically erased one or more blocks at a time or at a time, where the minimum erasable block may consist of one or more sectors and each sector may store 512 bytes or more data. .

Memory devices typically include one or more memory chips that can be installed on a card. Each memory chip includes an array of memory cells supported by decoders and peripheral circuits such as erase, write and read circuits. More complex memory devices are intelligent and involve a controller that performs higher levels of memory operations and interfacing.

There are many commercially successful nonvolatile solid state memory devices used in recent years. These memory devices may be flash EEPROM or may employ other types of nonvolatile memory cells. Examples of flash memories and systems and methods of making them are given in US Pat. Nos. 5,070,032, 5,095,344, 5,315,541, 5,343,063, 5,661,053, 5,313,421, 6,222,762. In particular, flash memory devices having a NAND string structure are described in US Pat. Nos. 5,570,315, 5,903,495, 6,046,935. In addition, nonvolatile memory devices are fabricated from memory cells having a dielectric layer for storing charge. Instead of the conductive floating gate described above, a dielectric layer is used. Such memory devices utilizing dielectric storage devices are described in Eitan et al., "NROM: A Novel Localized Trapping, 2-Bit Nonvolatile Memory Cell" IEEE Electron Device Letters, vol. 21, no. 11, November 2000, pp. 543-545. The ONO dielectric layer extends across the channel between the source and drain diffusions. Charge for one data bit is collected in the dielectric layer adjacent to the drain, and charge for another data bit is collected in the dielectric layer adjacent to the source. For example, US Pat. Nos. 5,768,192 and 6,011,725 disclose nonvolatile memory cells having a trapping dielectric sandwiched between two silicon dioxide layers. Multi-state data storage is implemented by individually reading the binary states of the spatially separated charge storage regions in the dielectric.

In order to improve read and program performance, a plurality of charge storage elements or memory transistors in the array are read or programmed in parallel. Thus, the "pages" of the memory elements are read or programmed together. In existing memory architectures, a row can typically contain several interleaved pages or make up a page. All memory elements of the page will be read or programmed together.

In flash memory systems, an erase operation may take as long as one digit in size than read and program operations. Accordingly, it is desirable to have an erase block of considerable size. Therefore, the erase time is reduced for a large group of memory cells.

The characteristic of the flash memory is based on that data must be written to the erased memory location. If data at any logical address from the host will have to be updated, one way is to rewrite the update data in the same physical memory location. That is, the logical to physical address mapping does not change. However, this would mean that the entire erase block containing this physical location would first have to be erased and then rewritten with updated data. Since this update method requires the entire erase block to be erased and rewritten, it is particularly inefficient if only the data to be updated occupies only a small portion of the erase block. In addition, this also increases the erase recycling frequency of the memory block, which is undesirable in view of the limited durability of this type of memory device.

Another problem with managing flash memory systems is the need to use system control and directory data. Data is generated and accessed during the course of various memory operations. As such, its efficient handling and prepared access will directly impact performance. Since flash memory is for storage and non-volatile, it would be desirable to keep this type of data in flash memory. However, as the file management system intervenes between the controller and the flash memory, the data cannot be accessed directly. In addition, system control and directory data tend to be active and fragmented, which is not helpful for storage in systems with large block erases. Typically, this type of data is built into the controller RAM, making it directly accessible by the controller. After the memory device is started up, the initialization process allows the flash memory to be scanned to compile the necessary system control and directory information to be placed in the controller RAM. This process is time consuming and requires controller RAM capacity, even more so with the increasing flash memory capacity.

U. S. Patent 6,567, 307 includes writing update data in a plurality of erased blocks that act as scratch pads and eventually coalescing valid sectors among the various blocks and rewriting the sectors after rearranging them in a logically sequential order. A method of processing sector updates between large erase blocks is disclosed. In this way, blocks need not be erased and rewritten with every minimal update.

Both WO 03/027828 and WO 00/49488 disclose a memory system that handles updates during a large erase block that includes dividing logical sector addresses into zones. Apart from other zones for user data, a small zone logical address range is reserved for active system control data. In this way, manipulation of system control data in its own zone will not interact with associated user data in other zones. The updates are at the logical sector level and the write pointer points to the corresponding physical sectors in the block to be written. The mapping information is buffered in RAM and eventually stored in the main memory's sector allocation table. The latest version of the logical sector will discard all previous versions of existing blocks, which are partially obsolete. Garbage collection is performed to keep partially obsolete blocks up to an acceptable number.

Prior art systems tend to cause the update data to be distributed over many blocks or the update data may partially obsolete many existing blocks. The result is often a large amount of garbage collection required for partially obsolete blocks, which is inefficient and leads to premature aging of memory. In addition, there is no systematic and efficient way of dealing with sequential updates compared to nonsequential updates.

Therefore, there is a general need for high capacity and high performance nonvolatile memory. In particular, there is a need for a high capacity non-volatile memory capable of performing memory operations in large blocks without the above mentioned problems.

Summary of the Invention

A nonvolatile memory system consists of physical groups of physical memory locations. Each physical group (metablock) can be erased as a unit and used to store data of the logical group. The memory management system allows the data of the logical group to be updated by allocating a metablock dedicated to 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 record is in logical order as it was originally stored (sequential) or not (out of order). As a result, the update metablock is closed for further records. One of several processes will take place, but eventually it will end with a fully filled metablock in the exact order that it replaces the original metablock. In the random case, directory data is kept in nonvolatile memory in a manner that aids in frequent updates. The system supports multiple logical groups being updated at the same time.

One feature of the invention allows data to be updated on a logical-group basis. Thus, when a logical group is being updated, the distribution of logical units (and a few memory units in which updates are obsolete) is limited in scope. This is especially true when logical groups are typically nested within physical blocks.

During the update of a logical group, typically one or two blocks need to be allocated to buffer the updated logical units. Accordingly, garbage collection only needs to be performed for a relatively few blocks. Garbage collection of random blocks may be performed by coalescence or compaction.

The efficient use of the update process becomes more apparent in the general processing of update blocks such that no additional block needs to be allocated for random (non-sequential) updates as compared to sequential ones. All update blocks are allocated as sequential update blocks, and any update blocks can be changed to random update blocks. In fact, changing the update block from sequential to random is at its discretion.

Efficient use of system resources allows multiple logical groups to be updated at the same time. This further increases efficiency and reduces overheads.

According to one aspect of the invention, in a nonvolatile memory with a block management system, an improved block replacement scheme is provided for systems that support up to a first predetermined maximum number of update blocks that are simultaneously open for writing data. Is implemented. The update blocks are mainly sequential update blocks, in which data is written in a logically sequential order, but up to a second predetermined maximum number, which may be random update blocks in which the data is not written in a logically sequential order. Each time a new allocation of update blocks causes the update block pool to exceed the first or second predetermined maximum number, one of the existing update blocks in the pool will be closed and removed to comply with the restriction. Prior to closing the update block, its data is merged into the sequential block. An improved approach is to avoid situations where sequential updates can cause an excessive number of random block coalescings. This is accomplished by separating the sequential update blocks and the random update blocks into respective replacement or coalescing pools. In particular, when the sequential update causes the allocation of new update blocks to exceed the first predetermined maximum number, free space is preferentially made in the latest least used sequential update block of the pool.

In current systems, there are generally two types of data: user data and control data. User data is typically sent from the host to the memory system in logical sequential order. Sequential update blocks are allocated to optimally handle sequential write operations from the host. In addition, the user data may be in a logically out of order, especially when there are updates following the logical data. Random update blocks are generated to optimally handle data in an out of order order. Another source of random or out of order data is control data maintained by the file system or memory system, such as file and directory information generated in the course of storing user data.

The previous method to comply with the actual system limit, which supports up to the maximum number of open update blocks simultaneously, was to close the most recently used update blocks in the pool, whether in sequential or random order.

The method is improved over the previous method in which the latest least used sequential update block in the pool is closed, especially if the update block needs to be closed in the pool of blocks during sequential write operations to make free space for new allocation. This allows various update blocks to be effectively used to handle sequential write operations and random write operations. In particular, this avoids the inefficient situation by the host where a large sequential write operation may force premature closure of random update blocks containing FAT and directory information. Another random block will be created almost immediately to store FAT and directory information that will be updated again once a large sequential write operation is performed. Creation of an improved replacement policy is used to avoid the overhead added when merging random blocks during sequential writing and coalescing of potentially open sequential or open random blocks to manage subsequent FAT and directory updates. And separation of coalescing pools.

The generalization of the method is based on a set of attributes, such as whether the update block is storing sequential data or nonsequential data, or what predefined type of system data. To classify update blocks. In implementing a limited number of update blocks pools, each class of update blocks will have its own rules for replacement when the maximum number supported for this class is exceeded.

For example, sequential update blocks and non-sequential update blocks are two different classes. The substitution rules for each of these classes are the same. That is, replace the least active with a new one. Thus, when the pool of sequential update blocks is exceeded, the least active in the pool will be closed and removed before new ones are put into the pool. The same is true for a pool of out of order update blocks.

In general, each class has its own replacement rules, independent of other classes. Examples of replacement rules are to replace the latest least accessed, most recently accessed, least frequently accessed, most frequently accessed, etc., according to corresponding classes.

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

Figure 1 schematically shows the main hardware components of a memory system suitable for implementing the present invention.

2 illustrates a memory organized into sectors (or metablocks) of physical groups and managed by a memory manager of a controller, in accordance with a preferred embodiment of the invention.

3A (i) to 3A (iii) schematically illustrate the mapping between logical groups and metablocks, in accordance with a preferred embodiment of the present invention.

3B schematically illustrates the mapping between logical groups and metablocks.

4 illustrates the alignment of metablocks to structures in physical memory.

5A illustrates metablocks formed by linking minimum erasure units of different planes.

5B illustrates one embodiment where one minimum erase unit (MEU) is selected from each plane to link to the metablock.

5C illustrates another embodiment where more than one MEU is selected from each plane to link to the metablock.

6 is a schematic block diagram of a metablock management system implemented in a controller and a flash memory.

7A shows an example of sectors in a logical group that are written in sequential order to a sequential update block.

7B illustrates an example of sectors in a logical group that are written in random order to the random update block.

8 illustrates an example of sectors in a logical group that are sequentially written to a sequential update block as a result of two separate host write operations with discontinuities at logical addresses.

9 is a flow diagram illustrating a process by an update block manager to update data in a logical group, in accordance with a general embodiment of the invention.

10 is a flow diagram illustrating a process by an update block manager to update data in a logical group, in accordance with a preferred embodiment of the invention.

11A is a flow diagram illustrating in more detail the coalescing process of closing the random update block shown in FIG. 10.

FIG. 11B is a flow chart illustrating in more detail the compression process for closing the random update block shown in FIG. 10.

12A shows all possible states of a logical group, and possible transitions between them under various operations.

12B is a table listing the possible states of a logical group.

13A shows all possible states of a metablock, and possible transitions between them under various operations. A metablock is a physical group corresponding to a logical group.

13B is a table listing the possible states of a metablock.

14 (a) to 14 (j) are state diagrams showing the effects of various operations on the state of a logical group and the physical metablock.

Figure 15 shows a preferred embodiment of the structure of an allocation block list (ABL) for tracking open and closed update blocks and blocks erased for allocation.

16A illustrates data fields of an out of order block index (CBI) sector.

16B illustrates an example where random block index (CBI) sectors are written to a dedicated metablock.

16C is a flow diagram illustrating access to data of logical sectors of a given logical group being randomly updated.

FIG. 16D is a flow diagram illustrating access to data of a logical sector of a given logical group being randomly updated, according to an alternative embodiment where the logical group is divided into subgroups.

16E illustrates examples of random block index (CBI) sectors and their functions in an embodiment where each logical group is divided into a plurality of subgroups.

17A illustrates data fields of a group address table (GAT) sector.

17B illustrates an example in which group address table (GAT) sectors are written to a GAT block.

18 is a schematic block diagram illustrating the distribution and flow of control and directory information for use and recycling of erased blocks.

19 is a flowchart illustrating a process of logical to physical address translation.

20 illustrates a hierarchy of operations performed on control data structures during the operation of memory management.

21 schematically illustrates two defined limits on the number of update blocks for a block management system.

FIG. 22 shows typical examples of combinations of two limitations that are optimal for various memory devices.

FIG. 23A schematically illustrates an update pool of a “5-2” configuration as described in FIG. 22.

Figure 23b schematically illustrates the closing of the least active update block to make free space for a new update block, according to the previous method.

FIG. 23C schematically illustrates putting a newly allocated update block into a pool after a closed update block has been removed to make free space.

FIG. 24A schematically illustrates an update pool of "5-2" as described in FIG.

24B schematically illustrates the closure of a minimum active update block to make free space for a new update block, according to the previous method.

24C schematically illustrates putting a new allocated update block into a pool after a closed update block has been removed to make free space.

FIG. 25A illustrates the method previously shown in FIG. 10, step 410, and in FIGS. 23B and 24B in which the most recently accessed update block is closed whenever a new assignment exceeds a predetermined limit.

FIG. 25B illustrates the method previously shown in FIG. 10, step 370 where the most recently accessed randomized (non-sequential) update block is closed whenever the number of random update blocks exceeds a predetermined limit.

FIG. 26A schematically illustrates an update pool of a “5-2” configuration as described in FIG. 22.

FIG. 26B schematically illustrates the closure of one of the pools of update blocks to make free space for a new update block, according to the present improved method.

FIG. 26C schematically illustrates putting a newly allocated update block into a pool after a closed update block has been removed to make free space.

FIG. 27A schematically illustrates an update pool of a “5-2” configuration as described in FIG. 22.

27B schematically illustrates the closure of one of the pools of update blocks to make free space for a new update block, in accordance with the present improved method.

FIG. 27C schematically illustrates the insertion of a new random update block into a pool after another random update block is closed and removed to make room.

28 is a flowchart illustrating the present improved method of managing a limited set of update blocks during sequential update, according to the first embodiment.

29 is a flowchart illustrating the present improved method of managing a limited set of update blocks having two predetermined limits, according to the second embodiment.

30 is a flow diagram illustrating the present improved method of 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 invention may be implemented. Similar memory systems are disclosed in US Patent Application Publication No. US-2005-0144365-A1 entitled " Non-Volatile Memory and Method with Control Data Management " by Gorobets et al.

Figure 1 schematically shows the main hardware components of a memory system suitable for implementing the present invention. Memory system 20 typically operates with host 10 via a host interface. The memory system is typically in the form of a memory card or an embedded memory system. The memory system 20 includes a memory 200 in which operations are controlled by the controller 100. The memory 200 is composed of one or more arrays of nonvolatile memory cells distributed over one or more integrated circuit chips. The controller 100 includes an interface 110, a processor 120, an optional coprocessor 121, a read only memory (ROM) 122, a random access memory (RAM) 130, and an optionally programmable nonvolatile memory. 124. The interface 110 has one component that interfaces the controller to the host and another component that interfaces with the memory 200. Firmware stored in nonvolatile ROM 122 and / or optional nonvolatile memory 124 provides code for processor 120 to implement the functions of controller 100. Error correction codes may be processed by processor 120 or optional coprocessor 121. In alternative embodiments, controller 100 is implemented by a state machine (not shown). In another embodiment, the controller 100 is implemented in a host.

Logical and Physical Block Structures

2 illustrates a memory organized into sectors (or metablocks) of physical groups and managed by a memory manager of a controller, in accordance with a preferred embodiment of the invention. Memory 200 is organized into metablocks, each metablock being a group of physical sectors S ₀ ,..., S _N-1 that can be erased together.

Host 10 accesses memory 200 when running an application under a file system or operating system. Typically, the host system addresses the data in units of logical sectors, for example, where each sector may contain 512 bytes of data. It is also common for a host to read or write to a unit of logical clusters, each cluster consisting of one or more logical sectors. In some host systems, there may be an optional host-side memory manager to perform low levels of memory management at the host. In most cases, during read or write operations, the host 10 essentially issues a command to the memory system 20 to read or write a segment containing data of a string of logical sectors with consecutive addresses. do.

The memory-side memory manager is implemented within the controller 100 of the memory system 20 to manage the storage and retrieval of data of host logical sectors among the metablocks of the flash memory 200. In a preferred embodiment, the memory manager incorporates a number of software modules for managing erase, read and write operations of metablocks. The memory manager also maintains system control and directory data associated with its operation in flash memory 200 and controller RAM 130.

3A (i) to 3A (iii) schematically illustrate the mapping between logical groups and metablocks, in accordance with a preferred embodiment of the present invention. The metablock of physical memory has N physical sectors to store data of N logical sectors of a logical group. 3A (i) shows data from logical group LG _i , where logical sectors are in contiguous logical order 0, 1,..., N-1. 3A (ii) shows that the same data is stored in the metablock in the same logical order. Metablocks are said to be "sequential" when stored this way. In general, metablocks may cause data to be stored in a different order, in which case the metablocks are referred to as "out of order" or "chaotic".

There may be an offset between the lowest address of the logical group and the lowest address of this metablock to which the metablock is mapped. In this case, the logical sector address is wrapped as a loop from the bottom to the top of the logical group in the metablock. For example, in FIG. 3A (iii), the metablock is stored at its first location, starting with the data of logical sector k. When the last logical sector N-1 is reached, it is wrapped in sector 0 and finally stores the data associated with logical sector k-1 in the last physical sector. In a preferred embodiment, the page tag is used to identify any offset, such as identifying the starting logical sector address of data stored in the first physical sector of the metablock. When the logical sectors of the two blocks differ only by the page tag, these two blocks will be considered to ensure that they are stored in a similar order.

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

Other types of mapping logical groups to metablocks are also contemplated. For example, metablocks with variable sizes are disclosed together in the US patent application, pending and co-pending under the name “Adaptive Metablocks” filed by Alan Sinclair on the same day as the present application. The entire disclosure of the co-pending application is hereby incorporated by reference.

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

Unlike prior art systems, system sectors (ie, file allocation tables, directories, or sub-directories) to localize sectors in the logical address space that may contain data with high-frequency and small size updates. There is no special partitioning or zoning of the sectors involved). Instead, the present method of updating sectors of logical groups will effectively handle the access patterns typical for system sectors, as well as the access patterns typical for file data.

4 illustrates the alignment of metablocks in structures in physical memory. The flash memory includes memory cells of blocks that can be erased together as a unit. These erase blocks are the minimum unit of erase of flash memory or the minimum erasable unit of memory (MEU). Although it is possible to construct a "super MEU" containing more than one MEU in some memory systems that support the erasure of multiple MEUs, the minimum erase unit is a hardware design parameter of the memory. For a flash EEPROM, the MEU may comprise one sector, but preferably a plurality of sectors. In the example shown, it has M sectors. In a 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 the metablock consists of P PEUs and each MEU contains M sectors, then each metablock will have N = P * M sectors.

The metablock represents a group of memory locations, for example, 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, where one metablock is the minimum erase unit. Within this specification, the terms "metablock" and "block" are used synonymously to define the minimum erase unit at the system level for media management, and the term "minimum erase unit" or MEU is the minimum erase of the flash memory. Used to represent units.

Minimum erase units for forming the metablock ( MEU ) 'S link

In order to maximize the programming speed and the erase speed, the information of a plurality of pages located in the plurality of MEUs is programmed in parallel, and the parallelism is utilized as much as possible by arranging the plurality of MEUs to be erased in parallel.

In flash memory, pages are grouped memory cells that can be programmed together in a single operation. The page may include one or more sectors. Also, a memory array can be partitioned into more than one plane, where only one MEU in one plane can be programmed or erased at a time. Finally, planes may be distributed among one or more memory chips.

In flash memory, MEUs may include one or more pages. MEUs in a flash memory chip can be organized into planes. Since one MEU from each plane can be programmed or erased simultaneously, it is convenient to form a plurality of MEU metablocks by selecting one MEU from each plane (see FIG. 5B below).

5A illustrates metablocks formed by linking minimum erasure units of different planes. Each metablock, such as MB0, MB1, ..., consists of MEUs from different planes of the memory system, where the different planes can be distributed between one or more chips. The metablock link manager 170 shown in FIG. 2 manages linking MEUs for each metablock. Each metablock is configured during the initial format process and preserves MEUs that are components of this metablock throughout the life of the system, unless there is a failure of one of the MEUs.

5B illustrates one embodiment where one minimum erase unit (MEU) is selected from each plane to link to the metablock.

5C illustrates another embodiment where more than one MEU is selected from each plane to link to the metablock. In another embodiment, more than one MEU may be selected from each plane to form a super MEU. For example, a super MEU can be formed from two MEUs. In this case, one or more passes may be taken for read or write operations.

Linking and relinking MEUs to metablocks is also disclosed on the same day as the present application, filed with Carlos Gonzales et al., Pending US patent application entitled "Adaptive Deterministic Grouping of Blocks into Multi-Block Structures". It is. The entire disclosure of the co-pending application is hereby incorporated by reference.

Metablock  management

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

The interface 110 allows the metablock management system to interface with the host system. Logical to physical address translation module 140 maps logical addresses from the host to host to physical memory locations. The update block manager module 150 manages in-memory data update operations for data of a given logical group. The erased block manager 160 manages the erase operation of metablocks and the allocation of these metablocks for storage of new information. The metablock link manager 170 manages linking sub-groups of sectors of the minimum erasable blocks making up a given metablock. Details of these modules will be given in their respective paragraphs.

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 tends to be small and frequently changing data, it cannot be easily stored or efficiently maintained in a flash memory having a large block structure. Hierarchical and distributed methods are employed to store more static control data while non-volatile flash memory places small amounts of more variable control data in the controller RAM for more efficient updating and access. In the case of a power shutdown or failure, this method scans a small set of control data in the nonvolatile memory, thereby allowing the control data to be quickly rebuilt into the nonvolatile controller RAM. This limits the number of blocks associated with possible activity of data in a given logical group. Accordingly, scanning is limited. In addition, some control data requiring persistence are stored in non-volatile metablocks that can be updated sector by sector, with each update resulting in a new sector replacing the old one. A sector indexing method is employed for the control data to track sector-by-sector updates in the metablock.

The nonvolatile memory 200 stores a relatively static large amount of control data. This includes group address tables (GAT) 210, random block indexes (CBI) 220, erased block lists (EBL) 230, and MAP 240. GAT 210 tracks the mapping between sectors of logical groups and their corresponding metablocks. The mapping does not change except for those that are updated. CBI 220 tracks the mapping of sectors that are logically out of order during the update. The EBL 230 keeps track of the erased metablock pool. The MAP 240 is a bitmap showing the erase state of all metablocks in the flash memory.

Volatile controller RAM 130 stores small portions of control data that are frequently changed and accessed. This includes the allocation block list (ABL) 134 and the cleared block list (CBL) 136. The CBL 136 tracks the de-allocated and erased metablocks while the ABL 134 tracks the allocation of metablocks to record the update data. In a preferred embodiment, RAM 130 acts as a cache for control data stored in flash memory 200.

update  Block manager

The update block manager 150 (shown in FIG. 2) handles updating of logical groups. According to one aspect of the invention, sectors of each logical group to be updated are assigned a dedicated update metablock for recording update data. In a preferred embodiment, any segment of one or more sectors of the logical group will be written to the update block. The update block may be managed to receive the updated data in sequential order or out of order (also known as random order). The random update block allows sector data to be updated in any order within the logical group, and by randomly repeating the individual sectors. In particular, the sequential update block can be an out-of-order update block, without the need for relocation of any data sectors. No predetermined allocation of blocks is required for random data update, where out of order writing to any logical address is automatically adjusted. Thus, unlike prior art systems, there is no special handling whether the various update segments of a logical group are in logical sequential or out of order. The generic update block will simply be used to record the various segments in the order requested by the host. For example, even though host system data or system control data tends to be updated in an unordered manner, regions of the logical address space corresponding to host system data need not be treated differently than regions with host user data.

The data of sectors of the complete logical group is preferably stored in a single metablock in a logically sequential order. Thus, the index of stored logical sectors is predefined. When a metablock has all sectors of a given logical group in storage in a predefined order, it is said to be "intact". Regarding the update block, when it is eventually completely filled with update blocks in a logically sequential order, the update block will be an updated intact metablock that easily replaces the original metablock. On the other hand, if the update block is completely populated with update data in a logically different order than the intact block, then the update block is an out-of-order or out-of-order update block and the out-of-order segments will eventually have the same update data in the logical group as the intact block. It must be further processed to be stored in order. In the preferred case, this is in logically sequential order in a single metablock. Further processing involves incorporating the updated sectors in the update block into another update metablock along with the unchanged sectors in the original block. The merged update blocks will be in logically sequential order and can be used to replace the original block. Under certain predetermined conditions, the coalescing process is preceded by one or more compression processes. The compression process simply rewrites the sectors of the random update block to the replacement random block, removing any duplicate logical sectors that were obsolete by subsequent updates of the same logical sector.

The update method allows a plurality of update threads to proceed simultaneously up to a predefined maximum. Each thread is a logical group that is updated using its own update metablock.

Sequential data update

When data belonging to a logical group is first updated, a metablock is allocated and dedicated as an update block for update data of the logical group. The update block is allocated when a command is received from the host to write a segment of one or more sectors of the logical group in which the existing metablock has stored all its sectors intact. In the first host write operation, data of the first segment is written in an update block. Since each host write is a segment of one or more sectors with consecutive logical addresses, the first update is therefore virtually always sequential. In subsequent host writes, update segments in the same logical group are written into the update block in the order received from the host. The block continues to be managed as a sequential update block while the sectors updated by the host in the associated logical group remain logically sequential. All updated sectors in this logical group are written to this block until this sequential update block is closed or switched to an unsequential update block.

FIG. 7A illustrates an example in which sectors in a logical group are written in sequential update block in sequential update block as a result of two separate host write operations, with corresponding sectors in the original block for the logical group being obsolete. In host write operation # 1, data in logical sectors LS5 to LS8 are being updated. Data updated as LS5 'to LS8' is recorded in a newly allocated dedicated update block.

For convenience, the first sector to be updated in the logical group is written to a dedicated update block starting from the first physical sector location. 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 start of the logical group and the start of the update block. This offset is known as the page tag as described above with respect to FIG. 3A. Subsequent sectors are updated in a logically sequential order. When the last sector of the logical group is written, the group addresses are wrapped and the write sequence continues at the first sector of the group.

In host write operation # 2, one segment of data is updated in the logical sectors LS9 to LS12. The data updated as LS9 'to LS12' is recorded in a dedicated update block at the position immediately after the last write end. It can be seen that the two host writes cause the update data to be written to the update block in a logically sequential order, that is, LS5 'to LS12'. Update blocks are considered as sequential update blocks because they are filled in a logically sequential order. The recorded update data in the update block discards the corresponding ones in the original block.

Random data update

Random update block management may be initiated for an existing sequential update block when any sector updated by the host in the associated logical group is logically out of order. The random update block is in the form of a data update block in which logical sectors in the associated logical group can be updated in any order and with any amount of repetition. This is created by switching from the sequential update block to the previously written sector in the logical group being updated when the sector written by the host is logically out of order. All sectors that are updated following this logical group are written to the next available sector location in the random update block, whatever their logical sector address is in the group.

FIG. 7B illustrates that random sectors in the original block for the logical group and dual sectors in the randomized update block are written out of order in the randomized update block as a result of five separate host write operations. Examples of sectors in a logical group are shown. In host write operation # 1, logical sectors LS10-LS11 of a given logical group stored in the original metablock are updated. The updated logical sectors LS10 'to LS11' are stored in a newly allocated update block. At this time, the update block is a sequential block. In host write operation # 2, logical sectors LS5 to LS6 are updated as LS5 'to LS6' and written to the update block at the position immediately after the last write. This converts the update block from sequential to random. In host write operation # 3, the logical sector LS10 is being updated again and written to the next position of the update block as LS10 ", where LS10" in the update block replaces LS10 in the original block by replacing LS10 'in the previous write. do. In host write operation # 4, the data in logical sector LS10 is updated again and written to the next position of the update block as LS10 "'. Accordingly, LS10"' is now the latest and unique to logical sector LS10. Valid data. In host write operation # 5, data is being updated in logical sector LS30 and written to the update block as LS30 '. Thus, the example illustrates that sectors within a logical group may be written to the randomized update block in any order, randomly and repeatedly.

Forced sequencing update

8 illustrates an example in which sectors are written in a sequential update block in a sequential update block as a result of two separate host write operations with discontinuities in logical addresses. In host write # 1, update data in the logical sectors LS5 to LS8 are recorded in a dedicated update block as LS5 'to LS8'. In host write # 2, update data in the logical sectors LS14 to LS16 are written to the update block after the last write as LS14 'to LS16'. However, there is an address jump between LS8 and LS14 and host write # 2 will normally cause the update block out of order. Since the address jump is not sequential, one choice is to perform the padding operation # 2A by first copying the data of intervening sectors from the original block to the update block before executing host write # 2. Accordingly, the sequential characteristics of the update block are preserved.

9 is a flow diagram illustrating a process by an update block manager to update data in a logical group, in accordance with a general embodiment of the invention. The update process includes the following steps.

Step 260: The memory is organized into blocks, where each block is divided into erasable memory units, each memory unit storing data in logical units.

Step 262: The data is organized into logical groups, each logical grouping being divided into logical units.

Step 264: In the standard case, all logical units of a logical group are stored between the memory units of the original block in a first defined order, preferably in logically sequential order. In this way, the index for accessing the individual logical units in the block is known.

Step 270: For data of a given logical group (eg, LG _X ), a request is made to update the logical unit in LG _X. (Logical unit updates are given by way of example. In general, an update will be a segment of one or more consecutive logical units within LG _X ).

Step 272: The requested update logical unit should be stored in a second block dedicated to recording updates of LG _X. The recording order follows a second order, typically the order in which updates are requested. One feature of the invention is that it is possible to build an update block that is initially comprehensive in recording data in a logically sequential or random order. Thus, according to the second order, the second block may be sequential or random.

Step 274: The second block causes the process to loop back to step 270 so that the requested logical units continue to be written. The second block will be closed for receiving further updates when certain conditions for closure are specified. In this case, the process proceeds to step 276.

Step 276: It is determined whether the closed second block has its update logic units written in an order similar to that of the original block. The two blocks are considered to have a similar order when their written logical units differ only by the page tag, as described with respect to FIG. 3A. If the two blocks have a similar order, the process proceeds to step 280; otherwise, some sort of garbage collection needs to be performed in step 290.

Step 280: Since the second block has the same order as the first block, it is used to replace the original first block. The update process ends at step 299.

Step 290: The most recent version of each logical unit of a given logical group is collected among a second block (update block) and a first block (one block). Merged logical units of a given logical group are written to the third block in an order similar to the first block.

Step 292: Since the third block (merged block) has a similar order as the first block, it is used to replace the original first block. The update process ends at step 299.

Step 299: When the closure process creates an intact update block, this becomes a new standard block for a given logical group. The update thread for the logical group will end.

10 is a flow diagram illustrating a process by an update block manager to update data in a logical group, in accordance with a preferred embodiment of the invention. The update process includes the following steps.

Step 310: For a given logical group (eg, LG _X ) data, a request is made to update a logical sector within LG _X. (Sector updates are given by way of example. In general, the update will be a segment of one or more consecutive logical sectors in the LG _X ).

Step 312: If there is no update block dedicated to LG _X already, proceed to step 410 to initiate a new update thread for the logical group. This will be accomplished by assigning an update block dedicated to writing the update data of the logical group. If there is already an open update block, proceed to step 314 to begin writing an update sector to the update block.

Step 314: If the current update block is already out of order (ie, out of order), simply proceed to step 510 to write the requested update sector to the out of order update block. If the current update block is sequential, flow proceeds to step 316 for processing of the sequential update block.

Step 316: One feature of the invention allows an update block to be built up initially to be comprehensive in writing data in a logically sequential or random order. However, it is desirable to keep the update blocks as sequential as possible, since the logical grouping eventually causes its data to be stored in the metablock in a logically sequential order. Since no garbage collection will then be needed, less processing will be required when the update block is closed for further updates.

Accordingly, it is determined whether the requested update will be in accordance with the current sequential order of the update block. If the updates follow sequentially, proceed to step 510 to perform sequential updates, and the update block will be in sequential state. On the other hand, if the updates are not in sequence (random update), this will switch the sequential update block out of order if no other actions are taken.

In one embodiment, nothing is done to save the situation and the process is allowed to update to go straight to step 370 and switch the update block to random.

Optional forced sequential process

In another embodiment, forced sequential process step 320 is optionally performed to maintain sequential update blocks as much as possible for current random order updates. There are two situations, both of which require copying sectors missing from the original block to maintain the sequential order of the logical sectors written to the update block. The first situation is when the update causes a short address jump. The second situation is to close this update block early to keep the update blocks in sequential state. The forced sequential process step 320 includes the following substeps.

Step 330: If the update causes a logical address jump not greater than the predetermined amount C _B , the process proceeds to a forced sequential update process in step 350, otherwise the process proceeds to step 340 to consider whether the process is eligible for forced sequential closure. do.

Step 340: If the number of unfilled physical sectors exceeds a predetermined design parameter C _C where half of the size of the update block is a typical value, the update block is relatively unused and will not close early. The process proceeds to step 370 where the update block will be out of order. On the other hand, if the update block is significantly filled, it is considered already used and therefore proceeds to step 360 for forced sequential closure.

Step 350: Forced sequential update keeps the current sequential update block in sequential state as long as the address hop exceeds a predetermined amount C _B. Essentially, sectors from the associated original block of the update block are copied to fill the gap of size by address hop. Accordingly, the sequential update block will be padded with data in intervening addresses before proceeding to step 510 to sequentially record the current update.

Step 360: Forced sequential closure causes the current sequential update block to be closed if it has already been sufficiently filled rather than switched to being out of order by the current random order update. Out of order or out of order updates are defined as having forward address transitions, reverse address transitions, or address repetitions not covered by the address operation exception described above. To prevent the sequential update block from being switched by random updates, the unwritten sector positions of the update block are filled by copying sectors from the associated original partially obsolete block of the update block. The original block can be completely obsolete and erased. The current update block now has a complete set of logical sectors and is then closed as an intact metablock replacing the original metablock. The process then proceeds to step 430 where a new update block is assigned to it to accept a record of the current sector update that was originally requested in step 310.

Random update  Switch to block

Step 370: When the update of the issues is not in sequential order, and optionally, if the forced sequential conditions are not satisfied, the update sector of the issue with the non-sequential address can be written to the update block when the process proceeds to step 510. By virtue, the sequential update block is allowed to transition to being out of order. If there is a maximum number of random update blocks, it is necessary to close the recently minimum accessed random update block before allowing the transition to proceed, thus preventing the maximum number of random blocks from being exceeded. The identification of the latest minimally accessed random update block is the same as the general case described in step 420, but limited to random update blocks only. Closing the random update block at this time is accomplished by coalescing as described in step 550.

New under system constraints update  Block allocation

Step 410: The process of assigning an erase metablock as an update block begins with determining whether a predetermined system limit has been exceeded. Due to finite resources, the memory management system typically allows a certain maximum number of update blocks U _MAX to exist simultaneously. This limit is a collection of sequential update blocks and random update blocks, and is a design parameter. In a preferred embodiment, the limit is for example up to eight update blocks. Also, due to a higher demand for system resources, there may be a corresponding predetermined restriction on the maximum number of random update blocks that can be open at the same time (eg, four).

Thus, when U _MAX update blocks have already been allocated, the next allocation request may be satisfied only after closing one of the existing allocated ones. The process proceeds to step 420. When the number of open update blocks is less than C _A , the process proceeds directly to step 430.

Step 420: If the maximum number of update blocks C _A is exceeded, the most recently accessed update block is closed and garbage collection is performed. The latest least accessed update block is identified as the update block associated with the most recently accessed logical block. For the purpose of determining the latest minimally accessed update blocks, the access includes writes and optionally reads of logical sectors. The list of open update blocks is maintained in the order of access: In initialization, no access order is assumed. Closure of the update block is done following the similar process described with respect to steps 360 and 530 when the update block is sequential and with respect to step 540 when the update block is random. Closure creates an empty space for allocation of the new update block at step 430.

Step 430: The allocation request is fulfilled by assignment of a new metablock as an update block dedicated to a given logical group LG _X. The process then goes to step 510.

In the update block update  Record data

Step 510: The requested update sector is written to the next available physical location of the update block. The process then proceeds to step 520 to determine whether the update block can be closed.

update  Block closure

Step 520: If the update block still has space to accept additional updates, go to step 570. Otherwise go to step 522 and close the update block. There are two possible implementations that fill the update block when the currently requested write attempts to write more logical sectors than the block has that space. In a first implementation, the write request is split into two parts, the first part being writing up to the last physical sector of the block. The block will then be closed and the second portion of the write will be treated as the next requested write. In another implementation, the requested write is held while the block is closed after causing the rest of its sectors to be padded. The requested entry will be treated as the next requested entry.

Step 522: If the update blocks are sequential, go to step 530 for sequential closure. If the update block is random, go to step 540 for random closure.

Sequential update  Block closure

Step 530: Since the update blocks are sequential and full, the logical group stored therein is intact. The metablock is intact and replaces the original. At this time, the original block is completely used and may be erased. The process then proceeds to step 570, where the update for the given logical group ends.

Random update  Block closure

Step 540: Since the update block is filled out of order and can contain multiple updates of certain logical sectors, garbage collection is performed to obtain valid data thereon. The random update block will be compressed or coalesced. Which process will be performed will be determined in step 542.

Step 542: Performing compression or coalescing will follow the deterioration of the update block. If a logical sector is updated many times, its logical address becomes very bad. There will be multiple versions of the same logical sector written to the update block and only the last recorded version is a valid version for this logical sector. In an update block containing logical sectors having multiple versions, the number of distinct logical sectors will be much less than the number of logical groups.

In a preferred embodiment, when the number of distinct logical sectors in the update block exceeds a predetermined design parameter C _D with a typical value that is half the size of the logical group, the closing process will perform coalescing in step 550, otherwise The process will proceed with the compression at step 560.

Step 550: If the random update block is to be coalesced, the original block and the update block will be replaced by a new standard metablock containing the coalesced data. After coalescing, the update thread will end at step 570.

Step 560: If the random update block is to be compressed, it will be replaced by a new update block with compressed data. Processing of the compressed update block after compression will end at step 570. Alternatively, compression can be delayed until the update block is rewritten, thus eliminating the possibility of coalescing following compaction and without intervening updates. The new update block will be used to update the given logical block again when the next request for update to LG _X appears in step 502.

Step 570: When the closure process creates an intact update block, it becomes a new standard block for a given logical group. The update thread for the logical group will end. When the closure process creates a new update block that replaces an existing block, the new update block will be used to record the next update requested for a given logical group. When the update block is not closed, processing will continue when the next request for update in LG _X appears in step 310.

As can be seen from the process described above, when the random update block is closed, the update data recorded therein is further processed. In particular its valid data is garbage collected by the process of compression into another random block, or by the process of forming a new standard sequential block incorporating its associated raw block.

11A is a flow diagram illustrating in more detail the coalescing process of closing the random update block shown in FIG. 10. Random update block coalescing is one of two possible processes that are performed when the update block is closing, for example when the update block is filled with all the last physical sectors of this block written. The coalescing is selected when the number of distinct logical sectors written in the block exceeds a predetermined design parameter C _D. The coalescing process step 550 shown in FIG. 10 includes the following substeps.

Step 551: When the random update block is closing, a new metroblock to replace it will be allocated.

Step 552: Ignore all discarded sectors and collect the most recent version of each logical sector among the random update block and its associated original block.

Step 554: Record the collected valid sectors in a logically sequential order in a new metablock to form an intact block, ie a block with all logical sectors of the logical group written in sequential order.

Step 556: Replace the original block with a new intact block.

Step 558: Clear the closed update block and the original block.

FIG. 11B is a flow chart illustrating in more detail the compression process for closing the random update block shown in FIG. 10. Compression is selected when the number of distinct logical sectors written in the block is less than the predetermined design parameter C _D. The compression process step 560 shown in FIG. 10 includes the following substeps.

Step 561: When the random update block is being compressed, a new metablock to replace it will be allocated.

Step 562: Gather the latest version of each logical sector among the existing random update blocks to be compressed.

Step 564: Write the collected sectors to a new update block to form a new update block with the compressed sectors.

Step 566: Replace the existing update block with a new update block with compressed sectors.

Step 568: Clear the closed update block.

Logic and Metablock  States

12A shows all possible states of a logical group, and possible transitions between them under various operations.

12B is a table listing the possible states of a logical group. Logical group states are defined as follows.

1. Intact: All logical sectors in a logical group were written to a single metablock in a logically sequential order, perhaps with wrapped page tags.

2. Unwritten: No logical sectors in the logical group have been written. The logical group is marked as unwritten in the group address table and does not have an assigned metablock. The predefined data pattern is returned in response to the host read for all sectors in this group.

3. Sequential Update: Some sectors in the logical group have been written in logically sequential order in the metablock, perhaps using page tags, thus replacing the corresponding logical sectors from any previous intact state of the group.

4. Out of order update: Some sectors in the logical group have been written logically in a non-sequential order in the metablock, perhaps using page tags, so that they replace the corresponding logical sectors from any previous intact state of the group. do. Sectors in a group may be written more than once, with the latest version replacing all previous versions.

13A shows all possible states of a metablock, and possible transitions between them under various operations.

13B is a table listing the possible states of a metablock. Metablock states are defined as follows.

1. Erase: All sectors in the metablock are erased.

2. Sequential Update: The metablock probably uses page tags, where sectors are partially written in a logically sequential order. All sectors belong to the same logical group.

3. Out-of-order update: A metablock is where sectors are partially or wholly written in logically out of order. Any sector may be written more than once. All sectors belong to the same logical group.

4: Intact: Metablocks are written globally in a logically sequential order, perhaps using page tags.

5: Original: Metablock was previously intact, but at least one sector was obsolete by host data update.

14 (a) to 14 (j) are state diagrams showing the effects of various operations on the state of a logical group and the physical metablock.

14A shows state diagrams corresponding to logical group and metablock transitions for a first write operation. The host writes one or more sectors of a previously unwritten logical group to the newly allocated erased metablock in a logically sequential order. Logical groups and metablocks go into a sequential update state.

14 (b) is a state diagram corresponding to logical group and metablock transitions for the first sanity operation. The previously written sequential update logical group is intact when all sectors have been written sequentially by the host. Further, the transition can occur if the group is filled by filling the remaining unwritten sectors with a predefined data pattern. The metablock is intact.

14C is a state diagram corresponding to logical group and metablock transitions for the first random operation. The previously unwritten sequential update logical group is out of order when at least one sector is written out of order by the host.

14 (d) is a state diagram corresponding to logical group and metablock transitions for the first compression operation. All valid sectors in a previously unordered random update logical group are copied from the previous block into a new random metablock, which is then erased.

14 (e) is a state diagram corresponding to logical group and metablock transitions for the first coalescing operation. All valid sectors in the unwritten random update logical group are moved from the previous block to fill the newly allocated erased block in a logically sequential order. Sectors not written by the host are filled with a predefined data pattern. The previous random block is then erased.

14 (f) is a state diagram corresponding to logical group and metablock transitions for a sequential write operation. The host writes one or more sectors of an intact logical group into the newly allocated erased metablock in logically sequential order. Logical groups and metablocks go into a sequential update state. Previously intact metablocks become original metablocks.

14 (g) is a state diagram corresponding to logical group and metablock transitions for sequential filling operation. The sequential update logical group is intact when all its sectors are sequentially written by the host. In addition, this may occur during garbage erasing when the sequential update logical group is filled with valid sectors from the original block in order to be intact, after which the original block is erased.

14 (h) is a state diagram corresponding to logical group and metablock transitions for an out of order write operation. The sequential update logical group is out of order when at least one sector is written out of order by the host. Out of order sector writes may cause valid sectors in the update block or the corresponding original block to be discarded.

14 (i) is a state diagram corresponding to logical group and metablock transitions for the compression operation. All valid sectors in the randomized logical group are copied from the previous block into a new randomized metablock, which is then erased. The original block is not affected.

14 (j) is a phase attitude corresponding to logical group and metablock transitions for coalescing operation. All valid sectors in the random update logical group are copied from the previous random blocks and the original block to fill the newly allocated erased blocks in a logically sequential order. The previous random block and the original block are then erased.

update  Block tracking and management

Figure 15 shows a preferred embodiment of the structure of an allocation block list (ABL) for tracking open and closed update blocks and blocks erased for allocation. An allocation block list (ABL) 610 is maintained in the controller RAM 130 to enable management of the allocation of erased blocks, allocated update blocks, associated blocks and control structures, and provides accurate logic to physical Enable address translation. In a 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 open update block list has one entry for each data update block that is currently open. Each entry holds the following information: LG is the logical group address to which the update metablock is currently dedicated. Sequential / out of order is a state indicating whether the update block has been filled with sequential or out of order update data. MB is the metablock address of the update block. The page tag is the starting logical sector written to the first physical location of the update block. The number of sectors written represents 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 associated circle block.

The closed update block list 616 is part of the allocation block list ABL. This is a set of block entries in the ABL with the attributes of the closed update block. The closed update block list has one entry for each data update block that is closed but the entry is not updated in the logical versus primary physical directory. Each entry holds the following information: LG is the logical group address to which the update block is currently dedicated. MB is the metablock address of the update block. The page tag is the starting logical sector written to the first physical location of the update block. MB ₀ is the metablock address of the associated original block.

Random Block Index

Sequential update blocks have data stored in a logically sequential order, so that any logical sector in the block can be easily found. The random update block has its logical sectors stored out of order and may store a plurality of update occurrences of the logical sector. Additional information must be maintained to track where each valid logical sector is located in the random update block.

In the preferred embodiment, the random block index data structures allow for fast access and tracking of all valid sectors in the random block. The random block index manages the logical address space of small areas independently, and efficiently handles system data and hot areas of user data. Performance is not significantly affected since index data structures have inherently infrequent update requirements and allow index information to be maintained in flash memory. On the other hand, the list of recently written sectors in the random blocks are kept in the random sector list in the controller RAM. In addition, a cache of index information from flash memory is maintained in the controller RAM to minimize the number of flash sector accesses for address translation. Indexes for each random block are stored in random block index (CBI) sectors in flash memory.

16A illustrates data fields of an out of order block index (CBI) sector. An random block index sector (CBI sector) contains an index for each sector in the logical group that is mapped to the random update block, and defines the location of each sector in the logical group in the random update block or its associated original block. A CBI sector is a valid CBI in a random block index for tracking valid sectors in an unordered block, an unordered block information field for tracking address parameters for an unordered block, and a metablock (CBI block) that stores CBI sectors. A sector index field for tracking sectors.

16B illustrates an example where random block index (CBI) sectors are written to a dedicated metablock. The dedicated metablock will be 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 can exist in the CBI block, only the last written copy is valid. For example, the CBI sector for logical group LG ₁ has been updated three times and the latest version is valid. The location of each valid sector in the CBI block is identified by a set of indices in the last written CBI sector in the block. In this example, the last CBI sector written to the block is the CBI sector for LG ₁₃₆ and its set of indices is valid to replace all previous ones. When the CBI block eventually becomes full with CBI sectors, the block is compressed during the control write operation by rewriting all valid sectors to the new block position. The entire block is then erased.

The random block index field in the CBI sector contains an index entry for each logical sector in the sub-group that maps to the logical group or random update block. Each index entry represents an offset in the random update block in which valid data for the corresponding logical sector is located. The reserved index value indicates that no valid data for the logical sector is present in the random update block and the corresponding sector in the associated original block is valid. A cache of some random block index field entries is maintained in the controller RAM.

The Random Block Information field in the CBI sector contains one entry for each Random Update block that records address parameter information for the block that exists in the system. Information in this field is only valid for the last sector written in the CBI block. This information is also in the data structures in RAM.

The entry for each random update block contains three address parameters. The first is the logical address of the logical group (or logical group number) associated with the random update block. The second is the metablock address of the random update block. The third is the physical address offset of the last sector written to the random update block. The offset information sets the starting point for scanning of the random update block during initialization, rebuilding the data structures in RAM.

The sector index field contains an entry for each valid CBI sector in the CBI block. This defines the offsets in the CBI block in which the most recently written CBI sectors associated with each allowed random update block are located. The reserved value of the offset in the index indicates that no random update block allowed.

16C is a flow diagram illustrating access to data of logical sectors of a given logical group being updated in random order. During the update process, the update data is written to the random update block while the unchanged data remains in the original metablock associated with the logical group. The process of accessing logical sectors of a logical group under random update is as follows.

Step 650: Start searching for a given logical sector of a given logical group.

Step 652: Find the last written CBI sector in the CBI block.

Step 654: Find the random update block or original block associated with the given logical group by querying the random block information field of the last written CBI sector. This step may be performed at any time immediately before step 662.

Step 658: If the last written CBI sector relates to a given logical group, the CBI sector is found. Proceed to step 662, otherwise proceed to step 660.

Step 660: Find the CBI sector for the given logical group by looking up the sector index field of the last written CBI sector.

Step 662: Search for a given logical sector among random blocks or original blocks by querying the random block index field of the found CBI sector.

FIG. 16D is a flow diagram illustrating access to data of a logical sector of a given logical group being randomly updated, according to an alternative embodiment where the logical group is divided into subgroups. The finite capacity of a CBI sector can only track a certain maximum number of logical sectors. When a logical group has more logical sectors than a single CBI sector can handle, the logical group is divided into a plurality of subgroups and a CBI sector is assigned to each subgroup. In one example, each CBI sector has sufficient capacity to track a logical group of 256 sectors and up to eight random blocks. If the logical group has a size exceeding 256 sectors, there is a separate CBI sector for a subgroup of 256 sectors in the logical group. CBI sectors exist for up to eight subgroups within a logical group, providing support for logical groups up to 2048 sectors in size.

In a preferred embodiment, an indirect indexing method is employed to facilitate the management of the index. Each entry in the sector index has direct and indirect fields.

The direct sector index defines the offsets in the CBI block where all possible CBI sectors related to a particular random update block are located. Information in this field is only valid for the last written CBI sector associated with this particular random update block. The reserved value of the offset in the index indicates that it does not exist because the corresponding logical subgroup related to the randomized update block does not exist, or because the update block is not allocated and has not been updated.

The indirect sector index defines the offsets in the CBI block where the most recently written CBI sectors associated with each allowed random update block are located. The reserved value of the offset in the index indicates that no allowed random update block exists.

16D illustrates a process of accessing logical sectors in a logical group under random update as follows.

Step 670: Divide each logical group into a plurality of subgroups and assign a CBI sector to each subgroup.

Step 680: Start searching for a given logical sector of a given subgroup of a given logical group.

Step 682: Find the last written CBI sector in the CBI block.

Step 684: Find the randomized update block or original block associated with the given subgroup by querying the randomized block information field of the last written CBI sector. This step may be performed at any time immediately before step 696.

Step 686: If the last written CBI sector relates to the given logical group, go to step 691, otherwise proceed to step 690.

Step 690: Find the last written plurality of CBI sectors for a given logical group by querying the indirect sector index field of the last written CBI sector.

Step 691: At least a CBI sector associated with one of the subgroups for a given logical group has been found. Continue.

Step 692: If the found CBI sector is related to a given subgroup, then the CBI sector for the given subgroup is found. Proceed to step 696. Otherwise, go to Step 694.

Step 694: Find the CBI sector for the given subgroup by querying the direct sector index field of the currently found CBI sector.

Step 696: Find a given logical sector among random blocks or original blocks by querying the random block index field of the CBI sector for a given subgroup.

16E illustrates examples of random block index (CBI) sectors and their functions in an embodiment where each logical group is divided into a plurality of subgroups. Logical group 700 originally has its own intact data stored in the original metablock 702. Updates are then made to the logical group to assign a dedicated random update block 704. In the present example, logical group 700 is divided into subgroups, each of these subgroups A, B, C, D having 256 sectors.

To find the i-th sector in subgroup B, the last CBI sector written to CBI block 620 is first found. The Random Block Information field of the last written CBI sector provides an address to find the random update block 704 for a given logical group. At the same time this gives the position of the last sector written to the random block. This information is useful when scanning and rebuilding indexes.

If the last written CBI sector turns out to be one of the four CBI sectors of a given logical group, it will be further determined if this is exactly the CBI sector for a given subgroup B containing the i th logical sector. If so, the random block index of the CBI sector will point to the metablock location for storing data for the i th logical sector. The sector location may be in random update block 704 or original block 702.

If the last written CBI sector turns out to be one of the four CBI sectors of a given logical group but is not exactly for subgroup B, its direct sector index is queried to find the CBI sector for subgroup B. Once this correct CBI sector is found, its random block index is queried to find the i th logical sector among random update block 704 and original block 702.

If the last written CBI sector turns out to be none of the four CBI sectors of a given logical group, its indirect sector index is queried to find one of four. In the example shown in FIG. 16E, the CBI sector for subgroup C is found. This CBI sector for subgroup C then has its own direct sector index queried to find the correct CBI sector for subgroup B. The example shows that when its random block index is queried, the i th logical sector is found unchanged and its valid data will be found in the original block.

Similar considerations apply to finding the j th logical sector in subgroup C of a given logical group. The example shows that the last written CBI sector turns out to be none of the four CBI sectors of a given logical group. Its indirect sector index points to one of four CBI sectors for a given group. The last of the four points indicated turns out to be exactly the CBI sector for subgroup C. When its random block index is queried, the seventh logical sector is found to be located at the location specified in the random update block 704.

The list of random sectors is in the controller RAM for each random update block in the system. Each list contains a record of the sectors written to the random update block because the associated CBI sector was last updated in flash memory. The number of logical sector addresses for a particular random update block that can be maintained in the random sector list is a design parameter with typical values of 8-16. The optimal size of the list is determined as a compromise between the impact on overhead for random data-write operations and the sector scanning time during initialization.

During system initialization, each random update block is scanned as needed to identify valid sectors written after the previous update of one of its associated CBI sectors. The random sector list in the controller RAM for each random update block is constructed. Each block only needs to be scanned into the last written CBI sector from the last sector address defined in its random block information field.

When a random update block is allocated, the CBI sector is written corresponding to all updated logical subgroups. The logical and physical addresses for the random update block have null entries in the random block index field and are written to the available random block information field in the sector. The random sector list is opened in the controller RAM.

When the random update block is closed, the CBI sector is written to the logical and physical addresses of the block removed in the random block information field in the sector. The corresponding random sector list in RAM is unused.

The corresponding random sector list in the controller RAM is modified to include the records of the sectors written to the random update block. When there is no ordered sector list in the controller RAM, there is no space available for writing of additional sector writes in the ordered update block, the updated CBI sectors are written for the logical subgroups related to the sectors in the list and the list is Cleared.

When the CBI block 620 is fully filled in, valid CBI sectors are copied into the allocated erased block, and the previous CBI block is erased.

Address tables

The logical-to-physical address translation module 140 shown in FIG. 2 is for associating a logical address of a host with a corresponding physical address in flash memory. The mapping between logical groups and physical groups (metablocks) is stored in a set of tables and lists distributed among nonvolatile flash memory 200 and volatile but faster RAM 130 (see FIG. 1). . The address table is maintained in flash memory, including metablock addresses for all logical groups in the memory system. In addition, logical to physical address records for recently written sectors are temporarily held in RAM. These volatile writes can be reconstructed from block lists and data sector headers in flash memory when the system is initialized after startup. Thus, the address table in flash memory only needs to be updated infrequently, leading to low percentage overhead write operations for control data.

The hierarchy of address writes for logical groups includes an open update block list, a closed update block list in RAM, and a group address table (GAT) maintained in flash memory.

The open update block list is a list in the controller RAM of data update blocks currently open for writing updated host sector data. The entry for the block is 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 the closed data update blocks. Some of the entries in the list are moved to sectors in the group address table during the 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 contains one entry for each logical group, in sequential order according to logical address. The nth entry in the GAT contains the metablock address for the logical group with address n. In a preferred embodiment, this is a table in flash memory, comprising a set of sectors (called GAT sectors) with entries defining metablock addresses for all logical groups in the memory system. GAT sectors are located in one or more dedicated control blocks (called GAT blocks) in flash memory.

17A illustrates data fields of a group address table (GAT) sector. The 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 in a range, and a GAT sector index. The first component includes information for finding a metablock associated with the logical address. The second component contains information for finding all valid GAT sectors in the GAT block. Each GAT entry has three fields, a metablock number, a page tag as defined above with respect to FIG. 3A (iii), and a flag indicating whether the metablock has been linked again. The GAT sector index lists the locations of valid GAT sectors in the GAT block. This index is in all GAT sectors but is replaced by the version of the next written GAT sector in the GAT block. Accordingly, only the version in the last written GAT sector is valid.

17B illustrates an example in which group address table (GAT) sectors are written to one or more GAT blocks. The GAT block is a metablock dedicated to recording GAT sectors. When the GAT sector is updated, it is written to the next available physical sector location in the GAT block 720. Therefore, multiple copies of the GAT sector exist in the GAT block, and only the last written copy is valid. For example, the GAT sector 255 (including pointers to logical groups LG ₃₉₆₈ -LG ₄₀₉₈ ) has been updated at least twice and the latest version is valid. The location of each valid sector in the GAT block is identified by a set of indices in the last written GAT sector in the block. In this example, the last written GAT sector in the block is the GAT sector 236 and its set of indexes is a valid index that replaces all previous ones. When the GAT block eventually becomes completely filled with GAT sectors, the block is compressed during the control write operation by rewriting all valid sectors to the new block position. The entire block is then erased.

As previously described, a GAT block contains entries for a set of groups that are logically contiguous in the area of the logical address space. Each of the GAT sectors in the GAT block contains logical to physical mapping information for 128 consecutive logical groups. The number of GAT sectors required to store entries for all logical groups in the address range spanned by the GAT block occupies only a portion of the total sector locations in the block. Therefore, the GAT sector can be updated by writing it to the next available sector location in the block. The index of all valid GAT sectors and the position of these sectors in the GAT block is kept in the index field in the most recently written GAT sector. The portion of the total sectors in the GAT block occupied by valid GAT sectors is a system design parameter that is typically 25%. However, there are up to 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.

The GAT update is performed as part of the control write operation, which is triggered when the ABL runs out of blocks for allocation (see Figure 18). This is done concurrently with ABL fill and CBL empty operations. During a GAT update operation, one GAT sector has entries updated with information from corresponding entries in the closed update block list. When the 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.

The GAT rewrite operation occurs during the control write operation when no sector position can be obtained for the updated GAT sector. A new GAT block is allocated and valid GAT sectors defined by the GAT index are copied in sequential order from the full GAT block. The filled GAT block is then erased.

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

Erased Metablock  management

The erase block manager 160 shown in FIG. 2 manages erase blocks using a set of lists for maintaining directories and system control information. These lists are distributed among the controller RAM 130 and the flash memory 200. When an erased metablock is to be allocated for storage of user data or for storage of system control data structures, the next available metablock number in the allocation block list (ABL) (see FIG. 15) maintained in the controller RAM is Is selected. Similarly, when a metablock is erased after it is discarded, its number is added to the cleared block list CBL which is also maintained in the controller RAM. Relatively static directories and system control data are stored in flash memory. These include erased block lists and a bitmap MAP listing the erased state of all metablocks in flash memory. The erased block lists and the MAP are stored in individual sectors and written to a dedicated metablock known as the MAP block. These lists, distributed among the controller RAM and flash memory, provide a hierarchy of erased block writes to efficiently manage erased metablock usage.

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

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

The allocation block list (ABL) tracks the erased metablock pool and the allocation of the erased metablocks to be an update block. Accordingly, each of these metablocks may be described by an attribute indicating whether it is an erased block, an open update block, or a closed update block in an ABL open assignment. 18 illustrates an ABL including an erased ABL list 612, an open update block list 614, and a closed update block list 616. Also, the associated original block list 615 is associated with the open update block list 614. Similarly, the associated erased original block list 617 is associated with the closed update block list. As previously shown in FIG. 15, these associated lists are part of an open update block list 614 and a 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 part of the allocation block list (ABL) 61, with entries in each of which correspond to the corresponding attribute. Have each.

MAP block 750 is a metablock dedicated to storing erase management records in flash memory 200. The MAP block stores a time series of MAP block sectors, each MAP sector being an erase block management (EBM) sector 760 or MAP sector 780. Since the erased blocks are all used for allocation and are recycled when the metablock is discarded, the associated control and directory data is preferably contained in a logical sector that can be updated in the MAP block, in each case a new block. Is written to the sector. Multiple copies of EBM sectors 760 and MAP sectors 780 may exist in MAP block 750, and only the latest version is valid. The index to the locations of valid MAP sectors is implied in a 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 compressed during the control write operation by rewriting all valid sectors to the new block position. The filled block is then erased.

Each EBM sector 760 contains erased block lists (EBL) 770, which are lists of addresses of some of the erased blocks of the population. Erased block lists (EBL) 770 act as a buffer containing erased metablock numbers from which metablock numbers are taken periodically to repopulate ABL, with metablock numbers periodically added to form a CBL. Empty it again. The EBL 770 functions as buffers for the available block buffer (ABB) 772, the erased block buffer (EBB) 774, and the cleared block buffer (EBB) 776.

The available block buffer (ABB) 772 contains a copy of the entries in ABL 610 immediately following the previous ABL fill operation. This is actually a backup copy of the ABL immediately after the ABL fill operation.

The erased block buffer (EBB) 774 is previously erased from the MAP sectors 780 or the CBB list 776 (described below) and can be used for transmission to the ABL 610 during an ABL fill operation. Contains block addresses.

The cleared block buffer (CBB) 776 contains addresses of erased blocks that were sent from the CBL 740 during the CBL empty operation and then sent to the MAP sectors 78 or to the EBB list 774.

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

Any block that does not contain valid data structures and that is not designated as an erased block in MAP, erased block lists, ABL or CBL is never used by the block allocation algorithm, and therefore for storage of host or control data structures. It cannot be accessed. This provides a simple mechanism to exclude blocks with defective locations from the flash memory address space that can be accessed.

The hierarchy shown in FIG. 18 allows the erased block writes to be managed efficiently and provides complete protection of the block address lists stored in the controller's RAM. Erased block entries are exchanged between these block address lists and one or more MAP sectors 780, depending on whether they are less frequent. These lists can be reconstructed during system initialization after power-down, through limited scanning of erased block lists and address translation tables stored in sectors in flash memory, and a small number of referenced data blocks in flash memory. .

Algorithms employed to update the hierarchy of erased metablock writes are one group of addresses in the order of addresses from the MAP block 750 with one group of block addresses from the CBL 740 reflecting the order in which the blocks were updated by the host. Assigns erased blocks for use in the order of interleaving blocks. For most metablock sizes and system memory capacities, a single MAP sector can provide the system with a bitmap for all metablocks. In this case, erased blocks are always allocated for use in the order of addresses recorded in this MAP sector.

Erase block management operations

As described above, ABL 610 is a list with erased metablocks that can be allocated for use, and address entries for recently allocated metablocks as data update blocks. The actual number of block addresses in the ABL is between the best and lowest system design variables. 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 may be reduced near the end of the life of the system when the number of available erased blocks is reduced by the failure of the blocks during its lifetime. For example, after the filling operation, entries in the ABL may specify the blocks available for the following purposes. Entries for partially written data update blocks with one entry per block, do not exceed the system limit for maximum concurrently opened update blocks. Between 1 and 12 entries for blocks erased for allocation as data update blocks. 4 entries for blocks that are erased for allocation as control blocks.

ABL Fill Behavior

As ABL 610 is diminished through assignments, it will need to be refilled. The operation of filling the ABL occurs during the control write operation. This begins when a block should be allocated, but ABL contains insufficient erased block entries available for allocation, either as a data update block or for some other control data update block. During the control write, the ABL filling operation is performed simultaneously with the GAT update operation.

The following operations are performed during the ABL filling operation.

1. ABL entries with properties of current data update blocks are preserved.

2. Unless an entry for a block is being written in a concurrent GAT update operation, ABL entries with attributes of closed data update blocks are preserved, in which case the entry is removed from the ABL.

3. ABL entries for unallocated erase blocks are preserved.

4. The ABL is compressed to remove gaps caused by the removal of entries, and maintains the order of entries.

5. The ABL is fully populated by attaching the next available entries from the EBB list.

6. The ABB list is overwritten with the current entries in the ABL.

CBL  Emptying behavior

CBL is a list of block addresses erased in the controller RAM, with the same limitation as ABL for the number of block entries erased. The operation of emptying the CBL is performed during the control write operation. This is therefore concurrent with ABL fill / GAT update operations, or CBI block write operations. In a CBL empty operation, entries are removed from CBL 74 and written to CBB list 776.

MAP  Exchange behavior

The MAP exchange operation between the erase block information in the MAP sectors 780 and the EBM sectors 760 may be performed periodically during the control write operation when the EBB list 774 is empty. If all erased metablocks in the system are written to the EBM sector 760, then no MAP sector 780 exists and no MAP exchange is performed. During the MAP exchange operation, the MAP sector supplying the EBB 774 to the erased blocks is considered as the source MAP sector 782. Conversely, a MAP sector that receives erased blocks from CBB 776 is considered as destination MAP sector 784. If there is only one MAP sector, this acts as both the source and destination MAP sectors, as defined below.

The following operations are performed during the MAP exchange.

1. The 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 related entries in the CBB, and the entries are removed from the CBB.

4. The updated destination MAP sector is written to the MAP block if there is a separate source MAP sector.

5. The source MAP sector is updated, as defined by the related entries in the CBB, and the entries are removed from the CBB.

6. The remaining entries in the CBB are attached to the EBB.

7. The EBB is filled to the extent possible with erased block addresses defined from the source MAP sector.

8. The updated source MAP sector is written to the MAP block.

9. The updated EBM sector is written to the MAP block.

List management

18 illustrates the distribution and flow of control and directory information among various lists. For convenience, the operations of moving entries between elements of lists or changing attributes of entries, identified in FIG. 18 as [A] to [O], are as follows.

[A] When an erased block is allocated as an update block for host data, the attributes of its entry in the ABL are changed from the erased ABL block to an open update block.

[B] When an erased block is allocated as a control block, its entry in the ABL is removed.

[C] When an ABL entry is created with open update block attributes, the 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 the update block is closed, the attributes of its entry in the ABL are changed from the open update block to the closed update block.

[E] When the update block is closed, its associated original block is erased and the attributes of the associated one block field in its entry in the ABL are changed to the erased one block.

[F] During the ABL fill operation, any closed update block whose address is updated to the GAT during the same control write operation has its entry removed from the ABL.

[G] During the 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.

When the [H] control block is erased, an entry for it is added to the CBL.

[I] During the ABL fill operation, erased block entries are moved from the EBB list to ABL and are given attributes of the erased ABL blocks.

[J] After modification of all relevant ABL entries during the ABL fill operation, block addresses in the ABL replace the block addresses in the ABB list.

At the same time as the ABL fill operation during the [K] control write, the entries for the erased blocks in the CBL are moved to the CBB list.

[L] During the MAP exchange operation, all relevant entries are moved to the MAP destination sector in the CC list.

[M] During the MAP exchange operation, all related entries are moved from the CBB list to the MAP source sector.

[L] 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 the MAP exchange operation, entries other than those moved to [M] are moved from the MAP source sector to populate the EBB list if possible.

Logical to Physical Address Translation

In order to find the physical location of the logical sector in the flash memory, the logical-to-physical address translation module 140 shown in FIG. 2 performs logical-to-physical address translation. Except for these recently updated logical groups, mass translation may be performed using a group address table in flash memory 200 or in a GAT cache in controller RAM 130. Address translations for recently updated logical groups will primarily require querying address lists for update blocks in controller RAM 130. The process for logical-to-physical address translation for logical sector addresses therefore depends on the type of block associated with the logical group in which the sector is located. The types of blocks are intact blocks, sequential data update blocks, random data update blocks, and closed data update blocks.

19 is a flowchart illustrating a process of logical to physical address translation. Essentially, the corresponding metablocks and physical sectors are found by using the logical sector address to first look up the various update directories such as the open update block list and the closed update block list. If the associated metablock is not part of the update process, directory information is provided by the GAT. Logical to physical address translation includes the following steps.

Step 800: A logical sector address is given.

Step 810: Query the given logical address in the open update block list 614 (see Figures 15 and 18) in the controller RAM. If the query fails, go to step 820; otherwise, go to step 830.

Step 820: Query the given logical address in the closed update block list 616. If the lookup fails, the given logical address is not part of any update process and goes to step 870 for GAT address translation. Otherwise, go to step 860 for a closed update block address translation.

Step 830: If the update blocks containing the given logical address are sequential, go to step 840 for sequential update block address translation. Otherwise, go to step 850 for random update block address translation.

Step 840: Obtain the metablock address using sequential update block address translation. Go to step 880.

Step 850: Obtain a metablock address using random update block address translation. Go to step 880.

Step 860: Obtain a metablock address using closed update block address translation. Go to step 880.

Step 870: Obtain a metablock address using group address table (GAT) translation. Go to step 880.

Step 880: Convert the metablock address into a physical address. The conversion method depends on whether the metablock is relinked.

Step 890: Obtained physical sector address.

Various address translation processes are described in more detail as follows.

Sequential update  Block Address Translation (Step 840)

Address translation for the target logical sector address in the logical group associated with the sequential update block can be achieved directly from the information in the open update block list 614 (see FIGS. 15 and 18) as follows.

1. It is determined from the "page tag" and "number of written sectors" fields in the list whether the target logical sector is located 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.

Random update  Block Address Translation (Step 850)

The address translation sequence for the target logical sector address in the logical group associated with the random update block is as follows.

1. If it is determined from the random sector list in RAM that the sector is a recently written sector, address translation can be achieved directly from its position in this list.

2. The most recently written sector in the CBI block contains, in its random block data field, the physical address of the random update block relative to the target logical sector address. It also implies an offset in its indirect sector index field, in the CBI block of the last written CBI sector associated with this random 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 translations.

4. In step 3, the CBI sector identified by the indirect sector index field is read.

5. The direct sector index field for the most recently accessed randomized update subgroup is cached in RAM, eliminating the need to perform a read in step 4 for repeated accesses to the same randomized update block.

6. The direct sector index field read in step 4 or step 5 this time identifies the CBI sector associated with the logical subgroup containing the target logical sector address.

7. The random block index entry for the target logical sector address is read from the CBI sector identified in step 6.

8. The most recently read randomized block index field can be cached in the controller RAM, eliminating the need to perform reads in steps 4 and 7 for repeated accesses to the same logical subgroup.

9. The random block index entry defines the location of the target logical sector in the random update block or in the associated original block. If a valid copy of the target logical sector is in the original block, this is found by 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 group associated with the closed update block can be achieved directly from the information in the closed block update list (see FIG. 18) as follows.

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 open or closed block update lists, its 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. To determine if an entry for the target logical group is contained in the GAT cache, the ranges of available GAT caches in RAM are evaluated.

2. If the target logical group is found in step 1, the GAT cache contains complete group address information, including both the metablock address and the page tag, to enable translation of the target logical sector address.

3. If the target address is not in the GAT cache, the GAT index must be read for the target GAT block to locate the GAT sector related to the target logical group address.

4. The GAT index for the last accessed GAT block is maintained in the controller RAM and can be accessed without the need to read sectors from the flash memory.

5. The list of metablock addresses for all GAT blocks, and the number of sectors written to each GAT block, is maintained in the controller RAM. If the required GAT index is not available in step 4, it may therefore be immediately read from the 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 obtained in step 4 or step 6. The GAT cache is updated with subdivisions of sectors containing the target entry.

7. The target sector address is obtained from the metablock address and "page tag" fields in the target GAT entry.

Metablock  To Physical Address Translation (Step 880)

If the flag associated with the metablock address indicates that the metablock has been relinked, the associated LT sector is read from the BLM block to determine the erase block address for the target sector address. Otherwise, the erase block address is determined directly from the metablock address.

Control data management

20 illustrates a hierarchy of operations performed on control data structures during the operation of memory management. 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 in lists in RAM.

Data update management operations are performed in RAM with respect to ABL, CBL and random sector list. ABL is allocated when an erased block is allocated as an update block or as a control block or when the update block is closed. The CBL is updated when the control block is erased or when an entry for a closed update block is written to the GAT. The update random sector list is updated when a sector is written to the random update block.

The control write operation causes information from the control data structures to be written to the control data structures in the flash memory, resulting in updating the flash memory and the other supporting control data structures in the RAM, if necessary. This starts when the ABL contains no further entries to be allocated as update blocks for erased blocks, or when the CBI block is rewritten.

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

One GAT sector is written, and during every control write operation, 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 some random sector write operation, as described above. When the CBI block is full, valid CBI sectors are copied to the allocated erased block, and the previous CBI block is erased.

As described above, the MAP exchange operation is performed when there are no more erased block entries in the EBB list in the EBM sector.

A MAP address (MAPA) sector that records the current address of the MAP block is written to a dedicated MAPA block in each case where the MAP block is rewritten. When the MAPA block is full, valid MAPA sectors are copied to the allocated erased block, and the previous MAPA block is erased.

The boot sector is written to the current boot block in each case where 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, which then becomes the current version. The previous current version is erased and becomes the backup version, and a valid boot sector is written back to it.

Control data integrity and management

Examples of control data are directory information and block allocation information associated with a memory block management system, such as those described with respect to FIG. 20. As described above, control data is maintained in both fast RAM and slower nonvolatile memory blocks. Any frequently changing control data is held in RAM by periodic control writes to update the equivalent information stored in the nonvolatile metablock. In this way, control data is stored in a slow flash memory that is nonvolatile but without the need for frequent access. A layer of control data structures such as GAT, CBI, MAP, and MAPA shown in FIG. 20 is maintained in flash memory. Accordingly, the control write operation causes the information from the control data structures in the RAM to update the equivalent control data structures in the flash memory.

As described in relation to FIG. 20, the block management system maintains a set of control data in flash memory during its operation. This set of control data is stored in metablocks similar to host data. As such, the control data itself will be managed in blocks and will receive updates, and thus garbage collection operations.

It has also been described that there is a hierarchy of control data and that things in the lower layer are updated more frequently than those in the upper layer. For example, assuming that every control block has N control sectors to write to, the next sequence of control updates and control block relocations normally occurs. Referring again to FIG. 20, every N CBI updates populates the CBI block and causes CBI relocation (rewrite) and MAP update to begin. If the random block is closed, this also starts the GAT update. All GAT updates cause the MAP update to begin. All N GAT updates fill the block and start the GAT block relocation. In addition, when the MAP block is filled, it also causes the MAP block relocation and MAPA block (if present, but otherwise the boot block points directly to the MAP) update. In addition, when the MAPA block is filled, it also causes the MAPA block relocation, boot block update, and MAP update to begin. Also, when the boot block is filled, it causes active boot block relocation to another boot block.

update  Block replacement method

According to another aspect of the invention, in a nonvolatile memory with a block management system, an improved block replacement method is implemented for a system that supports up to a first predetermined maximum number of update blocks simultaneously open for writing data. The update blocks are mainly sequential update blocks in which data is recorded in a logically sequential order, but up to a second predetermined maximum number, which may be random update blocks, in which the data is not recorded in a logically sequential order. Each time 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 will be closed and removed to comply with the restriction. Prior to closing the update block, its data is merged into the sequential block. An improved approach is to avoid situations where sequential updates can cause an excessive number of random block coalescings. This is accomplished by separating the sequential update blocks and the random update blocks into respective replacement or coalescing pools. In particular, when the sequential update exceeds the first predetermined maximum number of allocations of new update blocks, it first makes free space in the latest least used sequential update block of the pool.

In current systems, there are generally two types of data: user data and control data. User data is typically sent from the host to the memory system in logical sequential order. Sequential update blocks are allocated to optimally handle sequential write operations from the host. In addition, the user data may be in a logically out of order, especially when there are updates following the logical data. Random update blocks are created to optimally handle data in out-of-order order. Another source of random or out of order data is control data maintained by the file system or memory system, such as file and directory information generated in the course of storing user data.

The previous method of complying with the actual system limitation of supporting up to the maximum number of open update blocks at the same time was to close the most recently used update blocks in the pool, whether in sequential or random order.

The method is improved over the previous method in which the latest least used sequential update block in the pool is closed, especially if the update block needs to be closed in the pool of blocks during sequential write operations to make free space for new allocation. This allows various update blocks to be effectively used to handle sequential write operations and random write operations. In particular, this avoids the inefficient situation by the host where a large sequential write operation may force premature closure of random update blocks containing FAT and directory information. Another random block will be created virtually instantaneously to store FAT and directory information that will be updated again once a large sequential write operation is performed. Creation of an improved replacement policy is used to avoid the overhead added when merging random blocks during sequential writing and coalescing of potentially open sequential or open random blocks to manage subsequent FAT and directory updates. And separation of coalescing pools.

The practical system limitations that support the maximum number of concurrently open update blocks have been described above. For example, in one embodiment described in connection with FIG. 10, step 410 tests whether the new allocation will exceed the maximum number U _MAX of update blocks that can be open simultaneously to accept update data. If U _MAX will be exceeded, regardless of whether it is a sequential or random update block, the least active of the update blocks will be closed at step 420 to keep the system within the defined limit.

21 schematically illustrates two defined limits on the number of update blocks for a block management system. There is an overall limitation on the total number U _MAX of given update blocks given by the sum of the number of random update blocks N _C and the number of sequential update blocks N _S. Since the random update block is more resource intensive and requires additional maintenance of the random block index (CBI), there is preferably a limit to the maximum number of random update blocks (“U _CMAX ”). Accordingly, the first constraint requires that the total number of update blocks, N _C + N _S ≦ U _MAX . The second limitation requires that the number of random update blocks N _C ≦ U _CMAX .

FIG. 22 shows typical examples of combinations of two limitations that are optimal for various memory devices. The given combination is represented by U _MAX "-" U _CMAX . For example, " 3-1 " represents a block management system that allows up to three update blocks in the update pool and only one of them is an orderly update block. Likewise, " 7-3 " represents a block management system that supports up to seven update blocks, of which only three can be random update blocks. In general, simpler memory systems with less memory capacity will be more constrained and have fewer maximum numbers.

23A, 23B and 23C schematically show a sequence of events for putting a new update block into an update block pool, according to the first situation in the previous alternative method.

FIG. 23A schematically illustrates an update pool of a “5-2” configuration as described in FIG. 22. In this example, the update pool is fully occupied by up to five allowable update blocks. The update pool includes a sequential pool 1200 containing three sequential update blocks S1, S2, S3 and an unordered pool 1300 containing up to two unordered or nonsequential update blocks C4, C5. It is further divided into. The example shows the first situation where the least active block becomes a sequential update block such as S3 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 free space. For example, if the host writes sequential data to sectors of a logical group of sectors serviced by existing update blocks, a new update block will need to be allocated to write the data.

Figure 23b schematically illustrates the closing of the least active update block to make free space for a new update block, according to the previous method. In this case the least active update block will be S3 1201 which will be closed and removed from the pool of update blocks.

FIG. 23C schematically illustrates putting a newly allocated update block into a pool after a closed update block has been removed to make free space. In this case, the newly allocated update block S6 1212 will be put into the sequential pool 1200 to write data in a logically sequential order. Accordingly, U _MAX , the maximum number of update blocks allowed, is not exceeded.

24A, 24B and 24C schematically show a sequence of cases for putting a new update block into an update block pool according to the second situation in the previous alternative method.

FIG. 24A schematically illustrates an update pool in a " 5-2 " configuration as described in FIG. In this example, the update pool is completely filled with up to five allowable update blocks. The update pool includes a sequential pool 1200 containing three sequential update blocks S1, S2, and S3 and an unordered pool 1300 containing up to two unordered or nonsequential update blocks C4 and C5. Is further divided into a sequential pool (1200) containing. The example shows a second situation in which the least active block will be an unordered update block such as C4 1301.

24B schematically illustrates the closure of a minimum active update block to make free space for a new update block, according to the previous method. In this case the minimum active update block is C4 1301 and it will be closed and removed from the pool of update blocks.

24C schematically illustrates putting a new allocated update block into a pool after a closed update block has been removed to make free space. In this case, the newly allocated update block S6 1212 will be put into the sequential pool 1200 to write data in a logically sequential order. Accordingly, U _MAX , the maximum number of update blocks allowed, is not exceeded.

25A and 25B illustrate the maintenance of the U _MAX and U _CMAX limits in the method previously described in FIGS. 10, 23B and 24B, respectively. Two restrictions are typically imposed at the same time.

FIG. 25A illustrates the method previously shown in FIG. 10, step 410, and in FIGS. 23B and 24B in which the most recently accessed update block is closed whenever a new assignment exceeds a predetermined limit.

Step 1252: Organize the nonvolatile memory into blocks. Each block is for storing data that can be erased together.

Step 1254: Allocate up to a first predetermined number of update blocks that are simultaneously open for storing updates of data in logical units.

Step 1256: Whenever allocating a new update block exceeds a predetermined number, one of the most recently accessed update blocks is closed to make free space for the new update block.

FIG. 25B illustrates the method previously shown in FIG. 10, step 370 where the most recently accessed randomized (non-sequential) update block is closed whenever the number of random update blocks exceeds a predetermined limit.

Step 1354: Allocate up to a second predetermined number of update blocks among open update blocks for storing data of logical units in a logically out of order order.

Step 1356: Whenever the number of non-sequential update blocks exceeds the second predetermined number, one of the most recently accessed non-sequential update blocks is closed so as not to exceed the second predetermined number.

One disadvantage of this previous method is that this can lead to excessive closure of random update blocks under certain circumstances. This is particularly inefficient when sequential writes cause early closing of random blocks containing control data to make free space in the pool for newly allocated sequential blocks. For example, if the closed random update block C4 1310 was writing FAT and directory information, the replacement would immediately need to be allocated to perform this function as soon as the sequential write was done. This will again entail closing the current least active update block in the pool to make free space for the replacement update block for recording control data.

According to the present aspect of the invention, the closing of the update block in order not to exceed the predetermined maximum number of update blocks, from simply selecting the latest least used update blocks, to a method of reducing the case of excessive closure of random update blocks. It is further embodied as. In a preferred embodiment, if an update block is allocated to write sequential data and one in the update block pool needs to be closed to make free space, the minimum active sequential update block in the pool is closed.

26A, 26B and 26C schematically illustrate a sequence of events for putting a new update block into an update block pool, according to this improved alternative method.

FIG. 26A schematically illustrates an update pool of a “5-2” configuration as described in FIG. 22. In this example, the update pool is completely occupied by up to five allowable update blocks. The update pool includes a sequential pool 1200 containing three sequential update blocks S1, S2, and S3, and an unordered pool 1300 containing up to two unordered or nonsequential update blocks C4 and C5. Is further divided into). The example shows a situation similar to FIG. 24A where the smallest active block becomes an random update block such as C4 1301. This also shows sequential block S3 1202 as the least active in sequential pool 1200.

FIG. 26B schematically illustrates the closure of one block of an update block pool in order to make free space for a new update block, according to the present improved method. If the number of update blocks in the pool and the new allocation associated with sequential updates is already at a maximum, one of the update blocks in the pool will have to be closed to make free space for the newly allocated update block. However, in this case the least active block is C4 1301, which will be ignored because it is an unordered block. Instead, the least active update block in the sequential pool 1200 will be closed. In this example, it is S3 1202 that is to be closed and removed from the update block pool.

FIG. 26C schematically illustrates putting a newly allocated update block into a pool after a closed update block has been removed to make free space. In this case, the newly allocated update block S6 1212 will be put into the sequential pool 1200 to write the data in a logically sequential order. Accordingly, U _MAX , the maximum number of update blocks allowed, is not exceeded.

27A, 27B, and 27C schematically illustrate a sequence of events for putting a new random update block into an update block pool, according to this improved alternative method.

FIG. 27A schematically illustrates an update pool of a “5-2” configuration as described in FIG. 22. In this example, the update pool is completely occupied by up to five allowable update blocks. The update pool includes a sequential pool 1200 containing three sequential update blocks S1, S2, and S3, and an unordered pool 1300 containing up to two unordered or nonsequential update blocks C4 and C5. Is further divided into). The example shows that the least active block becomes a sequential update block such as S6 1201. This also shows random block C4 1302 as the least active in random pool 1300.

27B schematically illustrates the closure of one of the pools of update blocks to make free space for a new update block, in accordance with the present improved method. If a new random update block is put into the random pool 1300 that is already filled, one of the update blocks in the random pool will have to be closed to make free space. In the example, the random pool 1300 already contains up to two random update blocks. When another random update block is created, for example, when existing sequential block S1 1220 is to be converted to random blocks, the maximum number of random blocks will be exceeded if one of them is not removed. In this case, the minimum active random block C4 1302 is closed and removed from the random pool 1300 to make free space.

27C schematically illustrates putting a new random update block into the pool after another random update block is closed and removed to make room. In this case, S1 is switched from the sequential update block 1220 in the sequential pool 1200 to the random update block C6 1320 in the random order pool 1300. Accordingly, U _CMAX , the maximum number of random update blocks allowed, is not exceeded.

28 is a flowchart illustrating the present improved method of managing a limited set of update blocks during sequential update, according to the first embodiment.

Step 1400: Organize the nonvolatile memory into blocks. Each block is for storing data that can be erased together.

Step 1402: Allocate up to a first predetermined number of update blocks that are simultaneously open for storing updates of data in logical units.

Step 1406: In response to a write command to write sequential data, write data of logical units to the update block in sequential order.

Step 1408: In response to a predetermined condition satisfied for the update block to be closed for further writing of sequential logical units of data, allocate a new update block to continue writing, and if the new allocation exceeds the first predetermined number. , Preferentially closes the last least accessed update block in sequential order for any recently least accessed update block in out of order.

29 is a flowchart illustrating the present improved method of managing a limited set of update blocks with two predetermined limitations, according to the second embodiment.

Step 1410: Organize the nonvolatile memory into blocks. Each block is for storing data that can be erased together.

Step 1412: Allocate up to a first predetermined number of update blocks that are simultaneously open for storing updates of data in logical units.

Step 1416: Allocate up to a second predetermined number of update blocks among open update blocks for storing data of logical units in a logically out of order order.

Step 1418: Whenever the introduction of update blocks for storing data in a logically sequential order may exceed the first predetermined number, the data is placed in a logically sequential order to make free space for the introduced update blocks. Close the latest minimally accessed update blocks that contain.

Step 1420: Whenever introduction of update blocks for storing data in a logically out of order order may exceed a second predetermined number, in logically out of order order to make free space for the introduced update blocks. Closes the least recently accessed update blocks containing the data.

The generalization of the method is based on a set of attributes, such as whether the update block is storing sequential data or nonsequential data, or what predefined type of system data. To classify update blocks. In implementing a limited number of update blocks pools, each class of update blocks will have its own rules for replacement when the maximum number supported for this class is exceeded.

For example, sequential update blocks and non-sequential update blocks are two different classes. The substitution rules for each of these classes are the same. That is, replace the least active with a new one. Thus, when the pool of sequential update blocks is exceeded, the least active in the pool will be closed and removed before new ones are put into the pool. The same is true for a pool of out of order update blocks.

In general, each class has its own replacement rules, independent of other classes. Examples of replacement rules are to replace the latest least accessed, most recently accessed, least frequently accessed, most frequently accessed, etc., according to corresponding classes.

30 is a flowchart illustrating the present improved method of managing a limited set of update blocks with class based replacement rules.

Step 1430: Organize the nonvolatile memory into blocks. Each block is for storing data that can be erased together.

Step 1432: Provide a pool up to a first predetermined number of update blocks that are simultaneously open for storing updates of data in logical units.

Step 1436: Providing a set of predefined classes to classify update blocks based on a set of attributes, each class sub-pool up to a predetermined maximum number of update blocks associated with it. Support.

Step 1438: Provide a set of corresponding replacement rules to a set of predefined classes to specify an update block in each subpool to be replaced.

Step 1440: Divide the update blocks in the pool by the class into corresponding subpools.

Step 1442: Each time another update block of the same class is being put in it, close and remove the least active update block in the lower pool containing the associated maximum number of update blocks.

All patents, patent applications, papers, books, specifications, other publications, documents and references referenced herein are incorporated by reference in their entirety for all purposes. To the extent of any inconsistency or conflict in the definition or use of terms between any publications, documents or references referenced and the text of this document, the definition or use of terms in this document shall prevail.

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

As noted above, the present invention generally provides a memory block management system with an improved system that provides a non-volatile semiconductor memory and specifically manages the replacement of a concurrently open block pool for storing data. It is used to provide what is provided.

Claims (29)

In a nonvolatile memory composed of a plurality of blocks, each block is for storing data of logical units that can be erased together, and a method for storing data in the memory includes: Allocating no more than a first predetermined number of blocks as concurrently open update blocks for storing updates of data in a logical unit; In response to a write command to write data in a logically sequential order, writing the data to the update block in a logically sequential order; And In response to a predetermined condition that the update block is closed for further writing of the data in the sequential logical unit, a new update block is allocated to continue the writing, and the new allocation causes the first predetermined number to be allocated. If exceeded, preferentially closing the last least accessed update block that stored the data in sequential order than any recent minimum accessed one that stored the data in a non-sequential order. And storing the data in the memory. In a nonvolatile memory composed of a plurality of blocks, each block is for storing data of a logical unit that can be erased together, and a method for storing data in the memory is Allocating no more than a first predetermined number of blocks as concurrently open update blocks for storing updates of data in a logical unit; Allocating up to a second predetermined number of update blocks from the open update blocks to store data in logical units in a logically out of order order; Whenever the introduction of update blocks to store data in a logically sequential order can exceed the first predetermined number, the data is nested in a logically sequential order to make free space for the introduced update blocks. Closing the most recently accessed update blocks; And Whenever the introduction of update blocks to store data in a logically out of order order can exceed the second predetermined number, the data is placed in a logically out of order to make free space for the introduced update block. Closing the latest minimally accessed update blocks that contain And storing the data in the memory. 3. The method of claim 2, wherein said update block for storing data in a logically out of order sequence is converted from storing the data in a logically sequential order. In a nonvolatile memory composed of a plurality of blocks, each block is for storing data of a logical unit that can be erased together. A method for storing data in the memory includes: Allocating no more than a first predetermined number of blocks as concurrently open update blocks for storing updates of data in a logical unit; Providing a pool up to a first predetermined number of update blocks that are simultaneously open for storing updates of data in a logical unit; Providing 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 update blocks associated therewith; Providing a set of corresponding replacement rules for the set of predefined classes to specify the update block in the respective subpools to be replaced; Dividing the update blocks in the pool into groups into corresponding lower pools by class; And Whenever and when another update block of the same class is being introduced to a lower pool containing the associated maximum number of update blocks, closing and removing the least active update block in the lower pool, wherein the removed update block is Selecting according to the corresponding replacement rule for the same class. And storing the data in the memory. 5. The method of claim 4, wherein said set of attributes comprises a block for storing data in a logically sequential order. 5. The method of claim 4, wherein said set of attributes comprises a block for storing data in a logically out of order. 5. The method of claim 4, wherein said set of attributes comprises a block for storing system data associated with operating said memory. The method of claim 4, wherein the memory is a flash EEPROM. The method of claim 4, wherein the memory has a NAND structure. 5. The method of claim 4, wherein the memory is on a removable memory card. 5. The method of claim 4, wherein the nonvolatile memory includes memory cells having a floating gate structure. 5. The method of claim 4, wherein the nonvolatile memory includes memory cells having a dielectric layer structure. 13. The method of any of claims 1 to 12, wherein the memory has memory cells each storing one bit of data. 13. The method of any of claims 1 to 12, wherein the memory has memory cells each storing one or more bits of data. Non-volatile memory, A memory comprised of blocks, each block being divided into erasable memory units, each memory unit for storing data in logical units; And A controller for controlling the operations of the blocks, Assign a first predetermined number or less of blocks as concurrently open update blocks to store updates of data in a logical unit; In response to a write command to write data in logically sequential order, write the data to the update block in logically sequential order; In response to a predetermined condition that the update block is closed for further writing of the data in the sequential logical unit, a new update block is allocated to continue the writing, and the new allocation causes the first predetermined number to be allocated. If exceeded, the controller is configured to preferentially close the last least accessed update block that stored the data in sequential order than any recent minimum accessed that stored the data in a nonsequential order. Including, non-volatile memory. Non-volatile memory, A memory comprised of blocks, each block being divided into erasable memory units, each memory unit for storing data in logical units; And A controller for controlling the operations of the blocks, Assign a first predetermined number or less of blocks as concurrently open update blocks to store updates of data in a logical unit; Allocate up to a second predetermined number of update blocks from the open update blocks to store data in logical units in a logically out of order order; Whenever the introduction of update blocks to store data in a logically sequential order can exceed the first predetermined number, the data is nested in a logically sequential order to make free space for the introduced update blocks. Closes the least recently accessed update blocks; Whenever the introduction of update blocks to store data in a logically out of order order can exceed the second predetermined number, the data is placed in a logically out of order to make free space for the introduced update block. Closing the containing least recently accessed update blocks; Including, non-volatile memory. 17. The non- volatile memory as in claim 16, wherein the update block for storing data in a logically out of order sequence is converted from storing the data in a logically sequential order. Non-volatile memory, A memory comprised of blocks, each block being divided into erasable memory units, each memory unit for storing data in logical units; And A pool up to a first predetermined number of update blocks that are simultaneously open for storing updates of data in a logical unit; 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 update blocks associated therewith; A set of corresponding replacement rules for the set of predefined classes to specify the update block in the respective subpools to be replaced; A set of subpools containing update blocks for each class; And A controller for controlling the operations of the blocks, Whenever another update block of the same class is being introduced to a lower pool containing the associated predetermined maximum number of update blocks, the update block in the lower pool is closed and removed, and the removed update block is for the same class. Selecting the controller according to the corresponding replacement rule. Including, non-volatile memory. 19. The nonvolatile memory as in claim 18, wherein the set of attributes includes a block for storing data in a logically sequential order. 19. The nonvolatile memory as in claim 18, wherein the set of attributes includes a block for storing data in a logically out of order. 19. The non- volatile memory as in claim 18, wherein the set of attributes comprises a block for storing system data associated with operating the memory. 19. The nonvolatile memory as in claim 18, wherein the memory is a flash EEPROM. 19. The nonvolatile memory as in claim 18, wherein the memory has a NAND structure. 19. The nonvolatile memory as in claim 18, wherein the memory is on a removable memory card. 19. The nonvolatile memory as in claim 18, wherein the nonvolatile memory includes memory cells having a floating gate structure. 19. The nonvolatile memory as in claim 18, wherein the nonvolatile memory includes memory cells having a dielectric layer structure. Non-volatile memory, A memory comprised of blocks, each block being divided into erasable memory units, each memory unit for storing data in logical units; A pool up to a first predetermined maximum number of update blocks concurrently open for storing updates of data in a logical unit; 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 update blocks associated therewith; A set of corresponding replacement rules for the set of predefined classes to specify the update block in the respective subpools to be replaced; A set of subpools containing update blocks for each class; And Whenever another update block of the same class is being introduced into a lower pool containing the associated predetermined maximum number of update blocks, means for closing and removing the update block in the lower pool, wherein the removed update block is the same class. Means selected according to the corresponding replacement rule for Including, non-volatile memory. 28. The nonvolatile memory as in claim 15, wherein the memory has memory cells each storing one bit of data. 28. The nonvolatile memory as in any one of claims 15-27, wherein the memory has memory cells each storing one or more bits of data.

Images