KR20060134011A - Non-volatile memory and method with memory planes alignment - Google Patents

Abstract

A non-volatile memory is constituted from a set of memory planes, each having its own set of read/write circuits so that the memory planes can operate in parallel. The memory is further organized into erasable blocks, each for storing a logical group of logical units of data. In updating a logical unit, all versions of a logical unit are maintained in the same plane as the original. Preferably, all versions of a logical unit are aligned within a plane so that they are all serviced by the same set of sensing circuits. In a subsequent garbage collection operation, the latest version of the logical unit need not be retrieved from a different plane or a different set of sensing circuits, otherwise resulting in reduced performance. In one embodiment, any gaps left after alignment are padded by copying latest versions of logical units in sequential order thereto.

Description

Non-Volatile Memory and Methods with a Memory Plane Array {NON-VOLATILE MEMORY AND METHOD WITH MEMORY PLANES ALIGNMENT}

FIELD OF THE INVENTION The present invention generally relates to nonvolatile semiconductor memories, specifically those having a memory block management system optimized for operating multiple memory planes in parallel, each plane being provided by a read / write circuit itself. It is about.

In particular, solid-state memory capable of nonvolatile storage of charge in the form of EEPROM and flash EEPROM packaged as small shape factor cards has recently become the best storage device for various mobile and handheld devices, especially information devices and consumer electronics. It is becoming. Unlike the controller (random access memory), which is also a solid state memory, the flash memory is nonvolatile and retains its stored data even after the power is turned off. Also, unlike the controller (read only memory), the flash memory can be rewritten similarly to a disk storage device. Despite the higher cost, flash memory is increasingly used for mass storage applications. Conventional mass storage based on rotating magnetic media such as hard drives and floppy disks is inadequate in mobile and handheld environments. This is because disk drives tend to be bulky, susceptible to mechanical damage, and have high latency and high power requirements. These undesirable attributes make disk based storage impractical for most mobile and portable applications. On the other hand, flash memory, both in embedded and removable card form, is ideally suited for mobile and handheld environments because of its small size, low power consumption, high speed and high reliability characteristics.

Flash EEPROM is similar to EEPROM (Electrically Erasable and Programmable Read Only Memory) in that it is a nonvolatile memory that can be erased and new data can be written or " programmed " Both utilize a floating (non-connected) conductive gate of a field effect transistor structure, which is disposed over the channel region of the semiconductor substrate between the source and drain regions. At this time, the control gate is provided above 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 to an "on" state to enable the conductivity between its source and drain regions. do. In particular, flash memory, such as flash EEPROM, allows the entire block of memory cells to be erased simultaneously.

The floating gate holds 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 defined by the minimum and maximum threshold levels of the device, which in turn correspond to the range of degradation that can be programmed on the floating gate. The threshold window generally depends on the characteristics, operating conditions and history of the memory device. Each separate resolvable threshold voltage level range in the window can in principle be used to specify a separate defined memory state of the cell.

Transistors that function 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 pulls electrons through the thin gate dielectric onto the floating gate. In "tunneling injection", a high voltage is applied to the control gate relative to the substrate. In this way, electrons are drawn from the substrate to the intervening floating gate. The term "program" historically refers to writing to a memory by injecting a charge storage unit that was initially deleted from the memory to change the memory state, but it is now referred to in more general terms such as "write" or "record". Can be replaced.

The memory device may be erased by a number of mechanisms. For an EEPROM, the memory cell is electrically charged by applying a high voltage to the substrate relative to the control gate such that electrons in the floating gate tunnel through the thin oxide into the substrate channel region (ie, Fowler-Nordheim tunneling). Can be deleted. Typically, the EEPROM can be erased in bytes. For a flash EEPROM, the memory can electrically erase all at once or one or more minimum erasable blocks at a time, where the minimum erasable block can consist of one or more sectors, each sector can store more than 512 bytes of data. have.

Memory devices typically include one or more memory chips that can be mounted on a card. Each memory chip includes a decoder and an array of memory cells supported by peripheral circuits such as erase, write and read circuits. Intelligent controllers that perform higher levels of memory operation and interfacing also come with more sophisticated memory devices.

There are many commercially successful nonvolatile solid state memory devices in use today. These memory devices may be flash EEPROM or may use other types of nonvolatile memory cells. Examples of flash memories and systems and methods of manufacturing them are given in US Pat. Nos. 5,070,032, 5,095,344, 5,315,541, 5,343,063 and 5,661,053, 5,313,421 and 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 and 6,046,935. In addition, nonvolatile memory devices are made of memory cells having a dielectric layer for storing charge. Instead of the conductive floating gate element described above, a dielectric layer is used. Such memory devices using dielectric storage devices are described by Eitan et al, "NROM: A Novel Localized Trapping, 2-Bit Novolatile 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. Charges for one data bit are localized in the dielectric layer adjacent to the drain, and charges for the other data bits are localized in the dielectric layer adjacent to the source. By way of 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, multiple charge storage elements or memory transistors in an array are read or programmed in parallel. Thus, the "pages" of the memory elements are read or programmed together. In an existing memory architecture, a low typically includes several interleaved pages, or it may constitute one page. All memory elements of a page are read or programmed together.

In a flash memory system, the erase operation may take as much as one time longer than the read and program operations. Therefore, it is desirable to have erase blocks of significant size. In this way, the erase time is amortized over a large total memory cell.

The flash memory feature allows data to be written to a deleted memory location. When data of a specific logical address from the host is updated, one way is to rewrite the update data to the same physical memory location. That is, logical to physical address mapping is immutable. However, this means that the entire erase block containing its physical location must be deleted first, and then rewritten with update data. This update method is inefficient because the entire erase block needs to be erased and rewritten, and is therefore inefficient, especially when the data to be updated occupies only a small portion of the erase block. In addition, this results in a higher frequency of erase reuse of the memory block, which is undesirable in view of the limited durability of this type of memory device.

Another problem with flash memory system management is system control and directory data. Data is generated and accessed during the course of various memory operations. Thus, its efficient handling and instant access directly affects performance. Since flash memory means storage and is non-volatile, it is desirable to keep this type of data in flash memory. However, if there is an intervening file management system between the controller and the flash memory, the data can be accessed directly. In addition, system control and directory data tend to be active and fragmented, which is not advantageous for storage of systems with large block deletions. Conventionally, this type of data is set in the controller RAM, whereby direct access by the controller is possible. After the memory device is powered up, the initialization process allows the flash memory to be scanned to compile the necessary system control and directory information into the controller RAM. This process is time consuming and requires controller RAM capacity, all of which gets worse as flash memory capacity increases.

US 6,567,307 discloses a large erase block comprising writing update data to a plurality of erase blocks that act as scratch pads, ultimately merging effective sectors among the various blocks, and rewriting them in sectors after rearranging them in a logical sequential order. Disclosed is a method for dealing with sector update in between. In this way, blocks do not need to be deleted and rewritten on every minor update.

Both WO 03/027828 and WO 00/49488 disclose a memory system that handles updates between large erased blocks, including partitioning logical sector addresses within a zone. A small area of the logical address range is reserved for active system control data that is separate from other areas for user data. In this way, manipulation of system control data in its own area does not interact with associated user data in other areas. The update is at the logical sector level and the write pointer indicates the corresponding physical sector in the block to be written. The mapping information is buffered in RAM and ultimately stored in a sector allocation table in main memory. The latest version of the logical sector discards all previous versions of existing blocks, which are partially discarded. Defragmentation is performed to maintain the partially discarded block in an acceptable manner.

Conventional systems tend to have update data distributed over multiple blocks, or the update data may partially discard many existing portions. Often, the result is that a large amount of defragmentation is required for partially discarded blocks, which is inefficient and results in permanent aging of memory. In addition, there is no systematic and efficient way of dealing with sequential updates compared to nonsequential updates.

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

Non-volatile memory systems are organized into physical groups of physical memory locations. Each physical group (metablock) is erasable as a unit and can be used to store logical groups of data. The memory management system enables updating of a logical group of data by metablock allocation dedicated to writing the logical group of update data. The update metablock records the update data in the order in which it was received and has no limitation on whether the recording is in the correct logical order (sequential) as originally stored or not (chaotic). As a result, the update metablock is closed for further recording. One of a number of processes is taken, but ultimately ends with the exact order of fully filled metablocks replacing the original metablocks. In the case of chaotic, directory data is maintained in non-volatile memory in a manner that performs frequent updates. The system supports multiple logical groups being updated at the same time.

One feature of the present invention allows data to be updated in logical groupings. Thus, when a logical group is updated, the distribution of logical units (and also the scattering of memory units discarded by the update) is limited to a predetermined range. This is especially true when logical groups are typically contained within physical blocks.

During the update of a logical group, typically one or two blocks need to be allocated to buffer the updated logical unit. Thus, defragmentation only needs to be performed over a relatively few blocks. Defragmentation of chaotic blocks may be performed by either merging or compression.

The economics of the update process are more apparent than in the comprehensive processing of update blocks such that no additional blocks need to be allocated for chaotic (non-sequential) updates compared to sequential updates. Every update block is allocated as a sequential update block, and any update block can turn into a chaotic update block. In fact, the change of the update block from sequential to chaotic is arbitrary.

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

Alignment for Memory Spread Across Multiple Memory Planes

According to another aspect of the present invention, there is provided a memory array constructed from a plurality of memory planes and configured from a plurality of memory planes, so that logical units can be read in parallel or programmed into a plurality of planes. The initial logical unit of the first block stored in the plane is configured such that when updated, the updated logical unit remains in the same plane as the original state, in the provisional state. This object is achieved by writing the updated logical unit to the next available position of the second block in the same plane. Preferably, the logic unit is stored at the same offset position on the plane as another version so that all versions of a given logic unit can be serviced by the same set of sensing circuits.

In a preferred embodiment, the intervening gaps from the last program unit to the next planar aligned memory unit available are padded according to the current version of the logic units.

The padding above fills the gap with current versions of logical units that are logically performed from the last programmed logical unit and current versions of logically preceding logical units from logical units stored in the next available planar aligned memory unit. Is achieved.

In this way, all versions of the logic unit are on the same plane using the same offset as the original state so that in the garbage collection operation, the latest version of the logic unit does not have to be withdrawn (degraded) from another plane. maintain. In a preferred embodiment, each memory unit across the plane is updated or padded with the latest version. Logical units from each plane are readable in parallel and are in logical sequential order without further rearrangement.

With such a structure, it is possible to reduce the time for consolidation of the chaotic block by enabling planar reordering of recent versions of logical units of a logical group, and avoiding collecting recent versions from other memory planes. Such a configuration applies well to configurations where the performance specification for the host interface results in a maximum delay in completing sector write operations by the memory system.

Stepped program error handling

According to another aspect of the present invention, in a memory having a block management system, program errors in a block during a time critical memory operation are handled as the programming operation continues in the breakout memory. At too short a threshold time, the data written to the error block before the interruption occurs is transferred to another block, and such an action may be a breakout block. The block in which the error occurred is discarded. In this way, if a defect block is found, the stored data can be moved to a spot by moving the data stored in the defect block and handled without loss of data and without exceeding a specified time limit. This error handling is particularly important for the garbage collection operation so that during the critical time the entire operation does not have to be repeated on the new block. Then, at the appropriate time, data from the combining block can be rescued by moving back to another block.

Program error handling is very important during integration. Normal consolidation action integrates the current versions of all logical units of the logical group present in the original block and update block into the consolidation block. During the above integration operation, if a program error occurs in the integration block, another block acting as a breakout integration block is prepared to receive the integration of the remaining logical units. In this way, there will be no logical unit to be copied more than once, and the action of exceptional handling can be completed within a set period for normal integration action. At the appropriate time, the merging action can be accomplished by integrating all the good logic units in the group into the breakout block. The appropriate time may be another period outside the current host write operation when there is time to perform the consolidation. One suitable time may be another host write period where updates exist but there is no associated integration action.

Integration using program error handling can be implemented through a plurality of steps. In the first step, logical units are integrated into one or more blocks after a program error to avoid consolidating each logical unit more than once. The final step is completed at an appropriate time, at which time the logical group is integrated into one block, preferably by collecting all logical units into the breakout integration block in sequential order.

Out of order update block indexing

According to another aspect of the present invention, in a nonvolatile memory having a block management system supporting update blocks having nonsequential logical units, the indexes of the logical units in the nonsequential update block are buffered in RAM, and into the nonvolatile memory. It is stored periodically. According to one embodiment, the index is stored in the update block itself. In another embodiment, logical units written after the last update but before the next update have indexing information stored in the header of each logical unit. In this way, after power outage, the position of the recently written logical units can be determined without the need to perform scanning during the initialization period. In yet another embodiment, blocks are managed in a partially sequential and partially out of order manner, corresponding to more than one logical subgroup.

Control data integration and management

According to another aspect of the invention, critical data, such as some or all of the control data, is guaranteed with an extra level of reliability if it remains redundant. Such redundancy is intended for multi-state memory systems that use two-pass programming to continuously program the multi-bits of the same set of memory cells, such that any programming error in the second pass may cause the data configured by the first pass to fail. Run in a way that does not compromise. Such redundancy enables detection of write cancellation, detection of detection errors (eg, two copies have good ECC, but the data are different), and provides extra level of reliability. Several techniques are available.

In one embodiment, after two copies of a given data are programmed in an early programming pass, the next programming pass avoids programming memory cells that store at least one copy of the two copies. In this way, at least one of the two copies is canceled before the next programming pass is completed and is not affected if it corrupts the data of the early pass.

In another embodiment, two copies of a given data are stored in two different blocks having memory cells in which at least one of the two copies is programmed in the next programming pass.

In another embodiment, after two copies of a given data are stored in a programming pass, no further programming is performed on the set of memory cells that store the two copies. Such is accomplished by programming two copies in the ultimate programming pass for the set of memory cells.

In another embodiment, two copies of a given data are programmed into the multi-state memory in binary programming mode so that no further programming occurs on the programmed memory cells.

In another embodiment, in a multi-state memory system that employs a two-pass programming technique to continuously program multiple bits of the same set of memory cells, fault-tolerant code is generated by an early programming pass. The configured data is used to tod the multi-memory state so that it is insensitive to errors in the next programming pass.

According to another aspect of the present invention, in a nonvolatile memory having a block management system, control garbage collection or priority repositioning of a memory block is implemented to avoid a situation in which a large number of update blocks require repositioning at the same time. . For example, such a situation arises when updating control data used to control the operation of the block management system. The hierarchy of control data types may exist depending on the degree of change in the update frequency, resulting in relevant update blocks requiring garbage collection or repositioning at different rates. There may be a certain time period for more garbage collection actions to match than one control data type. In extreme cases, the repositioning steps of update blocks for all control data types may be aligned such that all update blocks may require repositioning at the same time.

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

1 is a schematic illustration of a main hardware component of a memory system suitable for implementing the present invention.

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

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

3B is a diagram schematically illustrating the mapping between logical groups and metablocks.

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

FIG. 5A illustrates a metablock consisting of linking of a minimum erasure unit of another plane. FIG.

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

FIG. 5C illustrates one embodiment where one or more MEUs are selected from each plane for linkage to the metablock. FIG.

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

FIG. 7A illustrates an example of sectors in a logical group written in sequential order to a sequential update block; FIG.

FIG. 7B illustrates an example of sectors in a logical group written in chaotic order in a chaotic update block. FIG.

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

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

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

11A is a flow diagram illustrating in more detail the merging process of closing the chaotic update block shown in FIG.

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

12A illustrates 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 illustrates all possible states of a metablock that are physical groups corresponding to logical groups and possible transitions between them under various operations.

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

14A-14J are state diagrams illustrating the state of logical groups and also the impact of various operations on physical metablocks.

Fig. 15 illustrates a preferred embodiment of the structure of an allocation block list (ABL) for keeping track of deleted blocks for allocation and open and closed update blocks.

FIG. 16A illustrates a data field of a chaotic block index (CBI) sector. FIG.

FIG. 16B illustrates an example of a chaotic block index (CBI) sector recorded in a dedicated metablock. FIG.

16C is a flow diagram illustrating access to data in logical sectors of a given logical group undergoing chaotic updates.

FIG. 16D is a flow diagram illustrating access to data in a logical sector of a given logical group receiving a chaotic update, according to an alternative embodiment where the logical group is divided into subgroups. FIG.

16E illustrates an example of a chaotic block indexing (CBI) sector and its function for an embodiment where each logical group is divided into a plurality of subgroups.

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

FIG. 17B is a diagram illustrating an example of a group address table (GAT) sector recorded in a GAT block. FIG.

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

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

20 illustrates a hierarchy of operations performed on a control data structure in the course of operations of memory management.

FIG. 21 is a diagram showing a memory array constructed from a plurality of memory planes.

Figure 22A is a flow chart illustrating an update method using planar alignment in accordance with a general implementation of the present invention.

FIG. 22B shows a preferred embodiment of the step of storing the update in the flow chart shown in FIG. 22A.

FIG. 23A is a diagram showing an example of logical units written in a sequential order for a sequential update block regardless of plane alignment. FIG.

Fig. 23B is a diagram showing an example of logical units written in non-aberration order for the chaotic update block regardless of the plane alignment.

Figure 24A illustrates an example of a sequential update of Figure 23A with planar alignment and padding in accordance with a preferred embodiment of the present invention.

Figure 24B illustrates a chaotic update example of Figure 23B with planar alignment and without padding in accordance with a preferred embodiment of the present invention.

Figure 24C illustrates a chaotic update example of Figure 23B with planar alignment and padding in accordance with another preferred embodiment of the present invention.

FIG. 25 is a diagram illustrating an exemplary memory structure, where each page includes two memory units to store two logical units, such as two logical sectors.

FIG. 26A shows an analogous view to the memory structure of FIG. 21 except that each page contains two sectors instead of one.

FIG. 26B is a diagram having the meta blocks of FIG. 26A with memory units configured in a generic linear fashion.

FIG. 27 is a diagram showing another structure for plane alignment within an update block without padding logical units copied from one position to another.

Fig. 28 is a diagram showing a structure in which the merging operation is repeated on another block when a program error occurs in the defective block during the merging operation.

FIG. 29 is a diagram schematically illustrating a host write operation with a time or write delay that provides sufficient time to complete the integration operation as well as the write (update) operation.

30 is a flowchart showing a program error handling in accordance with the overall structure according to the present invention.

FIG. 31A is a diagram showing a first embodiment of program error handling in which the third block (final position reset) block has a configuration different from that of the second (breakout) block.

