Host memory buffer allocation management

Abstract

Aspects of a memory device including a memory and a controller are provided. The memory includes a volatile memory. The controller can determine at least a portion of the volatile memory as a reusable region based on a host memory allocation from a host device. The controller can also calculate a size of the reusable region in the volatile memory. The controller can also perform one or more memory device operations in the reusable region of the volatile memory in response to the host memory allocation based on the calculated size of the reusable region. Thus, the controller can provide intelligent handling of host memory buffer allocations, thereby improving memory device read performance.

Description

Technical Field

[0001] This disclosure generally relates to electronic devices, and more specifically, to storage devices. Background Technology

[0002] Storage devices enable users to store and retrieve data. Examples of storage devices include non-volatile memory devices. Non-volatile memory typically retains data after a power cycle. An example of non-volatile memory is flash memory, which may contain an array of NAND cells on one or more dies. Flash memory can be found in solid-state drives (SSDs), secure digital cards (SD cards), etc. Typically, a non-volatile memory system has a memory controller that controls access from the host system to the non-volatile memory in the memory system. The host system can be a computer system, a cellular phone, a server, etc. The non-volatile memory system and the host system can exchange data via, for example, a peripheral component interconnect high-speed (PCIe) bus. Non-volatile memory high-speed (NVMe) is a logical device interface specification for accessing non-volatile memory attached via a PCIe bus. NVMe utilizes the parallelism provided by semiconductor memory, such as, but not limited to, SSDs.

[0003] Memory controllers typically have a certain amount of volatile memory, which can be used for a variety of tasks. For example, volatile memory can be used to cache a portion of the management table used to translate between logical addresses used by the host system and physical addresses in non-volatile memory. It should be noted that the full version of the management table can be stored in non-volatile memory. The benefit of caching the management table is that when the memory system receives a read or write request, it can determine which memory location needs to be accessed based on a much faster lookup in the memory controller's volatile memory. For fast and consistent performance, the organization of the management table can be chosen to minimize the required computation and the number of volatile memory lookups, but at the cost of requiring more volatile memory. Memory controllers can also use volatile memory for other purposes.

[0004] When SSDs were first introduced, Dynamic Random Access Memory (DRAM) was typically included as a cache for the SSD to improve drive performance. DRAM acts as a cache for writing data to the SSD and for storing a mapping table that keeps track of the location of data on the SSD to allow data access. In recent years, SSDs using DRAM have continued to push the limits and achieve better performance, becoming the standard. However, major improvements have been made to the SSD interface, NAND technology, SSD controller, and firmware.

[0005] Coupled with the desire to efficiently improve both performance and operational cost, host systems can make portions of their host memory available to the memory controller. For example, some versions of the NVMe protocol allow the Host Memory Buffer (HMB) feature, where portions of host memory are allocated for use by the memory controller. This option can save costs by allowing the memory controller to have less volatile memory. The HMB implemented via the NVMe 1.2 specification allows SSDs to utilize some of the DRAM attached to the host or central processing unit (CPU) via a PCIe connection, rather than requiring DRAM to support the SSD. The primary use of host DRAM is for caching mapped information, which typically requires only a buffer size of a few tens of megabytes (MB). Summary of the Invention

[0006] This document discloses one aspect of a storage device. The storage device includes a memory and a controller. The memory includes volatile memory. The controller is configured to determine that at least a portion of the volatile memory is a reusable region based on host memory allocation from a host device. The controller is also configured to calculate the size of the reusable region in the volatile memory. The controller is further configured to perform one or more storage device operations in the reusable region of the volatile memory in response to host memory allocation, based on the calculated size of the reusable region.

[0007] This document discloses another aspect of a storage device. The storage device includes a memory and a controller. The memory includes volatile memory. The controller is configured to determine that at least a portion of the volatile memory is a reusable region based on a host memory allocation from a host device. The controller is also configured to calculate the size of the reusable region in the volatile memory. The controller is further configured to perform one or more storage device operations in the reusable region of the volatile memory in response to a host memory allocation, based on the calculated size of the reusable region. The controller is also configured to release the host memory allocation back to the host device.

[0008] This document discloses another aspect of a storage device. The storage device includes memory and a controller. The memory includes volatile memory. The controller is configured to determine whether the storage device supports HMB allocation. The controller is also configured to send a request for HMB allocation for one or more internal modules associated with the controller to a host device when it is determined that the storage device supports HMB allocation. The controller is also configured to receive a response from the host device indicating whether the HMB allocation was successful. The controller is also configured to determine that at least a portion of the volatile memory is a reusable region based on the host memory allocation from the host device. The controller is also configured to calculate the size of the reusable region in the volatile memory. The controller is also configured to perform one or more storage device operations in the reusable region of the volatile memory in response to the host memory allocation based on the calculated size of the reusable region. The controller is also configured to release the host memory allocation back to the host device.

[0009] It should be understood that other aspects of the storage device will become apparent to those skilled in the art from the following detailed description, in which various aspects of the apparatus and method are shown and described by means of illustration. It will be appreciated that these aspects may be implemented in other and different forms, and that certain details may be modified in various other ways. Therefore, the drawings and detailed description should be considered illustrative rather than limiting in nature. Attached Figure Description

[0010] Various aspects of this disclosure will now be presented in a detailed description with reference to the accompanying drawings, by way of example but not as a limitation, in which:

[0011] Figure 1 A block diagram illustrating an exemplary embodiment of a storage device communicating with a host device.

[0012] Figure 2 To show Figure 1 A conceptual diagram of an instance of a logical-to-physical mapping table in the non-volatile memory of a storage device.

[0013] Figure 3 To show Figure 1 A conceptual diagram of an example of a two-dimensional array of memory cells in a storage device.

[0014] Figure 4 To show Figure 1 A conceptual diagram of an example of a three-dimensional array of memory cells in a storage device.

[0015] Figure 5 To show Figure 1 A conceptual diagram of an instance of a block array in a storage device.

[0016] Figure 6 To show Figure 1 An example of a voltage distribution diagram for a three-level cell in a storage device.

[0017] Figure 7 To illustrate communication with the host device Figure 1 A conceptual diagram of an example of a non-volatile memory system in a storage device.

[0018] Figure 8 To show in Figure 1 A flowchart illustrating an exemplary process for memory disposal during HMB allocation in a storage device.

[0019] Figure 9 To show Figure 1 A flowchart illustrating an exemplary process for allocating and releasing HMBs in a storage device.

[0020] Figure 10A and 10B To show Figure 1 A conceptual diagram of an example of memory disposal in a storage device.

[0021] Figure 11 To show as by Figure 1 A flowchart illustrating the process performed by the storage device for allocating host memory buffers.

[0022] Figure 12 To demonstrate the handling Figure 1 A conceptual diagram of an instance of a controller that allocates host memory buffers in a storage device. Detailed Implementation

[0023] The detailed description set forth below in conjunction with the accompanying drawings is intended as a description of various exemplary embodiments of the present disclosure and is not intended to represent only embodiments in which the present disclosure may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that the present disclosure may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring the concepts of the present disclosure. Acronyms and other descriptive terms may be used only for convenience and clarity and are not intended to limit the scope of the present disclosure.

[0024] The terms “exemplary” and “example” are used herein to mean serving as an example, illustration, or description. Any exemplary embodiment described herein as “exemplary” should not be construed as preferred or advantageous over other exemplary embodiments. Similarly, the term “exemplary embodiment” for apparatus, method, or article of manufacture does not require that all exemplary embodiments of this disclosure include the described components, structures, features, functionality, processes, advantages, benefits, or modes of operation.

[0025] As used herein, the term "coupled" is used to indicate a direct connection between two components, or, where appropriate, an indirect connection to each other via an intermediary or intermediate component. In contrast, when a component is referred to as "directly coupled" to another component, there is no intermediary element.

[0026] In the following detailed description, various aspects of storage devices that communicate with a host device will be presented. These aspects are well-suited for flash storage devices such as SSDs, Universal Serial Bus (USB) drives, and SD memory cards. However, those skilled in the art will recognize that these aspects are extend to all types of storage devices capable of storing data. Therefore, any references to particular devices or methods are intended only to illustrate various aspects of this disclosure, and it should be understood that such aspects can have a wide range of applications without departing from the spirit and scope of this disclosure. For example, although the following description refers to SSDs, the description can be similarly applied to other flash storage devices.

[0027] HMB leverages PCIe's Direct Memory Access (DMA) capability to allow SSDs to use some of the volatile memory attached to the CPU (e.g., Static Random Access Memory (SRAM) / DRAM), instead of requiring the SSD to contain its own SRAM / DRAM. Accessing host memory via PCIe is slower than accessing onboard SRAM / DRAM, but relatively faster than reading from flash (e.g., NAND memory). HMB is not intended to be a full-size replacement of the onboard SRAM / DRAM used in mainstream SSDs. In fact, all SSDs using the HMB feature have a target buffer size of tens of MB. This is sufficient for the drive to cache mapping information for tens of gigabytes (GB) of flash memory, which is adequate for many consumer workloads.

