Storage Class Memory

Abstract

A memory system and method for storing data in one or more memory chips are disclosed, including: one or more memory cards, each memory card having multiple memory chips, and each chip having multiple tube cores, and the tube core has multiple storage cells; a memory controller, including a conversion module, the conversion module also includes: a logical to virtual translation table (LVT) with multiple entries, each entry in the LVT is configured to map a logical address to a virtual block address (VBA), wherein the VBA corresponds to a group of storage cells on the one or more memory cards, wherein each entry in the LVT also includes a write wear level count for tracking the number of write operations to the VBA, and a read wear level count for tracking the number of read operations for the VBA mapped to the LVT entry.

Description

Technical Field

[0001] The present disclosure herein generally relates to logical-to-virtual and virtual-to-physical memory translation for storage class memory (SCM). Background Art

[0002] Storage class memory (SCM) is a type of persistent memory that combines the low latency and byte addressability of dynamic read access memory (DRAM) with the non-volatility, areal density, and economical characteristics of traditional storage media. In addition, given the byte addressability and low latency of SCM technology, a central processing unit (CPU) can access data stored in SCM without buffering that data in DRAM. Thus, SCM technology blurs the distinction between computer memory and traditional storage media and enables a single-level architecture without DRAM. Unlike traditional main memory and disk storage configurations, SCM provides a single-level architecture.

[0003] Typically, SCM is implemented as a solid-state device group connected to a computing system via several input / output (I / O) adapters, which are used to map the technology of the I / O devices to the memory bus of (one or more) central processing units. However, writing data to SCM requires attention to details in SCM technology: SCM media cards are organized as a collection of packages, each package including "N" dies with millions of byte-addressable memory elements. A common feature of SCM is that these memory devices have limited write durability. A memory device with limited write durability means that it cannot be written indefinitely before part of the SCM begins to fail. Identifying which memory is bad or prone to error helps reduce the risk of losing stored data. For example, memory bytes (or bit arrays) identified as bad can be completely avoided, and memory bytes that are not identified as bad can be used without restriction. In addition, the bad memory bytes in the embodiment can be replaced with spare bytes. Summary of the invention

[0004] An overview of the disclosure is given to aid in understanding computer systems, computer architectures, processors, storage class memory (SCM), and media management methods, and is not intended to limit the disclosure or the present invention. The disclosure is directed to one of ordinary skill in the art. It should be understood that the various aspects and features of the disclosure may be advantageously used alone in some instances, or in combination with other aspects and features of the present invention in other instances. Therefore, computer systems, architectures, processors, SCM, and their methods of operation may be varied and modified to achieve different effects.

[0005] A memory system for storing data in one or more memory chips is disclosed, wherein in one embodiment, the memory system includes: one or more memory cards, each card having multiple memory chips, and each chip having multiple dies, the multiple dies having multiple memory cells; a memory controller, the memory controller including a conversion module, the conversion module also including: a logical-to-virtual translation table (LVT) having multiple entries, each entry in the LVT being configured to map a logical address to a virtual block address (VBA), wherein the VBA corresponds to a group of memory cells (e.g., a logical block address (LBA)) on the one or more memory cards, wherein each entry in the LVT also includes a write wear level count for tracking the number of write operations on the VBA mapped to the LVT entry and a read wear level count for tracking the number of read operations on the VBA mapped to the LVT entry. In one or more embodiments, the write wear level count in the LVT is programmable to have a write level threshold corresponding to a maximum number of write operations to the VBA, and in response to a write operation exceeding (or equal to) the write level threshold in the LVT entry, data in the memory card corresponding to the LVT entry that exceeds (or equal to) the write level threshold is moved to a new location on the memory card having a different VBA.

[0006] In an embodiment, the memory system includes a VBA free list that identifies VBAs to which data can be written, and in response to a write operation, a new VBA is obtained from the VBA free list. . In one or more embodiments, the system is configured to be configured to obtain a new VBA from the VBA free list based on the wear level count. In one aspect, the read wear level count in the LVT is programmable to have a read level threshold corresponding to a maximum number of read operations of the VBA, and in response to a read operation exceeding the read level threshold in an LVT entry, the data in the memory card corresponding to the LVT entry exceeding (or equal to) the read level threshold is written to a new location on the memory card with a different VBA. In response to a read operation exceeding (or equal to) the read level threshold for an LVT entry, the system is configured to obtain a new VBA from the VBA free list, and write the data in the memory card corresponding to the LVT entry exceeding (or equal to) the read level threshold to a new location on the memory card with a different VBA.

[0007] In one or more embodiments, the memory system includes: a drift buffer having a plurality of entries for temporarily storing data; and a drift table having a plurality of entries, each drift table entry being configured to index into one of the plurality of entries in the drift buffer, each entry of the drift table mapping a drift buffer index to a VBA, wherein the system is configured to, in response to writing data to the memory card, also write the data to an entry in the drift buffer and further write the VBA and a corresponding logical address (e.g., a logical block address (LBA)) to an entry in the drift table indexed into the corresponding entry in the drift buffer. The memory system in an embodiment is configured to read from the drift buffer if data corresponding to the VBA is present in the drift buffer. In one aspect, the drift buffer is a circular FIFO buffer included on the memory card. Each LVT entry includes a field for indicating whether the drift buffer contains data corresponding to the LVT entry, wherein the system is configured in response to a hit on an LVT entry, wherein the LVT field indicates that data is in the drift buffer, and the LVT entry points to an entry in the drift table. In one embodiment each LVT entry has a drift buffer index valid field that indicates whether the drift buffer contains data corresponding to each corresponding LVT entry, and wherein the system is configured such that in response to a request to read data from the memory card, the system is configured to look up the logical address in the LVT and in response to finding the LVT entry corresponding to the logical address, the system checks the drift buffer index valid field, and in response to the drift buffer index valid field indicating that the requested data is not in the drift buffer, the system uses the VBA from the LVT entry, and in response to the drift buffer index valid field indicating that the requested data is in the drift buffer, the system reads the requested data from the drift buffer. In one aspect, the system is configured such that in response to the drift buffer valid field indicating that the requested data is in the drift buffer, the LVT points to an entry in the drift table, and the system uses the information in the drift table to obtain the requested data from the corresponding entry in the drift buffer. According to an embodiment, the system is configured such that in response to data being removed from a drift buffer entry, an LVT entry corresponding to the drift buffer entry from which the data was removed is updated such that the LVT entry contains the VBA of the entry removed from the drift buffer.

[0008] A method for reading data from one or more memory cards according to one or more embodiments is disclosed, wherein each memory card has a plurality of memory chips, and each memory chip has a plurality of dies, and the dies have a plurality of memory cells. In one aspect, the method includes: issuing a request for data located on the one or more memory cards; looking up a logical address of the requested data in a logical-to-virtual translation table (LVT) having a plurality of entries, each entry in the LVT mapping the logical address to a virtual block address (VBA), wherein the VBA corresponds to a set of memory cells in the one or more memory cards; in response to the logical address (e.g., logical block address (LBA)) of the requested data being located in an entry in the LVT, checking the LVT entry to determine whether the data is located in a drift buffer; in response to determining that the data is located in the drift buffer, reading the requested data from the drift buffer; and in response to determining that the data is not located in the drift buffer, obtaining a VBA corresponding to the logical address (e.g., logical block address (LBA)) of the requested data from the LVT entry, and reading the requested data in the memory card corresponding to the VBA.

[0009] In one embodiment, the method further includes: updating a read level count field in the LVT in response to reading the requested data from the memory card. The method according to one aspect further includes comparing the read level count in the LVT entry with a read level threshold field in the LVT entry, and in response to the read level count being equal to or exceeding the read level threshold, writing the data to be read to a new location on one or more memory cards having a different VBA. In one embodiment, the method includes: updating the LVT with the different VBA in response to writing the data to be read to a new location on one or more memory cards having a different VBA. In one aspect, the method further includes updating the VBA in the corresponding LVT entry in response to removing data from a drift buffer. The method according to another aspect includes moving an entry to the head of a drift buffer in response to reading data from a drift buffer.

[0010] A method for writing data to one or more memory cards is disclosed, wherein each memory card has multiple memory chips, and each memory chip has multiple tube cores, and the tube cores have multiple storage units. In one or more embodiments, the method includes: issuing a request to write data to the one or more memory cards; obtaining an available VBA from a VBA free list; writing data to a memory card location corresponding to the available VBA obtained from the VBA free list; writing the data to an entry in a drift buffer; and writing the VBA of the available VBA and the logical address corresponding to the available VBA to an entry in a drift table corresponding to the entry in the drift buffer. In one aspect, the method further includes writing the corresponding LVT entry with the available VBA. In an embodiment, the method also includes: writing a drift table index to an LVT entry corresponding to the VBA corresponding to the location on the memory card where the data is written, the drift table index identifying the drift table entry corresponding to the drift buffer entry of the data to be written, and setting a bit to identify that the data is in the drift buffer.

[0011] The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of exemplary embodiments of the invention, as illustrated in the accompanying drawings, wherein like reference numerals generally represent like parts of illustrative embodiments of the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] When read in conjunction with the provided drawings, the various aspects, features, and embodiments of computer systems, computer architectural structures, processors, memory systems, and methods of operation thereof will be better understood. For the purpose of illustrating various embodiments of aspects, features, and / or computer systems, computer architectural structures, processors, SCMs, and methods of operation thereof, the claims should not be limited to the precise arrangements, structures, features, aspects, components, subcomponents, systems, circuits, embodiments, methods, processes, techniques, circuits, embodiments, and devices shown, and the arrangements, structures, systems, components, subcomponents, features, aspects, methods, processes, techniques, circuits, embodiments, and devices shown may be used alone or in combination with other arrangements, structures, components, subcomponents, systems, features, aspects, circuits, embodiments, methods, techniques, processes, and / or devices.