FIG. 31B is a diagram showing another embodiment of program error handling in which the third (final position reset) block has the same configuration as the second (breakout) block.

32A is a diagram showing a flow chart of an initial update action in which an integration action is consequently obtained.

32B is a diagram showing a flow chart of a plurality of step integrating actions in the preferred embodiment of the present invention.

33 is a diagram illustrating exemplary timings of the first and last stages of a plurality of phase integration actions.

Fig. 34A is a diagram showing the case where the breakout integration block is not used as an update block, but its integration action is not used as an interrupted integration block.

34B is a diagram illustrating the third and final stages of the multi-step consolidation started at FIG. 34A.

35A shows a case where the breakout integration block is maintained as an update block that receives a host write rather than as an integration block.

35B is a diagram showing the third and final stages of the plural stage integration started in FIG. 35A for the second case.

FIG. 36A illustrates a staged program error handling applied in a scenario when a host write triggers the closure of an update block and the update block is sequential. FIG.

36B is a diagram illustrating staged program error handling, such as in the case of an update in an update block it can be applied to a partial block system.

Figure 36C is a diagram illustrating a staged program error handling garbage collection operations in a memory block management system that does not support logical groups mapped to metablocks.

FIG. 37 is a diagram illustrating an example of a write schedule of a CBI sector in an associated chaotic index sector after all N-sector writes of the same logical group.

FIG. 38A is a diagram showing an update block up to a point point when a CBI is written there after a predetermined number of writes.

FIG. 38B is a diagram showing an update block of FIG. 38A with data pages 1, 2 and 4 recorded further after the index sector.

FIG. 38C shows the update block of FIG. 38B with another logical sector written to trigger the next write of an index sector.

FIG. 39A shows an intermediate index for an intermediate scheme stored in the header of each sector of data in the chaos update block. FIG.

FIG. 39B shows an example for storing an intermediate index for intermediate writes in the header of each written sector. FIG.

40 is a diagram showing information of a chaos index field stored in a header of each data sector of a chaos update block.

Figure 41A is a diagram showing the threshold voltage distribution of a four-state memory array when each memory cell stores two bit data.

Fig. 41B is a diagram showing a conventional two-pass programming structure using gray code.

Fig. 42 is a diagram showing one safe method for protecting critical data by storing each of the overlapping sectors. For example, sectors A, B, C and D are duplicated and stored. If a data error occurs in one sector copy, the other can be read instead.

FIG. 43 is a diagram illustrating non-robustness having a configuration in which redundant sectors are generally stored in a multi-state memory.

Figure 44A illustrates one embodiment of storing a delayed duplicate copy of threshold data in a multi-state memory.

Figure 44B illustrates another embodiment of storing redundant copies of critical data in a logical upper page of a multi-state memory.

Figure 44C illustrates another embodiment of storing redundant copies of critical data in the binary mode of a multi-state memory.

FIG. 45 illustrates another embodiment of storing duplicate copies of critical data in two metablocks at the same time.

FIG. 46A is similar to FIG. 41A in showing the threshold voltage distribution of a four-state memory array, and is shown as a reference diagram of FIG. 46B.

46B is a diagram of another embodiment that simultaneously stores duplicate copies of critical data using fault-tolerant codes.

Fig. 47 is a diagram showing a table showing the possible states of two data copies and the availability of data.

Fig. 48 is a diagram showing a flow chart of preliminary repositioning of a memory block storing control data.

1 schematically illustrates a main hardware component 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 an internal memory system or a memory card. The memory system 20 includes a memory 200, and the operation of the memory is controlled by the controller 100. Memory 200 consists of one or more arrays of nonvolatile memory cells distributed over one or more integrated circuit chips. Controller 100 includes interface 110, processor 120, optional coprocessor 121, ROM (ROM, read only memory) 122, RAM (RAM, random access memory) 130, and optionally programmable. It consists of a nonvolatile memory 124. The interface 110 includes one component that interfaces a controller to a host and the other component that is interfaced to the memory 200. The firmware stored in the nonvolatile rob 122 and / or the optional nonvolatile memory 124 provides code for the processor 120 to perform the functions of the controller 100. The error correction code may be processed by the optional coprocessor 121 or the processor 120. In alternative embodiments, the 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 memory organized into a group (or metablock) of physical sectors and managed by a memory manager of a controller, according to a preferred embodiment of the present invention. Memory 200 is organized into metablocks, where each metablock is a group of physical sectors S ₀ ,..., S _{N-1 that} can be deleted together.

The host 100 accesses the memory 200 when operating an application under a file system or an operating system. Typically, the host system addresses data in units of logical sectors, where, for example, each sector may include 512 bytes of data. It is also common for the host to read and write to the memory system in units of logical clusters each composed of one or more logical sectors. In some host systems, there may be an optional host-side memory manager to perform lower levels of memory management on the host. In most cases, during a read or write operation, the host 10 issues a command to the memory system 20 to read or write a segment that primarily contains a string of logical sectors of data having consecutive addresses.

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

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

There may be an offset between the lowest address of the metablock being mapped and the lowest address of the logical group. In this case, the logical sector addresses wrap around as loops from the bottom of the logical group in the metablock back to the top. As an example, in FIG. 3A (iii), the metablock is stored at its initial location starting from the data of the logical sector k. When the last logical sector N-1 is reached, it returns to sector 0 and finally stores the data associated with logical sector k-1 in that last physical sector. In a preferred embodiment, a page tag is used to indicate any offset, such as to indicate the starting logical sector address of data stored in the first physical sector of the metablock. Two blocks are considered to have their logical sectors stored in a similar order when only the page tag is different.

3B schematically illustrates the mapping between logical groups and metablocks. Except for a few logical groups whose data is currently updated, each logical group is mapped to a unique metablock. After the logical group is updated, it can be mapped to other metablocks. Mapping information is maintained in a set of logical to physical directories. This will be described later in more detail.

Other types of logical groups for metablock mapping are also contemplated. As an example, a metablock with variable size is a co-pending, co-owned US patent, filed on the same date as herein, by Alan Sinclair, entitled “Adaptive Metablock”. Is disclosed in the application. The entire contents of this co-pending application are incorporated herein by reference.

One feature of the present 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. By way of example, a sector containing system data and a sector containing user data may be distributed in any of the logical address spaces.

Unlike prior art systems, any special partition of a system sector (i.e., sectors related to file allocation tables, directories, or subdirectories) for localizing logical address space sectors that are likely to contain data with high frequency and small size updates. No formation or localization is present. Instead, the scheme of updating a logical group of sectors effectively handles the ones representing file data and the pattern of access representing system sectors.

4 illustrates the alignment of metablocks having a structure in physical memory. Flash memory includes a block of memory cells that can be erased together as a unit. This erase block is the minimum eraseable unit (MEU) of memory or the minimum unit of erase of flash memory. The minimum erase unit is a hardware design parameter of the memory, and in some memory systems supporting multiple MEU deletions, it is possible to construct a "super MEU" comprising one or more MEUs. For flash EEPROMs, the MEU may include one sector, but preferably includes multiple sectors. In the embodiment 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 MEUs and each MEU includes M sectors, then each metablock has N = P * M sectors.

A metablock represents a group of memory locations, eg, sectors that can be deleted together, at the system level. The physical address space of the flash memory is treated as a set of metablocks, which are the minimum erase units. In this specification, the terms "metablock" and "block" are used in the same sense 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 unit of the flash memory. Used to indicate

Link formation of least erase units (MEUs) to form metablocks

In order to maximize the programming and deletion speed, parallelism is utilized as much as possible by arranging multiple MEUs in parallel and arranging multiple information pages located in multiple MEUs to be programmed in parallel.

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

In flash memory, the MEU may include one or more pages. MEUs in flash memory chips may be organized in a plane. Since one MEU from each plane can be programmed or deleted simultaneously, it is convenient to form multiple MEU metablocks by selecting one MEU from each plane (see FIG. 5B below).

5A illustrates a metablock constructed from linking of the minimum erasure unit of another plane. Each metablock, such as MB0, MB1, ..., is constructed from MEUs from different planes of the memory system, where the other planes are distributed between one or more chips. The metablock link manager 170 shown in FIG. 2 manages link formation of the MEU for each metablock. Each metablock is configured during the initial formatting process and maintains that configuration MEU throughout the life of the system, unless there is corruption in one of the MEUs.

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

5C illustrates another embodiment in which one or more MEUs are selected from each plane for linkage to the metablock. In other embodiments, one or more MEUs may be selected from each plane to form a super MEU. As an example, a super MEU can be formed from two MEUs. In this case, this may take one or more passes for read or write operations.

Linking or relinking of MEUs into metablocks is also the same as the present application, in which the name of the invention filed by Carlos Gonzales et al. Grouping of Blocks into Multi-Block Structures. "

Metablock Management

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

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 physical memory locations. The update block manager module 150 manages data update operations in memory for a given logical data group. The deletion block manager (! 60) manages the allocation and metablock deletion operations for storing new information. The metablock link manager 170 manages linkage of subgroups of the minimum erasable blocks of a sector to constitute a given metablock. Detailed descriptions of these modules will be given in their respective sections.

During operation, the metablock management system generates and operates with control data such as address, control and status information. Since many of the control data tend to be small-size data that changes frequently, it cannot be easily stored and maintained in a flash memory having a large block structure. Hierarchical and distributed schemes are used to store more static control data in non-volatile flash memory, placing lesser amounts of control data in the controller RAM for more efficient update and access. In the event of a power shutdown or failure, this scheme makes it easy to reconstruct control data in nonvolatile controller RAM by scanning a small set of control data in nonvolatile memory. This is possible because the present invention regulates the number of blocks associated with possible activities of a given logical group of data. In this way, scanning is limited. In addition, some of the 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 being written. A sector indexing scheme is used for control data to keep track of sector-by-sector updates in the metablock.

The nonvolatile flash memory 200 stores a relatively static large amount of control data. It includes a group address table (GAT) 210, chaotic block indexes (BSI) 220, an erase block list (EBL) 230, and a MAP 240. GAT 210 keeps track of the mapping between logical groups of sectors and their corresponding metablocks. The mapping remains unchanged except for the updates they receive. CBI 220 keeps track of the mapping of sectors that are logically out of order during the update. EBL 230 keeps track of the pool of deleted metablocks. MAP 240 is a bitmap that shows the erase status of all metablocks in flash memory.

Volatile controller RAM 130 stores a small portion of control data that is frequently changed and accessed. It includes an allocation block list (ABL) 134 and an erase block list (CBL) 136. ABL 134 keeps track of the allocation of metablocks to record update data, and CBL 136 keeps track of deallocated and deleted metablocks. In the preferred embodiment, the RAM 130 acts as a cache for the data of data stored in the 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, each logical group of sectors to be updated is assigned a dedicated update metablock to record the update data. In a preferred embodiment, any segment of one or more sectors of the logical group is recorded in an update block. The update block can be managed to receive update data in either sequential or non-sequential (also known as chaotic) order. The chaotic update block allows sector data to be updated in any order within the logical group, with any repetition of individual sectors. In particular, the sequential update block can be a chaotic update block without requiring any relocation of data sectors. No predetermined block allocation is needed for chaotic data update, and out of order writes at any logical address are automatically accepted. Thus, unlike prior art systems, there is no special processing as to whether the various update segments of the logical group are logically sequential or out of order. Comprehensive update blocks are simply used to record the various segments in the order in which they are requested by the host. By way of example, even if the host system data or system control data tends to be updated in chaotic form, the area of the logical address space corresponding to the host system data need not be treated differently than the area with host user data.

The data of the complete logical group of sectors is preferably stored in a logical sequential order in a single metablock. In this way, the indexes for the stored logical sectors are predefined. When a metablock is storing all sectors of a given logical group in a predefined order, it is said to be "complete". For an update block, this is eventually filled with update data in logical sequential order, after which the update block is an updated complete metablock that already replaces the original metablock. On the other hand, if the update block is filled with update data in a logical order that is different from that of the complete block, the update block is an out-of-order or chaotic update block, and the unaligned segment ultimately results in that the update data of the logical group is It must be further processed to be stored in the same order. In good cases, they are present in logically sequential order within a single metablock. Further processing involves merging the constant sectors in the original block and the update sectors in the update block into another update metablock. The merged update blocks are then logically in sequential order and can be used to replace the original block. Under some predetermined conditions, the merging process is preceded by one or more compaction processes. The compression process simply re-records the sectors of the chaotic update block into replacement chaotic update blocks, removing any duplicate logical sectors discarded by sequential updates of the same logical sector.

The update scheme allows multiple update threads to run simultaneously up to a specified maximum. Each thread is a logical group that receives updates using its dedicated 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 of update data of the logical group. The update block is assigned when a command is received from the host to record a segment of one or more sectors of a logical group in which the existing metablock completely stores all of its sectors. For the first host write operation, the first segment of data is recorded on the update block. Since each host write is a segment of one or more sectors with consecutive logical addresses, the first update is always essentially sequential. In sequential host recording, update segments in the same logical group are recorded in update blocks in the order received from the host. The block is still managed as a sequential update block, whereby update sectors remain logically sequential by the hosts in the associated logical group. All updated sectors in this logical group are written to this sequential update block until the block is closed or converted to a chaotic update block.

7A illustrates an example of sectors of a logical group written in sequential order in a sequential update block as a result of the corresponding sectors of the original block for the logical group discarded and two separate host write operations. In host write operation # 1, the data in logical sectors LS5-LS8 are updated. As LS5'-LS8 ', update data is recorded in a newly allocated dedicated update block.

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

In host write operation # 2, the segment of data in the logical sectors LS9-LS12 is updated. Update data to LS9'-LS12 'is recorded in the dedicated update block at the position immediately following the end of the last recording. It can be seen that the two host writes are such that the update data is logically recorded in the update block in sequential order, that is, LS5'-LS12 '. Since the update blocks are logically filled in sequential order, they are regarded as sequential update blocks. The update data recorded in the update block discards the corresponding in the original block.

Chaotic Data Update

Chaotic update block management is initiated for an existing sequential update block when any sector updated by a host in the associated logical group is logically out of order. The chaotic update block is a form in which logical sectors in the associated logical group can be updated in any order, in any repetition amount. This is created by conversion from a sequential update block when sectors written by the host are logically out of order with respect to previously written sectors in the logical group to be updated. Every sequentially updated sector in this logical group is written to the next available sector location in the chaotic update block, whatever its logical sector address is in the group.

FIG. 7B shows that the replaced sectors in the original block for the logical group and the duplicated sectors in the chaotic update block are discarded while written in chaotic order for the chaotic update block as a result of five separate host write operations. An example of a sector in a logical group is illustrated. 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'-LS11 'are stored in the newly allocated update block. At this point, the update blocks are sequential. In host write operation # 2, logical sectors LS5-LS6 are updated to LS5 '-LS6', and recorded in the update block at a position immediately following the last write. This converts the update blocks from sequential to chaotic. In host write operation # 3, the logical sector LS10 is updated again and recorded as LS10 "at the next position of the update block. At this point, LS10" in the update block replaces LS10 'in the previous recording, which in turn Replace LS10 in the original block. In host write operation # 4, the data in logical sector LS10 is updated again and recorded as LS "'at the next position of the update block. Thus, LS10"' is now up-to-date and the only valid data for logical sector LS10. to be. In host write operation # 5, the data in logical sector LS30 is updated and recorded in the update block as LS30 '. Thus, this example illustrates that sectors within a logical group can be written to the chaotic update block in any order with any number of iterations.

Forced sequential update

8 illustrates an example of sectors in a logical group that are written in sequential order in a sequential update block as a result of two separate host write operations with discontinuities in logical addresses. In host record # 1, update data in logical sectors LS5-LS8 are recorded in the dedicated update block as LS5 '-LS8'. In host write # 2, update data in logical sectors LS14-LS16 are recorded in the update block following the last write, as LS14'-LS16 '. However, there is an address jump between LS8 and LS14, and host write # 2 typically causes the update block to be out of order. Since address jumps are not sequential, one option is to perform the fading operation (# 2A) first, by copying the intervening sector's data from the original block to the update block before performing host write # 2. In this way, the sequential characteristics of the update block are preserved.

9 is a flowchart illustrating a process by an update block manager for updating a logical group of data according to a general embodiment of the present invention. The update process includes the following steps.

Step 260: The memory is organized into blocks, each block divided into memory units that can be deleted together, each memory unit for storing logical units of data.

Step 262: The data is organized into logical groups, where each logical group is divided into logical units.

Step 264: In the standard case, all logical units of the logical group are stored in the memory unit of the original block according to the first specified order, preferably the logical order. In this way, the indices for accessing the individual logical units in the box are known.

Step 270: For a given logical group of data (eg, LG _x ), a request is made to update a logical unit in LG _x (logical unit update is given by way of example. In general, the update is one or more in LG _x . A segment of continuous logic unit.)

Step 272: The requested update logical unit is stored in a second block dedicated to record the update of LG _x . The recording order follows the second order and is typically the order in which individuals are requested. One feature of the present invention is that the update block can be initially set up to record the data logically in sequential or chaotic order. According to the second order, the second block may be sequential or chaotic.

Step 274: The second block continues to have the requested recorded logical unit as the process returns to step 270. When a predetermined condition for closure is realized, the second block is closed to receive further updates. In this case, the process proceeds to step 276.

Step 276: A determination is made whether the closed, second block has its update logic units written in an order similar to that of the original block. As described in relation to FIG. 3A, when the written logical unit differs only in page tags, the two blocks are considered to have a similar order. If the two blocks have a similar order, the process proceeds to step 280, otherwise, some kind of defragmentation needs to be executed in step 290.

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

Step 290: The latest version of each logical unit of a given logical group is collected from among the second block (update block) and the first block (original block). Merged logical units of a given logical group are then 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 then ends at step 299.

Step 299: When the cleanup process creates a complete update block, it becomes a new standard block for a given logical group. The update thread for the logical group is terminated.

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

Step 310: For a given logical group of data (eg, LG _x ), a request is made to update a logical unit in LG _x (sector update is given by way of example. In general, the update is one or more consecutive in LG _x . Is a segment of a logical sector.)

Step 312: If there is no update block dedicated to LG _x already, proceed to step 410 to start a new update thread for the logical group. This is accomplished by allocating a dedicated update block to record the update data of the logical group. If there is already an update block open, the process proceeds to step 314 to start writing the update sector onto the update block.

Step 314: If the current update block is already chaotic (ie, out of sequence), then simply proceed to step 510 to record the requested update sector on the chaotic 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 present invention is that an update block can be initially set comprehensively to record data logically in sequential or chaotic order. However, because logical groups ultimately have their data stored in metablocks in logical sequential order, it is desirable to keep possible update blocks sequentially. Since defragmentation is unnecessary, when the update block is closed for further update, less processing is needed at this time.