[0028] HMB is a prominent feature of the NVMe protocol, representing a state-of-the-art storage interface for emerging storage devices such as SSDs. HMB enables the underlying storage to utilize a portion of the host memory to cache address mapping information and / or user data, overcoming the limited capacity of the storage device's internal memory. This technology provides opportunities for cost-effective optimization of I / O performance by sharing sufficient host memory with resource-constrained storage devices.

[0029] While SSD controllers contain a configured amount of memory, the amount of built-in memory may be insufficient to allow for a significant portion of the internal cached NAND mapping table. SSDs that omit volatile memory resources (e.g., SRAM / DRAM) can be less expensive and smaller; however, because the storage device can be resource-constrained, it may only be able to store its mapping table in flash memory (e.g., NAND) rather than significantly faster volatile memory, resulting in a considerable performance trade-off. SSDs can also have limitations due to firmware overhead, the complexity of storage operation algorithms, and the limited production costs of volatile memory resources (e.g., RAM) or other hardware peripherals that contribute to determining read and write performance. HMB features offer advantages in improving SSD performance, but these advantages cannot be fully realized due to host-side limitations.

[0030] This invention provides improvements to SSD read performance in successful HMB allocation scenarios. For example, host read performance can be improved for each successful HMB allocation. This invention facilitates the reuse of SSD volatile memory for SSD read performance improvements without requiring any additional HMB allocation requests. This invention also allows for dynamic configuration of host read performance for random read operations, sequential read operations, or both.

[0031] This invention provides efficient reuse of internal SRAM / DRAM during HMB allocation for loading additional datasets (e.g., logical block address (LBA) information blocks for 32MB of host data to logical mappings in 32KB), inverse memory address table (iSAT), relocation of information (e.g., garbage collection), etc. The SSD controller can send requests for HMB allocation for any of its internal modules to the host device for efficient processing to improve SSD read performance.

[0032] The SSD controller can send a request for HMB allocation to the host device, and based on the priority of the respective internal modules, the SSD controller can decide how to use the allocated HMB for its internal modules. In some aspects, when implementing the Memory Management Unit (MMU) for SRAM / DRAM disposal during HMB allocation between different internal SSD controller modules, the present invention can be extended to include further enhancements to address write operations (e.g., random, sequential, overlapping). This can help achieve improvements in SSD write performance, where write disposal requires a set of data merging requirements. The present invention can be further extended to address adaptive algorithms for loading datasets based on host read and / or write patterns and successful HMB allocation, to reduce the loading and eviction of datasets from SRAM / DRAM.

[0033] Figure 1 An exemplary block diagram 100 shows a storage device 102 communicating with a host device 104 (also a "host") according to an exemplary embodiment. The host device 104 and the storage device 102 may form a system, such as a computer system (e.g., a server, desktop computer, mobile phone / laptop computer, tablet computer, smartphone, etc.). Figure 1 The components may or may not be physically co-located. In this regard, the host device 104 may be located remotely from the storage device 102. Although Figure 1 The host device 104 is shown as separate from the storage device 102, but in other embodiments, the host device 104 may be wholly or partially integrated into the storage device 102. Alternatively, the host device 104 may be distributed across multiple remote entities, or alternatively, it may have some of the functionality of the storage device 102.

[0034] Those skilled in the art will understand that other exemplary embodiments may include more Figure 1 The elements shown may include more or fewer elements, and the disclosed processes may be implemented in other environments. For example, other exemplary embodiments may include different numbers of hosts communicating with storage device 102, or multiple storage devices 102 communicating with hosts.

[0035] Host device 104 can store data to and / or retrieve data from storage device 102. Host device 104 may include any computing device, such as a computer server, network attached storage (NAS) unit, desktop computer, laptop computer, tablet computer, mobile computing device such as a smartphone, television, camera, display device, digital media player, video game console, video streaming device, etc. Host device 104 may include at least one processor 101 and host memory 103. At least one processor 101 may include any form of hardware capable of processing data and may include general-purpose processing units (e.g., CPU), special-purpose hardware (e.g., application-specific integrated circuit (ASIC)), digital signal processors (DSP), configurable hardware (e.g., field-programmable gate array (FPGA)), or any other form of processing unit configured by means of software instructions, firmware, etc. Host memory 103 may be used by host device 104 to store data or instructions processed by the host, or data received from storage device 102. In some instances, host memory 103 may include non-volatile memory, such as magnetic memory devices, optical memory devices, holographic memory devices, flash memory devices (e.g., NAND or NOR), phase-change memory (PCM) devices, resistive random access memory (ReRAM) devices, magnetoresistive random access memory (MRAM) devices, ferroelectric random access memory (F-RAM) devices, and any other type of non-volatile memory device. In other instances, host memory 103 may include volatile memory, such as random access memory (RAM), DRAM, static RAM (SRAM), and synchronous dynamic RAM (SDRAM) (e.g., DDR1, DDR2, DDR3, DDR3L, LPDDR3, DDR4, etc.). Host memory 103 may also include both non-volatile and volatile memory, whether integrated together or as discrete units.

[0036] Host interface 106 is configured to interface storage device 102 with host device 104 via bus / network 108, and can use, for example, Ethernet or WiFi or bus standards (e.g., Serial Advanced Technology Attachment (SATA), PCIe, Small Computer System Interface (SCSI), or Serial Attached SCSI (SAS)) and other possible candidates for interface. Alternatively, host interface 106 may be wireless, and can use, for example, cellular communications (e.g., 5G NR, 4G LTE, 3G, 2G, GSM / UMTS, CDMA One / CDMA2000, etc.), wireless distribution methods via access points (e.g., IEEE 802.11, WiFi, HiperLAN, etc.), infrared (IR), Bluetooth, Wi-Fi, or other wireless wide area network (WWAN), wireless local area network (WLAN), wireless personal area network (WPAN) technologies or similar wide area, local area, and personal area technologies to interface storage device 102 with host device 104.

[0037] Storage device 102 includes a memory. For example, in Figure 1 In an exemplary embodiment, storage device 102 may include non-volatile memory (NVM) 110 for persistently storing data received from host device 104. NVM 110 may include, for example, flash memory, NAND memory (e.g., single-level cell (SLC) memory, multi-level cell (MLC) memory, three-level cell (TLC) memory, four-level cell (QLC) memory, five-level cell (PLC) memory, or any combination thereof), or NOR memory. NVM 110 may include multiple memory locations 112 for storing system data used to operate storage device 102 or user data received from the host and stored in storage device 102. For example, the NVM may have a cross-point architecture comprising a 2-D NAND array of memory locations 112, the 2-D NAND array having n rows and m columns, where m and n are predefined according to the size of the NVM. Figure 1In an exemplary embodiment, each memory location 112 may be a die 114 comprising multiple planes, each plane comprising multiple blocks of multiple cells 116. Alternatively, each memory location 112 may be a plane comprising multiple blocks of cells 116. For example, cells 116 may be single-level cells, multi-level cells, three-level cells, four-level cells, and / or five-level cells. Other instances of memory location 112 are possible; for example, each memory location may be a block or a group of blocks. Each memory location may contain one or more blocks in a 3-D NAND array. Each memory location 112 may contain one or more logical blocks mapped to one or more physical blocks. Alternatively, the memory and each memory location may be implemented in other ways known to those skilled in the art.

[0038] Storage device 102 also includes volatile memory 118, which may include, for example, DRAM or static random access memory (SRAM). Data stored in volatile memory 118 may include data read from NVM 110 or data to be written to NVM 110. In this regard, volatile memory 118 may include write buffers or read buffers for temporary data storage. Although Figure 1 The volatile memory 118 is shown as a controller 123 located remotely from the storage device 102, but the volatile memory 118 may be integrated into the controller 123.

[0039] The memory (e.g., NVM 110) is configured to store data 119 received from the host device 104. Data 119 may be stored in cell 116 of any of the memory locations 112. As an example, Figure 1 The data 119 is shown to be stored in different memory locations 112, but data can also be stored in the same memory location. In another example, memory location 112 can be different dies, and data can be stored in one or more of the different dies.

[0040] Each of the data 119 can be associated with a logical address. For example, the NVM 110 may store a logical-to-physical (L2P) mapping table 120 of the storage device 102 that associates each of the data 119 with a logical address. The L2P mapping table 120 stores a mapping from the logical address specified for data written from the host device 104 to the physical address in the NVM 110 indicating the location of each of the stored data. This mapping can be performed by the controller 123 of the storage device. The L2P mapping table may be a table or other data structure that contains identifiers, such as the logical block address (LBA) associated with each memory location 112 in the NVM where data is stored. Although Figure 1A single L2P mapping table 120 is shown in one of the memory locations 112 of the NVM to avoid excessive confusion. Figure 1 The concept is the same, but the L2P mapping table 120 can actually contain multiple tables stored in one or more memory locations of the NVM.