[0013] Figure 1 is a functional block diagram illustrating a computer system according to an embodiment of the present disclosure.

[0014] Figure 2A is a functional block diagram illustrating an example memory system and controller according to an embodiment of the present disclosure.

[0015] Figure 2B Depicted Figure 2A An example structure of a memory system of FIG.

[0016] Figure 3 A block diagram of an embodiment of hardware and processes for translating logical addresses to physical addresses in a memory system is presented.

[0017] Figure 4 is a flow chart of an embodiment of a method for performing a host read including a memory system (such as, for example, Figure 2A and 2B Conversion of logical addresses in a memory system).

[0018] Figure 5 is a flow chart of an embodiment of a method for performing a host write including a memory system (such as, for example, Figure 2A and 2B Conversion of logical addresses in a memory system).

[0019] Fig. 6A is used to translate virtual addresses into memory systems (e.g. Figure 2A and 2B A block diagram of a top view of an embodiment of a method and hardware for physical addresses in a memory system).

[0020] Figure 6B is used to convert the virtual block address into Figure 2A and 2B A flow chart of an example method of determining a physical address of a memory system.

[0021] Figure 6C shows the method for converting a virtual block address into Figure 2A and 2B An example translation table for physical addresses of a memory system.

[0022] Figure 7 It is shown that Figure 2A and 2B A flowchart of an example method of a cleaning process of a memory system;

[0023] Figure 8 It is shown for Figure 2A and 2B A flowchart of an example method of a memory repair action for a memory system.

[0024] Fig. 9A , Fig. 9B and Fig. 9C Shown for Figure 2A and Figure 2B Example scenarios of different types of memory repair actions for a memory system. DETAILED DESCRIPTION

[0025] The following description is made to demonstrate the general principles of the present invention and is not intended to limit the inventive concepts claimed herein. In the following detailed description, many details are set forth in order to provide an understanding of computer systems, computer architecture structures, processors, caches, memory systems and methods of operation thereof, however, those skilled in the art will understand that different and numerous embodiments of computer systems, computer architecture structures, processors, caches, memory systems and methods of operation thereof may be practiced without those specific details, and the claims and disclosures should not be limited to the arrangements, structures, systems, components, subcomponents, circuits, features, aspects, processes, methods, techniques, embodiments and / or details specifically described and shown herein. Further, in each of the various possible combinations and permutations, the specific features, aspects, arrangements, systems, embodiments, techniques, etc. described herein may be used in combination with other described features, aspects, arrangements, systems, embodiments, techniques, etc.

[0026] Unless expressly defined otherwise herein, all terms are to be given their broadest possible interpretation, including the meaning implied from the specification together with the meaning as understood by those skilled in the art and / or as defined in dictionaries, treatises, etc. It must also be noted that, as used in the specification and the appended claims, the singular forms "a", "an", and "the" include plural referents unless otherwise indicated, and that the terms "include" and / or "comprises" when used in the specification and claims specify the presence of stated features, integers, aspects, arrangements, embodiments, structures, systems, components, subcomponents, steps, operations, elements and / or parts but do not preclude the presence or addition of one or more other features, integers, aspects, arrangements, embodiments, structures, systems, components, subcomponents, steps, operations, elements, parts and / or combinations thereof.

[0027] The following discussion omits or only briefly describes conventional features of information processing systems, including processors and microprocessor systems and architectures, and address translation techniques and systems, which should be apparent to those skilled in the art. It is assumed that those skilled in the art are familiar with the general architecture of processors, and in particular, with address translation techniques and systems and their operation. It should be noted that elements are numbered according to the diagram in which the element is introduced, and that the numbered element is generally referred to by that number in subsequent diagrams.

[0028] Figure 1 A high-level block diagram representation of a computer 100-A connected to another computer 100-B via a network 130 is depicted according to one embodiment of the present invention. The term "computer" is used herein for convenience only, and in different embodiments is a more general data processing system, such as a mobile phone, tablet computer, server computer, etc. The mechanisms and apparatus of embodiments of the present invention are equally applicable to any suitable data processing system.

[0029] The main components of the computer 100 may include one or more processors 101, a main memory system 102, a terminal interface 111, a storage interface 112, an I / O (input / output) device interface 113, and a network adapter or interface 114, all of which are directly or indirectly communicatively coupled for inter-component communication via a memory bus 103, an I / O bus 104, and an I / O bus interface unit 105. This computer 100 includes one or more general-purpose programmable central processing units (CPUs) 101A, 101B, 101C, and 101D, collectively referred to herein as processors 101. In an embodiment, the computer 100 includes multiple processors typical of relatively large systems; however, in another embodiment, the computer 100 may instead be a single CPU system. Each processor 101 executes instructions stored in the main memory system 102 and may include one or more levels of on-board cache.

[0030] In an embodiment, the main memory system 102 may include random access semiconductor memory (e.g., DRAM, SCM, or both), storage devices, or storage media for storing or encoding data and programs. In another embodiment, the main memory system 102 represents the entire virtual memory of the computer 100, and may also include virtual memory of other computer systems coupled to the computer 100 or connected via the network 130. The main memory system 102 is conceptually a single monolithic entity, but in other embodiments, the main memory system 102 is a more complex arrangement, such as a hierarchy of caches and other memory devices. For example, memory may exist in multiple levels of caches, and these caches may be further divided by function, so that one cache holds instructions and another cache holds non-instruction data, which is used by one or more processors. The memory may be further distributed and associated with different CPUs or sets of CPUs, as known in any of a variety of so-called non-uniform memory access (NUMA) computer architectures.

[0031] The main memory system 102 stores or encodes an operating system (OS) 150, an application 160, and / or other program instructions. Although the operating system (OS) 150, the application 160, etc. are shown as being included in the main memory system 102 in the computer 100, in other embodiments, some or all of them may be located on different computer systems and may be remotely accessed, for example, via the network 130. The computer 100 may use a virtual addressing mechanism that allows the programs of the computer 100 to behave as if they only have access to a large single storage entity rather than to multiple smaller storage entities. Therefore, although the operating system 150, the application 160, or other program instructions are illustrated as being included in the main memory system 102, these elements do not have to be all completely included in the same storage device at the same time. In addition, although the operating system 150, the application 160, other program instructions, etc. are illustrated as separate entities, in other embodiments, some of them, some of them, or all of them may be packaged together.

[0032] In an embodiment, the operating system 150, the application 160, and / or other program instructions include instructions or statements executed on the processor 101, or instructions or statements interpreted by instructions or statements executed on the processor 101, so as to perform functions as further described below. When such program instructions can be run by the processor 101, such a computer 100 becomes a specific machine configured to execute such instructions. For example, instructions for a memory mirroring application 160A can be loaded on one or more computers 100A, which causes the computer 100A to mirror the main memory system 102 into a first portion and a redundant second portion. In another example, the main memory system 102 can be mirrored by the operating system 150. In another example, the main memory system 102 can be mirrored by a virtualizer application 170 (such as a hypervisor).

[0033] One or more processors 101 may act as a general-purpose programmable graphics processor unit (GPU) that constructs an image (e.g., a GUI) for output to a display. The GPU works in conjunction with one or more applications 160 to determine how to manipulate pixels on, for example, a display, a touch screen, etc. to create a display image or user interface. Ultimately, the image (e.g., a GUI, etc.) is displayed to the user. The processor 101 and the GPU may be discrete components or may be integrated into a single component.

[0034] The memory bus 103 provides a data communication path for transferring data between the processor 101, the main memory system 102, and the I / O bus interface unit 105. The I / O bus interface unit 105 is further coupled to the system I / O bus 104 for transferring data to and from different I / O units. The I / O bus interface unit 105 communicates with multiple I / O interface units 111, 112, 113, and 114, also referred to as I / O processors (IOPs) or I / O adapters (IOAs), via the system I / O bus 104. The I / O interface units support communication with various storage devices and I / O devices. For example, the terminal interface unit 111 supports the attachment of one or more user I / O devices 121, which may include user output devices (such as video display devices, speakers, and / or televisions) and user input devices (such as keyboards, mice, keypads, touch pads, trackballs, buttons, light pens, or other pointing devices). The user can manipulate the user input device using the user interface to provide input data and commands to the user I / O device 121 and the computer 100, and can receive output data via the user output device. For example, the user interface can be presented via the user I / O device 121, such as displayed on a display device, played via a speaker, or printed via a printer. The user interface can be a user interface that provides content to the user visually (e.g., via a screen), audibly (e.g., via a speaker), and / or via touch (e.g., vibration, etc.). In some embodiments, the computer 100 itself acts as a user interface because the user can move the computer 100 in a manner that interacts with the computer application 160, inputs or manipulates data, functions, etc.

[0035] The storage interface unit 112 supports the attachment of one or more local disk drives or auxiliary storage devices 125. In an embodiment, the auxiliary storage devices 125 are rotating disk drive storage devices, but in other embodiments they are arrays of disk drives configured to appear as a single large storage device to the host computer, or any other type of storage device. The contents of the main memory system 102, or any portion thereof, can be stored to and retrieved from the auxiliary storage devices 125 as needed. The local auxiliary storage devices 125 typically have a slower access time than the main memory system 102, meaning that the time required to read data from and / or write data to the main memory system 102 is less than the time required to read data from and / or write data to the local auxiliary storage devices 125.