Thus, a determination is made whether the requested update follows the current sequential order of the update block. If the updates follow sequentially, then proceed to step 510 to perform a sequential update, where the update blocks remain sequentially. On the other hand, if the updates do not follow sequentially (chaotic updates), which converts the sequential update block to chaotic ones if no other action is taken.

In one embodiment, no further action is taken to remedy this situation and the process proceeds directly to step 370 where the update is allowed to convert the update block into a chaotic private block.

Optional forced sequential process

In another embodiment, a forced sequential process step 320 is optionally performed to preserve the sequential update block as far as possible in terms of pending chaotic updates. Two situations exist, both of which require copying missing sectors from the original block to maintain the sequential order of logical sectors recorded on the update block. The first situation is when the update generates a short address jump. The second situation is to clean up the update blocks early to maintain their order. The forced sequential process step 320 includes the following substeps.

Step 330: If the update generates 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 considering whether the process is eligible for forced sequential cleanup. Proceed to step 340 to do this.

Step 340: If the number of unfilled physical sectors exceeds a predetermined design parameter C _C whose typical value is half the size of the reforming block, then the update block is relatively unused and does not close prematurely. The process proceeds to step 370, where the update block is chaotic. On the other hand, if the update block is substantially filled, it is considered already heavily utilized, and therefore proceeds to step 360 for forced sequential cleanup.

Step 350: The forced sequential update causes the current sequential update block to remain in sequence unless the address jump exceeds a predetermined amount C _B. In essence, sectors from the associated original block of update blocks are copied to fill the gaps covered by the address jumps. Thus, the sequential update block fades with data at the intervening address before proceeding to step 510, to sequentially record the current update.

Step 360: Forced sequential cleanup causes the current sequential update block to be cleaned up if it is already sequentially filled, instead of being converted to chaotic by pending chaotic updates. Chaotic or non-sequential update is defined as having a forward address transition that is not covered by the address jump exception, backward address transition, or address repetition described above. In order to prevent the sequential update block from being converted by chaotic update, the unwritten sector position of the update block is filled by copying the sector from the associated original partial discard block of the update block. The original block can then be completely discarded and deleted. The current update block now has a complete set of logical sectors and is then organized as a complete metablock replacing the original metablock. The process then proceeds to step 430 to allow a new update block to be allocated in place to accommodate recording of the initially requested pending sector update at step 310.

Conversion to Chaotic Update Block

Step 370: When the pending update is not in sequential order and, optionally, the forced sequential condition is not met, when proceeding to step 510, the sequential update block is written so that pending update sectors with non-sequential addresses are recorded on the update block. By enabling it to be converted to chaotic. If there is a maximum number of chaotic update blocks, it is necessary to close the most recently accessed chaotic update block before allowing the conversion to proceed, thus preventing the maximum number of chaotic blocks from being exceeded. The identification of the most recently accessed chaotic update block is the same as the general case described in step 420, but only limited to the chaotic update block. Chaotic update block closure at this time is achieved by merging as described in step 550.

Allocation of new update blocks subject to system regulation

Step 410: The process of assigning a delete metablock as an update block begins with a determination as to whether a predetermined system limit has been exceeded. Due to limited resources, memory management systems typically allow a predetermined maximum number of update blocks C _A to exist simultaneously. This limit is a group of sequential update blocks and chaotic update blocks and is a design parameter. In a preferred embodiment, this limit is, for example, up to eight update blocks. In addition, due to the demand for higher system resources, there may also be a corresponding predetermined limit on the maximum number of chaotic update blocks (eg, 4) that can be open at the same time.

Thus, when a C _A update block is already allocated, then the next allocation request can only be satisfied after closing one of the existing allocations. 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 C _A of update blocks is exceeded, the most recently accessed update block is closed and defragmentation is performed. The most recently accessed update block is represented as an update block associated with the most recently accessed logical block. To determine the most recently accessed block, the access includes writing and optionally reading a logical sector. A list of open update blocks is maintained for access, and at initialization, no access order is assumed. Closure of the update block follows the similar process described in connection with steps 360 and 530 when the update blocks are sequential, and follows the similar process described in connection with step 540 when the update block is chaotic. Closure, at step 430, creates room for allocation of new update blocks.

Step 430: The allocation request is satisfied with the allocation of a new metablock as an update block dedicated to a given logical group LG _x . The process then proceeds to step 510.

Record of update data on update block

Step 510: The requested update sector is recorded on the next available physical location of the update block. The process then proceeds to step 520 to determine if the update block is ready for cleanup.

Update block cleanup

Step 520: If the update block still has space to accommodate additional updates, proceed to step 570. Otherwise proceed to step 522 to clear the update block. When the currently requested write attempts to write more logical sectors than the space the block has, there are two possible implementations of filling the update block. In the first implementation, the write request is split into two parts, the first part writing to the last physical sector of the block. The block is then closed and the second part of the record is treated as a new requested record. In another implementation, the requested write is held while the block is fading the remaining sectors and then closed. The requested record is treated as a new requested record.

Step 522: If the update blocks are sequential, proceed to step 530 for sequential closure. If the update block is chaotic, then proceed to step 540 for chaotic closure.

Sequential update block cleanup

Step 530: Since the update blocks are sequential and fully populated, the logical group stored therein is complete. The metablock is complete and replaces the original. At this time, the original block can be completely discarded and deleted. The process then proceeds to step 570, where the update thread for the given logical group ends.

Chaotic Update Block Cleanup

Step 540: Since the update block is filled out of order and may include multiple updates of some logical sectors, defragmentation is performed to salvage the valid data therein. The chaotic update block is compressed or merged. Which process will be performed is determined in step 542.

Step 542: Performing compression or merging depends on degeneration of the update block. When a logical sector is updated many times, its logical address is very degenerate. There are multiple versions of the same logical sector recorded on the update block, only the last recorded version being valid for that logical sector. In an update block containing logical sectors having multiple versions, the number of distinct logical sectors is much smaller 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 whose typical value is half the size of the logical group, the cleanup process performs merging at step 550, and the Otherwise, the process proceeds to compression at step 560.

Step 550: If the chaotic update block is merged, the original block and update block are replaced with a new standard metablock containing the merged data. After the merge, the update thread ends at step 570.

Step 560: If the chaotic update block is compressed, it is replaced by a new update block that carries the compressed data. After compression, processing of the compressed update block ends at step 570. Alternatively, the compression is delayed until the update block is written again, thus eliminating the possibility of merging following compression without intervening updates. The new update block is then used for further update of the given logical block when the next request for update in LG _x appears in step 502.

Step 570: When the cleanup process generates a complete update block, this becomes a new standard for a given logical group. The update thread for the logical group is terminated. When the cleanup process creates a new update block that replaces an existing one, the new update block is used to record the next update requested for a given logical group. When the update block is not cleaned up, processing continues when the next request for update in LG _x appears in step 310.

As can be seen from the above-described process, when the chaotic update block is closed, the subject data recorded thereon is further processed. In particular, the valid data is defragmented by either a compression process to another chaotic block or a merge process with its associated original block to form a new standard sequential block.

11A is a flow diagram illustrating in more detail the merging process of closing the chaotic update block shown in FIG. 10. Chaotic update block merging is one of two possible processes that are performed when the update block is cleaned, eg, when the update block is filled with its last physical sector location where it is written. When the number of distinct logical sectors written in the block exceeds the predetermined design parameter C _D , merging is selected. The merging process step 550 shown in FIG. 10 includes the following substeps.

Step 551: When the chaotic update block is closed, a new metablock is assigned to replace it.

Step 552: Ignore all discarded sectors and collect the latest version of each logical sector in the chaotic update block and its associated original block.

Step 554: Record the valid sectors collected on the new metablock in logical sequential order to form a complete block, ie, a block having all of the logical sectors of the logical group recorded in sequential order.

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

Step 558: Delete the cleaned update block and the original block.

FIG. 11B is a flow diagram illustrating in more detail the compression process for closing the chaotic 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 chaotic update block is compressed, a new metablock is allocated to replace it.

Step 562: Collect the latest version of each logical sector of existing chaotic update blocks to be compressed.

Step 564: Record the collected sectors on the new update block to form a new update block with the compressed sector.

Step 566: Record the collected sectors on the new update block to form a new update block having the compressed sector with the existing update block.

Step 568: Delete the cleaned update block.

Logical and Metablock States

12A illustrates 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. The logical group state is defined as follows.

1. Full: All logical sectors in a logical group are written in logical sequential order within a single metablock, possibly using page tag wrap around.

2. Unrecorded: No logical sectors in the logical group are recorded. Logical groups are marked unwritten in the group address table and do not have any assigned metablocks. In response to a host read for all sectors in this group, a defined data pattern is returned.

3. Sequential Update: Some sectors in the logical group are possibly written in logical sequential order in the metablock using page tags, so that they replace the corresponding logical sectors from any previous complete state of the group.

4. Chaotic Updates: Some sectors in a logical group are written logically in a non-sequential order within the metablock, possibly using page tags, so that they can map the corresponding logical sectors from any previous complete state of the group. Replace. Sectors within a group can be written more than once, with the latest version replacing all previous versions.

13A illustrates 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. The metablock state is defined as follows.

1. Deleted: All sectors in the metablock are deleted.

2. Sequential Update: Metablocks are partially written into sectors in logically sequential order, possibly using page tags. All sectors belong to the same logical group.

3. Chaotic Updates: Metablocks are written into sectors in partly or completely logical out of order. Any sector can be written more than once. All sectors belong to the same logical group.

4. Fully: Metablocks are written completely in logical sequential order, possibly using page tags.

5. Original: The metablock was previously complete, but at least one sector was discarded by host data update.

14A-14J are state diagrams illustrating the state of logical groups and also the effects of various operations on physical metablocks.

14A shows a state diagram corresponding to a logical group and metablock transition for a first write operation. The host writes one or more sectors of a previously unrecorded logical group in logically sequential order to the newly allocated deleted metablock. Logical groups and metablocks proceed in sequential update state.

14B shows a state diagram corresponding to a logical group and metablock transition for the first full operation. When all sectors are sequentially written by the host, the previous unrecorded sequential update logical group is in a complete state. The transition also occurs when the card fills the group by filling the remaining unrecorded sectors with the defined data pattern. The metablock is complete.

14C shows a state diagram corresponding to a logical group and metablock transition for a first chaotic operation. The previous unrecorded sequential update logical group becomes chaotic when at least one sector is written out of order by the host.

14D shows a state diagram corresponding to a logical group and metablock transition for a first compression operation. All valid sectors in the previous unrecorded chaotic update logical group are copied from the old block to be deleted later into the new chaotic metablock.

14E illustrates a state diagram corresponding to a logical group and metablock transition for a first merge operation. All valid sectors in the previous unrecorded chaotic update logical group are moved out of the old chaotic block to fill the newly allocated erased blocks in logical sequential order. Sectors not written by the host are filled with a defined data pattern. The old chaotic block is then deleted.

14F is a state diagram corresponding to a logical group and metablock transition for a sequential write operation. The host writes one or more sectors of the full logical group into newly allocated deleted metablocks in logical sequential order. Logical groups and metablocks proceed in sequential update state. The previous full metablock becomes the original metablock.

14G shows a state diagram corresponding to logical group and metablock transitions for sequential charging operation. When all those sectors are sequentially written by the host, the sequential update logical group is complete. This may also be done during defragmentation when the sequential update logical group is filled with valid sectors from the original block to complete it, after which the original block is deleted.

14H is a state diagram corresponding to a logical group and metablock transition for an out of sequence write operation. Sequential update logical groups become chaotic when at least one sector is written out of order by the host. Out-of-sequence sector writing may cause valid sectors of the update block or the corresponding original block to be discarded.

14I is a state diagram corresponding to a logical group and metablock transition for a compression operation. All valid sectors in the chaotic update logical group are copied from the old block to be deleted to the new chaotic metablock. The original block is not affected.

14J is a state diagram corresponding to a logical group and metablock transition for a merge operation. All valid sectors in the chaotic update logical group are copied from the old chaotic block and the original block to fill the newly allocated erase blocks in logical sequential order. The old chaotic block and the original block are then deleted.

Update block tracking and management

Figure 15 illustrates a preferred embodiment of the structure of the allocation block list (ABL) for keeping track of deleted and open and closed update blocks for allocation. An assignment block list (ABL) 610 is maintained in the controller RAM 130 to enable allocation management of delete blocks, assigned update blocks, associated blocks and control structures, and to enable accurate logical to physical address transitions. . In a preferred embodiment, the ABL includes a list of delete 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 current update metablock belongs. Sequential / chaotic is a state that indicates whether the update block is filled with either sequential or chaotic update data. MB is the metablock address of the update block. The page tag is a starting logical sector recorded at the first physical location of the update block. The number of sectors written represents the number of sectors currently recorded on the update block. MB ₀ is the metablock address of the associated original block. Page tag ₀ is the page tag of the associated source block.

The closed update block list 616 is a subset 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 is closed, but has one entry for each data update block whose entry has not been updated in the logical versus main physical directory. Each entry holds the following information. LG is a logical group address to which the current update block belongs. MB is the metablock address of the update block. The page tag is a starting logical sector recorded at the first physical location of the update block. MB ₀ is the metablock address of the associated original block.

Chaotic Block Indexing

Sequential update blocks have data stored in a logical order so that any logical sector in the block can be easily located. The chaotic update block has logical sectors stored out of order, and can also store multiple update generations of logical sectors. Additional information must be retained to keep track of where each valid logical sector is located in the chaotic update block.

In a preferred embodiment, the chaotic block indexing data structure allows tracking and quick access of all valid sectors of the chaotic block. Chaotic block indexing handles small areas of the logical address space independently and efficiently handles hot areas of system data and user data. Indexing data structures basically allow indexing of information held in flash memory with infrequent update requests and are therefore not strongly impacted by performance. Meanwhile, the list of recently recorded sectors of the chaotic block is held in the chaotic sector list of the controller RAM. In addition, a cache of index information from the flash memory is maintained in the controller RAM to minimize the number of flash sector accesses for address translation. The index for each chaotic block is stored in the chaotic block index (CBI) of flash memory.

16A shows data fields of a chaotic block index (CBI) sector. A chaotic block index sector (CBI sector) includes an index for each sector of a logical group mapped to a chaotic update block and defines the location of each sector of the logical group in the associated original block or chaotic update block. . The CBI sector includes a chaotic block index field for keeping track of valid sectors in the chaotic block, a chaotic block information field for keeping track of address parameters for the chaotic block, and a metablock for storing the CBI sector (CBI). Sector index field for keeping track of valid CBI sectors in the block).

16B shows an example of a chaotic block index (CBI) sector recorded in a dedicated metablock. The dedicated metablock will be referred to as CBI block 620. Once the CBI sector is updated, it is written to the next available physical sector location of the CBI block 620. Thus multiple copies of the CBI sector will exist in the CBI block with only a valid last write copy. For example, the CBI sector for logical group LG ₁ is updated three times with a valid final version. The location of each valid sector of the CBI block is identified by a set of indices of the last recorded CBI sector of the block. In this example, the last recorded CBI sector of the block is the CBI sector for LG ₁₃₆ and the index set is a valid one representing all previous ones. When the CBI block is finally filled with CBI sectors, the block is compressed during the control write operation by rewriting all valid sectors to the new block position. The full block is erased.

The chaotic block index field in the CBI sector contains an index entry for each logical sector in the logical group or subgroup mapped to the chaotic update block. Each index entry means an offset within the chaotic update block in which valid data for the corresponding logical sector is located. The inverse index value indicates that there is no valid data for the logical sector in the chaotic update block, and the predetermined chaotic block index field entry is held in the controller RAM.

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

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

The sector index field contains an entry for each valid CBI block of the CBI block. This defines the offset within the CBI block in which the most recently recorded CBI sector is located for each allowed chaotic update block. The value of the offset inverse of the index indicates that no allowed chaotic update block exists.

16C is a flow diagram illustrating access to data in logical sectors of a given logical group under chaotic update. During the update process, update data is recorded in the chaotic update block while the unchanged data is kept in the original metablock associated with the logical group. The process of accessing a logical sector of a logical group under chaotic update is as follows.

Step 650: Locate a given logical sector of a given logical group.

Step 651: Locate the last recorded CBI sector in the CBI block.

Step 654: Locate the chaotic update block or original block associated with the given logical group by referring to the chaotic block information field of the last recorded CBI sector. This step may be performed at any time prior to step 662.

Step 658: If the last recorded CBI sector is directed to a given logical group, the CBI sector is located. It precedes step 662. Otherwise, precede with step 660.

Step 660: Locate the CBI sector for the given logical group by referring to the sector index field of the last recorded CBI sector.

Step 662: Position a given logical sector among the chaotic block or the original block by referring to the chaotic block index field of the located CBI sector.

FIG. 16D is a flow diagram illustrating access to data in a logical sector of a given logical group under chaotic updating, in accordance with an alternative embodiment where the logical group is divided into subgroups. The finite capacity of a CBI sector can only hold a predetermined maximum number of tracks of logical sectors. When a logical group has more logical sectors than a single CBI sector can handle, the logical group is divided into multiple subgroups with CBI sectors assigned to each subgroup. In one example, each CBI sector has sufficient capacity to track a logical group of 256 sectors and has up to eight chaotic update blocks. If a logical group has a size of 256 sectors, then individual CBI sectors exist for a subgroup of 256 sectors in the logical group. CBI sectors exist for up to eight subgroups within a logical group and support up to 2048 sectors for the logical group.

In a preferred embodiment, an indirect indexing scheme is employed for easy handling of the index.

The direct sector index defines the offset in the CBI block where all possible CBI sectors for a particular chaotic update block are located. The information in this field is valid only in the last recorded CBI sector for that particular chaotic update block. The inverse value of the offset of the index indicates that no CBI sector exists because the corresponding logical subgroup for the chaotic update block does not exist or is not updated because the update block is allocated.

The indirect sector index defines the offset at which the most recently recorded CBI sector is located for each allowed chaotic update block. The inverse of the offset of the index indicates that no allowed chaotic update block exists.

16D shows a process of accessing logical sectors of a logical group under chaotic updates as follows.

Step 670: Partition each logical group into multiple subgroups and specify a CBI sector for each subgroup.

Step 680: Begin locating a given logical sector of a given subgroup of a given logical group.

Step 682: Locate the last recorded CBI sector of the CBI block.