[0041] Figure 2 Conceptual diagram 200 for an instance of L2P mapping table 205, which shows data 202 received from the host device and Figure 1 The mapping between logical and physical addresses in the NVM 110. Data 202 can correspond to... Figure 1 Data 119 in the table, and L2P mapping table 205 can correspond to Figure 1 The L2P mapping table 120 is used. In one exemplary embodiment, data 202 may be stored in one or more pages 204 (e.g., pages 1 to x), where x is the total number of pages of data written to NVM 110. Each page 204 may be associated with one or more entries 206 in the L2P mapping table 205, which identify an LBA 208, a physical address 210 associated with the data written to NVM, and a data length 212. The LBA 208 may be a logical address specified in a write command for data received from a host device. The physical address 210 may indicate the block and offset to which the data associated with the LBA 208 is physically written. The length 212 may indicate the size of the written data (e.g., 4KB or some other size).

[0042] Return to reference Figure 1 The volatile memory 118 also stores a cache 122 for the storage device 102. The cache 122 contains entries showing a mapping from a logical address specified by the host device 104 to a physical address in the NVM 110 indicating the location where the data is stored. This mapping can be performed by the controller 123. When the controller 123 receives a read command or write command for data 119, the controller checks the logical-to-physical mapping for each piece of data in the cache 122. If no mapping exists (e.g., it is the first request for data), the controller accesses the L2P mapping table 120 and stores the mapping in the cache 122. When the controller 123 executes the read command or write command, the controller accesses the mapping from the cache and reads or writes data from the NVM 110 at the specified physical address. The cache may be stored in the form of a table or other data structure containing a logical address associated with each memory location 112 in the NVM where data is being read.

[0043] NVM 110 includes a sense amplifier 124 and a data latch 126 connected to each memory location 112. For example, memory location 112 may be a block containing cells 116 on multiple bit lines, and NVM 110 may contain a sense amplifier 124 on each bit line. Additionally, one or more data latches 126 may be connected to the bit lines and / or the sense amplifiers. The data latches may be, for example, shift registers. When data is read from a cell 116 of memory location 112, the sense amplifier 124 senses the data by amplifying the voltage on the bit lines to a logic level (e.g., readable as '0' or '1'), and the sensed data is stored in the data latch 126. Controller 123 controls the transfer of data via a data bus from the data latches 126 to volatile memory 118, where the data is stored until it is transferred to host device 104. Because the controller 123 may not have additional memory, it can retain data until the data is moved from the data latch 126 to the volatile memory 118. When data is written to cell 116 at memory location 112, the controller 123 stores the programmed data in the data latch 126, and the data is subsequently transferred from the data latch 126 to cell 116.

[0044] The storage device 102 includes a controller 123, which includes circuitry for executing instructions, such as one or more processors, and the storage device may include a microcontroller, a digital signal processor (DSP), an ASIC, an FPGA, hardwired logic, analog circuitry, and / or combinations thereof.

[0045] Controller 123 is configured to receive data transmitted from one or more cells 116 of various memory locations 112 in response to a read command. For example, controller 123 may read data 119 by activating sense amplifier 124 to sense data from cell 116 into data latch 126, and controller 123 may receive data from data latch 126. Controller 123 is also configured to program data into one or more cells 116 in response to a write command. For example, controller 123 may write data 119 by sending data to data latch 126 to be programmed into cell 116. Controller 123 is further configured to access L2P mapping table 120 in NVM 110 when reading or writing data to cell 116. For example, controller 123 may receive a logical-to-physical address mapping from NVM 110 in response to a read or write command from host device 104, identify the physical address mapped to the logical address identified in the command (e.g., translate the logical address to a physical address), and access or store data in unit 116 located at the mapped physical address.

[0046] The controller 123 and its components may be implemented using embedded software that performs the various functions of the controller described herein. Alternatively, the software for implementing each of the foregoing functions and components may be stored in memory external to the NVM 110, storage device 102, or host device 104, and may be accessed by the controller 123 for execution by one or more processors of the controller 123. Alternatively, the functions and components of the controller may be implemented using hardware within the controller 123, or a combination of the foregoing hardware and software may be used.

[0047] In operation, host device 104 stores data in storage device 102 by sending a write command to storage device 102, the write command specifying one or more logical addresses (e.g., LBAs) and the length of the data to be written. Host interface 106 receives the write command, and the controller allocates memory location 112 in the NVM 110 of storage device 102 for storing the data. Controller 123 stores L2P mappings in the NVM (and cache 122) to map the logical addresses associated with the data to the physical addresses allocated to the memory location 112. The controller also stores the length of the L2P-mapped data. Controller 123 then stores the data in memory location 112 by sending the data to one or more data latches 126 connected to the allocated memory location, the data being programmed from the allocated memory location into cell 116.

[0048] Host device 104 can retrieve data from storage device 102 by sending a read command specifying one or more logical addresses associated with the data to be retrieved from storage device 102, and the length of the data to be read. Interface 106 receives the read command, and controller 123 accesses the L2P mapping in cache 122 or another NVM to translate the logical address specified in the read command into a physical address indicating the location of the data. Controller 123 then reads the requested data from the memory location 112 specified by the physical address by sensing the data using sense amplifier 124 and storing it in data latch 126, until the read data returns to host device 104 via host interface 106.

[0049] Figure 3 An example of a NAND memory array 300 with cell 302 is shown. Cell 302 may correspond to Figure 1Cell 116 in the NVM 110. Multiple cells 302 are coupled to word lines 304 and bit lines 306. For example, the memory array 300 may contain n word lines and m bit lines within a block of die 114 of the NVM 110, where n and m are predefined according to the block size. Each word line and bit line may be associated with a row and column address, respectively, which the controller 123 may use to select a specific word line and bit line (e.g., using a row and column decoder). For example, word lines 0-n may each be associated with their own row address (e.g., word line 0 may correspond to word line address 0, word line 1 may correspond to word line address 1, etc.), and bit lines 0-m may each be associated with their own column address (e.g., bit line 0 may correspond to bit line address 0, bit line 1 may correspond to bit line address 1, etc.). Select gate source (SGS) cell 308 and select gate drain (SGD) cell 310 are coupled to memory cells 302 on each bit line 306. SGS cell 308 and SGD cell 310 connect memory cell 302 to source line 312 (e.g., ground) and bit line 306, respectively. Serial 314 may contain a group of cells 302 coupled to a bit line within the block (including SGS cell 308 and SGD cell 310), while page 316 may contain a group of cells 302 coupled to a word line within the block.

[0050] Figure 4 An example of a three-dimensional (3D) NAND memory array 400 with cell 422 is shown. Cell 422 may correspond to Figure 1 Cell 116 in NVM 110. (As in...) Figure 3 In a 2D memory array 300, multiple cells 422 can be coupled to word lines 414 and bit lines 416. However, in a 3D memory array 400, each word line 414 can contain multiple word line strings 418, and bit lines 416 can be connected to each of the word line strings 418. Similarly, SGS cells and SGD cells (not shown) can connect memory cells in each word line string 418 to source lines (not shown) and bit lines 416, respectively. Therefore, the 3D memory array 400 can store more individually accessible data pages on each word line 414 (e.g., in word line strings 418) than the 2D memory array 300. Although Figure 4 The 3D memory array 400 shown includes instances of two word line strings 418 for each word line 414, but in other instances, word line 414 may contain other numbers of word line strings (e.g., four WL-Strs 0-3). Figure 3 The architecture, or variations thereof, can be used in 3D NAND implementations to include bit-cost scalable (BiCS) flash memory for ultra-high-density storage devices.

[0051] Figure 5 An example of a NAND memory array 500 comprising a block 502 containing multiple strings 504 is shown. Block 502 may correspond to... Figure 1 The blocks of bare die 114 in NVM 110, and the strings 504 can each correspond to Figure 3 The string 314. For example, in Figure 3 In the memory array 300, each string 504 may contain a group of memory cells each coupled to a bit line 506 and individually coupled to a corresponding word line 508. Similarly, each string may contain an SGS cell 510 and an SGD cell 512, which respectively connect the memory cells in each string 504 to the source line 514 and the bit line 506.

[0052] When controller 123 reads data from or writes data to page 316 of cell 302 (i.e., on word lines 304, 508), controller 123 may send a command to apply a read voltage or programming voltage to the selected word line and a pass voltage to the other word lines. The read or programming state of the cell (e.g., logic '0' or logic '1' for SLC) can then be determined based on a threshold voltage of cell 302. For example, during an SLC read operation, if the threshold voltage of cell 302 is less than the read voltage (i.e., current flows through the cell in response to the read voltage), controller 123 may determine that the cell stores logic '1', and if the threshold voltage of cell 302 is greater than the read voltage (i.e., current does not flow through the cell in response to the read voltage), controller 123 may determine that the cell stores logic '0'. Similarly, during an SLC programming operation, the controller can store logic '0' by sending a command to apply a programming voltage to cell 302 on word lines 304, 508 until the cell reaches a threshold voltage, and during an erase operation, the controller can send a command to apply an erase voltage to block 502 containing cell 302 (e.g., to the substrate of a cell, such as a p-well) until the cell shrinks back below the threshold voltage (back to logic '1').