[0036] The I / O device interface 113 provides an interface to any of various other input / output devices or other types of devices (such as a printer or fax machine). The network adapter 114 provides one or more communication paths from the computer 100 to other data processing devices (such as many other computers), which paths may include, for example, one or more networks 130. Although the memory bus 103 is shown in FIG. 2 as a relatively simple single bus structure that provides a direct communication path between the processor 101, the main memory system 102, and the I / O bus interface 105, in practice, the memory bus 103 may include a plurality of different buses or communication paths, which may be arranged in any of a variety of forms, such as point-to-point links in a hierarchical, star, or mesh configuration, multiple hierarchical buses, parallel and redundant paths, or any other suitable type of configuration. In addition, although the I / O bus interface 105 and the I / O bus 104 are shown as a single corresponding unit, the computer 100 may actually include multiple I / O bus interface units 105 and / or multiple I / O buses 104. Although multiple I / O interface units are shown that separate the system I / O bus 104 from the various communication paths running to the various I / O devices, in other embodiments some or all I / O devices are directly connected to one or more system I / O buses.

[0037] The I / O interface 113 may include electronic components and logic for adapting or converting data from one protocol on the I / O bus 104 to another protocol on another bus. Thus, the I / O interface 113 may connect a variety of devices to the computer 100 and to each other, such as but not limited to tape drives, optical drives, printers, disk controllers, other bus adapters, PCI adapters, workstations, using one or more protocols including but not limited to Token Ring, Gigabyte Ethernet, Ethernet, Fibre Channel, SSA, Fibre Channel Arbitrated Loop (FCAL), Serial SCSI, Ultra3 SCSI, InfiniBand, FDDI, ATM, 1394, ESCON, wireless repeaters, Twinax, LAN connections, WAN connections, high performance graphics, etc. Although shown as different entities, multiple I / O interface units 111, 112, 113, and 114, and the functions of the I / O interface units 111, 112, 113, and 114 may be integrated into similar devices.

[0038] In various embodiments, the computer 100 is a multi-user mainframe computer system, a single-user system, a server computer, a storage system, or a similar device having little or no direct user interface but receiving requests from other computer systems (clients). In other embodiments, the computer 100 is implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a phone, a smart phone, a pager, an automobile, a teleconferencing system, an appliance, or any other suitable type of electronic device.

[0039] The network 130 may be any suitable network or combination of networks, and may support any protocol suitable for transmitting data and / or code to / from the computer 100A and at least the computer 100B. In various embodiments, the network 130 may represent a data processing device or a combination of data processing devices directly or indirectly connected to the computer 100. In another embodiment, the network 130 may support wireless communication. Alternatively and / or additionally, the network 130 may support hardwired communication, such as a telephone line or cable. In an embodiment, the network 130 may be the Internet, and may support IP (Internet Protocol). In an embodiment, the network 130 is implemented as a local area network (LAN) or a wide area network (WAN). In an embodiment, the network 130 is implemented as a hotspot service provider network. In another embodiment, the network 130 is implemented on an intranet. In an embodiment, the network 130 is implemented as any appropriate cellular data network, a cell-based radio network technology, or a wireless network. In an embodiment, the network 130 is implemented as any suitable network or a combination of networks. Although one network 130 is shown, in other embodiments, any number of networks (of the same or different types) may exist.

[0040] Figure 1 The diagram is intended to depict representative major components of computer 100. However, individual components may have different Figure 1 The greater complexity represented in , can exist different from Figure 1 100, and the number, type, and configuration of such components may vary. Several specific examples of such additional complexity or additional variations are disclosed herein; these are examples only and are not necessarily the only such variations. For example, different program instructions implemented on computer system 100 according to various embodiments of the present invention may be implemented in a variety of ways, including using different computer applications, routines, components, programs, objects, modules, data structures, etc.

[0041] See now Figure 2A , shows a schematic block diagram of an example main memory system 102 communicating with a processor 101 via a memory controller 200. Figure 2AAs shown, the memory module or card 102 (e.g., an SCM media card) is configured to store data in a plurality of "K" packages (i.e., chips) 252a-k (e.g., K=24), and each package includes a plurality of "N" dies 251a-n (e.g., N=16). Each package in an embodiment may include the same number of "N" dies (e.g., N=8, 16, etc.). Each die in the dies 251a-n includes a plurality of "M" memory cells, specifically, memory cells 250a-m. The plurality of memory cells 250 in each die may be grouped into a plurality of "X" media replacement unit (MRU) groups 253a-p, and in an embodiment, each die may include a fixed number of MRU groups 253. For example, there may be 16 (X=16) MRU groups in the die 251. In one or more embodiments, the memory module / card 102 also includes a drift buffer 260 for storing data (e.g., temporarily storing data as will be described later). In an aspect, the memory module / card 102 also includes a drift table 230 for mapping entries to a drift buffer 260, as will be described later.

[0042] Furthermore, if Figure 2B As shown, each MRU group 253a-p may include a plurality of MRUs 254a-n, each MRU including a plurality of "B" bit arrays, and each bit in the bit array including a memory cell. Figure 2B As shown, the MRU group in the embodiment is divided into 128 columns, called bit arrays. The MRU group is divided horizontally into rows called MRUs. Each MRU has a 128-bit array. Figure 2B Each box in can be a bit array of one million bits. In addition, each MRU includes a "P" number of pages, where a page is a unit of data that can be written or read in the SCM (e.g., 16 bytes or 128 bits). In an embodiment, an MRU can contain 1M pages. A page uses bits from a valid bit array during read and write operations. The number of valid bit arrays from which each page takes a memory cell may depend on the required redundancy and / or cleaning process (described below) of the memory cells in the memory module / card 102. For example, in each MRU, if four bit arrays are reserved as spares for exchange operations with failed / error-prone bit arrays, during read-write operations, each page will include bits from 124 valid bit arrays in the 128-bit array (128-bit array in the MRU minus 4 reserved bit arrays = 124 valid bit arrays). This means that a page can store 15.5 bytes of actual data. As described below, spare MRUs from all MRU groups and dies in a single package can replace a failed MRU in that package.

[0043] It should be noted that using 1 million bits per array (1024*1024) is a design choice of the example embodiments disclosed in the present disclosure. However, the present disclosure is not limited thereto, and any number of bits per array may be used (e.g., 500,000, 2 million, 3 million, etc.). The number of bits per array is then used to determine the number of MRUs, and therefore the size of the table (e.g., chip select table (CST), media repair table (MRT), bit array repair table (BART), etc.).

[0044] The total capacity of the memory module / card 102 can be determined according to K*C (measured in bytes), where C is the capacity of each package. In the K packages of the memory module / card 102, some packages can be used to store data, and other or remaining packages can be used for error correction codes (ECC) and metadata for data management. Error correction codes are used to correct errors in the data stored in the data area. Each memory module / card 102 (e.g., SCM media card) has I / O data with a z-bit data width and an address bit of the appropriate size depending on the capacity. SCM can be, for example, a phase change memory (PCM), a resistive RAM (RRAM) or any suitable non-volatile memory.

[0045] Although Figure 2A The memory controller 200 is shown as being external to the memory module / card 102, but the present disclosure is not limited thereto and the controller 200 may be part of the memory module / card 102. Figure 2A As shown, the controller 200 may include at least one of the address translation module 202, the cleaning module 204 and the media repair module 206. The modules 202, 204 and 206 may be implemented in software, firmware, hardware or a combination of two or more of software, firmware and hardware. In other examples, the controller 200 may include additional modules or hardware units, or may include fewer modules or hardware units. The controller 200 may include a microprocessor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other digital logic circuits.

[0046] The address translation module 202 may associate a logical block address (LBA) and / or a virtual block address (VBA) used by the processor 101 with a physical block address (PBA) of the memory module / card 102 (as discussed below). For example, in response to the address translation module 202 receiving an LBA from the processor as part of a read or write command, the address translation module 202 may look up the VBA via a logical to virtual table (LVT) 210, and the address translation module 202 may then use the VBA to determine the PBA of the memory module / card 102 corresponding to the received LBA. In some examples, the address translation module 202 may use a hierarchical virtual to physical table structure (V2P) to perform the translation from the VBA to the PBA (as discussed below). For example, the address translation module 202 may include a chip select table (CST) 220, a media repair table (MRT) 222, and a bit array repair table (BART) 224.

[0047] Cleaning module 204 can be configured to detect and correct faults or errors in memory module / card 102. Errors in memory can be caused by alpha particles or other particles, or by physical defects in memory cells. As used herein, the term "scrubbing" generally refers to the process of detecting errors and correcting correctable errors in a memory system. Errors can include soft (or transient) errors and hard errors in some cases. In different embodiments, memory scrubbing can use the process of detecting and correcting bit errors in memory as described below. In order not to interfere with conventional memory requests from CPU and therefore prevent performance degradation, scrubbing (described below) can be completed by making a specific part of memory module / card 102 exit the service for the scrubbing process. Since scrubbing can include normal read and / or write operations, it can increase the power consumption of memory compared to non-scrubbing operations. Therefore, according to various embodiments, scrubbing is performed discontinuously but periodically. For many servers, the timing or cycle for scrubbing can be configured in the BIOS setup program.