Step 684: Locate the chaotic update block or original block associated with the given subgroup by referring to the chaotic block information field of the last recorded CBI sector. This step may be performed at any time before step 696.

Step 686: If the last recorded CBI sector is directed to a given logical group, step 691 is followed. Otherwise, step 690 is followed.

Step 690: Locate the last write of multiple CBI sectors for a given logical group by referring to the indirect sector index field of the last recorded CBI sector.

Step 691: locate at least a CBI sector associated with one of the subgroups for a given logical group. continuation.

Step 692: If the located CBI sector is directed to a given subgroup, the CBI sector for the given subgroup is located. It is followed by step 696. Otherwise preceded by step 694.

Step 694: Locate the CBI sector for a given subgroup by referring to the direct sector index field of the currently located CBI sector.

Step 696: locate a given logical sector among the chaotic block or original block by referring to the chaotic block index field of the CBI sector for the given subgroup.

16E shows an example of chaotic block indexing (CBI) sectors and their functionality for an embodiment where each logical group is divided into multiple subgroups. Logical group 700 has intact data that was originally stored in original metablock 702. The logical group then receives an update with assignment of a dedicated chaotic update block 704. In this example, the logical group 700 is divided into predetermined subgroups A, B, C, and D, each having 256 sectors.

In order to locate the i-th sector in subgroup B, the last recorded CBI sector of CBI block 620 is first located. The chaotic block information field of the last recorded CBI sector provides an address for positioning the chaotic update block 704 for a given logical group. At the same time, the position of the sector last recorded in the chaotic block is provided. This information is useful in the case of scan and reconstruction indexes.

The last recorded CBI sector is made into one of the four CBI sectors of a given logical group and will determine whether the CBI sector for the given subgroup B containing the i th logical sector is correct. If so, the chaotic block index of the CBI sector will be pointed to the metablock location for storing data for the i th logical sector. The sector location may be in chaotic update block 704 or original block 702.

The last recorded CBI sector is made into one of the four CBI sectors of a given logical group and is not correct for subgroup B, but a direct sector index is referenced to locate the CBI sector for subgroup B. Once this correct CBI sector is located, the chaotic block index is referenced to locate the i th logical sector among chaotic update block 704 and original block 702.

If the last recorded CBI sector is not composed of any of the four CBI sectors of a given logical group, its indirect sector index is referenced to locate one of the four. In the example shown in FIG. 16E, the CBI sector for subgroup C is located. This CBI sector for subgroup C then has its direct sector index reference to locate the correct CBI sector for subgroup B. For example, when a chaotic block index is referenced, it is found that the logical sector has not changed and its valid data is located in the original block.

Similar considerations apply to locating the j th logical sector of subgroup C of a given logical group. The example shows that the last recorded CBI sector does not consist of any of the four CBI sectors of a given logical group. The four indicated last writes correctly constitute the CBI sector for the subgroup C. When the chaotic block index is referenced, it is found that the j th logical sector is located at the designated position of the chaotic update block 704.

A list of chaotic sectors is present in the controller RAM for each chaotic update block in the system. Each list contains a record of the sectors written in the chaotic update block because the associated CBI sectors are last updated in flash memory. The number of logical sector addresses for a particular chaotic update block that can be retained in the chaotic 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 sector scanning time during initialization and its effect on the overhead for chaotic data write operations.

During system initialization, each chaotic update block is scanned because it needs to identify a valid sector written since the previous update of one of its associated CBI sectors. A chaotic sector list in the controller RAM for each chaotic update block is constructed. Each block only needs to be scanned from the last sector address specified in its chaotic block information field in the last recorded CBI sector.

When a chaotic update block is allocated, the CBI sector is written to correspond to all update logical sub-groups. The logical and physical addresses for the chaotic update block have a null entry in the chaotic block index field and are written to the available chaotic block information field in the sector. The chaotic sector list is opened in the controller RAM.

When the chaotic update block is closed, the CBI sector is written to the logical and physical address of the block removed from the chaotic block information field in the sector. The corresponding chaotic sector list in RAM is not used.

The corresponding chaotic sector list in the controller RAM is modified to include a record of the sectors recorded in the chaotic update block. When the chaotic sector list in the controller RAM does not have available space for the record of additional sector writes to the chaotic update block, an update CBI sector is written for the logical sub-groups for the sectors in the list, and the list is Erased.

When the CBI block 620 becomes full, a valid CBI sector is copied to the assigned erase block, and the previous CBI block is deleted.

Address table

The logical-to-physical address translation module 140 shown in FIG. 2 functions to associate the logical address of the host with the corresponding physical address in the flash memory. The mapping between logical groups and physical groups (metablocks) is stored in a set of lists and tables distributed between nonvolatile flash memory 200 and volatile but more sensitive 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 the RAM. These volatile records can be reconstructed from data sector headers and block lists in flash memory when initialized after system startup. Thus, the address table in flash memory only needs to be updated infrequently, leading to an overhead write operation for a low rate of control data.

The hierarchical structure of address records 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 the data update block that is currently open for writing updated host sector data. The entry for the block is moved to the closed update block when the block is closed. The closed update block list is a list in the controller RAM of the closed data update block. The subset of entries in the list is 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 includes one entry for each logical group sequentially ordered by logical address. The nth entry in the GAT contains the metablock address for the logical group having address n. In a preferred embodiment, this is a table in flash memory that includes 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 shows a data field of a group address table (GAT) sector. The GAT sector may, for example, have sufficient capability to contain GAT entries for a set of 128 contiguous logical groups. Each GAT sector contains two elements, a set of GAT entries for the metablock address of each logical group in range and a GAT sector index. The first element includes information for locating a metablock associated with a logical address. The second element contains information for locating all valid GAT sectors in the GAT block. Each GAT entry has three fields, the number of metablocks, a page tag as defined above with respect to FIG. 3A (iii), and a flag indicating whether the metablock is relinked. The GAT sector index lists the positions of valid GAT sectors in the GAT block. This index is in all GAT sectors, but is replaced by the next recorded version of the GAT sector in the GAT block. Thus, only versions in the last recorded GAT sector are valid.

17B shows an example of a group address table (GAT) sector recorded in one or more GAT blocks. The GAT block is a metablock dedicated to GAT sector recording. When the GAT sector is updated, it is written to the next available physical sector location in the GAT block 720. Thus, multiple copies of a GAT sector may exist in a GAT block with only the last written copy valid. As an example the GAT sector 255 (including pointers in logical group LG _3968- LG ₄₀₉₈ ) is updated at least twice with the latest version being valid. The location of each valid sector in the GAT block is identified by understanding the set of indices in the last recorded GAT sector in the block. In this example, the last recorded GAT sector in the block is the GAT sector 236, and its set of indices is valid to replace all previous ones. When the GAT block is eventually completely filled with the GAT sector, the block is compressed during the control write operation by rewriting all valid sectors in the next block position. Next, the full block is deleted.

As mentioned above, a GAT block contains entries for a locally contiguous set of groups within a region of the logical address space. The GAT sectors in the GAT block each contain logical to physical mapping information for 128 consecutive logical groups. The number of GAT sectors required to store entries for all logical groups within the address range spanned by the GAT block occupies only a portion of the total sector positions in the block. Thus, 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 their positions in the GAT block is maintained in the index field in the most recently recorded GAT sector. The portion of the total sector in the GAT block occupied by the effective GAT sector is a system design parameter that is typically 25%. However, there is a maximum of 64 valid GAT sectors per GAT block. In systems with large logical capacity, it may be necessary to store GAT sectors in one or more GAT blocks. In this case, each GAT block is associated with a fixed range of logical groups.

The GAT update is performed as part of the control write operation triggered when the ABL comes out of the block for allocation (see FIG. 18). This is done simultaneously with the ABL charging and CBL emptying operations. During a GAT update operation, one GAT sector has an entry updated with information from the corresponding entry in the closed update block list. When the GAT entry is updated, any corresponding entry is removed from the closed update block list CUBL. As an 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 position in the GAT block.

The GAT rewrite operation occurs during the control write operation when no sector position is available for the updated GAT sector. New GAT blocks are allocated and copied in sequential order from the full GAT block, which is filled with valid GAT sectors as defined by the GAT index. Next, the full GAT block is deleted.

The GAT cache is a copy in the controller RAM 130 of entries in the division of 128 entries in the GAT sector. The number of GAT cache entries is a system design parameter with a typical value of 32. A GAT cache for the associated sector partition is created each time an entry is read from the GAT sector. Multiple GAT caches are maintained. Number is a design parameter with a typical value of four. The GAT cache is replaced with entries for different sector partitioning on a minimum current use basis.

Deleted metablock management

The deletion block manager 160 shown in FIG. 2 manages deletion blocks using a set of lists for holding directories and system control information. These lists are distributed between the controller RAM 130 and the flash memory 200. When the deleted metablocks must be allocated for the storage of user data or for the storage of system control data structures, the next available number of metablocks in the allocation block list (ABL) (see FIG. 15) held in the controller RAM is selected. do. Similarly, when a metablock is deleted after it is withdrawn, its number is added to the erase block list CBL also held in the controller RAM. Relatively static directories and system control data are stored in flash memory. These include a bitmap (MAP) and a list of erased blocks, listing the deleted states of all metablocks in flash memory. The erase block list and the MAP are stored in separate sectors and recorded in a dedicated metablock known as a MAP block. These lists, distributed between controller RAM and flash memory, provide a hierarchical structure of erase block records to efficiently manage the use of deleted metablocks.

18 is a schematic block diagram showing distribution and flow of control and directory information for use and reproduction of an erased block. Control and directory data are maintained in a list held in controller RAM 130 or in MAP block 750 residing in flash memory 200.

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

The allocation block list (ABL) keeps track of the allocation of deleted metablocks as update blocks and the pool of deleted metablocks. Thus, each of these metablocks, which can be described by an attribute, specifies whether it is a delete block in an ABL pending allocation, open update block or closed update block. 18 shows an ABL including a deleted ABL list 612, an open update block list 614, and a closed update block list 616. Also associated with the open update block list 614 is the associative source block list 615. Similarly, associated with the closed update block list is the associated deleted original block list 617. As previously shown in FIG. 15, these association lists are a subset of each of the open update block list 614 and the closed update block list 616. The deleted ABL block list 612, the open update block list 614 and the closed update block list 616 are all a subset of the allocation block list (ABL) 610 in each entry within each having a corresponding attribute.

MAP block 750 is a metablock dedicated to storing deletion management records in flash memory 200. The MAP block stores a time series of MAP block sectors, where each MAP sector is an erase block management (EBM) sector 760 or a MAP sector 780. As the erase block is used for allocation and played back when the metablock is withdrawn, the association control and directory data are preferably included in a logical sector that can be updated in the MAP block with each moment of update data recorded in a new block sector. do. Multiple copies of EBM sector 760 and MAP sector 780 may be present in MAP block 750 with only the latest version valid. The index for the location of the valid MAP sector is contained in a field in the EMB block. A valid EMB sector is always last written into the MAP block during a control write operation. When MAP block 750 is filled, it is compressed during a control write operation by rewriting all valid sectors to a new block position. Next, the full block is deleted.

Each EBM sector 760 includes an erase block list (EBL) 770, which is a list of addresses of a subset of a collection of erase blocks. The Deleted Block List (EBL) 770 acts as a buffer containing the number of deleted metablocks, from which the metablock number is periodically taken to recharge the ABL, and periodically added to it to empty the CBL. . The EBL 770 functions as a buffer for the available block buffer (ABB) 772, the erase block buffer (EBB) 774 and the erase block buffer (CBB) 776.

The available block buffer (ABB) 772 includes a copy of the entry in the ABL 610 immediately following the previous ABL charging operation. This is useful for a backup copy of ABL immediately after an ABL charging operation.

The erase block buffer (EBB) 774 is a transfer block previously delivered from the MAP sector 780 or from the CBB list 776 (described below) and available for transfer to the ABL 610 during an ABL charging operation. Contains the address.

The erase block buffer (CBB) 776 includes the address of the erase block that can be delivered from the CBL 740 and sequentially delivered to the MAP sector 780 or the EBB list 774 during the CBL empty operation.

Each of the MAP sectors 780 includes a bitmap structure called MAP. The MAP uses one bit for each metablock in flash memory used to indicate the erase status of each block. The bits corresponding to the block addresses listed in the erase block list in the ABL, CBL or EBM sectors are not set to the erase state in the MAP.

Any block that does not contain a valid data structure and is not designated as a delete block in MAP, delete block list, ABL or CBL is not used by the block allocation algorithm at all, and therefore is inaccessible for storage of host or control data structures. Do. This provides a simple mechanism for excluding blocks with defective locations from the accessible flash memory address space.

The hierarchical configuration shown in FIG. 18 allows the erase block record to be managed efficiently and provides complete security of the block address list stored in the RAM of the controller. Erased block entries are exchanged between one or more MAP sectors 780 and these block address lists on an infrequent basis. These lists can be reconstructed during system initialization after power off via limited scanning of the address translation table stored in sectors in flash memory and information in the erase block list and a few referenced data blocks in flash memory.

The algorithm adopted for updating the hierarchical configuration of the deleted metablock record is a block in address order from MAP block 750 with a burst of block addresses from CBL 740 reflecting the order block updated by this host. This results in a delete block that is allocated for use in the inserting sequence of bursts. For maximum metablock size and system memory capacity, a single MAP sector can provide a bitmap for all metablocks in the system. In this case, the erase block is always recorded in this MAP sector so that it is allocated for use in address order.

Delete block management behavior

As noted above, ABL 610 is a list with address entries for deleted metablocks that can be allocated for use and recently allocated metablocks as data update blocks. The actual number of block addresses in the ABL lies between the maximum and minimum limits, which are 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 can be reduced adjacent to the end of the life of the system because the number of available erased blocks is reduced by the failure of the block during its lifetime. By way of example, after the charging operation, an entry in the ABL specifies a block that is available for the following purposes. The entry for the partially written data updates the block with one entry per block without exceeding the system limit for the maximum value of the update block opened simultaneously. Between 1 and 20 entries for the erase block for allocation as a data update block. As the control block there are four entries for the delete block for assignment.

ABL charging operation

When ABL 610 is depleted through assignment, it needs to be recharged. The operation for charging the ABL occurs during the control write operation. This is triggered when a block should be allocated, but the ABL contains insufficient delete block entries available for allocation as a data update block or for some other control data update block. During the control recording, the ABL charging operation occurs concurrently with the GAT update operation.

The following actions occur during the ABL charging operation.

1. An ABL entry with the attributes of the current data update block is maintained.

2. If an entry for the block is not written to the concurrent GAT update operation, an ABL entry with the attributes of the closed data update block is maintained, in which case the entry is removed from the ABL.

3. ABL entries for unallocated delete blocks are maintained.

4. ABL compresses to maintain the order of entries by eliminating the gap created by the removal of entries.

5. The ABL is fully charged by attaching the next available entry from the EBB list.

6. The ABB list is replaced with the current entry in the ABL.

CBL empty action

CBL is a list of erase block addresses in the controller RAM with the same limitation on the number of ABL and erase block entries. The operation of emptying the CBL occurs during the control write operation. Therefore, this occurs simultaneously with the ABL charge / GAT update operation or the CBI block write operation. In a CBL empty operation, entries are removed from CBL 740 and written to CBB list 776.

MAP exchange behavior

The MAP exchange operation between the EBM sector 760 and the erase block information in the MAP sector 780 may occur periodically during the control write operation when the EBB list 774 is empty. If all deleted metablocks in the system are recorded in the EBM sector 760, there is no MAP sector 780 and no MAP exchange is performed. During the MAP exchange operation, the MAP sector supplying the EBB 774 with the erase block is considered as the source MAP sector 782. Conversely, the MAP sector that receives the erase block from CBB 776 is considered as the incoming MAP sector 784. If there is only one MAP sector, it acts as a source and destination MAP sector as described below.

The following operation is performed during the MAP exchange.

1. The source MAP sector is selected based on the incremental pointer.

2. The destination of the 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 of the MAP sector is updated as defined by the relevant entry in the CBB, and the entry is removed from the CBB.

4. The updated incoming MAP sector is recorded in the MAP block, unless there is any separate source MAP sector.

5. As defined by the relevant entry of the CBB, the source MAP sector is updated and 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 the specified erase block address 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 the various lists. For convenience, the operations for moving an entry between elements of the list indicated as [A] to [O] in FIG. 18 or for changing an attribute of the entry are as follows.

[A] When a deletion block is assigned as an update block for host data, the attribute of that entry in the ABL is changed from the deleted ABL block to an open update block.

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

[C] When an ABL entry is created with an open update block attribute, the associated original block field is added to the entry to record the original metablock address for the updated logical group.

[D] When the update block is closed, the attribute of that entry in the ABL is changed from the open update block to the closed update block.

[E] When the update block is closed, the associated original block is deleted, and the attribute of the associated original block in the entry in the ABL is changed to the deleted original block.

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

[G] During an ABL filling operation, when an entry for a closed update block is removed from the ABL, the entry for the associated deleted original block is moved to the CBL.

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

[I] During the ABL charging operation, the deletion block entry is moved from the EBB list to the ABL, and the attribute of the deleted ABL block is given.

[J] During the ABL charging operation, after the change of all relevant ABL entries, the block address in the ABL replaces the block address in the ABB list.

[K] Simultaneously with the ABL filling operation during the control write, the entry for the erase block in the CBL is moved to the CBB list.

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

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

Following [L] and [M] during the [N] MAP exchange operation, all remaining entries are moved from the CBB list to the EBB list.

[O] During the MAP exchange operation, subsequent to [N], if entries other than those moved within [M] are available, they are moved from the MAP source sector to populate the EBB list.

Logical to Physical Address Translation

In order to locate the physical locations of logical sectors in the flash memory, the logical to physical address translation module 140 shown in FIG. 2 performs logical to physical address translation. Except for the most recently updated logical group, it may be performed using a group address table (GAT) present in flash memory 200 or a GAT cache in controller RAM 130. Address translation for recently updated logical groups requires a list of reference addresses for update blocks that are primarily present in controller RAM 130. The process for logical-to-physical address translation for a logical sector address thus depends on the type of block associated with the logical group in which the sector is located therein. Types of blocks are: complete block, sequential data update block, chaotic data update block, closed data update block.

19 is a flowchart illustrating the process of logical to physical address translation. In practice, corresponding metablocks and physical sectors are arranged by using logical sector addresses to refer first to various update directories, such as an open update block list and a closed update block list. If the associated metablock is not part of the update process, then the 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: Reference a given logical address in the open update block list 614 in the controller RAM (see Figures 15 and 18). If the reference fails, go to step 820; otherwise, go to step 830.

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

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

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