[0053] For cells storing multiple bits (e.g., MLC, TLC, QLC, etc.), each word line 304, 508 may contain multiple pages 316 of cell 302, and the controller may similarly send commands to apply read or program voltages to the word lines to determine the read or program state of the cell based on the cell's threshold voltage. For example, in the case of a TLC, each word line 304, 508 may contain three pages 316, which contain a lower page (LP), a middle page (MP), and a upper page (UP) corresponding to different bits stored in the TLC, respectively. In one example, when programming the TLC, the LP may be programmed first, followed by the MP and then the UP. For example, the programming voltage may be applied to the cells on word lines 304, 508 until the cell reaches a first intermediate threshold voltage corresponding to the cell's least significant bit (LSB). Next, LP can be read to determine a first intermediate threshold voltage, and then a programming voltage can be applied to the cell on the word line until the cell reaches a second intermediate threshold voltage corresponding to the next bit of the cell (between the LSB and the most significant bit (MSB)). Finally, MP can be read to determine a second intermediate threshold voltage, and then a programming voltage can be applied to the cell on the word line until the cell reaches a final threshold voltage corresponding to the MSB of the cell. Alternatively, in other instances, LP, MP, and UP can be programmed together (e.g., in full sequence programming or fuzzy-fine programming), or LP and MP can be programmed first, followed by UP (e.g., LM-fuzzy-fine programming). Similarly, when reading the TLC, controller 123 can read LP to determine whether the LSB stores logic 0 or 1 depending on the threshold voltage of the cell, the controller can read MP to determine whether the next bit stores logic 0 or 1 depending on the threshold voltage of the cell, and the controller can read UP to determine whether the final bit stores logic 0 or 1 depending on the threshold voltage of the cell.

[0054] Figure 6An example of a voltage distribution chart 600 is shown, illustrating different NAND states of a TLC (e.g., cells 116, 302) storing three data bits (e.g., logic 000, 001, etc., up to logic 111). The TLC may contain an erase state 602 corresponding to logic '111' and multiple programming states 604 (e.g., AG) corresponding to other logic values ​​'000-110'. Programming states 604 may be separated by different threshold voltages 606. Initially, for example, after controller 123 erases block 502 containing cells, cells 116, 302 may be in erase state 602. When controller 123 programs LP, MP, and UP as described above, the voltage of cells 116, 302 may increase until it meets the threshold voltage 606 corresponding to the logic value to be stored, at which point the cell transitions to its corresponding programming state 604. Although Figure 6 The diagram shows eight NAND states for a TLC, but the number of states can vary depending on the amount of data stored in each cell 116, 302. For example, an SLC may have two states (e.g., logic 0 and logic 1), an MLC may have four states (e.g., logic 00, 01, 10, 11), and a QLC may have sixteen states (e.g., erase and AN).

[0055] When controller 123 attempts to program cells 116, 302 of selected word lines 304, 508 into one of programming states 604, the controller may perform incremental step pulse programming (ISPP) over several programming cycles or ISPP cycles. For example, a programming voltage (e.g., a high voltage) may be applied to the selected word lines 304, 508, a pass voltage (e.g., a high voltage less than the programming voltage) may be applied to other word lines 304, 508, a bit line programming voltage (e.g., a low voltage) may be applied to bit lines 306, 506 connected to the selected cells being programmed on the selected word lines, and a bit line inhibit voltage (e.g., a high voltage) may be applied to bit lines 306, 506 connected to other cells not programmed on the selected word lines. Applying a high programming voltage to the selected word lines and a low voltage to the selected bit lines allows electrons to tunnel from the channel into the charge trapping layer of the selected cells, thereby increasing the threshold voltage of the cells. On the other hand, applying a high voltage to the unselected bit lines prevents electrons from tunneling from the channel into the charge trapping layer of the unselected cells, thereby preventing an increase in the threshold voltage of the cells. Therefore, bit lines coupled to cells programmed to lower states can be disabled to prevent an increase in the threshold voltage of those cells, while other cells are programmed to higher states. For example, in the case of TLC, the bit lines of cells initially programmed to state A can be disabled first, followed by the bit lines of different cells programmed to state B, then the bit lines of cells reaching state C, then state D, and so on, until the remaining cells on the selected word line finally reach state G and all cells on the selected word line are programmed.

[0056] After applying a programming voltage in a programming cycle or ISPP cycle, a programming check voltage (e.g., a low voltage) may be applied to word lines 304 and 508 to determine whether the cell's threshold voltage has increased beyond the corresponding threshold voltage to enter the expected programming state. If none of the cells transition to the expected programming state, another programming cycle or ISPP cycle is executed, in which a higher programming voltage may be applied to further increase the cell's threshold voltage. Subsequently, the programming check voltage may be applied again to determine whether the cell's threshold voltage has transitioned to the expected programming state. This process of increasing the programming voltage and checking the voltage threshold of the selected cells may be repeated over several programming cycles. If a cell transitions to its corresponding programming state and the total number of programming cycles does not exceed a predetermined cycle count, the controller may determine that the cell has entered its expected programming state and is therefore successfully programmed. Otherwise, if the total number of programming cycles exceeds the predetermined cycle count before the cell transitions to its corresponding programming state, the controller may determine that a programming failure has occurred.

[0057] Figure 7 for Figure 1A block diagram of an example non-volatile memory system in a storage device, depicting further details of an exemplary embodiment of the memory controller 123 and the host device 104. In one exemplary embodiment, Figure 7 The system is an SSD. As used herein, memory controller 123 is a means of managing data stored on a non-volatile memory device and communicating with a host device 104, such as a computer or electronic device. In some exemplary embodiments, non-volatile memory 110 includes flash (e.g., NAND, NOR) memory cells, in which case memory controller 123 may be a flash memory controller.

[0058] In addition to the specific functionalities described herein, the memory controller 123 may have various other functionalities. For example, the memory controller may format the memory to ensure proper operation, list faulty memory cells, and allocate spare memory cells to replace future faulty cells. A portion of the spare cells may be used to maintain firmware to operate the memory controller and implement other features. In operation, the host device 104 may communicate with the memory controller 123 when it needs to read data from or write data to the memory. If the host device 104 provides a logical address (LA) to which data will be read / written, the memory controller 123 may translate the logical address received from the host device 104 into a physical address in the memory. The logical address may be an LBA, and the physical address may be a physical block address (PBA). (Alternatively, the host device 104 may provide the physical address). The memory controller 123 can also perform various memory management functions, such as, but not limited to, wear leveling (distributing writes to avoid wear on specific memory blocks that would otherwise be repeatedly written to) and garbage collection (moving only valid data pages to new blocks after a block is full, so that full blocks can be erased and reused).

[0059] Memory controller 123 may be configured to implement a memory access protocol, such as the NVMe protocol. In some exemplary embodiments, memory controller 123 is configured to implement an extension to the NVMe protocol that allows memory controller 123 to request dynamic changes to the size of HMB 770. Memory controller 123 implementing the NVMe protocol or an extension to the NVMe protocol is referred to herein as an NVMe memory controller, which allows memory controller 123 to request dynamic changes to the size of HMB 770. Similarly, host controller 780 implementing the Peripheral Component Interconnect (PCI) protocol or an extension to the NVMe protocol is referred to herein as an NVMe host controller, which authorizes memory controller 123 to request dynamic changes to the size of HMB 770.

[0060] A portion of host memory 103 may be used for HMB 770. HMB 770 may be a buffer allocated by host device 104 for use by memory controller 123. In some exemplary embodiments, HMB 770 is used for exclusive purposes by memory controller 123. For example, memory controller 123 may use HMB 770 to cache data. In one exemplary embodiment, host device 104 may guarantee that data in HMB 770 is valid and force notification to memory controller 123 before any operation that could cause data loss (e.g., power loss, host need for this buffer, etc.). In one exemplary embodiment, host device 104 allows memory controller 123 to acknowledge this operation before data loss. In one exemplary embodiment, host device 104 may perform an initial allocation of HMB 770 to memory controller 123 upon initialization of memory controller 123. In one exemplary embodiment, memory controller 123 is initialized upon power-up of storage device 102. The initial allocation may conform to NVMe; however, the initial allocation of HMB is not limited to NVMe.

[0061] The HMB 770 can be logically divided into units such as data buffers. For example, each data buffer can be 4KB, or some other size. Host memory 103 can be used to store an HMB pointer. The HMB pointer may contain the physical address of the buffer in host memory 103. The HMB pointer may also contain a size parameter indicating the size of the buffer.