[0048] In some embodiments, the scrubbing module 204 may include an error rate table (ERT) 240. The error rate table may be configured to store information related to memory defects or errors in the memory module / card 102. In some embodiments, an ERT may be assigned for each package included in the memory module / card 102 (e.g., 24 ERTs for 24 packages of a media card).

[0049] The media repair module 206 may be configured to repair errors or defects in the memory module / card 102 by analyzing the information stored in the ERT. For example, the media repair module 206 may create an ERT summary table and cause the memory controller to perform appropriate corrective actions, such as, but not limited to, replacing one or more failed portions of the memory module / card 102 with a properly functioning spare (e.g., replacing a failed bit array, MRU, MRU group, die, or package with a suitable spare); modifying various translation tables; searching for spare memory portions / locations; creating spare memory portions / locations; rebalancing spare memory portions / locations (to increase the likelihood of locating spares for future replacements). In an embodiment, the media repair module 206 may be configured to consider functional correctness while avoiding replacements that may negatively affect the performance of the memory module / card 102.

[0050] See now Figure 3 , a block diagram overview of an embodiment of hardware and process flow in a memory system for translating logical addresses into virtual addresses (logical to virtual (L2V) translation), where the virtual addresses can be translated into real or physical addresses on the media card 390 (virtual to physical (V2P) translation). The host addresses the memory / media card 390 by logical unit number (LUN) and logical unit number offset (LUN offset). The translation table 360 ​​translates these LUNs and LUN offsets into logical block addresses (LBAs). As Figure 3 As shown in the LBA table 360 ​​in , multiple LUNs are supported. In an embodiment, there is an LBA for each 4KB block that the host can access. The LBAs are fed into a logical to virtual translation table (LVT) 370, which converts or transforms each LBA into a virtual entry or address, such as a virtual block address or VBA. The VBA is fed into a media table 380, where the virtual address (e.g., VBA) is converted into a physical or real address on the media card 390, as explained in detail later in this disclosure. The virtual to physical conversion in one or more embodiments includes a chip select table (CST), a media repair table (MRT), and a bit array repair table (BART) for repairing the media.