Step 850: Acquire a metablock address using chaotic update block address translation. Proceed to step 880.

Step 860: Acquire a metablock address using closed update block address translation. Proceed to step 880.

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

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

Step 890: A physical sector address is obtained.

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

Sequential Update Block Address Translation (step 840)

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

1. From the "Page Tag" and Number of Sectors Recorded "field in the list, it is determined whether the target logical sector is located in the update block or in the associated original block.

2. The metablock address suitable for the target logical sector is read from the list.

3. The sector address in the metablock is determined from the appropriate "Page Tag" field.

Chaotic Update Block Address Translation (Step 850)

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

1. If it is determined from the chaotic sector in RAM that the sector is a recently recorded sector, address translation is achieved directly from that position in this list.

2. The most recently recorded sector in the CBI block contains the physical address of the chaotic update block associated with the target logical sector address in its chaotic block data field. It also contains, in its indirect sector index field, the offset in the CBI block of the last recorded CBI sector associated with this chaotic update block (see FIGS. 16A-16E).

3. The information in these fields is cached in RAM, eliminating the need to read sectors during subsequent address 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 chaotic update subgroup is cached in RAM, eliminating the need to perform the read in step 4 for iterative access to the same chaotic update block.

6. The direct sector index field read in step 4 or step 4 sequentially indicates the CBI sector associated with the logical subgroup containing the target logical sector address.

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

8. The most recently read chaotic block index field may be cached in controller RAM to eliminate the need to perform the read in steps 4 and 7 for repeated access to the same logical subgroup.

9. The chaotic block index entry defines the location of the target logical sector in either the chaotic update block or the associated original block. If a valid copy of the target logical sector is in the original block, it is placed by the use of 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 is 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 either an open or closed block update list, the entry in that 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 included in the GAT cache, the scope of the available GAT cache in RAM is evaluated.

2. In step 1, when the target logical group is found, the GAT cache includes global group address information including both the metablock address and the page tag, enabling 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 identify the location of the GAT sector relative 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 having to read a sector from the flash memory.

5. The list of metablock addresses for all GAT blocks and the number of sectors written in each GAT block are maintained in the controller RAM. If the required GAT index is not available in step 4, it can therefore be read immediately from the flash memory.

6. The GAT sector with respect 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 the subdivision of the sector containing the target entry.

7. The target sector address is obtained from the "page tag" field and the metablock address 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

10 illustrates a hierarchy of operations performed on a control data structure in the course of operations of memory management. Data update management operations operate on the various lists present in RAM. Control write operations operate on dedicated blocks in flash memory and various control data sectors, and also exchange data with lists in RAM.

The data update management operation is performed in RAM on the ABL, CBL, and chaotic sector lists. ABL is updated when a deleted block is allocated as an update block or control block, or when the update block is closed. The CBL is updated when the control block is deleted or when an entry for a closed update block is written to the GAT. The update chaotic sector list is updated when a sector is written to the chaotic update block.

The control write operation causes information from the control data structure in the RAM to be written to the control data structure in the flash memory, if necessary, along with the flash memory and other resulting updates supporting the control data structure in the RAM. This is triggered in either case when the ABL no longer contains an entry for the deleted block to be allocated as an update block, or when the CBI block is rewritten.

In the preferred embodiment, the ABL charging operation, the CBL emptying operation, and the EBM sector update operation are performed during all control write operations. When the MAP block containing the EBM sectors is full, the valid EBM and MAP sectors are copied to the allocated deleted block, and the previous MAP block is deleted.

During all control write operations, one GAT sector is written, and the closed update block list is changed accordingly. When the GAT block becomes full, a GAT rewrite operation is performed.

After a specific chaotic sector write operation, the CBI sector is recorded as described above. When the CBI block becomes full, a valid CBI sector is copied to the allocated erase block, and the previous CBI block is deleted.

When there are no more deleted block entries in the EBM list in the EBM sector, as described above, the MAP exchange operation is performed.

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

In each case where the MAPA block is rewritten, a boot sector is written in the current boot block. When the boot block becomes 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 deleted, becomes the backup version, and the valid boot sector is written back to it.

Alignment for Memory Spread Across Multiple Memory Planes

As previously described with reference to Figures 4, 5A-5C, multiple memory planes are allowed to operate in parallel to improve performance. Basically, each plane has a set of sense amplifiers as part of the read and program circuits serving in parallel the corresponding pages of memory cells that function to span the plane. When a plurality of planes are combined with each other, the plurality of pages work in parallel with each other, so that better performance can be obtained.

According to another aspect of the invention, a given memory is provided for a memory configuration organized in erasable blocks and constructed from multiple memory planes such that logical units can be read or programmed into multiple planes in parallel. When the first logical unit of the first block stored in the plane is updated, a configuration is made that can keep the updated logical unit in the same plane as the original state. Such a configuration is achieved by writing the updated logical units in the next usable position of the second block, greener same plane. Preferably, the logic unit is stored in the same offset position on the plane as different versions so that certain logic units can be serviced by the same set of sensing circuits.

In a preferred embodiment, the mutual interference gaps from the last program memory unit to the next planar aligned memory unit available are padded depending on the current version of the logic units. The padding fills the gap with current versions of logical units that are logically followed by current versions of logical units that are logically followed by the last programmed logical unit, and from logical units stored in the next available planar aligned memory unit. Is achieved accordingly.

In this way, all versions of the logic unit are kept in the same plane with the latest offset such that in the garbage collection operation, the latest version of the logic unit is not withdrawn (decreased in performance) from another plane. In a preferred embodiment, each memory unit across each plane is updated or padded with recent versions. Thus, in parallel operation across multiple planes, the logic units are organized in a logical sequential order without requiring additional rearrangement.

Such a structure has the advantage of enabling on-plane reordering of recent versions of logical units of a logical group and reducing the time required for consolidation of chaotic blocks by avoiding collecting recent versions from different memory planes. And this is advantageous in the configuration in which the performance specification for the host interface brings the maximum delay for the completion of the sector write operation by the memory system.

Figure 21 shows a memory array constructed from multiple memory planes. Memory planes may be constructed from the same memory chip, and may be constructed from multiple memory chips. Each plane 910 has its own set of read and program circuits 912 to service the page 914 of memory cells in parallel. Without losing its general features, the memory array has four planes that operate in parallel.

In general, the logical unit is the smallest unit accessed by the host system. The logical unit is a sector having a size of 512 bytes. Pages are the largest units of parallel reads or programs organized on a plane. The logical page has one or more logical units. Thus, when combining multiple planes, the maximum unit of parallel read or program can be defined as a metapage of memory cells, which metapage consists of pages from each of the plurality of planes. For example, a metapage such as MP ₀ has planes P0, P1, P2 and P3, namely four pages, and stores LP ₀ , LP ₁ , LP ₂ and LP ₃ in parallel. Thus, the read and write performance of the memory is increased by four times compared to operating on one plane.

The memory array is organized into metablocks such as MB ₀ , ..., MB _j, and all memory cells in each meta block can be deleted together as a unit. A metablock such as MB0 is constructed from multiple memory locations to store a logical page 914 such as LP ₀ -LO _N-1 . Logical pages in the metablock are distributed on four planes P0, P1, P2, and P3 in a predetermined order according to the order in which the metablock is filled. For example, when logical pages are filled in a logical sequential order, the planes are filled in the same order as the first page in the first plane and the second page in the second plane. Once the final plane is complete, the fill action resumes periodically from the first plane in the next meta page. In this way, the continuous operation of the logical pages becomes accessible in parallel when all planes work in parallel.

In general, if there are W planes operating in parallel and the metablocks are filled by logical sequential order, then the k-th logical page in the metablock is on plane x, where x = kMOD W. For example, assuming four planes, W = 4, and when filling blocks in logical sequential order, the fifth logical page LP5 is placed in the plane defined by 5 MOD 4, the above configuration. Corresponds to the plane 1 of FIG.

Memory operations in each memory plane are performed by a set of read / write circuits 912. Data existing inside or outside each of the read / write circuits is transmitted through the data bus 930 under the control of the controller 920. The buffer 922 of the controller 920 buffers the transfer of data through the data bus 930. In particular, if the action in the first plane requires transfer to data in the second plane, a two-step process is required. Data is first read from the second plane by the controller and transmitted to the first plane via the data bus and the buffer. Indeed, in the most preferred memory structure, data transfer between two different bit lines requires interchange over data bus 920.

At the very least, such an effect affects the transfer from one set of read / write circuits in one plane to another set of read / write circuits in the other plane. If the planes are constructed from different chips, it will probably require transmission between the chips.

The present invention provides a structure and configuration for memory block management in order to be able to avoid data access from another plane by one plane to maximize performance.

As shown in Fig. 21, a metapage is composed of a plurality of logical pages, one for each plane. Each logical page consists of one or more logical units. As data is written to a logical unit into blocks by logical units across the planes, each logical unit will coincide with one of four memory planes.

The problem of plane alignment occurs when the logical unit is updated. In the present example provided for illustrative purposes, the logical unit consists of 512 byte logical sectors, and the logical page is the entire logical unit. Since the flash memory does not first erase the entire block and does not allow rewriting of any part of the block, updates to the logical pages are not written to the current location, but are written to the unused location of the block. Older versions of the logic unit are closed. After a number of updates have been made, one block contains a number of logical units that are closed after the update. Blocks are represented as "dirty" and the garbage collection operation ignores such dirty logic units, but collects the latest version of each individual logical unit and rewrites them in one or more new blocks in a logical sequential order. do. The dirty block is deleted and used again.

When an updated logical unit is written to the next unused location in a block, it is not written to the same memory plane as the previous version. That is, when garbage collection operations such as consolidation or compression are performed, the latest version of the logical unit is rewritten in the same plane as the original to maintain the original order. However, if the latest version is fetched from another plane, performance degradation occurs.

Therefore, in another aspect of the present invention, when the first logical unit of the first block stored in a given plane is updated, the updated logical unit is configured to be kept in the same plane as the first one. This is accomplished by writing the updated logical unit to the next available position of the second block in the same plane. In one preferred embodiment, any interference gap that exists from the last program memory unit to the next available planar aligned memory unit is padded with current versions of logic units present at the same relative position as the first logic unit in the first block. (E.g., fill by copy).

Fig. 22A is a flowchart showing an update method using plane alignment according to the overall configuration of the present invention.

Step 950: In a nonvolatile memory organized in blocks, each block is partitioned into erasable memory units, each memory unit storing a logical unit of data.

Step 952: Configure memory from a plurality of memory planes, each plane having a set of sensing circuits for serving memory pages in parallel, the memory pages having one or more memory units.

Step 954: Store a first version of logical newnits among the memory units of the first block according to the first order. Each first version logical unit is stored in one of the memory planes.

Step 956: Store the next versions of the logical units in a second block in a second order that is different from the first order. Each next version is stored in the next available memory unit in the same plane as the first version, so that all versions of the logic unit are accessible from the same plane by the same set of sensing circuits.

Figure 22B shows a preferred embodiment of the step of storing the update in the flow chart shown in Figure 22A.

Step 956 'includes steps 957, 958 and 959.

Step 957: Partition each block into meta pages. Each meta page is constructed from a page of each plane. The above step is performed before the storing step.

Step 958: Store the next version of the logical unit in the second block according to a second order that is different from the first order. Each next version stores in the next available memory unit with the same offset in the same meta page as that of the first version.

Step 959: At the same time as storing the next version of the logical units, copy the current versions of the logical units in accordance with the first order and pad unused memory units by meta page prior to the next available unit.

Figure 23A shows an example of logical units written in sequential order for sequential update blocks regardless of plane alignment. The above example shows that each logical page has a size of logical sector such as LS0, LS1. In the case of four planes, each block, such as MB0, is partitioned into meta pages MP0, MP1, ..., where each meta page, such as MP0, is LS0, LS1 from planes P0, P1, P2, and P3. , Four sectors such as LS2, LS3. Thus, blocks are filled in logical units sector by sector in cycle order in planes P0, P1, P2, and P3.

In host write operation # 1, the data in logical sectors LS5-LS8 are updated. Updated data such as LS5'-LS8 'are written in the newly allocated update block, starting from the first available position.

In host write operation # 2, the data segment in logical sectors LS9-LS12 is updated. Updated data, such as LS9'-LS12 ', is written to an update block constructed within a position after the end of the last write. Two host writes are provided so that the update data can be written in the update block in logical sequential order such as LS5'-LS12 '. The update block is defined as a sequential update block after it is filled in logical sequential order. The update data recorded in the update block closes the corresponding data in the first block.

However, update logical sectors are written in the update block according to the next available position regardless of plane alignment. For example, sector LS5 is first recorded in plane P1, but updated LS5 'is recorded in P0. Similarly, other update sectors are all error aligned.

Figure 23B shows an example of logical units that are skewed out of order for the chaotic update block irrespective of plane alignment.

In host write operation # 1, logical sectors LS10-LS11 of a given logical group stored in the first meta block are updated. The updated sectors LS10'-LS11 'are stored in the newly allocated update block. At this point, the update blocks are made sequentially. In host write operation # 2, logical sectors LS5-LS6 are updated to LS5'-LS6 'and written into the update block at the position after the last write. The above operation converts the update blocks from sequential order to chaotic order. In the host write operation # 3, the logical sector LS10 'is updated again and written as LS10 " at the next position of the update block. At this point, LS10 " in the update block overtakes LS10 'in the previous record which alternately overtakes LS10 in the first block. In host write operation # 4, the data in logical sector LS10 " is updated again, and written as LS10 '" in the next position of the update block. Thus, LS10 '' 'becomes the latest and only valid version for logical sector LS10. All previous versions of the LS10 are now closed. For host write action # 5, the data in logical sector LS30 are updated and written into the update block as LS30 '. In the above example, the logical units in the logical group are written in the chaotic update block in a predetermined order and with a certain repeatability.

Again, update logical sectors are written in the update block according to the next available position regardless of plane alignment. For example, the sector LS10 is first recorded in the plane P2 (for example, MP2, third plane), but the update LS10 'is recorded in P0 (for example, MP0, first plane). Similarly, for host write action # 3, logical sector LS10 'is updated again as LS10 " and placed in the next available position that coincides with plane P0 (first plane in MP1). Thus, writing the update sector to the next available position of the block means that the updated sector may be stored in a plane different from the previous version.

Planar aligned, sequential update block with interference gaps filled by padding

24A is a diagram showing a sequential update example of FIG. 23A with plane alignment and padding according to one preferred embodiment of the present invention.

For host write action # 1, updated data LS5'-LS8 'is written into a newly allocated update block starting from the first usable plane alignment position. In this case, LS5 is first located in P1, and P1 corresponds to the second plane of the meta page. Thus, LS5'-LS7 'is programmed in the corresponding planes in the first available meta page MP0 of the update block. At the same time, the unused first plane gap in MP0 is padded with the current version of logical sector LS4 preceding LS5 in the meta page of the first block. The first LS4 is treated as closed data. The remaining LS8 'is written in the first plane of the next meta page MP1 and is plane aligned.

For host write operation # 2, the data updated by LS9'-LS12 'is written into the update block of the next available plane alignment position. Thus, LS9 'is written into the next available planar alignment memory unit, which corresponds to the second plane of MP1. In this case, no gap occurs and no padding is required. An update block is defined as a sequence update block because it is filled in logical sequential order. Furthermore, it is called plane alignment because each update logic unit is in the same plane as the original plane.

Planar Alignment and Chaos Update Block with Interference Gap

Figure 24B shows a chaotic update example of Figure 23B with planar alignment but without padding in accordance with a preferred embodiment of the present invention.

In the host write operation # 1, the updated logical sectors LS10'-LS11 'are stored in the newly allocated update block. They do not need to be stored in the next available memory unit, but they are stored in the next available flat aligned memory units. Since LS10 'and LS11' are first stored in planes P2 and P3 (third and fourth planes of MP2 of the first block, respectively), the next available plane alignment memory units are in the third and fourth planes of MP0 'of the update block. Located. At this point, the update block is out of order, and the pages of MP0 'are filled in the order of Unfilled, Unfilled, LS10' and LS11 '.

For host write action # 2, logical sectors LS5-LS6 are updated as LS5'-LS6 'and written into an update block of the next available plane alignment position. Thus, LS5 'and LS6' corresponding to the second (P1) and third (P2) planes of the first block or the memory unit MP1 are programmed to the corresponding plane within the next available metapage MP1 'in the update block.

In the host write operation # 3, the logical sector LS10 'is updated again and written as LS10' 'in the next planar alignment position of the update block. Thus, it is written on the next available third plane, which is located at MP2 '. Such a configuration produces a leading gap in the final plane in MP1 ', and a leading gap in the two first planes of MP2'. By the above operation, the LS10 'is closed at the MP0'.

In host write operation # 4, the data in logical sector LS10 " is updated again and written as LS10 " " in the usable third plane of meta page MP2 'in the update block. Thus, LS10 '' 'is now the latest and only valid version for logical sector LS10. Accordingly, a gap consisting of MP2 'and two first planes MP3' is formed.

In host write operation # 5, the data in logical sector LS30 is updated and written as LS30 'in the update block. Since the first LS30 is in the third plane of P2 or meta page, it is written to the next available third plane in the update block. In this case, it becomes the 3rd plane of MP4 '. A gap is formed between the two first planes MP4 'from the final plane of MP3'. In the above description, logical sectors within a logical group are written in the chaotic update block in a predetermined order and at a predetermined repeatability in a planar alignment method. In the next garbage collection operation, all versions, in particular the most recent version of a given logical sector, are conveniently serviced by the same set of sensing circuits.

Planar aligned, chaotic update block with interference gaps filled with padding

Figure 24C shows a chaotic update example of Figure 23B with planar alignment and padding in accordance with another preferred embodiment of the present invention.

In this embodiment, it is similar to that of Fig. 24B, except that the interference gaps are first filled with padding. For host write action # 1, the gap formed by the unused first and second planes of meta page MP0 'is first padded with the current versions of LS8 and LS9, with the above configuration placed in the first block. Here, LS8 and LS9 are located in the closed first block. At this point, the update blocks are sequential, and the metapage MP0 'is filled in the order of LS8, LS9, LS10' and LS11 '.

For host write action # 2, the gap is formed by the unused first plane in MP1 ', which is first padded with LS4. Accordingly, LS4 in the first block is closed. The second write converts the update blocks from sequential to chaotic.