[0062] It should be noted that a portion of the host memory 103 can be used as a data buffer, wherein the host device 104 can store host data to be written to the NVM 110, or store host data read from the NVM 110.

[0063] Host device 104 includes host controller 780. As used herein, host controller 780 is a means of communicating with memory controller 123 to access non-volatile memory under the control of memory controller 123. Host controller 780 may be configured to implement host controller functions including, but not limited to, NVMe memory access protocols. It should be noted that host controller 780 may be configured to implement techniques that may be extensions to, for example, NVMe memory access protocols.

[0064] The host controller 780 has an HMB allocator 744, which is configured to allocate HMBs to the memory controller 123 and maintain HMB allocations with the storage device until certain power state events. In one exemplary embodiment, the HMB allocator 744 is configured to allocate HMBs 770 based on a request from the memory controller 123 during a power-on state of the storage device, and the host controller 780 maintains the HMB allocations with the storage device until the storage device is powered off (normal or abnormal). In this respect, the HMB allocations can be completely released during a power-off state of the storage device. In some aspects, the host controller 780 can maintain the HMB allocations with the storage device even if the storage device transitions to a low power state (e.g., power state 3, power state 4).

[0065] The host controller 780 can be accessed via interface 106 (in... Figure 1 The storage device interface 748 communicates with the memory controller 123. The storage device interface 748 may include a physical layer interface (PHY) that provides an electrical interface to the storage device 102 and / or interface 106. In one exemplary embodiment, the PHY includes PCIe-compliant hardware. However, the PHY is not limited to PCIe. The storage device interface 748 generally facilitates the transmission of data, control signals, and timing signals via interface 106.

[0066] For example, the HMB distributor 744 and the storage device interface 748 may take the form of an encapsulated functional hardware unit (e.g., circuitry) designed for use with other components, portions of programming code (e.g., software or firmware) executable by processing circuitry (or one or more processors) that typically performs a specific function in the associated functions, or a separate hardware or software component that interfaces with a larger system. For example, the HMB distributor 744 may include an ASIC, FPGA, circuitry, digital logic circuitry, analog circuitry, a combination of discrete circuitry, gates, or any other type of hardware or combination thereof. Alternatively or additionally, each module may include or include software stored in a processor-readable device (e.g., host memory 103) to program one or more processors to perform the functions described herein.

[0067] The memory controller 123 may interface with the NVM 110. In one exemplary embodiment, the memory controller 123 and a plurality of memory dies (together including storage device 102) implement an SSD, which may emulate, replace, or substitute for a hard disk drive inside the host, as a NAS device, etc. Alternatively, it is not necessary for the SSD to act as a hard disk drive.

[0068] In some exemplary embodiments, storage device 102 includes a single channel between memory controller 123 and non-volatile memory 110, but the subject matter described herein is not limited to having a single memory channel. For example, in some non-volatile memory device architectures, depending on the memory controller capabilities, there may be four, seven, eight, or more channels between memory controller 123 and memory die. In any of the exemplary embodiments described herein, there may be more than a single channel between memory controller and memory die, even if a single channel is shown in the figures.

[0069] The memory controller 123 includes a host interface 106 that provides an electrical interface to the host device 104 or a next-level memory controller. The host interface 106 may include a PHY. In one exemplary embodiment, the host interface 106 includes PCIe-compliant hardware. However, the host interface 106 is not limited to PCIe. The host interface 106 typically facilitates the transmission of data, control signals, and timing signals. The host interface may be configured to provide communication with the host device 104.

[0070] The memory controller 123 includes an HMB handling module 750. In some aspects, the HMB handling module 750 may be referred to as an MMU. The HMB handling module 750 is configured to request the allocation of an HMB 770. The HMB handling module 750 may be configured to request the initial allocation of an HMB during memory controller initialization. In one exemplary embodiment, the HMB handling module 750 is configured to request an additional HMB 770 during runtime (e.g., after memory controller initialization). In one exemplary embodiment, the HMB allocation is released after a normal or abnormal shutdown of the storage device, after which the HMB handling module 750 may make another request for HMB allocation when the storage device is powered on again. In another exemplary embodiment, the HMB handling module 750 may be configured to release the additional HMB 770 after the memory controller 123 has completed using the additional HMB 770.

[0071] Host memory 103 may store HMB pointers as pointers to data buffers of HMB 770. For example, each HMB pointer may point to a cell in memory. Each cell in memory may be a page, where the page size is set by host device 104. In one exemplary embodiment, the HMB pointer may be a host memory buffer descriptor according to the NVMe protocol. However, the HMB pointer is not limited to the NVMe protocol. The HMB pointer may be provided by HMB allocator 744 in host device 104.

[0072] In some aspects, the HMB processing module 750 may request HMB allocations with a minimum and / or maximum range. If the HMB processing module 750 determines that the authorized HMB allocation corresponds to a smaller than the requested minimum allocation (e.g., a partial HMB allocation), the HMB processing module 750 may reject the HMB allocation and subsequently initiate a new request. On the other hand, if the HMB processing module 750 accepts the authorized HMB allocation, the HMB processing module 750 may not initiate a new request to modify the size of the requested HMB allocation. In other aspects, the host memory 103 may be used to store log pages, which may be used to store various information to be reported to the host device 104. In one exemplary embodiment, the log pages are used to store information about changes in the amount of requested HMB 770. For example, the log pages may contain requests for additional HMBs or the release of a portion of HMB 770 back to the host device 104.

[0073] The HMB 770 can be used to store management tables. In one exemplary embodiment, the management table includes an L2P table (logical-to-physical mapping) and a P2L table (physical-to-logical mapping). The memory controller 123 can use the management table to map logical addresses (LAs) to physical addresses (PAs). Such management tables can be used to directly map LAs to PAs, or LAs can be mapped to intermediate or virtual block addresses that are mapped to PAs. In some exemplary embodiments, the logical address is a logical block address, and the physical address is a physical block address. Other variations are also possible.

[0074] The management table can also be used to manage the caching of data in locations other than volatile memory 110. In one exemplary embodiment, memory controller 123 caches data in HMB 770. For example, memory controller 123 may use HMB 770 to cache data associated with some LA (or range of LA). The management table can also be used to manage the caching of data in HMB 770. In one exemplary embodiment, memory controller 123 caches data in volatile memory 118. For example, memory controller 123 may use volatile memory 118 to cache data associated with some LA (or range of LA). The management table can also be used to manage the caching of data in volatile memory 118. In one exemplary embodiment, volatile memory 118 is volatile memory (e.g., Figure 1 volatile memory 118).

[0075] DMA logic 753 is configured to control DMA transfers of data between non-volatile memory 110 and host memory 103 in host device 104. DMA logic 753 can directly access HMB 770. For example, DMA logic 753 can cache data in HMB 770. For example, DMA logic 753 can access data from HMB 770 and transfer it to volatile memory 118 (e.g., ...). Figure 1 (The cache 122). DMA logic 753 can use the HMB pointer to access the correct location in HMB 770.

[0076] The memory controller 123 may include a memory interface that provides command sequences to and receives status information from the non-volatile memory 110. The memory interface may be configured to access non-volatile memory on the non-volatile memory 110. The memory interface may provide an electrical connection to line 718. The memory interface may control the timing of signals transmitted via line 718 to the non-volatile memory 110. In one exemplary embodiment, the memory interface may be a dual data rate (DDR) interface. In some exemplary embodiments, the memory interface is a flash memory interface. However, the memory cells in the non-volatile memory 110 are not limited to flash memory. Therefore, the memory interface is not limited to a flash memory interface.

[0077] For example, Figure 7 The components of the memory controller 123 depicted herein may take the form of: packaged functional hardware units (e.g., circuitry) designed for use with other components; portions of programming code (e.g., software or firmware) executable by a (micro)processor or processing circuitry (or one or more processors) that typically performs a specific function of the associated functions; or stand-alone hardware or software components that interface with a larger system. For example, all or part of each module (including, but not limited to, HMB disposal module 750, DMA logic 753, host interface 106) may contain an ASIC, FPGA, circuitry, digital logic circuitry, analog circuitry, a combination of discrete circuitry, gates, or any other type of hardware or combinations thereof. Alternatively or additionally, all or part of each module may contain or include software stored in a processor-readable device (e.g., memory) for programming one or more processors for the memory controller 123 to perform the functions described herein. Figure 7 The architecture depicted is an exemplary embodiment of a component (e.g., cache 122) that may or may not use the memory controller 123.

[0078] like Figure 7As described, memory controller 123 uses memory to cache mapping information for data stored in NVM 110. However, the size of the memory in memory controller 123 is typically insufficient to allow caching a significant portion of the NAND mapping table. Therefore, storage device 102 (e.g., memory controller 123) uses HMB features to cache mapping information for flash memory of tens of gigabytes, which is sufficient for many consumer workloads.

[0079] In an exemplary embodiment, memory controller 123 sends a request for HMB allocation (e.g., HMB allocation request 730) to host device 104. The HMB allocation may be requested for servicing any internal module (not shown) of memory controller 123, such as a Storage Address Table (SAT), Inverse SAT (iSAT), XOR parity data, Controller Address Table (CAT), Relocation Library (RLC), etc. In some aspects, HMB allocation request 730 may include a request from an internal module, such that multiple HMB allocation requests may be sent to host device 104 on behalf of multiple internal modules of memory controller 123, where each request per internal module. In other aspects, HMB allocation request 730 may include an aggregated request from multiple internal modules, where HMB allocation request 730 specifies the requested size of HMB 770 for each of the internal modules. If host device 104 grants all requested HMB allocations, the area in storage device 102's volatile memory 118 (e.g., static random access memory (SRAM)) used for the requested modules (e.g., SAT, iSAT, XOR, CAT, RLC, etc.) may not be used.

[0080] This disclosure provides a process for managing HMB allocation to improve SSD read performance. According to the invention, after successful allocation of HMB 770, the memory controller 123 determines the allocated HMB size for the corresponding module. A volatile memory 118 (e.g., SRAM / DRAM) allocation for the corresponding module is obtained, and it is determined whether the SRAM / DRAM region is reusable. If the volatile memory 118 region is determined to be reusable, the memory controller 123 calculates the size of the reusable volatile memory 118 region and loads a preferred dataset (e.g., a logical mapping of LBA information blocks for 32MB of host data to 32KB) into the reusable volatile memory 118 region to improve sequential or random read performance. The loading of the dataset can be determined by the memory controller 123 based on the current host read pattern, and the loading can be customized for the application to achieve optimal read performance. If the allocated HMB area is to be released, the memory controller 123 can determine which modules are using the allocated area in HMB 770 and whether the corresponding allocated volatile memory 118 area is being reused. If the memory controller 123 determines that the reused volatile memory 118 area is to be released, the memory controller 123 can evict all datasets from the volatile memory 118 area and release the allocated HMB 770 area back to the host device 104. The algorithm for loading datasets is further adapted based on the host read / write pattern to reduce the loading and eviction of datasets from the volatile memory 118 area.

[0081] If multiple modules of memory controller 123 use the authorized allocation of HMB 770 for their internal operations (as a single request, and to authorize HMB allocation for the storage device), then HMB disposal module 750 can combine all information blocks of the volatile memory 118 region into a single logical information block and use this effectively to improve host reads.

[0082] Figure 8 To show in Figure 1 A flowchart of an exemplary process 800 for memory disposal during HMB allocation in storage device 102. Figure 8 In this context, the memory controller 123 may function based on whether its request for HMB allocation is authorized by the host controller 780. In some aspects, process 800 may be executed during the initialization phase of the memory controller 123. In other aspects, process 800 may be executed during the runtime phase.

[0083] Some of the frames may be executed by host device 104 (e.g., by host controller 780), while others may be executed by storage device 102 (e.g., by memory controller 123). The initialization phase refers to the initialization of memory controller 123. In one embodiment, the initialization phase is performed according to the NVMe protocol. However, the initialization phase is not limited to NVMe. The initialization phase may be performed after a power-on reset of storage device 102. The initialization phase can be used to establish values ​​in registers, such as PCIe registers.

[0084] At 802, it is determined whether storage device 102 supports HMB allocation. In some aspects, block 802 may be performed by host device 104 (e.g., by host controller 780). In other aspects, block 802 may be performed by storage device 102 (e.g., by memory controller 123). If storage device 102 supports HMB allocation, process 800 proceeds to block 804. Otherwise, process 800 terminates.

[0085] At 804, the memory controller 123 requests a certain amount of host memory 103 from the host controller 780 for use by the memory controller 123 (e.g., HMB allocation request 730). In one embodiment, the memory controller 123 makes the request according to a version of the NVMe protocol. In one embodiment, the memory controller 123 requests the allocation of HMB 770 according to a version of the NVMe protocol. The memory controller 123 may indicate the requested size of the allocated host memory 103 for use by the memory controller 123. In some aspects, the memory controller 123 may specify a preferred requested size of HMB 770. In some aspects, the memory controller 123 may specify a minimum size of HMB 770 required by the memory controller 123.

[0086] Block 804 includes the host controller 780 allocating regions of host memory 103 for use by memory controller 123. In block 804, the host controller 780 may perform block 804 in response to a request from memory controller 123. In one embodiment, the host controller 780 may generate a list of descriptors having pointers to regions of host memory 103. In some aspects, the descriptor list may contain pointers to one or more regions of HMB 770.

[0087] At 806, memory controller 123 can determine whether the requested HMB allocation was successful. If the HMB allocation is successful, process 800 proceeds to block 808. Otherwise, process 800 can be terminated. Block 806 includes host controller 780 reporting whether the allocation from host memory 103 to memory controller 123 was successful. In some aspects, host controller 780 sends an HMB allocation response indicating whether the HMB allocation was successful (e.g., ...). Figure 7 (HMB allocation response 732 in the context of memory controller 123). In one embodiment, host controller 780 sends a command to memory controller 123 to report the allocation. For example, host controller 780 may indicate which internal module of memory controller 123 has allocated at least a portion of HMB 770. In another instance, host controller 780 may indicate the total HMB allocation corresponding to the total allocation size of HMB 770 used by memory controller 123.

[0088] Box 806 may include a decision based on whether host controller 780 authorizes HMB allocation request 730. Depending on the degree to which host controller 780 authorizes the request, three outcomes are possible: Host device 104 may fully authorize HMB allocation request 730, meaning host controller 780 provides the entire requested allocation amount of HMB 770. In this respect, full authorization of HMB allocation request 730 indicates a successful HMB allocation. Host controller 780 may reject HMB allocation request 730, meaning host controller 780 will not authorize the requested allocation of HMB 770. In this respect, rejection of HMB allocation request 730 indicates an unsuccessful HMB allocation. Host controller 780 may partially authorize HMB allocation request 730, meaning host controller 780 may authorize a portion of the requested amount of HMB 770. In this respect, partial authorization of HMB allocation request 730 indicates a successful HMB allocation. If the host device 104 fully authorizes the HMB allocation request 730, the memory controller 123 uses the allocated HMB 770 to perform a task. For example, the memory controller 123 uses the allocated HMB 770 to perform a storage device operation (e.g., garbage collection).

[0089] At block 808, the memory controller 123 allocates a region of volatile memory based on the corresponding priority of the corresponding module, according to the allocated HMB from the total HMB allocation for the corresponding module used by the memory controller 123. In this regard, the memory controller 123 can determine how to utilize the allocated HMB of the corresponding module by allocating the volatile memory region to determine whether SSD read performance during HMB allocation can be improved. In contrast, conventional methods require that the SRAM region allocated to the requesting module in the storage device cannot be effectively utilized in response to a fully requested HMB allocation. In some aspects, each internal module of the memory controller 123 may have a different priority. In some aspects, the priority may be based on the type of internal module. In some aspects, the priority may be based on the number of workloads being processed by the internal module, such that the priority increases with the number of workloads.

[0090] At block 810, memory controller 123 acquires an allocated region of volatile memory 118 for a corresponding module. For example, memory controller 123 may acquire an allocated region of cache 122 (e.g., SRAM, DRAM). Regions in volatile memory 118 may be allocated to specific internal modules of memory controller 123. (See reference...) Figure 9 Further details are discussed regarding the allocation of volatile memory 118 for the corresponding module.

[0091] At 812, the memory controller 123 determines whether the acquired allocated area of ​​the volatile memory 118 is reusable. If the acquired allocated area of ​​the volatile memory 118 is reusable, process 800 proceeds to block 814. Otherwise, process 800 may terminate at this point.

[0092] In some aspects, if the host controller 780 fully authorizes the requested HMB allocation, the amount of volatile memory released may substantially correspond to the total amount of volatile memory used by the internal module. For example, if the internal module uses 500KB of volatile memory and the HMB allocation indicates that 500KB of host memory is allocated to the internal module, the memory controller 123 may determine that 500KB can be released through the HMB allocation. The memory controller 123 may determine that 500KB is sufficient to perform one or more read operations that will improve the SSD read performance of the internal module, and determine that the acquired allocated area of ​​volatile memory 118 is reusable. In other aspects, if the host controller 780 authorizes only a portion of the requested HMB allocation, the amount of volatile memory released may correspond to a portion of the total amount of volatile memory used by the internal module. For example, if the internal module uses 50KB of volatile memory and the HMB allocation indicates that 4KB of host memory is allocated to the internal module, the memory controller 123 may determine that 4KB can be released through the HMB allocation. The memory controller 123 may determine that 4KB is insufficient to perform one or more read operations that would improve the SSD read performance of the internal module, and determines that the acquired allocated area of ​​volatile memory 118 is not reusable. In another example, if the internal module uses 100KB of volatile memory and the HMB allocation indicates that 90KB of host memory is allocated to the internal module, the memory controller 123 may determine that 90KB can be released through the HMB allocation. The memory controller 123 may determine that 90KB is sufficient to perform one or more read operations that would improve the SSD read performance of the internal module, and determines that the acquired allocated area of ​​volatile memory 118 is reusable. In some aspects, the degree to which the released area in volatile memory 118 is reusable may be based on a configurable threshold. For example, when the released area exceeds a configurable threshold, the memory controller 123 may determine that the released area of ​​volatile memory is reusable. In some aspects, the configurable threshold may represent the amount of memory required to facilitate the execution of storage device operations associated with the memory controller module.

[0093] At 814, when the acquired allocated area in volatile memory 118 is reusable, memory controller 123 calculates the size of the reusable volatile memory 118 area. This calculation can be more refined than the coarse calculation used at block 812. The reusable area calculation can be used to determine whether subsequent loading of the mapping table and / or buffer allocation for host device 104 can be performed.

[0094] At 816, depending on the reusable area calculation, the memory controller 123 can load the iSAT table and / or relocation information. The amount of volatile memory used to load the iSAT / RLC can correspond to the amount calculated at box 814.

[0095] At 818, depending on the reusable area computation, memory controller 123 can load a dataset to improve random read performance. The amount of volatile memory used to load the dataset for random performance can correspond to the amount computed at box 814.

[0096] At 820, depending on the reusable area computation, memory controller 123 can load a dataset to improve sequential read performance. The amount of volatile memory used to load the dataset for sequential performance can correspond to the amount computed at box 814.

[0097] At 822, depending on the reusable area computation, memory controller 123 can load a dataset to improve random and sequential read performance. The amount of volatile memory used to load the dataset for random and sequential performance can correspond to the amount computed at box 814.

[0098] At 824, depending on the reusable area calculation, memory controller 123 can allocate reusable areas for host read and / or write buffering. The amount of volatile memory allocated for host read / write buffering may correspond to the amount calculated at box 814.

[0099] Figure 9 To show Figure 1 The flowchart illustrates an exemplary process 900 of HMB allocation and release in storage device 102. Memory controller 123 may utilize reusable volatile memory to improve SSD read / write performance and decides to release the allocated HMB back to host device 104.

[0100] At 902, the memory controller 123 decides to release the allocated HMB to the host device 104. In some aspects, the memory controller 123 may determine that the corresponding internal module is performed using a reusable area in the volatile memory 118, and decide to issue a command instructing the memory controller 123 to release the corresponding allocated HMB to the host device 104.

[0101] At 904, the memory controller 123 can identify which modules are using HMB allocations. The memory controller 123 can determine which modules are using HMB allocations by obtaining information from the HMB allocation response 632 indicating whether a requested HMB allocation for the corresponding internal module was successful. In other aspects, the memory controller 123 can maintain a bitmap indicating which internal modules have used their respective HMB allocations.

[0102] At 906, the memory controller 123 determines whether a region in volatile memory 118 associated with an HMB allocation for a corresponding module is being reused. For example, a region in volatile memory 118 freed by an HMB allocation and determined to be sufficient for reuse by the memory controller 123 may be marked in a bitmap by the memory controller 123. If it is determined that a region in volatile memory 118 is being reused, process 900 proceeds to block 908. Otherwise, process 900 proceeds to block 910.

[0103] At 908, when the memory controller 123 determines that an object region in volatile memory 118 is being reused, the memory controller 123 may evict all datasets from the reused region in volatile memory 118. In other aspects, the memory controller 123 may evict all datasets from extended volatile memory (e.g., RAM) regions used for host read and write buffers. At 910, the memory controller 123 releases the allocated HMB back to the host device 104.

[0104] Figure 10A and 10B To show Figure 1 A conceptual diagram illustrating an example of volatile memory handling in storage device 102. Figure 10AIn this context, the memory controller 123 includes one or more internal modules configured to perform specific memory device operations. For example, the memory controller 123 includes multiple internal modules such as SAT, iSAT, XOR, CAT slots, compressed CAT slots, RLC, and other modules (e.g., module N-1, module N), where N is a predefined number of modules in the memory controller. For example, SAT may refer to a logical-to-physical address mapping. iSAT may refer to a physical-to-logical address mapping. Garbage collection algorithms may also use physical-to-logical address mappings to identify which memory blocks need to be relocated. Physical-to-logical address mappings will sometimes be referred to herein as "reverse mapping" or iSAT. In other instances, XOR, or "exclusive OR," is a reliability enhancement that can increase the reliability of NAND components. XOR schemes are named after Boolean logic functions and allow the replacement of up to an entire defective NAND die within a component via XOR operations. The XOR scheme provides protection against die failures and external uncorrectable bit error rate (UBER) events by replacing the entire or defective portion of a NAND die array with a spare NAND die array containing reconstructed data via XOR parity data bits. The primary goal of the XOR scheme in SSDs is to reduce any catastrophic data loss failures and average failure rate. This is achieved using the Boolean XOR logic function A XOR B XOR B = A. XORing an incoming data packet from the host produces XOR parity bits, which can then be used to reconstruct the data if needed. By storing the result of A XOR B as parity data, the scheme allows A or B to be reconstructed by XORing the parity data with A (to reconstruct B) or B (to reconstruct A).

[0105] like Figure 10A As depicted, volatile memory 118 includes allocated regions assigned to corresponding internal modules. During HMB allocation, these allocated regions can be fully or partially released. For example, a first region containing release region 1022 of volatile memory 118 can be allocated to the SAT internal module, a second region containing release region 1024 of volatile memory 118 can be allocated to the XOR internal module, a third region containing release region 1026 of volatile memory 118 can be allocated to the CAT slot internal module, and a fourth region containing release region 1028 of volatile memory 118 can be allocated to another internal module (e.g., module N-1). Each of the release regions 1022, 1024, 1026, and 1028 may be discontinuous and correspond to an assigned memory region of the corresponding internal module. In some aspects, each of the release regions may be referred to as a block of information in the released memory.

[0106] exist Figure 10B In this context, the memory controller 123 can determine the allocation of HMB 770 by multiple modules of the memory controller 123 for their internal operations. The HMB processing module 750 of the memory controller 123 can combine all information blocks of the released volatile memory into a single logical information block and efficiently utilize the combined information block of the released memory to improve host read performance. For example, the HMB processing module 750 can combine released regions 1022, 1024, 1026, and 1028 into a contiguous logical information block 1030 of usable volatile memory. The remaining area of ​​the volatile memory 118 can be reorganized to form the logical information block 1032 of the used volatile memory.

[0107] Figure 11 To show as by Figure 1 The flowchart illustrates the process 1100 performed by the storage device for allocating host memory buffers. For example, process 1100 may be performed in, for instance... Figure 1 This is performed in the storage device 102 shown. Each step in the flowchart can be controlled using a controller (e.g., controller 123) as described below, by a component or module of the controller, or by some other suitable component.

[0108] As indicated by box 1102, controller 123 can determine that at least a portion of the volatile memory is a reusable region based on host memory allocation from host device 114. For example, refer to Figure 1 , 7 8 and 9, Controller 123 may determine whether the storage device supports HMB allocation. Controller 123 may also send a request for HMB allocation for one or more internal modules associated with the controller to the host device when it determines that the storage device supports HMB allocation. Controller 123 may also receive a response from the host device indicating whether the HMB allocation was successful. Controller 123 may also allocate reusable regions in volatile memory corresponding to the host memory allocation for the internal modules based on the corresponding priority of the internal modules of the controller, according to the total host memory allocation. Controller 123 may also obtain the allocated regions in volatile memory for the internal modules. In determining that at least a portion of the volatile memory is reusable, Controller 123 may calculate a first amount of memory to be released in at least a portion of the volatile memory based on the host memory allocation, and may determine a second amount of memory for performing storage device operations associated with the internal modules of the controller, such that Controller 123 may determine that the first amount of memory is greater than the second amount of memory to conclude that the released regions are reusable.

[0109] As indicated by box 1104, controller 123 can calculate the size of a reusable region in volatile memory. As indicated by box 1106, controller 123 can perform one or more storage device operations in the reusable region of volatile memory in response to host memory allocation, based on the calculated size of the reusable region.

[0110] As indicated by box 1108, controller 123 may release host memory allocations back to host device 114. Controller 123 may also determine which allocated regions of host memory corresponding to the host memory allocation are being released. Controller 123 may identify which of one or more internal modules associated with the controller are using the allocated regions of host memory, and determine whether reusable regions in volatile memory associated with the host memory allocation are being reused by the identified internal modules. Upon determining that reusable regions in volatile memory are being reused, controller 123 may also evict one or more datasets from the reusable regions of volatile memory.

[0111] Figure 12 To demonstrate the handling Figure 1 A conceptual diagram 1200 illustrates an example of a controller 1202 allocated to a host memory buffer in storage device 102. Controller 1202 is coupled to memory 1204 in the storage device. Controller 1202 may include module 1206. For example, controller 1202 may correspond to controller 123, and memory 1204 may correspond to... Figure 1 The storage device 102 contains volatile memory 128. Module 1206 may correspond to HMB processing module 750. Controller 1202 is also coupled to host 1210 containing HMB 1212. For example, host 1210 may correspond to host device 104, and HMB 1212 may correspond to HMB 770. Controller 1202 may be implemented in software, hardware, or a combination of hardware and software. In one exemplary embodiment, the controller is implemented using several software modules that execute on one or more processors, but as those skilled in the art will appreciate, the controller may be implemented in different ways. Those skilled in the art will readily understand how the controller is best implemented based on the specific design parameters of the system.

[0112] Controller 1202 may include module 1206, which provides means for determining that at least a portion of volatile memory is a reusable region based on host memory allocations made with a host device. For example, module 1206 may perform the aforementioned process described at 1102. In one configuration, module 1206 may provide means for calculating the size of the reusable region in volatile memory, for example, as described in conjunction with 1104. In one configuration, module 1206 may provide means for performing one or more storage device operations in the reusable region of volatile memory in response to host memory allocations based on the calculated size of the reusable region, for example, as described in conjunction with 1106. Controller 1202 may also provide means for releasing the allocated region of host memory back to the host device, for example, as described in conjunction with 1108.

[0113] Therefore, the controller described in this disclosure improves the read and / or write performance of the storage device by efficiently reusing the internal volatile memory during HMB allocation. For example, the controller may load additional datasets (e.g., logical mappings of information blocks with logical block addresses of host data), reverse the memory address table, relocate information (e.g., garbage collection), etc. In this way, the controller can send requests for HMB allocations for any of its internal modules to the host device for efficient processing. Thus, improvements in SSD read and write performance can be achieved with minimal changes to the controller logic and / or the interface to the internal memory and the host device.

[0114] Various aspects of this disclosure are provided to enable those skilled in the art to practice it. Various modifications to the exemplary embodiments presented throughout this disclosure will be apparent to those skilled in the art, and the concepts disclosed herein are extendable to other magnetic storage devices. Therefore, the claims are not intended to limit them to the various aspects of this disclosure, but are to be accorded the full scope consistent with the language of the claims. All structural and functional equivalents of the various components throughout the exemplary embodiments described in this disclosure that are known to or will later be known to those skilled in the art are expressly incorporated herein by reference and are intended to be covered by the claims. Furthermore, nothing disclosed herein is intended to be exclusive to the public, whether or not it is expressly stated in the claims. No element of any claim shall be construed under U.S. 35 U.S. SC § 112(f) or a similar statute or rule of law of another jurisdiction, unless the phrase “component is used for” is used to explicitly describe the element, or, in the case of a method claim, the phrase “step is used for” is used to enumerate the element.

Claims

1. A storage device comprising: Memory, which includes volatile memory; as well as The controller is configured as follows: At least a portion of the volatile memory is determined to be a reusable region based on host memory allocation from the host device; Calculate the size of the reusable region in the volatile memory; as well as Based on the calculated size of the reusable region, one or more storage device operations are performed in the reusable region of the volatile memory in response to the host memory allocation. The determination that at least a portion of the volatile memory is reusable includes: A first amount of memory to be released in at least a portion of the volatile memory is calculated based on the host memory allocation; Determine a second amount of memory for performing the one or more storage device operations associated with the internal modules of the controller; and It is determined that the first quantity in the memory is greater than the second quantity in the memory.

2. The storage device of claim 1, wherein the controller is further configured to determine whether the storage device supports host memory buffer allocation, i.e., HMB allocation.

3. The storage device according to claim 2, wherein the controller is further configured to: In response to determining that the storage device supports the HMB allocation, a request for the HMB allocation for one or more internal modules associated with the controller is sent to the host device; and Receive a response from the host device indicating whether the HMB allocation was successful.

4. The storage device of claim 1, wherein the controller is further configured to: Based on the corresponding priority of the internal modules of the controller, the reusable area in the volatile memory is allocated to the internal modules according to the host memory allocation; and Obtain the allocated reusable area in the volatile memory used for the internal module.

5. The storage device of claim 1, wherein the execution of the operation of the one or more storage devices includes loading one or more of inverse memory address table information or relocation information associated with a garbage collection operation in the reusable region of the volatile memory.

6. The storage device of claim 1, wherein the execution of the one or more storage device operations includes loading one or more mapping tables associated with the one or more storage device operations in the reusable region of the volatile memory.

7. The storage device of claim 6, wherein the one or more storage device operations include one or more of random read operations, sequential read operations, random write operations, sequential write operations, or relocation operations.

8. The storage device of claim 1, wherein the execution of the one or more storage device operations includes allocating one or more host buffers associated with the one or more storage device operations in the reusable region of the volatile memory.

9. The storage device of claim 1, wherein the controller is further configured to: Determine to release the allocated region of host memory corresponding to the host memory allocation; Identify one or more internal modules associated with the controller that are using the allocated region of the host memory; Determine whether the reusable region in the volatile memory associated with the host memory allocation is reused by one or more identified internal modules; When it is determined that the reusable area is being reused, one or more datasets are evicted from the reusable area of ​​the volatile memory; as well as Release the allocated region of the host memory to the host device.

10. A storage device comprising: Memory, which includes volatile memory; as well as The controller is configured as follows: At least a portion of the volatile memory is determined to be a reusable region based on host memory allocation from the host device; Calculate the size of the reusable region in the volatile memory; Based on the calculated size of the reusable region, one or more storage device operations are performed in the reusable region of the volatile memory in response to the host memory allocation; as well as Allocate and release the host memory to the host device. The determination that at least a portion of the volatile memory is reusable includes: A first amount of memory to be released in at least a portion of the volatile memory is calculated based on the host memory allocation; Determine a second amount of memory for performing the one or more storage device operations associated with the internal modules of the controller; and It is determined that the first quantity in the memory is greater than the second quantity in the memory.

11. The storage device of claim 10, wherein the controller is further configured to determine whether the storage device supports host memory buffer allocation, i.e., HMB allocation.

12. The storage device of claim 11, wherein the controller is further configured to: In response to determining that the storage device supports the HMB allocation, a request for the HMB allocation for one or more internal modules associated with the controller is sent to the host device; and Receive a response from the host device indicating whether the HMB allocation was successful.

13. The storage device of claim 10, wherein the controller is further configured to: Based on the corresponding priority of the internal modules of the controller, the reusable area in the volatile memory is allocated to the internal modules according to the host memory allocation; and Obtain the allocated reusable area in the volatile memory used for the internal module.

14. The storage device of claim 10, wherein the controller is further configured to: Determine to release the allocated region of host memory corresponding to the host memory allocation; Identify one or more internal modules associated with the controller that are using the allocated region of the host memory; Determine whether the reusable region in the volatile memory associated with the host memory allocation is reused by one or more identified internal modules; and When it is determined that the reusable area is being reused, one or more datasets are evicted from the reusable area of ​​the volatile memory.

15. The storage device of claim 10, wherein the execution of the one or more storage device operations includes loading one or more mapping tables associated with the one or more storage device operations in the reusable region of the volatile memory, and wherein the one or more storage device operations include one or more of a random read operation, a sequential read operation, a random write operation, a sequential write operation, or a relocation operation.

16. A storage device comprising: Memory, which includes volatile memory; as well as The controller is configured as follows: Determine whether the storage device supports host memory buffer allocation, i.e., HMB allocation; In response to determining that the storage device supports the HMB allocation, a request for the HMB allocation for one or more internal modules associated with the controller is sent to the host device; Receive a response from the host device indicating whether the HMB allocation was successful; When the HMB allocation with the host device is successful, at least a portion of the volatile memory is determined to be a reusable region; Calculate the size of the reusable region in the volatile memory; Based on the calculated size of the reusable region, one or more storage device operations are performed in the reusable region of the volatile memory in response to the HMB allocation; as well as Release the HMB allocation back to the host device. The determination that at least a portion of the volatile memory is reusable includes: A first amount of memory to be released in at least a portion of the volatile memory is calculated based on the HMB allocation; Determine a second amount of memory for performing the one or more storage device operations associated with the internal modules of the controller; and It is determined that the first quantity in the memory is greater than the second quantity in the memory.

17. The storage device of claim 16, wherein the controller is further configured to: Based on the corresponding priority of the internal modules of the controller, the reusable area in the volatile memory is allocated to the internal modules according to the HMB allocation; and Obtain the allocated reusable area in the volatile memory used for the internal module.

18. The storage device of claim 16, wherein the controller is further configured to: Determine to release the allocated region of host memory corresponding to the HMB allocation; Identify one or more internal modules associated with the controller that are using the allocated region of the host memory; Determine whether the reusable region in the volatile memory associated with the HMB allocation is reused by one or more identified internal modules; and When it is determined that the reusable area is being reused, one or more datasets are evicted from the reusable area of ​​the volatile memory.

Images