[0051] In one or more embodiments, the LVT 370 is arranged in a table structure and has a plurality of entries 372. In an embodiment, each entry 372 in the LVT 370 includes a virtual block address (VBA) or drift table index, write wear level count data, and read wear level count data. For each LBA, there is a one-to-one mapping to the VBA (assuming the LBA is not trimmed). Other metadata may be included in the LVT. In an embodiment, the LVT 370 is stored in DRAM, and in one aspect, the field size of each entry is small, such as 8 bytes per entry. In an implementation, the LVT 370 is located in the memory controller 200, and in one aspect, the LVT 370 may be included in the memory controller 200. Figure 2A The address conversion module 202 ( Figure 2A Table 1 below illustrates an example of LVT entry 372.

[0052] Table 1: LVT entry fields

[0053]

[0054] The LVT entries in Table 1 are only one example, and other storage media, fields, and field sizes are contemplated for LVT 370 and LVT entries 372. The media on media card 390 will consume some locations over time, so in one or more embodiments, the design will be overloaded visually. There should be a small amount of over-provisioning to account for media exhaustion, and so according to one aspect, the number of LBAs will typically be slightly less than the number of VBAs, such as 10% less. So, for example, if media card 390 supports 614M VBAs, LVT 370 will have entries close to 614M. In an embodiment, the total size of the memory is indicated to the host as less than its actual size.

[0055] The media card 390 allows write operations to be performed to the same address / location, but because writes may interfere with adjacent areas on the media card 390, in an embodiment, new data is written to a different location on the media card 390. In one aspect, no location on the media card 390 is written to more than a threshold number (e.g., 10,000 times) more than any other location on the media card 390. For example, in an embodiment, a location (e.g., a block of memory cells) on the media card 390 is not written to "Y" times that another location on the media card is written to. The Write Wear Level field (bits 39:32 in Table 1) in the LVT 370 is used to control this aspect of the operation. Reads may also interfere with the media, so data should be rewritten to a new location / address after "N" reads of the location. The LVT 370 has a Read Wear Level count (bits 53:40 in Table 1) to track and record the number of reads that have occurred on a block since the last write to that block. In response to the read count exceeding a value (e.g., a threshold), the block will be moved and / or copied to a new location on the media card that will have a new VBA. For example, after 10,000 reads, the hardware will perform a wear level move where the data is copied / written to a new location on the media card with a corresponding new VBA.

[0056] After a new location on the media card is written, it should not be read for a period of time (typically milliseconds, such as 10 milliseconds). To overcome the potential waiting time for reading a new location on the media card, a drift buffer is provided in an embodiment. The drift buffer 260 in an embodiment is included in Figure 2AThe drift buffer is preferably a FIFO buffer that is used to keep a copy of newly written data so that the drift buffer can be read instead of the media card 390 during a time frame when the newly written media should not be read. The drift buffer has multiple entries, and in an embodiment has a table or index (e.g., a drift buffer index or drift table 330) to associate the VBA with the entries in the drift buffer. When data is newly written to the media (e.g., a memory card), the data is also written to the drift buffer entry, and the VBA is stored in the drift table entry 332 corresponding to the drift buffer entry. The drift table 330 stores the VBA and the corresponding LBA. For example, the drift table entry indexes the drift buffer entry and maps the VBA to the corresponding LBA. When data is written to the drift buffer, the VBA field in the LVT 370 points to the drift table entry 372 using the drift table index instead of the VBA. When processing a read operation, the table entry corresponding to the LBA in the LVT has a drift buffer index valid bit that is set to indicate that the data is in the drift buffer, and the system uses the drift table to identify the drift buffer table entry and reads the data from the corresponding drift buffer. In the case where the drift buffer index valid bit is set, in an embodiment, the LVT does not return a VBA. In an embodiment, the drift table 330 is smaller than the LVT 370 and can be a DRAM on the controller 200 and / or the media card 102 / 390. An example drift table entry 332 is shown in Table 2 below.

[0057] Table 2: Drift table entries

[0058]

[0059]

[0060] When data has aged out of drift buffer, the VBA field from drift table 330 is copied to the corresponding entry 372 in LVT 370. The table structure of drift table 330 and LVT 370 makes it easy to utilize drift buffer and also read cache. When used as read cache, drift buffer will be filled in both before writing and reading or reading. In addition, the time that frequently utilized data is retained in drift buffer can be extended by updating drift table 330, and the data being utilized will be retained in drift buffer. For example, the read hit data can be moved to the head of drift buffer. In this way, the time that frequently read data stays in drift buffer can be extended.

[0061] Figure 3A VBA free list 340 is also shown. The VBA free list 340 has a plurality of entries 342. VBAs that do not actively store data associated with an LBA are maintained on the VBA free list 340 and, in an embodiment, are organized or prioritized based on wear levels. When a write command requires an idle VBA to store data, an idle VBA is obtained from the VBA free list 340. If the write command is for an LBA that has been previously written, the previously used VBA (corresponding to the previously used LBA) is added to the VBA free list 340. The VBA free list 340 may be located on the controller 200 and / or the media card 102 / 390. Table 3 below shows the free list entries in the VBA free list 340, where the entries are indexed by VBA.

[0062] Table 3: VBA Free List Entries

[0063]

[0064] Reference now Figure 4 , discloses a flowchart showing an example method 400 for processing a host read command, including, for example, converting and / or transforming a logical address (e.g., LBA) into a virtual block address or VBA. The flowcharts and block diagrams in the accompanying drawings show exemplary architectures, functions, and operations of possible implementations of systems, methods, and computer program products according to different embodiments of the present invention. In this regard, each box in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which includes one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions indicated in the box may occur in an order different from the order indicated in the figure. For example, depending on the functions involved, two blocks shown in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, can be implemented with a dedicated hardware-based system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

[0065] At 405, a host read command is issued by the host. As described above, the host addresses the media card by a logical unit number (LUN) and a LUN offset. At 410, the LUN and LUN offset are converted into a logical block address or LBA. At 415, a logical to virtual address translation table or LVT entry corresponding to the LBA is read. That is, in an embodiment, the LVT is searched and a comparison is performed using the LBA converted from the LUN and LUN offset, and the entry corresponding to the LBA in the LVT is read. In one or more embodiments, it is determined at 420 whether the entry read from the LVT is trimmed. A trimmed entry in the LVT is a case where the entry is not available on the medium and / or should not be read. In the embodiment of Table 1, bit 54 indicates whether the entry 372 in the LVT is trimmed. If the entry read at 420 is trimmed (420: yes), zero is returned at 425, and a good completion is notified to the host at 430.

[0066] If at 420, the read LVT entry is not trimmed (420: No), the process 400 continues to 435, where it is determined whether the LBA is in the drift buffer (indexed in the drift table). Thus, for example, for an LVT entry such as in the example of Table 1, bit 31 (the drift buffer index valid bit) is read, and if bit 31 is set to 1, the LBA is in the drift buffer. If the LBA is in the drift buffer (435: Yes), then at 440, the entry in the drift table 330 with the corresponding LBA is read. The entry for the drift buffer is obtained from the drift table, and the corresponding drift buffer is read at 445. In the example of Table 1, if the LBA is in the drift buffer, bits 20:0 in the LVT are indexes into the drift table 330, and the corresponding entry in the drift table indicates what entry in the drift buffer is to be read. After reading the drift buffer at 445, the process continues to 450, where, in one or more embodiments, it is determined whether there are any read errors. If there is a read error ( 450 : YES), then the host is notified of the read failure at 460 . If there is no read error ( 450 : NO), then the host is notified of a good completion, such as a good read completion, at 455 .

[0067] If it is determined at 435 that the LBA is not in the drift buffer (435: No), then the LVT read level count is updated at 470. In the example LVT entry of Table 1, if the drift buffer index valid bit 31 is set to 0, then bits 29:0 in the LVT refer to the VBA that selects a 5120-byte block on the storage class memory (SCM). In this example, the LBA is not in the drift buffer, so the process 400 continues at 475, where it is checked whether the read level count of the entry (media address) exceeds a particular threshold. For example, it can be determined whether the read count level exceeds a threshold, such as 10,000 reads. The threshold level can be set at different values, the different values ​​can be pre-programmed, or can be changed during operation based on many factors. If the read level does exceed the read level count (475: Yes), then a loss level move operation is scheduled at 480, in which the data is moved to a new location, as discussed, for example, in the present disclosure. After the loss level move at 480, process 400 continues at 485 where the VBA and metadata are read from the LVT. On the other hand, if it is determined at 475 that the read count threshold has not been exceeded (475: No), the process continues to 485 where the VBA and metadata are read from the LVT. Figure 4 As shown, processing continues after 485 where it is determined at 450 whether there are any read errors, and depending on whether there are any errors, the host is notified of a good completion at 455 or the host is notified of a read failure at 460.

[0068] See now Figure 5 , discloses a flow chart showing an example method 500 for processing a host write command, including, for example, converting and / or transforming a logical address (e.g., LBA) into a virtual block address or VBA. At 505, a host write command ready indication is issued by the host. The address of the write command is issued as a LUN and a LUN offset. At 510, the LUN and the LUN offset are converted into a logical block address or LBA. At 512, in one or more embodiments, it is determined whether the host write data is all zeros. If the host write data is all zeros (512: yes), the process jumps to step 540 and does not perform writing data to the medium (or drift buffer). If the host write data is not all zeros (512: no), the process continues to 515, where a request is made for a VBA free list of available entries. In one or more embodiments, the request is for a VBA with a lowest wear level, and / or the VBA free list is configured to provide a VBA with a lowest wear level.

[0069] At 520, the data is written to a memory (e.g., a media card). In addition, at 525, the data is also written to a drift buffer, and at 530, a new drift table entry is written. That is, at 525 and 530, the data is written to the entry in the drift buffer, and the corresponding entry in the drift table to which the entry in the drift buffer is indexed is written with the VBA, LBA, and optionally with the metadata or other data shown in Table 2. In one aspect, the CRC and other metadata are provided with the request from the host. At 535, it is determined whether the write is complete. The process remains at 535 until the write is complete (535: Yes).

[0070] When the writing of the media, drift buffer, and drift table is complete, process 500 continues to 540, where the old LVT entry is read. At 540, the LVT corresponding to the LBA is read. In one or more embodiments, the old LVT entry is replaced with the new LVT entry. At 545, it is determined whether the old LVT entry is trimmed. If the LVT entry is trimmed, it indicates that the media should not be read or is unusable. In one or more embodiments, when the LBA has never been written or was last written with zeroed data, the entry in the LVT is marked as trimmed. If the old LVT entry is marked as trimmed (545: yes), the process continues to 565, where the new LVT is written. If at 545, the old LVT is not trimmed (545: no), the process continues to 550, where it is determined whether the LBA corresponding to the VBA being written is in the drift buffer. If the LBA at 550 is determined to be in the drift buffer (550: yes), the old drift table entry is read at 555 to obtain the VBA. Note that the entry in the drift table obtained at 555 is a different entry then the entry in the drift table that is written at 530 because the write process overwrites the old entry in the drift table and the read entry is not updated. Continuing, at 560, the VBA is returned to the VBA free list with the wear level indicated. If it is determined at 550 that the LBA is not in the drift buffer (550: No), in an embodiment proceed directly to 560, where the VBA is returned to the free list with its indicated wear level data so that the available VBA can be prioritized in the VBA free list. After 560, the process proceeds to 565, where the new LVT is written.

[0071] In an embodiment, after 560, the process proceeds to 565, where a new LVT is written. The contents of the written LVT will depend on previous processing. If the new LVT entry is to be marked as trimmed due to the host write data being all zeros (512: yes), the new LVT entry will contain a trimmed indicator, an invalid VBA, and a drift buffer index valid field that is cleared (set to zero). If the new LVT entry is not to be marked as trimmed because the host write data is not all zeros (512: no), the new LVT entry will contain a drift buffer index valid field set to indicate that the drift buffer index is valid together with the valid drift buffer index. When a new LVT entry is written, the read count field in the LVT entry is always cleared (set to zero). In one or more aspects, other metadata including wear level data is written to the LVT entry at 565. In one aspect, the write wear level comes from the VBA free list 340. After 565, processing continues to 570, where the host is notified that the write is complete.

[0072] It can be appreciated that in one or more embodiments, a write operation can trigger a drift table cast-out 575. At the beginning, the drift buffer has space for the next write operation. However, after the drift buffer is full, the oldest entry should be unallocated to make room for the next write operation. In one or more embodiments, the drift buffer may need to discard or unallocate one or more entries in the drift buffer, and several entries may be discarded before the write pointer, so there is room for the next write to the drift buffer. In an embodiment of discarding the drift buffer entry, the drift table is read to obtain discard information, including the LBA of one or more drift table entries to be removed from the drift buffer. Next, the LVT entry of the one or more LBAs to be removed from the drift buffer is read, and it is determined whether the LVT entry corresponding to the one or more LBAs to be discarded from the drift buffer points to the drift table. If the LVT entry points to the drift table (e.g., the drift buffer index valid bit is set), the LVT entry is written to clear the drift buffer index valid bit and change the DBI in the LVT entry to VBA. If the LVT entry does not point to the drift table, eg, the drift buffer index valid bit is not set, then the LVT has already been updated and an update of the LVT entry is not necessary.

[0073] Now refer to Fig. 6A , a block diagram showing a view of the hardware and processes involved in converting a virtual block address (VBA) to a physical address on a media card, and referring to Figure 6B , showing a flowchart of an example of converting a virtual block address (VBA) into a physical address, the physical address indicating the address used to Figure 1 , 2A102 and 103. The memory module / card 102 of 104 and 105 is a memory module / card 106 of the embodiment of the present invention. The memory module / card 106 of 104 and 106 is a memory module / card 107 of the embodiment of the present invention. The memory module / card 107 of 104 and 105 is a memory module / card 108 of the embodiment of the present invention. The memory module / card 108 of 104 and 105 is a memory module / card 106 of the embodiment of the present invention. The memory module / card 108 of 104 and 105 is a memory module / card 106 of the embodiment of the present invention. The memory module / card 108 of 104 and 105 is a memory module / card 108 ...

[0074] Those skilled in the art will appreciate that the VBA may be derived from a logical block address (LBA) received from a host using the methods and structures described above, and in one or more embodiments derived using any now or hereafter known method. Figure 6B The flowchart is based on the following assumptions: Figure 1 The lowest addressable granularity of the memory module / card 102 is 16 bytes, and the memory module / card 102 includes 24 packages, 8 or 16 dies per package, 16 MRU groups per die, 64 MRUs per MRU group, 128-bit arrays per MRU (4 of which are spare), 1 million bits in each bit array, and 1 million pages per MRU (each page includes 128 bits, i.e., 16 bytes). It should be understood that Figure 6B The process can be used for other memory system configurations.

[0075] This flow chart further assumes that the data of the data block including the size of 4K bytes is performed read / write operation.As such, each read / write operation is performed for a total of 5120 bytes of data, which include the data of 4K bytes received from the host, ECC bytes and some metadata.Assuming that the lowest addressable granularity of memory module / card 102 is 16 bytes, the data of 5120 bytes can be stored in 320 discrete pages (each 16 bytes, 15.5 bytes are used to keep actual data) across memory module / card 102.It will be understood that 320 discrete pages should be evenly distributed across memory module / card 102, for wear leveling.Therefore, the conversion process converts VBA into 320 discrete pages of the physical address in memory module / card 102, and VBA represents such 320 discrete pages. The VBA is a 30-bit address, and the lower 20 bits (i.e., the least significant bits) of the VBA are ignored during conversion because they represent a collection of 1 million 4K byte-sized blocks that all have the same upper 10 bits (most significant bits) of the VBA (collectively, the 1 million 4K byte blocks are referred to as virtual repair units (VRUs) represented by the VBA). It should be noted that the example embodiments disclosed herein use a 30-bit VBA to address a 4TB media card. However, the present disclosure is not limited to this, and addresses of other sizes can be similarly used for different media cards. As described below, the upper 10 bits can be used to identify the VRU using a chip select table. The number of VRUs is configured based on the actual media card (for example, if the actual storage capacity of a 4TB media card is approximately 2.5TB, the number of VRUs is 614). For different media cards, different upper bits can be used to identify the VRU using a chip select table (CST).

[0076] like Figure 6C As shown, the conversion of the VBA to a physical address is a multi-layered lookup that includes at least three lookup tables: a chip select table (CST) (e.g., the same for all 24 packages), 24 media repair tables (MRTs) (e.g., one for each package), and 24 bit array repair tables (BARTs) (e.g., one for each package). At 602, the VBA is indexed into the CST. As described above, in one or more embodiments, the lower 20 bits of the VBA representing the VRU are ignored during the conversion, and at step 602, only the upper 10 bits of the VBA are indexed into the CST.

[0077] like Figure 6CAs shown, CST 610 includes columns indexed by package numbers (e.g., Pkg 0-23) and rows indexed by VRU numbers. The high (most significant) 10 bits of the VBA are used to identify the VRU number. Each entry 611 in CST 610 includes a total of 16 bits: the least significant 9 bits (i.e., 9 IRU bits) used to determine the number of intermediate repair units (IRUs); the next 3 bits are reserved for future use, the next 1 bit indicates whether the VRU is to be cleaned (i.e., the clean bit), the next bit is a flag bit indicating whether the package is included in the VRU for performing VBA read / write operations (i.e., the included flag bit), the next bit, which indicates whether the package contains an IRU for which some or all of the MRUs have failed (i.e., the partially failed bit); and the last most significant bit (a total of 16 bits) indicates whether the package includes a complete spare IRU (i.e., the spare bit). Similarly, in an embodiment, a partially marked IRU as failed and / or spare may not be used for read / write operations.

[0078] As described above, the included flag bit of the CST entry 611 indicates whether the package will contain data for VBA (i.e., read / write operations). For example, if the value of the included flag bit for the package is "0", it will not contain data for VBA read / write operations, and if the value of the included flag bit for the package is "1", it will contain data for VBA read / write operations (and vice versa). In an embodiment, of the 24 packages on the media card, only 20 packages are used to perform read / write operations, and 4 packages are spare packages for replacing failed packages by the media repair module 206. Since the 320 pages for storing 5120-byte-sized data blocks are evenly distributed on the memory module / card 102, during the conversion, the flag bits of the included 20 packages will indicate that the corresponding package will contain data for VBA read / write operations. In addition, each of the 20 packages will include 16 discrete pages (or beats) that will contain data to achieve a uniform distribution of data. As used herein, the term beat is used to describe a page in a package that will contain data for performing read and write operations corresponding to a received VBA. These 16 beats for each package can be identified using MRT and BART, as discussed below. Thus, during conversion, the VBA is indexed into the CST at 602, and the upper 10 bits of the VBA are used to identify the VRU number, and the CST is used for the corresponding included flag bits and IRU bits for each package.

[0079] Return to reference Figure 6B, for each package, the 9 IRU bits retrieved from the corresponding CST entry may be used to index into the MRT for that package at step 604. Specifically, for each of the 20 valid packages, the 9 IRU bits from CST 610 are used to identify the IRU number (0-511), which in turn is used to index into MRT 620.

[0080] like Figure 6C As shown, MRT 620 includes rows indexed by IRU numbers and columns indexed by beat numbers. Each entry 621 in MRT 620 includes a total of 16 bits, and determines the physical address (a total of 16) of each beat on the package that will contain the data for performing VBA read / write operations. The physical address is represented as a combination of the die index in the package (the least significant 4 bits of entry 621), the MRU group index in the die (the lower 4 bits of entry 621), and the MRU index (the lower 6 bits of entry 621) in the MRU group that will include the beat (D / MG / M). Entry 621 also includes a fault bit (the bit next to the most significant bit) and a spare bit, the fault bit indicates whether the page represented by D / MG / M has been previously declared to have failed, and the spare bit indicates whether the page represented by D / MG / M has been previously declared to be separately spare (if the entire IRU is spare, then the MRU is not marked as spare in entry 621). Faulty pages and / or spare pages may not be used for read / write operations. Therefore, each packaged MRT 620 returns 16 physical addresses for each packaged beat, which may contain data for performing a read / write operation of the VBA.

[0081] As discussed above, the MRU includes 128 bit arrays, four of which are reserved as spare bit arrays, and each of the 1 million pages in the MRU occupies 1 bit from each of the 124 remaining bit arrays. Therefore, at step 606, BART 630 can be used to determine the index corresponding to the 124 bit array in each MRU of the above physical address, and the corresponding beat from which the occupied bit is to perform the VBA read / write operation. Figure 6C As shown, each row of BART 630 can be indexed using the D / MG / M identifier from MRT 620, and each column of BART 630 is indexed by 0-3 because each MRU includes 4 unused bit arrays. Each entry 631 of BART 630 includes 8 bits-7 least significant bits, which indicates one of the four unused bit arrays (in the 128-bit array) of the MRU for that row, and the most significant bit is reserved for future use. By excluding the unused bit arrays from the MRU, the 124-bit array that will be occupied by the beat can be determined.

[0082] In step 608, the system may use the 20 least significant bits of the VBA in conjunction with the physical address (D / MG / M) and the unused bit array index to perform a read / write operation at the appropriate memory cell, where the actual read / write operation may be performed according to the interface specifications of each specific SCM memory technology.

[0083] It should be noted that the unused bit array indexes of BART 330 may be used in (see below) Figure 7 The error rate table (ERT) 640 created during the memory cleaning process described in the previous section is determined by Figure 6C As shown, the ERT 640 of the package includes rows corresponding to the 128-bit array and columns corresponding to the MRUs in the package. Because one VRU is cleaned at a time during the cleaning process, the MRU of the ERT 640 corresponds to the VRU being cleaned (discussed below). In addition, the cleaning process described below targets 16 beats (i.e., MRUs) for each package, and updates the ERT for each package so that there are 16 MRUs in the ERT. Each entry 641 in the ERT includes the total number of stuck bits observed during the cleaning process of the VRU. Because the VRU includes 1 million consecutive VBAs, the total number of stuck bits can be 2 million ((1 million stuck-at-0 and 1 million stuck-at-1, although it is usually not both).

[0084] Reference now Figure 7 , describes a flow chart showing an example scrubbing process for a memory module / card 102. The scrubbing process may be performed to periodically rewrite data within a threshold time period to ensure data readability and accuracy, periodically flip bits of a memory system to condition each memory cell for future programmability, and / or test the memory system and collect statistics corresponding to stuck-at error failures (which may in turn be used to initiate media repair actions). In certain embodiments, the scrubbing process may be performed on one VRU at a time (in a round-robin fashion and / or upon the occurrence of a triggering event) by disabling any further read / write operations from the VRU, taking 1 million consecutive VBAs corresponding to the VRU being scrubbed out of service.

[0085] During the cleaning process, at 702, the system identifies a VRU to be cleaned. In one or more embodiments, the cleaning process for each VRU may be performed periodically and in a cyclical manner (e.g., every 24 hours) and / or upon the occurrence of a triggering event (e.g., detection of a memory error (such as an asynchronous memory error), detection that a memory operation requires a higher level of ECC correction, etc.). The cleaning process for the VRU may be scheduled so that a complete memory module / card 102 may be cleaned during a threshold time period (e.g., 24 hours, 48 ​​hours, etc.).

[0086] At 704, in one or more embodiments, the system determines whether the identified VRU is in service for performing a read / write operation. If the identified VRU is in service for performing a read / write operation (704: Yes), the system may remove the VRU from use (706). Removing the VRU (e.g., removing 1 million consecutive VBAs from service) may include, but is not limited to, removing all 1 million VBAs of the identified VRU from a free list of the memory system (which identifies a free area of ​​memory of a required specific size). Specifically, the system may not allow any VBAs of the VRU to be placed on the free list after a write operation is released. Additionally and / or alternatively, the system may also remove any existing data from all VBAs of the VRU currently used to store data by migrating the data to another location, removing the VBA from a logic-to-virtual table (LVT) that tracks the current value of the VBA, and / or removing the VBA from a drift buffer.

[0087] When the identified VRU is removed from service and / or if the identified VRU is determined to be out of service for performing read / write operations (704: No), at 708, the system may initialize (e.g., assign a zero value) counters for all ERTs corresponding to the identified VRU. At 710, the system may issue a write operation for each VBA of the identified VRU having pattern A. Examples of pattern A may include a string of all 1s (to detect all stuck-at-0 bits), a string of all 0s (to detect all stuck-at-1 bits), a string of all 5s (to detect two adjacent bits that are stuck to each other), etc. Once the pattern A write operation has been performed for all VBAs in the VRU, at 712, the system may issue a read operation for each VBA of the identified VRU to determine the number of stuck-at-fault bits in the VRU. For example, if pattern A includes a string of all 1s, the read operation may be used to determine the stuck-at-0 bits in the VRU, and if pattern A includes a string of all 0s, the read operation may be used to determine the stuck-at-1 bits in the VRU. Other patterns may be used to identify the number of other stuck-at faults in the VRU (eg, stuck-at-X, 2 or more bits stuck to each other, etc.).

[0088] At 714, the system may issue a write operation for each VBA of the identified VRU with pattern B, where pattern B is different from pattern A. Examples of pattern B may include a string of all 1s (to detect all stuck-at-0 bits), a string of all 0s (to detect all stuck-at-1 bits), a string of all 5s (to detect two adjacent bits stuck to each other), etc. Once the pattern B write operation has been performed for all VBAs in the VRU, at 716, the system may issue a read operation for each VBA of the identified VRU to determine the number of stuck-at-faulty bits in the VRU. For example, if pattern A includes a string of all 1s and is used to identify stuck-at-0 bits in the VRU, pattern B may include a string of all 0s to determine stuck-at-1 bits in the VRU.

[0089] It should be noted that during the cleaning process of a VRU, all 128-bit arrays of each MRU of the VRU (not just the 124-bit arrays) are written / read by ignoring the BARTs during the conversion process so that stuck-in faults can be detected on each bit array. Specifically, the conversion of each of the 1 million VBAs of the VRU to a physical page address is performed using only the CST and MRT. In addition, the conversion during the cleaning process also includes the failed IRU and / or spare IRU. Each cleaning process typically results in the creation of 20-24 ERTs (for each package).

[0090] At 718, the system may update the ERT counter from step 708 (i.e., update the counter to indicate the total number of stuck-in failures) based on the determined stuck-in-0 bit and stuck-in-1 bit values ​​for each bit array of each MRU in the VRU being cleaned. At 720, the system may perform a media repair action (see below). Figure 8 discuss).

[0091] At 722, the system may return the VRU to service by, for example, inserting the VRU's 1 million VBAs into a free list. As described below, if the VRU is converted to a spare IRU during a media repair action, the VRU may not be returned to service.

[0092] See now Figure 8 , describes a flow chart showing example media repair actions performed during each scrubbing process of a memory system. As described above, during the scrubbing process, an ERT for each package is constructed that indicates the number of stuck-in faults (e.g., stuck-in-1, stuck-in-0, etc.) for each bit array index / MRU in the bit array index / MRU of the VRU being scrubbed. The system can analyze the counters in the ERT to perform such operations as Figure 8Media repair actions as described in . Media repair actions may include bit array repair (almost always performed), MRU replacement and / or IRU replacement.

[0093] At 802, the system may determine whether a bit array repair, MRU replacement, and / or IRU replacement needs to be performed on the cleaned VRU. In some embodiments, the system may determine whether an MRU replacement and / or IRU replacement needs to be performed on the VRU by identifying and analyzing the number of bad beats in the ERT.

[0094] A beat can be identified as a bad beat by analyzing the fixed-in-position counts of each bit array in the beat. Specifically, for each of the bit arrays of the beat, the system determines whether the number of fixed-in-position counts is greater than a first threshold (T H ), greater than the second threshold (T L ) but less than the first threshold T H , or whether it is an acceptable number of fixed-positions. Threshold T L and T H Determined by the strength of the ECC. Example T H It can be about 2000 to about 7000 digits per million, for example T L may be from about 200 to about 700 bits per million, and an example acceptable number of fixed-position bits may be less than T L (e.g., less than 100 digits per million).

[0095] If no more than 4 beats have a value greater than T L The number of fixed bits (for example, if the beat includes more than T H A fixed-bit array with a 1-bit count number and a value greater than T L 3-bit array with a fixed bit count number), then the system can only perform bit array repair as discussed below. Fig. 9A An example ERT created after a VRU cleanup is shown, indicating that a bit array repair is required.

[0096] Additionally and / or alternatively, if some beats (but not all and / or less than a threshold number) include a time interval greater than T H The number of fixed-bit counts in the array is more than 4 bits and / or has a value greater than T L If the number of fixed-bit counts in the bit array is more than 11, then the system can determine that the beat is a failed MRU. In addition to bit array repair, the system can perform MRU replacement for such a failed MRU. Fig. 9B An example ERT created after a VRU cleanup is shown, indicating that an MRU replacement is required.

[0097] If all or a certain threshold number of beats in the ERT for a package are bad (i.e., more than 4 bits of the array have a value greater than T H The number of fixed-bit counts and / or arrays with more than 11 bits has a value greater than T L If the system determines that the IRU that includes the bad beat has failed, the system can determine that the IRU that includes the bad beat has failed. In addition to the bit array repair, in one or more embodiments, the system then performs an IRU replacement for such a failed IRU. If there is no spare MRU in the package that includes the failed MRU that needs to be replaced, the IRU replacement can also be performed. Fig. 9C An example ERT created after a VRU cleanup is shown, indicating that an IRU replacement is required.

[0098] The number of bit arrays is provided as an example only, and other numbers are within the scope of the present disclosure for determining whether a bit array repair, MRU replacement, and / or IRU replacement needs to be performed on a VRU.

[0099] At 804, if bit array repair is needed, a system according to an aspect performs a bit array repair action by excluding the worst bit array from use during read / write operations. The system can first identify the worst 4-bit array and its corresponding index for each MRU in the ERT (i.e., column) by analyzing the total number of stuck-in failures observed for each bit array. The worst 4-bit array is the bit array with the highest number of stuck-in failures observed during the scrubbing process. The system can then update and save the BART corresponding to the ERT to include the worst 4-bit array index as the unused bit array index for the MRU. If more than 4 bit arrays are bad, the system can invoke the ECC to perform media repair.

[0100] At 806, if MRU / IRU replacement is required for the failed MRU, the system according to one aspect determines whether the failed MRU is a spare MRU and / or is included in a spare IRU. If the failed MRU is a spare MRU and / or is included in a spare IRU (806: Yes), the system may mark the MRU as a failed MRU (rather than a spare) (808) without replacement. However, if the failed MRU is not a spare MRU and is not included in a spare IRU (806: No), the system according to an embodiment performs MRU replacement (810) and updates the MRT accordingly (812). It should be noted that a spare MRU can be considered as a candidate for replacing a failed MRU only if the performance of the MRU will not be degraded, because performance degradation can be caused by improper ordering of D / MG / M values ​​within the beat of the IRU.

[0101] In one aspect, the system performs MRU replacement (810) by first searching for a spare MRU in the same package as the failed MRU that needs to be replaced. If no spare MRU is found, the system in this embodiment also searches for a spare IRU in the same package and classifies the spare IRU as a spare MRU. The spare MRU and / or IRU in the same package can then be used to replace the failed MRU and / or the IRU that includes the failed MRU. In one embodiment, the system converts the good MRU (i.e., the MRU that does not need to be replaced) of the replaced IRU into a spare MRU. After the replacement, in one or more embodiments, the system updates the MRT for the package to exchange the physical addresses of the pages in the failed MRU or IRU (i.e., D / MG / G) with the physical addresses of the pages in the spare MRU or IRU.

[0102] However, if the package that includes the failed MRU does not include a spare MRU or IRU, in one or more embodiments, the system replaces the entire IRU with a spare IRU in another package (814). A system according to one aspect converts a good MRU (i.e., an MRU that does not need replacement) of the replaced IRU to a spare MRU. After the replacement, in an embodiment, the system updates the CST to swap the in-use IRU with the spare IRU and the spare / failed IRU indication in the CST. It should be noted that in an embodiment, a spare IRU from the same package as the failed MRU / IRU is preferred for replacement over a spare IRU from another package.

[0103] If the system cannot find any spare MRU or IRU in any package, then in one or more embodiments, the system creates (816) a spare IRU from the VRU being cleaned (and does not return it to service) and marks the failed MRU as failed. In one aspect, the system updates the CST and MRT to indicate that the VRU has been used to create a spare IRU and cannot be used for read / write operations.

[0104] In one or more embodiments, it may be necessary to refresh the media, for example once a day. In a refresh operation, the data in the VBA is copied to the new VBA, then the old VBA is written to all "1"s for the first time, then written to all "0"s for the second time, and then the old VBA is put back into service.

[0105] Although the above-described illustrative embodiments are preferably implemented in hardware, such as in units and circuits of a processor, various aspects and / or techniques of the illustrative embodiments may also be implemented in software. For example, it should be understood that Figure 4-8Each block of the flowchart diagrams in the drawings, and the combination of blocks in the flowchart diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor or other programmable data processing device to produce a machine, so that the instructions executed on the processor or other programmable data processing device create a device for implementing the functions specified in the flowchart block or multiple flowchart blocks. These computer program instructions can also be stored in a computer readable memory or storage medium, and these instructions cause the processor or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer readable memory or storage medium produce an article of manufacture including an instruction device that implements the functions specified in the flowchart block or multiple flowchart blocks.

[0106] Accordingly, the blocks of the flowchart illustration support a combination of means for performing the specified function, a combination of steps for performing the specified function, and a program instruction device for performing the specified function. It should also be understood that each block of the flowchart illustration and the combination of blocks in the flowchart illustration can be implemented by a computer system based on dedicated hardware that performs the specified function or step or by a combination of dedicated hardware and computer instructions.

[0107] One or more embodiments of the present disclosure may be systems, methods, and / or computer program products. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to perform aspects of the present invention.

[0108] A computer-readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. More specific examples of non-exhaustive list computer-readable storage media include the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device such as a punch card or a protruding structure in a groove having instructions recorded thereon, and any suitable combination of the above. As used herein, a computer-readable storage medium should not be interpreted as a temporary signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal emitted by a wire.

[0109] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device or to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium in the corresponding computing / processing device.

[0110] The computer-readable program instructions for performing the operation of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and conventional procedural programming languages ​​(such as "C" programming languages ​​or similar programming languages). The computer-readable program instructions may be executed completely on a user's computer, partially on a user's computer, executed as an independent software package, partially on a user's computer, partially on a remote computer, or completely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or may be connected to an external computer (e.g., using an Internet service provider via the Internet). In some embodiments, an electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may be personalized by utilizing the state information of the computer-readable program instructions to execute the computer-readable program instructions to perform various aspects of the present disclosure.

[0111] Various aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of boxes in the flowchart and / or block diagram can be implemented by computer-readable program instructions.

[0112] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that these instructions, when executed by the processor of the computer or other programmable data processing device, create a device for implementing the functions / actions specified in one or more boxes of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which instructions cause the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable storage medium in which the instructions are stored includes a manufactured product containing instructions for implementing aspects of the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0113] These computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so as to cause a series of operating steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, thereby causing these instructions executed on the computer, other programmable apparatus, or other device to implement the functions / actions specified in the flowchart and / or block diagram or multiple boxes.

[0114] The flowcharts and block diagrams in the accompanying drawings show the architecture, functions and operations of possible implementations of the systems, methods and computer program products according to different embodiments of the present disclosure. To this end, each box in the flowchart or block diagram may represent a module, segment or part of an instruction, which includes one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the box may not occur in the order marked in the figure. For example, two boxes shown in succession may be executed substantially simultaneously, or these boxes may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, can be implemented with a dedicated hardware-based system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

[0115] In addition, the system according to different embodiments may include a processor and logic integrated with the processor and / or executable by the processor, the logic being configured to perform one or more of the process steps described herein. By being integrated with it, it is meant that the processor has logic embedded therein as hardware logic, such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), and the like. Processor executable means that the logic is hardware logic; software logic, such as firmware, part of an operating system, part of an application; and the like, or some combination of hardware and software logic, which is accessible by the processor and configured to cause the processor to perform some functions when executed by the processor. The software logic may be stored on local and / or remote memory of any memory type, as known in the art. Any processor known in the art, such as a software processor module and / or a hardware processor, such as an ASIC, an FPGA, a central processing unit (CPU), an integrated circuit (IC), a graphics processing unit (GPU), and the like may be used.