For host write # 3, it is created by the unused final plane in MP1 'and the two first planes of MP2'. The final plane of MP1 'is first padded by LS7 after the last program LS6', and the two first planes of MP2 'are padded by LS10, i.e., LS8 and LS9. This closes LS10 in MP0 'and LS7-LS9 in the original block.

For host write action # 4, the gap is formed by the final plane in MP2 'and the two first planes in MP3'. The final plane of MP2 'is padded by LS11' corresponding to the current version of the logical unit after the last write LS10 '' in meta page MP2 '. The two first planes of MP3 'are padded by LS8 and LS9, respectively, because the logic units precede LS10' '' in meta page MP3 '.

For host write action # 5, the gap by the last plane of MP3 'and the two first planes of MP4' is padded by LS11 ', LS28 and LS29, respectively. Thus, logical sectors within a logical group are written in the chaotic update block in a predetermined order and in a predetermined repeatability in a planar alignment manner.

In a preferred embodiment, the meta page includes the cycling of pages from separate planes. Because meta pages are read or programmed in parallel, the granularity of meta pages allows each host update to be implemented.

In the embodiment by the example of Figs. 24A and 24C, during each host write, padding is performed on unused memory units preceding the plane aligned memory unit, and an update is programmed for the memory unit. The action of unused memory units after the last programmed memory unit is delayed until the next host write. In general, any preceding unused memory units are padded within the bounds of the metapage. In other words, if the preceding gap is delayed for two metapages, padding is performed for each metapage in a logically sequential order that is appropriate for each metapage, but the continuity is Does not matter.

In the case of block consolidation, if partially written, the final written metapage is completely filled by padding.

In another embodiment, some partially filled metapages are sufficiently padded before moving to the next metapage.

Memory Unit Granularity

Depending on the flexibility supported by the individual memory structures, it is possible to modify the read or program units. The independent nature of the individual planes allows each page from the individual planes in the metapage to be read and programmed independently of each other. The examples described above have the largest unit of program that can be a page in each plane. Within the metapage, partial metapage programming is possible that is smaller than all pages. For example, it is possible to program three first pages of a metapage and then program a fourth page.

At the plane level, a physical page has one or more memory units. If each memory unit stores a sector of data, the physical page stores one or more sectors. Some memory architectures support partial page programming and inhibit programming of selected memory units within a page so that the selected logical units can be individually programmed at different times for multiple programming passes.

Logical unit alignment in the memory plane for chaotic updating of logical groups

In a block memory management system, logical groups of logical units are stored in a logical sequential order within the first block. When the logical group is updated, the next versions of the logical units are stored in an update block. If logical units are stored in a chaotic way (e.g., out of order) in the update block, garbage collection is performed to collect the latest versions of the logical units among the first block and the update block, making them new first block. It will be integrated sequentially into. If the updated versions of a given logical unit are stored in an update block so that all versions are accessible by the same set of sensing circuits, the above garbage collection operation is efficient.

According to another aspect of the present invention, in the block memory management system described above, if the memory is organized into a series of memory pages, respective pages of the memory units are serviced in parallel by a set of sensing circuits, and if all of them All versions of a given logical unit are sorted if they have the same offset position in the page they are stored in.

Figure 25 shows an exemplary memory organization, each page having two memory units for storing two logical units, such as two logical sectors. In the first block, because logical sectors are stored in logically sequential order, logical sectors LS0 and LS1 are stored in page P0, logical sectors LS2 and LS3 are stored in page P1, and logical sectors LS4 and LS5 are paged. Stored in P3. For two sector pages, the first sector from the left has a page offset of zero and the second sector has a page offset of one.

When the logical group of logical sectors sequentially stored in the first block is updated, the updated logical sectors are written in the update block. For example, logical sector LS2 is in page P0 with offset 0 in the first block. In the first write, if LS2 is updated to LS2 ', it is stored in the first available location located in the update block with the same page offset zero. The same exists in the first memory unit of page P0. In the second write, if LS5 is updated to LS5 ', it will be stored in the first available location in the update block with the same page offset 1. The same exists in the second memory unit with offset 1 of page P1. However, before storing LS5 ', the unused memory units with offset 1 at P0 and the unused memory units with offset 0 at P1 are the logic that maintains at least logical sequential order within each page. Padded by providing a copy of the latest version of the sectors. In this case, LS3 is copied to offset position 1 position in P0 and LS4 is offset to offset 0 position in P1, respectively. In the third write, if LS2 'is updated back to LS2' ', it will be stored into offset 0 of P2. In the fourth write, if LS22 and LS23 are updated to LS22 'and LS23', respectively, they will be stored at offsets 0 and 1 of P3 respectively. However, prior to such an action, the unused memory unit with offset 1 at P2 is padded with LS3.

The update sequence described above pretends that individual sectors can be programmed within a page. For some memory structures where partial page programming is not supported, all sectors within a page must be programmed together. In this case, in the first write, LS2 and LS3 are programmed together at P0 ', and in the second write, LS4 and LS5' are programmed together at P1 ', respectively. In the third write, LS2 " and LS3 are each programmed together to P2 '.

Align Planes Within Metapages

The unit of the program has a subpage granularity. If the granularity of writing to the chaotic update block is a metapage, the entries in the CBI block described with reference to Figures 16A and 16B relate to the metapage instead of the sector. Increased granularity reduces the number of entries written for the chaotic update block, direct indices are removed, and a single CBI sector can be used per metablock.

Figure 26A is similar to the memory structure of Figure 21 except that each page has two sectors instead of one. That is, the metapage MP0 has a page for storing two logical units of data, respectively. If each logical unit becomes a sector, the logical sectors are stored sequentially in MP0 with LS0 and LS1 in plane p0 and LS2 and LS3 in P1.

FIG. 26B shows the metablocks of FIG. 26A with memory units schematically organized in a linear fashion. Compared with the single sector page of Fig. 21, logical sections are stored periodically in four pages having two sectors in each page.

In general, if there are W planes acting in parallel, and if there are K femory per page, and the metablocks are filled in sequential order with logical logic, then the k-th logical page in the metablock is in plane x Where x = k 'MOD W and k' = INT (k / K). For example, with four planes, W = 4, two sectors per page, K = 2, and k = 5, which corresponds to the fifth logical sector LS5, which is k shown in FIG. 24A. As in the plane given by 2 MOD 4 corresponding to plane 2. In general, the same principle applies to implementing the planar alignment described above.

The examples given above are for page alignment with planes in multiple plane structures. In the case of pages with multiple sectors, it is desirable to maintain sector alignment within one page. In this way, the same set of sense circuits can be used for different versions of the same sector. Operations such as sector repositioning and read-modify-write can be performed efficiently. When sorting the sector order within one page, the same technique may be used, such as sorting pages in a plane. Depending on the embodiment, certain interference gaps may or may not be padded.

Logical unit or planar alignment without padding

Figure 27 shows a structure for planar alignment in one update block without padding logical units copied from one position to another. The portions of the four planes across the update block are defined as four buffers that collect plane aligned update logic units received from the host. Each logical unit received from the host is programmed without padding in the next available memory unit of the given buffer. Different numbers of logical units are programmed in each plane according to the order of logical unit addresses received from the host.

The chaos update block MB1 'contains updated versions of all logical units of the logical metapage, such as MP0'. And, it may include fewer than all the logical units of the metapage such as MP1 '. In the case of MP1 ', the missing logic unit LS4 can be obtained from the corresponding first block MB0.

This other structure is particularly efficient if the memory structure supports parallel reading of binary logical pages from each plane. In this way, all logical pages of a metapage can be read in a single parallel read operation even if individual logical pages are not organized from the same column.

Stepped program error handling

If a program error occurs in a block, all data stored in the block is transferred to another block, and the block in which the error occurred is marked bad. Depending on the time specification during the action in which the error is detected, it may not have enough time to further transfer the stored data to another block. The worst case is when another and similar garbage collection action is required to relocate all data to another block, that is, a program error occurs in the middle of a normal garbage collection action. In such cases, the specific write latency limit of a given host / memory device is often violated because it is designed to not accommodate two dozen garbage operations for one.

Fig. 28 shows a program error occurring in a defective block animation during the merging operation, in which the merging operation is repeated in another block. For example, block 1 is the first block that stores the complete logical unit of a logical group in logical sequential order. Although shown for illustrative purposes, the first block has sections A, B, C and D, each section storing a subgroup of logical units. When the host updates certain logical units in the group, new versions of the logical units are written to an update block, block 2. As described above in connection with the update block, depending on the host, the update may write logical units in a sequential order or in a non-sequential (chaos) order. Ultimately, the update block is blocked from further receiving the update for some other reason. If the update block (block 2) is blocked, the current versions of the logical units present in the update block or the original block (block 1) are incorporated into a new block (block 3) to form a new original block for the logical group. do. The example shows an update block containing new versions of logical units in sections B and D. FIG. Sections B and D are schematically shown in block 2 and are not needed at the location where they are written and are aligned to the original positions in block 1.

In the coalescing operation, the current versions of all the logical units of the logical group initially present in block 1 are written in sequential order to the coalescing block (block 3). Logical units in section A are copied from block 1 to block 3, and in section B from block 2 to block 3. For example, if the logical unit of section C is copied from block 1 to block 3, a program error may occur due to a block 3 defect.

One way to deal with program errors is to restart the integration process for a new block (block 4). Thus, sections A, B, C and D are copied into block 4 and defective block 3 is saved. However, since this is a two-integrated action, the result is a copy of two blocks that are saturated with logical units.

The memory device has a specific time schedule to perform a predetermined action. For example, if a host writes to a memory device, the write operation is expected to finish within a given given time, which is called a write delay. If a memory device, such as a memory card, is busy writing data from the host, it sends a " Busy " state to the host indicating the busy state. If the busy state persists longer than the write delay period, the host times out the write operation and registers an exception or error for the write operation.

29 schematically illustrates a host write operation with a timing or write delay that provides sufficient time to complete the integration operation as well as the write operation (delay). The host write action provides a write delay Tw, which provides the update block (FIG. 29A) with sufficient time for completion of the update action 972 of write host data. As described earlier in the block management system, host writes to update blocks may trigger a coalescing action. That is, in addition to the update action 972 by timing, the integration action 974 (Fig. 29B) is enabled. However, restarting the coalescing operation in response to an error that has occurred may take too long time and exceed the set write delay.

According to another aspect of the present invention, in a memory having a block management system, a program error occurring in a block during a time-critical memory operation may be implemented by continuing a programming operation in the breakout memory. At smaller threshold times, data written to the failed block before the interruption occurs is transferred to another block, which may be a breakout block. The block in which the error occurred is discarded. If a combined block is found in this way, the data stored in the defective block can be transferred directly in the field, thereby allowing the stored data to be handled in the field without data loss and without exceeding a set time limit. This error handling is particularly important for the garbage collection operation since the entire operation does not have to be repeated for a new block for a threshold time. As a result, at some reasonable time, data from the defective block can be obtained by repositioning to another block.

30 is a flowchart showing a program error handling in accordance with the overall structure of the present invention.

Step 1002: Organize the nonvolatile memory into blocks. Each block is partitioned into memory units that can be erased together. Each memory unit stores a logical unit of data.

Program Error Handling (Step 1)

Step 1012: Store the order of the logical units of data in the first block.

Step 1014: After storing the plurality of logical units, in response to a storage error in the first block, store the next logical units in a second block that functions as a breakout block for the first block.

Program Error Handling (Final Step)

Step 1020: In response to a predetermined event, transfer logical units stored in a first block to a third block, where the third block may or may not coincide with the second block.

Step 1022: Discard the first block.

Fig. 31A is a diagram showing a first embodiment of program error handling in a configuration in which the third block (final position reset) block is different from the second (breakout) block. In step I, a series of logical units is written to the first block. If logical units are constructed from host writes, the first block is defined as an update block. If the logic units are constructed from the integration of the compression action, the first block is defined as a reposition block. At a given point, if a program error is detected at block 1, a breakout block is constructed. Logical units and other next units that fail to be written to block 1 are written to the breakout block instead. In this way, no additional time is required to replace error block 1 and the data present therein.

In the interference phase II, all written logic units of the sequence are obtainable between block 1 and block 2.

In the final step III, error block 1 and the data present therein are replaced by repositioning the logic units to block 3, which block 3 functions as a reposition block.

In other words, the data in the error block is revived and the error block is discarded. The final step is timed so as not to conflict with the timing of any other temporary memory operation.

In the present embodiment, the reposition block 3 is clearly different from the breakout block 2. In other words, this is useful when the breakout block is written to additional logical units during the intermediate step. In other words, the breakout block switches to the update block and does not serve to reposition the logical units from the defective block 1.

Fig. 31B shows another embodiment of program error handling, where the third (final position reset) block is the same as the second (brateout) block. Steps I and II are similar to the first embodiment of Fig. 31A. However, in step III, the logic units from the defective block I are repositioned to the breakout block 2. This is useful when the breakout block 2 is written to an additional logical unit that is different from the initial order of the previous write operation. In this way, minimal blocks are needed to store the logical units.

Example for handling program errors in the integration process

Program error handling is particularly important in the integration process. Normal consolidation action is integrated into the consolidation block, and current versions of all logical units in the logical group are between the initial block and the update block. In the course of the integration operation, if a program error occurs in the integration block, another block acting as a breakout block receives the integration of the remaining logical units. In this way, there will be no logical unit to be copied more than once, and the action of exceptional handling is completed within a set period of time during the normal integration action. At the appropriate time, the integration operation can be completed through the breakout block with all the good logic units in the group. Appropriate time means a different period of time outside of the current host write activity when there is time to perform the integration. Such a suitable time can be implemented during another host write process where there is an update but no corresponding aggregation action.

In particular, integration using program error handling can be implemented in a number of steps. In the first step, logical units are merged into one or more blocks after a program error to avoid consolidating one or more logical units. The final phase is completed in a timely manner, integrating into one block by collecting all logical units into breakout consolidation blocks in sequential order.

32A is a flow chart of an initial update action that may achieve an integration action.

Step 1102: Organize the nonvolatile memory into blocks, each block partitioned into erasable memory units, each memory unit storing a logical unit of data.

Step 1104: Organize the data into a plurality of logical groups. Each logical group is a group of logical units that can be stored in a block.

Step 1112: Receive host data packaged into logical units.

Step 1114: Store the first version of the logical units of the logical group in the first block according to the first order to generate the first block of the logical group.

Step 1116: Store in a second block containing a next version of logical units of the logical group according to the second order to generate an update block of the logical group.

Step 1119: For a predetermined event in the section described above, garbage collection is performed to collect the current version of the logical units in the various blocks and rewrite it into a new block.

32B is a flow chart of a multi-step integration action of a preferred embodiment of the present invention.

Integrated Error Handling (Phase I)

Error handling, integration action for step I action 1120 includes step 1122 and step 1124.

Step 1122: Store current versions of logical units of a logical group similar to the first order in a third block to generate a coalescing block for the logical group.

Step 1124: In response to a storage error in the coalescing block, the logic units of the logical group deviating from the third block are stored in a fourth block similar to the first order to provide a breakout coalescing block.

Data in blocks 1 and 2 are transferred to blocks 3 and 4, and blocks 1 and 2 are deleted to increase space. In a preferred embodiment, block 2 is immediately released and reused as EBL (Erased Block List, see FIG. 18). Block 1 can be released if it is a closed getdate block. There is another block pointed to by the corresponding GAT entry.

In particular, block 3 becomes the first block for the logical group and block 4 becomes the replacement sequential update block for block 3.

After the phase I integration is complete, the memory device sends a busy signal to signal the host.

Intermediate action (phase II)

Step II, which is intermediate action 1130, may be performed before step III integrated action 1140. Many possible scenarios consist of steps 1132, 1134 and 1136.

Step 1132: For the write operation of the logical group, write as a fourth block (Breekeout Integration Block) as an update block.

If the host writes to the logical group in question, block 4, which is a breakout consolidation block and acts as a replacement sequential block, will be used as a normal update block.

Depending on the host write, it may remain in a sequential state or may be converted to a chaotic state. As an update block, it may be in any point trigger closure of another chaotic block, as described in the previous embodiment.

If the host writes to another logical group, it proceeds directly to step III.

Step 1134: Alternatively, in a read operation, the memory is read as the first block for the logical group using the third block, and the fourth block is read as the update block.

In this case, the logical units from sections A and B are read from block 3 as the first block of the logical group. And logical units from sections C and D are read from block 4 as update blocks of the group. Since sections A and B can be read from block 3, programming will not have access to the page that is causing the error, and there will be no access to the parts written after that. Since the GAT directory in the flash memory has not yet been updated and points to block 1 as the first block, there is no data read from it, and the block itself can be deleted early.

Another possibility is a host read of logical units in a logical group. In this case, the logical units from sections A and B will be read from block 3 as the logical group first block, and the logical units from sections C and D will be read from block 4 as the sequential update block of the group.

Step 1136: Or, in power-up initialization, one of the first to fourth blocks is checked again by scanning their contents.

Another possibility of the intermediate stage applies for memory devices that are powered off and restarted. As described above, during the power-up initialization process, the blocks in the allocation block list (deletion pool block used, see Figures 15 and 18) are scanned, sequential for the first block of special state (block 3) and the logical group. Identify the combined block of blocks that becomes the update block (block 4). The flag of the first logical unit of the block block (block 4) indicates that the block is the first block (block 3) that has failed due to a program error. In communication with the block directory (GAT), block 3 is positioned.

According to one embodiment, the flag is programmed into the first logical unit in the breakout integration block (block 4). According to this action, the special state of the logical group is indicated, for example, indicating that it is merged into two blocks, namely blocks 3 and 4.

Another way to use flags to identify logical groups using faulty blocks is that the first block is filled with something like that (unless the last page has an error, the last page has no ECC error). Rather, it detects blocks by defecting during scanning according to features. According to the older method, there may be an information record for error groups / blocks stored in the control data structure, but not in the header area of the first sector written in the breakout integration block (block 4) in the flash memory.

Integration Completed (Step III)

Step 1142: In response to the predetermined event and for the first case when the fourth block has not been continuously recorded after Step I, take the current version of all the good logical units of the logical group similar to the first order. Store and merge the third and fourth blocks into the fifth block for the second case where the fourth block after step I is further recorded.

Step 1144: Thereafter, for the first case, operate the memory with the fourth block integrated as the first block for the logical group, and for the second case, memory with the fifth block as the first block for the logical group. Activate

Final consolidation in Phase III will take place whenever the opportunity is reached without violating the stated time limits. The preferred case is to piggyback on the next write slot when there is no consolidation action to accompany, and when there is an update action on another logical group. If a host write to another logical group triggers dozens of garbage itself, the Phase III integration is delayed.