[0116] In the following claims, all means or steps plus corresponding structures, materials, actions, and equivalents of functional elements are intended to include any structure, material, or action for performing the function in combination with other claimed elements as specifically claimed. The description of the embodiments of the present disclosure has been presented for the purpose of illustration and description, but is not intended to be exhaustive or limited to the embodiments in the disclosed form. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the present disclosure. The embodiments and examples are selected and described in order to best explain the principles and practical application of the present disclosure, and to enable others of ordinary skill in the art to understand the disclosure of various embodiments with various modifications suitable for the intended specific use.

[0117] The programs described herein are identified based on the applications in which they are implemented in specific embodiments of the present disclosure. However, it should be understood that any specific program nomenclature herein is used only for convenience, and therefore the present disclosure should not be limited to use in any specific application identified and / or implied by such nomenclature.

[0118] It will be clear that the different features of the aforementioned systems and / or methods may be combined in any way so as to create multiple combinations from the description presented above.

[0119] It should be further appreciated that embodiments of the present disclosure may be provided as a service deployed on behalf of a customer to provide services on demand.

[0120] The description of different embodiments of the present disclosure has been presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein are selected to best explain the principles of the embodiments, practical applications, or technical improvements to technologies found in the marketplace, or to enable those of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A memory system for storing data, the memory system comprising: One or more memory cards, each card having a plurality of memory chips, and each chip having a plurality of dies having a plurality of memory cells; A memory controller, the memory controller comprising a conversion module, the conversion module further comprising: a logical-to-virtual translation table LVT having a plurality of entries, each entry in the LVT being configured to map a logical address to a virtual block address VBA, wherein the VBA corresponds to a set of memory cells on the one or more memory cards, wherein each entry in the LVT further includes a write wear level count for tracking the number of write operations to the VBA mapped to the LVT entry and a read wear level count for tracking the number of read operations to the VBA mapped to the LVT entry, The memory card comprises: a drift buffer for temporarily storing data, wherein each entry of the LVT is configured to indicate whether data is located in the drift buffer.