33 illustrates exemplary timings of the first and last steps of a multistep integration action. The host write delay is the width of each host write slot with a period Tw. Host write 1 is a simple update and the current versions of the first set of logical units in logical group LG1 are written to the associated update block.

For host write 2, another update to logical group LG1 occurs to cause the update block to close (full state). A new update block is prepared to record the remaining updates. The provision of a new update block triggers a garbage collection, in which an integration action is performed on LG4 to reclaim the block for reuse. The current logical units of the LG4 group are based on the integrated blocks in aberration order. The integration action proceeds until the defect is found on the integration block. Phase 1 integration is performed in a configuration in which the integration action continues in the breakout integration block. And the final integration of LG4 (Phase III) will wait for the next opportunity.

For host write 3, writes of logical units of logical group LG2 occur, which triggers integration to LG2. This means that time slots are already being used sufficiently.

In host write 4, the action is simply to write the logical units of LG2 to an update block. The spare time in the time slots provides an opportunity for the final integration of LG4.

An embodiment that is not converted to a breakout integration jloy update block

 34A and 34B show the first case for stages I and III of multiple stage integration when applied to the examples of FIGS. 28 and 31.

34A shows the case where the breakout integration block is not used as an update block but is further used as an integration block in which the integration operation is stopped. In particular, FIG. 34A is for host write # 2 in FIG. 33, where the host writes an update of logical units belonging to logical group LG1, and by action triggers the integration of a block associated with another logical group LG4.

The information in the initial block (block 1) and update block (block 2) is implemented in the same way as the example of FIG. In the course of the integration action, the integration block (block 3) finds a defect at the point of integrating the logic unit of section C. However, unlike the unified structure of Fig. 28, the multiple step structure according to the present invention continues the unified action for the new block (block 4) acting as a breakout unified block. In the phase I consolidation action, the logical units in sections A and B are integrated in an integration block (block 3). If a program error occurs in the integration block, the remaining logical units in sections C and D are copied sequentially into the breakout integration block (block 4).

If the host writes an update in the first logical group that triggers the coalescing action of the block with respect to the second logical group, the updates of the first logical group are written as an update (new update block) for the first logical group. In this case, the breakout integration block (block 4) is not used to write any update data outside of the integration action, leaving the breakout integration block incomplete yet.

Since the data in blocks 1 and 2 are sufficiently contained into other blocks (block 3), they can be erased again for reproduction. The address table (GAT) is updated to block 3 as the first block for the logical group. Directory information for the update block (in Figure ALC, see Figures 15 and 18) is also updated to block 4, which becomes a sequential update block for the logical group (eg LG4).

As a result, the consolidated logical group is not localized in one block, but is divided into a combined consolidation block (block 3) and a breakout consolidation block (block 4). An important feature of this architecture is that the logical units in the group are integrated only once during this step at the expense of distributing the integration over one or more blocks. In this way, the integration action can be completed within the normal prescribed time.

FIG. 34B shows the third and final stages of the multi-step consolidation started at FIG. 34A. As described with respect to Figure 33, phase III consolidation is executed at the appropriate time after the first phase in the same time zone as the next host write process that does not trigger an accompanying consolidation. In particular, Figure 34B relates to a time slot, where host write # 4 of Figure 33 occurs. During the above period, the host write updates the logical units belonging to the logical group LG2 without triggering another additional consolidation action. Thus, the surplus time in the time slot can be used for stage III to complete the integration of logical group LG4.

By means of integrating all the good logic units of LG4 that are not in the breakout block into the breakout block. For example, sections A and B are copied from block 3 into breakout blocks (block 4) in a logically sequential order. In the wrap-around structure of the logical unit within the block and the use of page tags (see FIG. 13A), although the examples show that in block 4, sections A and B are written after sections C and D, the order of recording is Same as the sequential order of A, B, C and D. According to the method of implementation, current versions of the good logical units to be copied are obtained from block 3 because it already exists in an integrated form, and will be collected from block 1 if they are not deleted.

After the final consolidation is made on the breakout block (block 4), it is designated as the first block for the nori group, and the corresponding directory (eg, GAT, see Fig. 17A) will be updated accordingly. Similarly, the error physical block (block 3) is marked bad and is mapped out. The other blocks and blocks 1 and 2 are deleted and played back. And, the renewal for LG2 is recorded in the update block related to LG2.

Embodiment in which the breakout integration block is implemented as an update block

35A and 35B show the second case for the step I and step III actions of the carpenter step integration, respectively, as applied to the examples of FIGS. 28 and 33.

Figure 35A illustrates the breakout integration block being maintained as an update block, receiving a host write rather than an integration block. This configuration works well for host writes that update logical group LG4 and trigger consolidation within the same logical group during the process.

As shown in Fig. 34A, the consolidation of block 1 and block 2 to block 3 continues while processing section C, until a program error is detected. Integration continues with the breakout integration block (block 4). Instead of waiting in step III to complete the consolidation of the logical group, after the good logic units (eg, within sections C and D) are integrated within the breakout block (block 4), the breakout block Is maintained as an update block. This case works well in a scenario where host writes update a logical group and misintegrate the same logical group. For example, it is possible to record the host update for the logical group LG4 written in the breakout consolidation block (block 4) instead of being written to the new update block according to this configuration. The update block (formerly breakout consolidation block (block 4)) is sequential or chaotic depending on the host data written therein. As in the illustrated example, block 4 is confused because the next new version of the logical units in section C leaves the preceding version in block 4 closed.

In the interim process, block 3 is defined as the first block for LG4, and block 4 will be the associated update block.

Figure 35B shows the third and final stages of the multi-step consolidation started in Figure 35A for the second case. As described with respect to Figure 33, the consolidation in step III is performed at some reasonable time after the first step, such as the next host write time, without triggering the accompanying consolidation action. During the above process, the host write updates the logical units belonging to the logical group without triggering the coalescing action. The extra time in the time slot can be used for phase III operation to complete the integration of logical group LG4.

Logical group LG4 is collected from blocks 3 and 4 into a new unified block (block 5). Block 3 is given a "bad" indication, block 4 is played, and a new unified block (block 5) becomes a new block for logical group LG4. Other blocks such as block 1 and block 2 are also deleted and replayed.

Another embodiment of stepped program error handling

The example sentences described in Figures 31A, 31B, 34A, 34B, and 35B apply to a preferred block management system having a physical block (metablock) that stores only logical units belonging to the same logical group.

The invention is equally applicable to other block management systems in which no more logical groups exist for disadvantaged block alignments such as those disclosed in WO 03/027828 and WO 00/49488. Examples of staged program error handling methods for such other systems are shown in FIGS. 36A, 36B, and 36C.

Figure 36A illustrates a staged program error handling method as applied to a scenario when a host write triggers the closure of an update block and when the update block is sequential. In this case, the closing is performed by copying the remaining valid data B and C from the first block 2 to the sequential update block 3. If a program error occurs at the start of data part C programming, part C is programmed in block 4 reserved. The new host data is written to a new update block 5 (not shown). Steps II and III of the method are the same as in the case of chaotic block closure.

Fig. 36B is a diagram illustrating program error handling staged as applied to the partial block system in the case of updating of update blocks. In this case, the logical group is stored in the first block 1 and other update blocks. The coalescing action copies data from the original block 1 and the other update block 2 into one of the update blocks (block 3 in the figure, selected according to certain rules). The difference from the main scenario described above is that block 3 has already been partially written.

Figure 36C illustrates a staged program error handling garbage collection operations or cleaning operations within a storage block management system that does not support logical groups mapped to metablocks. Such a memory block management (cycle storage) system is disclosed in WO 03/27828 A1. The main feature of a cycle storage system is that blocks are not allocated for a single logical group. There is no support for multiple logical groupings for control data in metablocks. Garbage collection is to have a valid data sector that has no relationship (random logical block addresses) to a relocation block that may have some data from the partially closed block. If the reposition block has enough of the course of action, another one will be opened.

Out of order update block indexing

In the early section on chaotic block indexing, and with respect to Figures 16A-16E, the CBI sector stores an index that tracks the location of the logical sector that is randomly stored within the chaotic or out of order update block.

According to another aspect of the present invention, in a nonvolatile memory having a block management system for supporting an update block having an out of order logical unit, the index of the logical unit in the update block buffered with RAM is periodically stored in the nonvolatile memory. . In one embodiment, the index is stored in a block for storing the indexes. The index is then stored in the update block. In another embodiment, the index is stored in the header portion of each logical unit. In another aspect, logical units written after and before the last index update have indexing information stored in the header of each logical unit. In this way, after a power interruption, the position of the recently written logical unit is determined without the need for scanning during the initialization process. In another aspect of the invention, blocks are more related than one logical subgroup, and are managed in part sequentially and partly out of order.

Index pointer stored within a CBI sector in a CBI block after some triggering event

According to the structure shown in Figures 16A-16E, a list of recently written sectors in the chaos block is provided in the controller RAM. The CBI sector containing the most current indexing information is written to flash the memory (CBI block 620) after a certain number of writes in the logical group associated with the given chaotic block. In this way, the number of updates to the CBI block is reduced.

Prior to the next update of the CBI for the logical group, the list of the latest write sectors of the nong group is held in the controller RAM. If the memory device is in the case of a power off, such a list is lost, but can be rebuilt by scanning the updated blocks in the process of initializing after the power is supplied again.

Figure 37 shows an example of a CBI sector write schedule to a related chaotic index sector block after all N-sector writes of the same logical group. The example sentences show two logical groups LG3 and LG11 performing concurrent updates. Logical sectors of LG3 are stored in sequential order within the first block. Updates of logical sectors in the group are written on the associated update block in the order indicated by the host. Examples illustrate the chaotic update order. At the same time, logical group LG11 is updated in a similar manner in its update block. After every logical sector write, its position in the update block is kept in the controller RAM. After every triggering event, the current index of logical sectors in the update block is written to the non-volatile chaotic index sector block in the form of a chaotic index sector. For example, some triggering event occurs after every N writes, where N is three.

Given examples are provided as data logic units in sector form. One skilled in the art is a collection such as a page in which a logical unit contains a sector or a group of sectors. Also, the first page in the sequential block need not be logical page 0 because the page tag wrap around may be in place, and the page tag wrap around may be in place.

Index pointer stored in CBI sector in chaotic update block after some triggering event

In another embodiment, the index pointer is stored in the CBI sector in the chaos update block after every N writes. This structure is the same as the previously described embodiment in that the index is stored in the CBI sector. The difference from the previous embodiment is that the CBI sector is written to the CBI sector block, not to the update block itself.

It is to maintain the chaos block indexing information in the chaos update block itself. 37A, 37B, and 37C show the state of an update block storing CBI sectors in three different stages.

Figure 38A shows an update block up to the pointer when a CBI sector is written after a certain number of writes. In the above example, after the host sequentially writes logical sectors 0-3, it instructs another version of logical sector 1 to be rewritten to break the sequence of writing data.

The update block is converted into a chaotic update block according to the implementation of chaos block indexing included in the CBI sector. As previously described, the CBI contains indices for all logical sectors of the chaos block. For example, the 0th input includes an offset in the update block for the 0th logical sector. Similarly, the n-th input indicates the offset for the n-th logical sector. The CBI sector is written to the next available position in the update block. To prevent frequent flash access, the CBI sector is written after every N data sector writes. In this example, N is four. If the power is cut off at this point, the last write sector becomes a CBI sector and the block is defined as a chaotic update block.

FIG. 38B shows the update block of FIG. 38A with logical sectors 1, 2, and 4 further written thereafter after the index sector. The new versions of logical sectors 1 and 2 precede the older versions written in the update block. In the case of a power cycle at this point in time, the last write sector needs to be found first, and needs to be scanned to find the last write index sector and the latest write data sector.

FIG. 38C shows the update block of FIG. 38B with another logical sector seized by triggering the next write of an index sector. After another N (N = 4) sector writes, the same update block writes another current version of the CBI sector.

The advantage of this structure is that there is no need for a separate CBI block. At the same time, the overhead data area of the physical flash sector is large enough to accommodate the number of inputs required for the index by validating the sectors in the chaotic update block. The chaos update block has all the information and no external data is needed for address translation. This reduces control updates due to CBI block compression and achieves a simpler algorithm capable of shorter cascade control updates.

Information about recently written sectors stored in the data sector header in the chaos update block

According to another aspect of the invention, the index of the logical unit written to the block is stored in the nonvolatile memory after every N writes, and the current information for the logical unit of intermediate writes is the overhead portion of each written logical unit. Are stored in. In this way, after power is resupplied, information about the logical units written since the last index update can be quickly obtained from the overhead portion of the last written logical unit in the block without having to scan the block.

Figure 39A shows an intermediate index for intermediate writing stored in the header portion of each data sector in the chaos update block.

FIG. 39B shows an example of storing an intermediate index for intermediate writing present in the header of each sector. FIG. In the example, after four sectors, LS0 through SL3 are written, and the CBI index is written as the next sector in the block. Thus, logical sectors LS1 ', SL2' and SL4 are written in blocks. At each time, the header stores an intermediate index for the logical unit written after the last CBI index. The header in LS2 'has an index that provides not only the final CBI index, but also its offset (eg, location) of LS1'. Similarly, the header in LS4 has an index that provides offsets of LS1 'and LS2' as well as the final CBI index.

The last sector of data written contains information up to the N-last write page (e.g., the last tucked CBI sector). When power re-start is initiated, the final CBI index provides indexing information for logical units written before the CBI index sector, and the indexing information for the next logical unit written is found in the header of the last sector of data written. Such a structure has the advantage of eliminating (initializing) the need to scan the block for the next written sectors to determine their location.

The structure for storing intermediate index information in the header of the data sector is equally applicable whether a CBI index sector is stored in an update block or whether a separate CBI sector is stored in a preceding section.

Index pointers stored in data sector headers in the chaos update block

In another embodiment, the full CBI index is stored in the server header portion of each data sector in the chaos update block.

40 shows information in the chaos index field stored in the header of each data sector in the chaos update block.

The information capacity of sector headers is limited, so the range of indexes provided by a single sector is part of the hierarchical indexing structure. For example, sectors within a particular plane of memory provide indexing only to sectors within that plane. Thus, the range of logical addresses is divided into subranges so that an indirect indexing structure is applied. For example, if sectors with 64 logical addresses are stored in one plane, each sector has three fields for sector offset values. Here, each field may store four offset values. The first field has a physical offset for the last written sector in the logical offset ranges 0-15, 15-31, 32-47 and 48-63. And the second field defines the physical offset values for four sub ranges of four sectors within the range associated therewith. The third field has physical offset values for four sectors within the subrange with which it is associated. The physical offset of a logical sector in the chaos update block is determined by reading indirect offset values up to three sectors.

The advantage of this structure is that the block eliminates the need for CBI blocks or CBI sectors. However, the overhead data area of the physical flash sector is large enough to accommodate the number of inputs needed for an index to remove sectors from the chaotic update block.

Limited logical scope in logical groups for chaotic update blocks

Within a logical group, the logical range of setters that can be written non-linearly is reduced. The main advantage of the technique in which sectors out of range are written sequentially within the original block and garbage collection operations is that the data written sequentially is executed faster, and only one multi-sector page (in the case of a multi-chip case). Is shorter because it needs to be read to take all the data for the target page (but the source and target are aligned, if not, another read is required) Sequential data can be copied from the source to the target without the data transfer to or from the controller using the on-chip copy feature, if source data is scattered as in a chaotic block, one per sector Page reads are required to collect all sectors written to the destination Can.

In one embodiment, instead of limiting the logic control to a certain number of sectors, it is implemented by reducing the number of CBIs (which makes sense to limit the chaotic range for larger group / meter blocks). For example, if the metablock / group is 2048 sectors, an 8CBI sector may be needed. And each covers a contiguous logical range of one subgroup of 256 sectors. If the number of CBIs is limited to four, chaotic metablocks can be used for up to four write groups. Logical groups have four partially or wholly subgroups. At least four subgroups exist in sufficient order. If the chaotic block has four usable CBI sectors, the host writes the sectors out of the CBI sector. And chaos logic groups must be integrated and closed. However, this is very unlikely to occur in practical applications. Hosts do not need four chaotic ranges of 256 sectors (subgroups) within the range of 2048 setters (logical groups). As a result, in the normal case, the garbage collection time is not affected, but the limit rule gauze forms an extreme way of garbage collection that is too long, which can trigger a time out of the host.

Indexing of Partial Sequential Chaos Update Blocks

If a sequential update block is partially written before being converted to chaos management mode, all or some portions of the sequentially updated section of the logical group are updated sequentially, and chaos update management is a subset of the logical group's address ranks. Is applied.

Control data integration and management

Data stored in the memory device is broken due to the power cut, and a defect occurs at a predetermined memory location. If a defect is found in the memory block, the data is moved to another block and the hard block is discarded. If the error is not large, it is corrected in an on-the-fly manner by an error correction code (ECC) stored with the data. However, if ECC fails to correct such problem data, much time is required. For example, when the number of error bits exceeds the capacity of the ECC. This situation is unacceptable for critical data such as control data associated with the memory block management system.

Examples of control data are directory information and block allocation information relating to the memory block management system shown in FIG. As described above, control data is maintained in high speed RAM and low speed nonvolatile memory blocks. Frequently changed control data is held in RAM periodically with control writes to update the equivalent information stored in the nonvolatile metablock. In this way, control data is a low speed flash memory that is stored non-volatile, but does not require frequent access. Layers of control data structures such as GAT, CBI, MAP, and MAPA are maintained in flash memory. According to the control write operation, the information from the control data structure in the RQAM updates the equivalent control data in the flash memory.

Critical data redundancy

According to another aspect of the present invention, some or all of the data, such as the control data, may be kept redundantly to ensure high reliability. Redundancy is the following method, i.e. for a multi-state memory system using a two-pass programming technique for successively programming the same set of multi-bits of a memory cell, any programming error in the second pass results in It does not interfere with the data formed by it. Redundancy enables the detection of write abandonment, detection of detection errors (copy is a good ECC reporter, but data is different), further improving reliability. Several techniques of data redundancy are used.

In one embodiment, after two copies of a given data have been programmed in a previous programming pass, the next programming pass avoids programming memory cells that store at least one of the two copies. In this way, at least one of the two copies is not affected if the next programming pass is canceled before completion and does not damage the data of the preceding pass.

In another embodiment, two copies of a given data are stored in two different blocks, with at most one of the two copy quintets having memory cells programmed in the next programming pass.