2. A memory system as described in claim 1, wherein the write wear level count in the LVT is programmable to have a write level threshold corresponding to a maximum number of write operations to a VBA, and in response to a write operation exceeding the write level threshold in an LVT entry, the data in the memory card corresponding to the LVT entry that exceeds the write level threshold is moved to a new location on the memory card having a different VBA.

3. The memory system of claim 2, further comprising a VBA free list that identifies VBAs to which data can be written, and in response to a write operation, obtains a new VBA from the VBA free list. 4 . The memory system of claim 3 , wherein the system is configured to obtain a new VBA from the VBA free list based on the wear level count.

5. The memory system of claim 1 , wherein a read wear level count in the LVT is programmable to have a read level threshold corresponding to a maximum number of read operations of a VBA, and in response to a read operation exceeding the read level threshold in an LVT entry, data in the memory card corresponding to the LVT entry exceeding the read level threshold is written to a new location on the memory card having a different VBA.

6. The memory system of claim 5 further comprises a VBA free list that identifies a VBA that can be used to receive write data, and in response to a read operation exceeding a read level threshold for an LVT entry, obtains a new VBA from the VBA free list, and writes data in a memory card that exceeds the read level threshold corresponding to the LVT entry to a new location on a memory card having a different VBA.

7. The memory system of claim 6, wherein the system is configured to obtain a new VBA from the VBA free list based on the wear level count in response to a read operation exceeding the read level threshold.

8. A memory system as described in claim 1, wherein the drift buffer has multiple entries, and the memory system also includes a drift table having multiple entries, each drift table entry is configured to index to one of the multiple entries in the drift buffer, each entry of the drift table maps a drift buffer index to a VBA, wherein the system is configured to respond to writing data to the memory card, also write the data to the entry in the drift buffer and further write the VBA and the corresponding logical address to the entry in the drift table that indexes to the corresponding entry in the drift buffer. 9 . The memory system of claim 8 , configured to read from the drift buffer if data corresponding to the VBA exists in the drift buffer.

10. The memory system of claim 8, wherein the drift buffer is a circular FIFO buffer contained on the memory card.

11. The memory system of claim 8, wherein each LVT entry includes a field for indicating whether the drift buffer contains data corresponding to the LVT entry, wherein the system is configured in response to a hit on an LVT entry, wherein the LVT field indicates that data is in the drift buffer, and the LVT entry points to an entry in the drift table.

12. The memory system of claim 8, further comprising a drift buffer index valid field in each LVT entry, indicating whether the drift buffer contains data corresponding to each corresponding LVT entry, and wherein the system is configured such that in response to a request to read data from the memory card, the system is configured to search the logical address in the LVT and in response to finding the LVT entry corresponding to the logical address, the system checks the drift buffer index valid field, and in response to the drift buffer index valid field indicating that the requested data is not in the drift buffer, the system utilizes a VBA from the LVT entry, and in response to the drift buffer index valid field indicating that the requested data is in the drift buffer, the system reads the requested data from the drift buffer.

13. The memory system of claim 12, wherein the system is configured such that in response to the drift buffer valid field indicating that the requested data is in the drift buffer, the LVT points to an entry in the drift table, and the system obtains the requested data from a corresponding entry in the drift buffer using information in the drift table.

14. The memory system of claim 8, wherein the system is configured such that in response to data being removed from a drift buffer entry, an LVT entry corresponding to the drift buffer entry from which the data was removed is updated such that the LVT entry contains the VBA of the entry removed from the drift buffer.

15. The memory system of claim 1 further comprises a chip selection table CST and a media repair table MRT, wherein the CST is configured to identify one or more valid memory chips during a transition for performing a memory access operation, the MRT corresponds to each of the memory chips, and each MRT is configured to identify one or more memory dies during a transition for performing a memory access operation.

16. The memory system of claim 1, further comprising a logical address translation table configured to correspond a logical address represented as a logical unit number and a logical unit number offset to a logical block address LBA, and wherein the LVT is configured to map each LBA to a VBA.

17. A method for reading data from one or more memory cards, each memory card having a plurality of memory chips, each memory chip having a plurality of dies, the dies having a plurality of storage cells, the memory card comprising a drift buffer for temporarily storing data, the method comprising: issuing a request for data located on the one or more memory cards; Look up a logical address of the requested data in a logical-to-virtual translation table LVT having a plurality of entries, each entry in the LVT mapping a logical address to a virtual block address VBA and indicating whether the data is located in the drift buffer, wherein the VBA corresponds to a set of memory cells in the one or more memory cards; In response to a logical address of the requested data being located in an entry in the LVT, checking the LVT entry to determine whether the data is located in the drift buffer; In response to determining that the data is located in the drift buffer, reading the requested data from the drift buffer; as well as In response to determining that the data is not located in the drift buffer, a VBA corresponding to the logical address of the requested data is obtained from the LVT entry, and the requested data in the memory card corresponding to the VBA is read.

18. The method of claim 17, further comprising updating a read level count field in the LVT in response to reading the requested data from the memory card.

19. The method of claim 18 further includes comparing the read level count in the LVT entry with a read level threshold field in the LVT entry, and in response to the read level count being equal to or exceeding the read level threshold, writing the data to be read to a new location on one or more memory cards having a different VBA.

20. The method of claim 19, further comprising: In response to writing data to be read to a new location on one or more memory cards having a different VBA, the LVT is updated with the different VBA.

21. The method of claim 20, further comprising updating the VBA in the corresponding LVT entry in response to removing data from the drift buffer.

22. The method of claim 17, further comprising moving the entry to a head of the drift buffer in response to reading data from the drift buffer.

23. A method for writing data to one or more memory cards, each memory card having a plurality of memory chips, each memory chip having a plurality of dies, the dies having a plurality of storage cells, the memory card including a drift buffer for temporarily storing data, the method comprising: issuing a request to write data to the one or more memory cards; Get available VBA from the virtual block address VBA free list; Writing data to a memory card location corresponding to an available VBA obtained from a VBA free list; Writing the data into an entry in the drift buffer; Write the VBA of the available VBA and the logical address corresponding to the available VBA into the entry in the drift table corresponding to the entry in the drift buffer, The method further includes: writing a drift table index into a logical-to-virtual translation table (LVT) entry corresponding to the VBA and corresponding to a location on the memory card of the written data, the drift table index identifying the drift table entry corresponding to the drift buffer entry of the written data, and Set bit to identify that data is in the drift buffer.

24. The method of claim 23, further comprising writing the corresponding LVT entry with an available VBA.

Images