In another embodiment, after two copies of a given data are stored in a programming pass, no further programming is performed on the set of memory cells that store the two copies. This is accomplished by programming two copies in the ultimate programming pass for the memory cell.

In another embodiment, two copies of a given data are programmed into multi-state memory in binary programming mode such that no further programming on the programmed memory cell occurs.

In another embodiment, in a multi-state memory system using two pass programming techniques for successively programming multi-bits of the same set of memory cells, the data set by the pass in initial programming may be followed in a subsequent programming pass. A fault-tolerant is used to code multiple memory states so that they are not affected by the error of.

The complexity of data replication occurs in multi-state memories where each memory cell stores more than one bit of data. For example, four-state memory can represent this bit. One existing technique is to use two-pass programming to program such memory. The first bit (lower page bit) is programmed by the first pass. The same cell is then programmed in a second pass to represent a given second bit (high page bit). In order not to change the value of the first bit in the second pass, the memory state description of the first bit is made to influence the value of the second bit. Thus, if an error occurs during power down or other causes during programming of the second bit resulting in an incorrect memory state, the value of the first bit may also be destroyed.

Figure 41A shows the threshold voltage distribution of a four-state memory array as each memory cell stores this bit of data. The four distributions show the distribution of four memory states, "U", "X", "Y" and "Z". Before the memory cell is programmed it is first erased to the "U" or "non-write" state. The memory states, "X", "Y", and "Z" are gradually reached as they are programmed with increasing memory cells.

Figure 41B shows a conventional, two-pass programming configuration using Gray code. Four states can be represented by two bits, such as (Upper page bit, Lower page bit), the lower page bit and the upper page bit. For a page of cells to be programmed in parallel, there are two actual logical pages: a logical lower page and a logical upper page. The first programming pass only programs logical lower pages. A second programming pass on the same page, followed by proper coding, programs the logical upper page without resetting the logical lower page. A commonly used code is a gray code that changes only one bit when changing to adjacent states. Therefore, this code has a less required advantage for error correction since only one bit is included.

A common configuration for using gray code is to have "1" indicate "not programmed". Thus, the erased memory state " U " is represented by (Upper page bit, Lower page bit) = (1,1). Any cell for storing data " 0 " in the first pass for programming the logical lower page. Has a logical state transition from (x, 1) to (x, 0), where x represents the high-order "don't care" value. However, since the higher bits have not yet been programmed, "x" can also be labeled "1" for consistency. The (1,0) logical state represents the programming of the cell to memory state "X". That is, the lower bit value of "0" before the second program pass is represented by the memory state "X".

Second pass programming is performed to store the bits of the logical upper page. Only cells that require an upper page bit value of "0" are programmed. After the first pass, the cells on this page are logical states (1,1) or (1,0). In order to preserve the value of the lower page in the second pass, it is necessary for the lower bit value of "0" or "1" to be distinguished. The memory cell in question is programmed to memory state " Y " for switching from (1,0) to (0,0). In order to switch from (1,1) to (0,1) the memory cell in question is programmed to memory state "Z". In this method, both the low page bit and the high page bit can be decoded by measuring the memory state programmed into the cell during reading.

However, gray code, two-pass programming configurations can be problematic when second-pass programming is error-prone. For example, programming the upper page to "0" while the lower bit is at "1" causes a transition from (1,1) to (0,1). This requires that memory cells be progressively programmed from "X" and "Y" to "Z" via "U". If there is a power failure before completion of programming, it may end in one of the switching memory states, ie, "X". When the memory cell is read out, the "X" is decoded as logical state (1,0). This had to be (0,1), giving inaccurate results in both the high and low bits. Likewise, if programming is interrupted when "Y" is reached, it corresponds to (0,0). The upper bit is now correct but the lower bit is still an error.

Thus, it can be appreciated that a problem with upper page programming can already be modulated with data in the lower page. In particular, if the second pass programming involves passing to an intermediate memory state, then the program abort will have programming ending in the memory state, resulting in a decoded in the incorrect lower page.

FIG. 42 illustrates a technique for securely guarding critical data as each sector is dual saved. For example, the sectors A, B, C and D are kept in duplicate copies. If there is corruption of data in one sector copy, other data can be read instead.

FIG. 43 illustrates non-robustness in which dual sectors are typically preserved in multi-state memory. As mentioned above, in an exemplary four-state memory, the multi-state page actually includes a logical lower page and a logical upper page, which are individually programmed in two passes. As illustrated, the page is four sectors wide. Thus, sector A and its duplicates are programmed simultaneously in the logical lower page, and so does sector B and its duplicates.

Next, in the subsequent second pass of programming in the logical upper page, sectors C and C are programmed simultaneously, and so are sectors D and D. If a program interruption is caused during the program of sectors C and C, sectors A and A in the lower page will be destroyed. If the lower page sectors are read first and not buffered prior to the upper page programming, they may become unrecoverable if destroyed. Therefore, if two copies of critical data are preserved at the same time as sectors A and A, both of them cannot be prevented from being destroyed by the continuous problem of sectors C and C in its upper page. .

44A illustrates one embodiment of preserving staggered copies of critical data in a multi-state memory. Basically, the lower page is preserved in the same manner as in Fig. 43, that is, sectors A and A and sectors B and B. However, in the upper page programming, the sectors C, D are interleaved using their copy as (C, D, C, D). If partial page programming is supported, two copies of sector C are programmed simultaneously and similarly for two copies of sector D. If the program of say (say), the two sectors (C) is stopped, the lower page is destroyed only by one copy of the sector (A) and one copy of the sector (B). The other copy remains unchanged. Thus, if there are two copies of the critical data stored in the first pass, they are not subject to subsequent second pass programming at the same time.

44B illustrates another embodiment of preserving double copies of critical data only for logical upper pages of a multi-state memory. In this case, the data in the lower page is not used. The critical data and its duplicates, such as sectors A and A and sectors B and B, are kept only in the logical upper page. In this way, if there is a program interruption, the critical data is rewritten in another logical upper page, while any destruction on the lower page data is not critical. This solution basically uses half the storage capacity of each multi-state page.

44C illustrates another embodiment for preserving double copies of critical data in binary mode of a multi-state memory. In this case, each memory cell is programmed in binary mode where its threaded area is only divided into two zones. Thus, if a program interruption occurs, there is only one pass programming and the programming is re-initiated at another location. This solution also uses half of the storage capacity of each multi-state page. Operating multi-state memory in binary mode is disclosed in US Patent No. 6,456,528, which is incorporated herein by reference.

45 illustrates another embodiment of preserving a double copy of critical data in two different metablocks simultaneously. If one of the blocks becomes inactive, the data can be read from another copy. For example, the critical data is included in sectors A, B, C, D and E, F, G, H, and J, K, L. The two copies will be written to two different blocks (Block 0 and Block1) at the same time. If one copy is written to the logical lower page, the other copy will be written to the logical upper page. In this way there will always be one copy programmed in the logical upper page. If a program break occurs, it can be reprogrammed into another logical upper page. At the same time, if the lower page is destroyed, another upper page copy will be made in another block.

46B illustrates another embodiment of preserving double copies of critical data at the same time by the use of fault-tolerant code. 46A illustrates the threshold voltage distribution of a four-state memory array and is shown as a reference for FIG. 48B. The fault-tolerant code essentially avoids any higher page programming to transit through any intermediate states. Thus, the first pass lower page programming has a logical state (1, 1) that transfers to (0,1) as indicated by programming the erase memory state ("U" to "Y"). In a second pass programming of the upper page bit ("0"), if the lower page bit is "1", the logic state (1,1) is the erase memory from "Y" to "Z". Send as (0, 1), as represented by programming state. Since the upper page programming only involves programming to the next neighboring memory state, program abort does not change the lower page bits.

Serial Write

Double copies of the critical data are preferably written together as described above. Another way to avoid causing errors in both copies is to record the copies sequentially. This method is slow, but the copies themselves indicate when their programming is successful or when the controller checks both copies.

47 is a table showing the possible states of two copies of data and the validity of the data.

If both the first and second copies are free of ECC errors, the programming of the data is believed to be completely successful. Valid data can be obtained from any copy.

If the first copy has no ECC error, but the second copy has an error, it may mean that programming was interrupted during the second copy program. The first copy contains valid data. The second copy is not reliable even if the error is correctable.

If the first copy has no ECC error and the second copy is empty (if deleted), it may mean that the programming was aborted after the end of the first copy programming and before the start of the second copy. The first copy contains valid data.

If the first copy has an ECC error and the second is empty (if deleted), it may mean that programming was interrupted during the programming of the first copy. The first copy may contain invalid data even if the error is correctable.

For reading of the data maintained in the replicas, the following technique using the presence of duplicate copies is preferred. Read and compare both copies. In this case, the status of both copies as indicated in FIG. 47 can be used to ensure that there are no erroneously detected errors.

In view of speed and simplicity, in another embodiment where the controller reads only one copy, it is desirable to alternate copy reading between the two copies. For example, when the controller reads control data, it reads copy 1, and the next controller read (which one controller read) must be from copy 2 and then from copy 1, then read copy 1 again. In this way, both copies will be read and reviewed in an orderly manner (ECC reviewed). This reduces the risk of failing to detect errors in time caused by lowering data retention. For example, if only copy 1 is normally read, copy 2 may gradually degrade to the level where the error is no longer salvaged by the ECC, and the second copy may no longer be used.

Pre-emptive data relocation

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

It has also been described that there is a hierarchy of control data, with those in the lower layers being updated more frequently than those in the upper ones. For example, if every control block has N control sectors for writing, then the next sequence of control update and control block relocation occurs normally. Referring again to FIG. 20, every N CBI update fills the CBI block and causes CBI relocation (rewrite) and MAP update. Closure of the chaotic block also triggers GAT renewal. Every GAT update causes a MAP update. Every N GAT update occupies a block and causes a GAT block relocation. Also, when the MAP block becomes full it causes a MAP block relocation and an update of the MAPA block (if present, otherwise the BOOT block points directly to the MAP). Also, when the MAPA block becomes full, it causes MAPA block relocation, BOOT block update, and MAP update. Also, when a BOOT block becomes full, it causes an active BOOT block relocation to another BOOT block.

Since the layer is formed by BOOT control data on top with MAPA, MAP and GAT, there will be a "dependent control update" in every N ³ GAT update, and all GAT, MAP, MAPA and BOOT blocks will be relocated. If a GAT update is caused by a cyclic or sequential update block closure as a result of a host write, there will also be garbage collection operations (ie, relocation or rewrite). In the case of Kiatic Update Block Garbage Collection, the CBI will be updated and may also cause CBI block relocation. Therefore, in this extreme situation, multiple metablocks need to be garbage collected at the same time.

Each control data block of the layer has its own periodicity in that it is filled and rearranged. If each proceeds normally, there will be time where the phases of multiple blocks line up and cause massive relocation or garbage collection that includes all blocks at the same time. Relocation of many control blocks is time consuming and some hosts do not tolerate the long delays caused by such large control operations and should be avoided.

According to another aspect of the present invention, in a nonvolatile memory with a block management system, a situation in which "control garbage collection" or preferential relocation of a memory block requires that multiple update blocks all need to be revacated at the same time. It is implemented to avoid. For example, this situation can occur when updating control data used to control the operation of the block management system. The hierarchy of control data can exist as varying the degree of update frequencies, resulting in different proportions of the relevant update blocks requiring garbage collection or relocation. There will be a certain number of times garbage collection operations of one or more control data types are met. In an abnormal situation, the relocation phase of update blocks for all control data types may be aligned, resulting in all update blocks requiring relocation at the same time.

This unnecessary situation is avoided by the present invention, whenever a current memory operation accommodates spontaneous garbage collection operations, preferential relocation of update blocks occurs and the blocks are completely filled in advance. In particular, the highest data type in the hierarchy is given priority to the block with the slowest rate. In this way, if the slowest proportion of blocks are rearranged, they do not require another garbage collection for a relatively long time. Also, slower proportions of blocks that are higher in the hierarchy do not have much relocation cascade to trigger. The method of the invention can be thought of as introducing some sort of dithering into the overall mixture to avoid the alignment steps of the various suspected blocks. Thus, whenever an opportunity arises, the slow-filling block with some margin from the full fill is preferentially relocated.

In a system with a layer of control data, the lower one in the layer changes faster than the higher one due to the cascading effect, so that a higher block of control data in the layer is given priority. One example of an opportunity to implement spontaneous preferential relocation is that the remainder of its latent period can be utilized for preferential relocation operations when host write does not trigger self relocation. In general, the margin of a block that must be wholly relocated is a certain number of written memory units before the block is completely filled. Consider whether there is enough margin to facilitate the relocation of blocks that are fully prefilled but overly immature, causing useless resources. In a preferred embodiment, the predetermined number of unused memory units is one to six memory units.

48 shows a flowchart of preferential relocation of memory blocks storing control data.

Step 1202: Configuring nonvolatile memory in blocks that are divided into erasable memory units together.

Step 1204: Maintaining different types of data.

Step 1206: Rank the different types of data.

Step 1208: storing updates of different types of data between the plurality of blocks such that each block necessarily stores the same type of data.

Step 1210: Responsive to a block having fewer than a predetermined number of empty memory units and having the highest rank data type among the plurality of blocks, relocating the current data update of the block to another block. Proceed to Step 1208 unless interrupted.

An example algorithm for implementing preferential relocation for the control data shown in FIG. 20 is as follows:

If (if there is no garbage collection due to user data) OR (if MAP has 6 or fewer unused sectors) OR (if GAT has 3 or fewer unused sectors)

Then

If (if BOOT has an unused sector of 1)

Then relocate the BOOT (that is, relocate it to a block)

Else

If (if MAPA has an unused sector of 1)

Then relocate MAPA and update MAP

Else

If (if MAP has an unused sector of 1)

Then relocate the map

Else

If (most recently updated, or largest, if GAT has an unused sector of 1)

Then relocate the GAT

Else

If (if CBI has an unused sector of 1)

Then relocate CBI

Else

Else

Exit

Thus, preferential relocation is typically performed when no user data garbage collection occurs. In the worst case, every host write triggers user data garbage collection, but when there is sufficient time for spontaneous relocation of one block, preferential relocation can be performed on one control block at the same time.

When user data garbage collection operations and control updates coincide with physical errors, preferential relocation early, i.e., when the block still has two or more unused memory units (e.g., sectors). Or it is better to do controlled garbage collection to have a larger safe margin.

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

Claims (23)

In a nonvolatile memory organized in blocks, each block is partitioned into erasable memory units, wherein each memory unit stores a logical unit of data, wherein the method of storing and updating data includes: Organizing the memory into page series, each page having all memory units serviced in parallel by a set of sensing circuits therein; Organizing data into a plurality of logical groups, each logical group being partitioned into a plurality of data logical units; Storing, by page, a first version of the logical units of the logical group in the first block such that each logical unit can be stored in the memory unit of the page according to a given offset; Storing, by page, the next version of the logical units of the logical group in a second block according to a second order different from the first order, each next version having an offset in the same page as that of the first version; Stored in an available memory unit, wherein all versions of the logic unit are accessible by the same group of sensing circuits. The method of claim 1, wherein the current versions of the logical units are copied in accordance with the first order to store the next unused memory units that precede the next available memory unit in each page, the next versions of the logical units. And at the same time, further comprising padding. The method of claim 1, further comprising: constructing a memory from a plurality of memory planes, the plane consisting of a series of pages, each page having all memory units serviced therein in parallel by a set of sensing circuits; Organizing the memory into a series of metapages, wherein each metapage is constructed from memory pages from each plane such that all memory units in one metapage can be serviced in parallel by sensing circuits. How to. 4. The method of claim 3, wherein copying current versions of logical units in accordance with the first order to store the next unused memory units preceding each next available memory unit in each page, the next versions of logical units. And at the same time, further comprising padding. The method of claim 1, wherein each logical unit is a sector of host data. The method of claim 1, wherein each page stores one data logical unit. The method of claim 1, wherein each page stores more than one or more data logic units. The method of claim 1, wherein the nonvolatile memory has floating memory cells. The method of claim 1, wherein the nonvolatile memory is a flash EEPROM. The method of claim 1, wherein the nonvolatile memory is an NROM. The method of claim 1, wherein the nonvolatile memory is provided in a memory card. The method of claim 1, wherein the nonvolatile memory includes memory cells that each store one bit of data. The method of claim 1, wherein the nonvolatile memory includes memory cells that each store more than one bit of data. Non-volatile memory, A memory composed of a plurality of blocks, each block being a plurality of memory units that can be erased from each other, each memory unit storing a logical unit of data, wherein each block of the plurality of meta pages Stores a logical group, each meta page constructed from memory pages of each plane; A controller for controlling the operation of the blocks; The controller stores a first version of a logic unit of data among the memory units of the first block in a first order, wherein each first version logic unit is stored within one of the memory planes; The controller stores the next versions of the logic units into a second block in a second order that is different from the first order, wherein each next version is stored in a next memory unit available within the same plane as the first version. Thus, all versions of the logic unit are accessible from the same plane. The controller of claim 14, further comprising: a controller for storing, by metapage, certain unused memory units preceding the next available memory unit with current versions of the logical units in a first order, while storing the next versions of the logical units. Further comprising the next usable memory unit having an offset in the same meta page as that of the first version. 15. The memory of claim 14 wherein the nonvolatile memory has floating gate memory cells. 15. The memory of claim 14 wherein the nonvolatile memory is a flash EEPROM. 15. The memory of claim 14 wherein the nonvolatile memory is an NROM. 15. The memory of claim 14 wherein the nonvolatile memory is provided in a memory card. 20. The memory of any one of claims 14 to 19, wherein the nonvolatile memory includes memory cells that each store one bit of data. 20. The memory of any one of claims 14 to 19, wherein the nonvolatile memory includes memory cells that each store more than one bit of data. Non-volatile memory, A memory composed of a plurality of blocks, each block being a plurality of memory units that can be erased from each other, each memory unit storing a logical unit of data, wherein each block of the plurality of meta pages Stores a logical group, each meta page constructed from memory pages of each plane; Means for storing a first version of the logic units of data among the memory units of the first block in a first order, the first version logic unit being stored inside one of the memory planes; Means for storing next versions of logical units in a second block in a second order that is different from the first order, wherein each next version is stored in a next memory unit usable in the same plane as the first version, and Non-volatile memory, characterized in that all versions of the unit are accessible from the same plane. 23. The apparatus of claim 22, further comprising means for padding, by meta page, certain unused memory units prior to the next available memory unit having current versions of logical units in a first order. And the unit has an offset in the same meta page as that of the first version.

Images