SSD usage of host memory buffers for improved performance

Abstract

Aspects of a storage device that requests L2P address translation data from an HMB for execution of associated host commands using a dynamically determined HMB pass size are provided. The storage device includes a volatile memory and a controller. The controller allocates a plurality of memory locations in the volatile memory for L2P address translation data from the HMB. The controller receives a command indicating a host data length and transmits a request for a portion of the L2P address translation data stored in the HMB for the command. The HMB pass size associated with the request may be based on the host data length of the associated host command, a number of idle and contiguous memory locations available in the HMB read buffer, or a minimum between a size of the portion and a total size of the idle and contiguous memory locations. Accordingly, HMB delivery latency may be reduced.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of, and is hereby incorporated by reference in its entirety, U.S. Non-Provisional Application No. 17 / 931,447, filed on September 12, 2022, and entitled “SSD USE OF HOST MEMORY BUFFER FOR IMPROVED PERFORMANCE,” for all purposes. Background Art Technical Field

[0003] The present disclosure relates generally to electronic devices and, more particularly, to storage devices.

[0004] introduction

[0005] 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 power is restarted. An example of non-volatile memory is flash memory, which may include an array of NAND cells on one or more dies. Flash memory can be found in solid-state devices (SSDs), secure digital (SD) cards, and the like.

[0006] The flash memory storage device may store control information associated with the data. For example, the flash memory storage device may maintain a control table including a mapping of logical addresses to physical addresses. The control table is used to track the physical location of logical sectors or blocks in the flash memory.

[0007] The host device may include a host memory buffer (HMB). The HMB allows the storage device to utilize host volatile memory (e.g., dynamic random access memory (DRAM)) for the storage device's own purposes. For example, although accessing data in an HMB (e.g., in a host DRAM) is slower than accessing data in a flash storage device, such data access is still faster than accessing data in a NAND memory, and thus the controller may utilize the HMB to store various control information and user data for host commands. Summary of the invention

[0008] An aspect of a storage device is disclosed herein. The storage device includes a volatile memory and a controller. The controller is configured to: allocate a plurality of memory locations in the volatile memory for logical to physical (L2P) address translation data from a host memory buffer (HMB); receive a command indicating a host data length; and transmit a request for a portion of the L2P address translation data stored in the HMB, wherein the portion of the L2P address translation data is for the command. The size of the L2P address translation data associated with the request is based on the host data length indicated in the command.

[0009] Another aspect of a storage device is disclosed herein. The storage device includes a volatile memory and a controller. The controller is configured to: allocate a plurality of memory locations in the volatile memory for storing L2P address translation data from an HMB; and transmit a request for a portion of the L2P address translation data stored in the HMB, wherein the portion of the L2P address translation data is for a host command. The size of the L2P address translation data associated with the request is based on the number of free and contiguous memory locations at the time of the request.

[0010] Another aspect of a storage device is disclosed herein. The storage device includes a volatile memory and a controller. The controller is configured to: allocate multiple memory locations in the volatile memory for storing logical to physical (L2P) address translation data from an HMB; receive a command; and transmit a request for a portion of the L2P address translation data stored in the HMB, wherein the portion of the L2P address translation data is used for the command. The size of the L2P address translation data associated with the request is based on the minimum of the following: the size of the portion of the L2P address translation data used for the command, and the total size of the number of free and continuous memory locations at the time of the request.

[0011] It will be appreciated 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 illustrated and described by way of illustration. As will be appreciated, these aspects may be implemented in other different forms, and several details thereof may be modified in various other aspects. Therefore, the drawings and detailed description are to be considered illustrative rather than restrictive in nature. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Various aspects of the invention will now be presented in detail by way of example and not limitation, with reference to the accompanying drawings, in which:

[0013] Figure 1is a block diagram illustrating an exemplary embodiment of a storage device in communication with a host device.

[0014] Figure 2 is an example Figure 1 A conceptual diagram of an example of a logical-to-physical mapping (L2P) table in a non-volatile memory of a storage device.

[0015] Figure 3 This is an example of using HMB to store L2P address translation data. Figure 1 A conceptual diagram of an example of a controller in a storage device.

[0016] Figure 4 is an example Figure 1 A conceptual diagram of an example of an HMB read buffer in a volatile memory of a storage device for storing L2P table address translation data read from an HMB.

[0017] Figure 5 is an example of receiving and executing a host command Figure 1 A conceptual diagram of an example of a state of an HMB read buffer in a volatile memory of a storage device.

[0018] Figure 6 is an example after receiving and executing a host command Figure 1 A conceptual diagram of another example of an HMB read buffer in a volatile memory of a storage device.

[0019] Figure 7 is an example of receiving and executing a host command Figure 1 A conceptual diagram of another example of an HMB read buffer in a volatile memory of a storage device.

[0020] Figure 8 This is a part that illustrates dynamically requesting L2P address translation data from HMB for processing host commands. Figure 1 A conceptual diagram of an example of a controller in a storage device.

[0021] Fig. 9 is an example as Figure 1 A flowchart of an example of a method performed by a storage device for requesting L2P address translation data from an HMB using a dynamically determined HMB transfer size.

[0022] Fig.10 is exemplified in Figure 1 A conceptual diagram of an example of a controller in a storage device that uses a dynamically determined HMB transfer size to request L2P address translation data from an HMB. DETAILED DESCRIPTION

[0023] The specific embodiments described below in conjunction with the accompanying drawings are intended to be a description of various exemplary embodiments of the present invention, and are not intended to represent the only embodiment that can practice the present invention. In order to provide a thorough understanding of the present invention, the specific embodiments include specific details. However, it will be apparent to those skilled in the art that the present invention can be practiced without these specific details. In some cases, well-known structures and components are shown in the form of block diagrams to avoid obscuring the concept of the invention. Acronyms and other descriptive terms may be used only for convenience and clarity and are not intended to limit the scope of the present invention.

[0024] The words "exemplary" or "example" are used herein to mean serving as an example, instance, or illustration. Any exemplary embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other exemplary embodiments. Likewise, the term "exemplary embodiment" of an apparatus, method, or article does not require that all exemplary embodiments of the invention include the described components, structures, features, functions, 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 to indicate an indirect connection to each other through intervening components or intermediate components where appropriate. In contrast, when a component is referred to as being "directly coupled" to another component, there are no intervening elements.

[0026] In the following detailed description, various aspects of a storage device that communicates with a host device will be presented. These aspects are well suited for flash storage devices, such as SSDs and SD cards. However, those skilled in the art will recognize that these aspects can be extended to all types of storage devices capable of storing data. Therefore, any reference to a specific device or method is intended only to illustrate various aspects of the present invention, and it should be understood that these aspects can have a wide range of applications without departing from the spirit and scope of the present disclosure.

[0027] Storage devices that lack dynamic random access memory (DRAM) (e.g., DRAMless devices) or include limited DRAM (e.g., low DRAM devices) can utilize a host memory buffer (HMB) to store logical to physical (L2P) address translation data. The L2P address translation data may include pages of an L2P mapping table that a controller may use to translate logical addresses in host commands to physical addresses in flash memory. Since static RAM (SRAM) is typically limited in size, the HMB provides additional storage capacity for the controller to utilize the L2P address translation data, which host memory can be accessed more quickly than the flash memory (NAND) of the storage device itself.

[0028] When the controller obtains a host command (e.g., a read command or a write command) that includes an associated logical address where host data may be stored, the controller may first check whether the associated L2P mapping table entry already exists in the SRAM, in which case the controller may proceed to convert the logical address of the data to a physical address in the NAND flash memory and execute the command (e.g., read or write user data) at the physical address. If the L2P mapping table entry does not exist in the SRAM, the controller may check whether the mapping is stored in the HMB before relying on reading the flash memory for the mapping. If the mapping is stored in the HMB, the controller may issue an HMB read request to the host to transfer the mapping to the SRAM of the storage device. After storing the mapping in the SRAM in response to the HMB read request, the controller may extract the mapping and execute the command.

[0029] At present, the amount of L2P address conversion data (HMB transfer size) that the controller can obtain in a single HMB read request is fixed based on the size of the memory slot in the SRAM in which the conversion data is stored. For example, if the size of a single memory slot in the HMB read buffer is 128 bytes, the HMB transfer size of a single HMB read request can be similarly fixed to 128 bytes to adapt to the memory slot size. For small host commands (e.g., a read command of 128kB or less host data), the byte amount may be sufficient to cover the host data associated with the host command in an HMB read request. For example, if the host command includes 128kB of host data and the HMB transfer size of the L2P address conversion data of 128 bytes also includes 128kB (or kiB) of host data, then an HMB read request may be sufficient to obtain the entire L2P address conversion data for a 128kB host command. However, for large host commands (e.g., a read command of 1MB host data), the byte amount may not be sufficient to cover the host data associated with the host command in an HMB read request. For example, if a host command includes 1MB of host data, but the HMB transfer size of 128 bytes of L2P address translation data only includes 128kB (or kiB) of host data, eight HMB read requests may be required to obtain the L2P address translation data for the 1MB host command (i.e., 128kB*8 requests=1MB). Since each HMB read request for L2P address translation data increases latency in completing the associated host command, such large host commands may result in significant latency and reduced performance when executing such host commands.

[0030] Therefore, in order to improve the performance of the storage device, the controller of the storage device may apply a dynamic HMB transfer size for the HMB read request so as to efficiently read the L2P address conversion data from the HMB with the minimum waiting time. For example, the controller may apply a dynamic HMB transfer size for a single HMB read request based on the host data length of the associated host command and / or based on the number of continuous memory locations available in the HMB read buffer, rather than applying a static HMB transfer size based on the size of the memory slots in the HMB read buffer as previously described. In order to determine the HMB transfer size associated with the HMB read request, the controller may identify the host data length associated with the host command, and then identify the amount of free continuous memory slots required to accommodate the L2P address conversion data for the host data length in the HMB read buffer. The controller may search for free continuous memory slots in the HMB read buffer, and if the number of free continuous memory slots found by the controller is the same as the number required to accommodate the entire L2P address conversion data, the controller may set the HMB transfer size associated with the HMB read request to the total size of the required number of memory slots. Therefore, the controller may obtain the entire L2P address conversion data of the host command in response to a single HMB read request.

[0031] For example, assuming that in one example the host command includes a 1MB data length, the memory slot size of the HMB read buffer is 128 bytes, and the 128-byte L2P address translation data includes 128kB or kiB of host data. In this case, eight idle and continuous 128-byte memory slots will be required to accommodate the entire 1KB of L2P address translation data for the 1MB host command (128 bytes per slot * 8 slots = 1KB). Therefore, if the controller locates eight continuous and idle memory slots in the HMB read buffer, the controller can dynamically set the HMB transfer size to 1KB, rather than statically fixing the HMB transfer size to 128 bytes based on a single memory slot size as previously described. Therefore, instead of statically sending eight HMB read requests as previously described to obtain 1KB of L2P address translation data, the controller can dynamically send one HMB read request for the entire 1KB of L2P address translation data. Therefore, a reduced waiting time when obtaining the L2P address translation associated with the command can be achieved.

[0032] On the other hand, if the controller determines that the HMB read buffer includes less than the required amount (e.g., less than eight in the aforementioned example), the controller may set the HMB transfer size to the total size of the free contiguous memory slots actually found by the controller. For example, assume that as an alternative to the above-mentioned 1MB host command example, the controller locates four free and contiguous 128-byte memory slots in the HMB read buffer, which can accommodate 512 bytes of L2P address translation data (128 bytes per slot * 4 slots = 512 bytes) of the entire 1KB of L2P address translation data required to address the 1MB host command. In this case, the controller can dynamically set the HMB transfer size for an HMB read request to 512 bytes, rather than statically fixing the HMB transfer size to 128 bytes as previously described. Similarly, if the controller locates four additional free and contiguous 128-byte memory slots in the HMB read buffer (which are not contiguous with the aforementioned four other slots), these slots can accommodate the remaining 512 bytes of the 1KB of L2P address translation data, and the controller can similarly dynamically set the HMB transfer size for another HMB read request to 512 bytes. Therefore, instead of statically sending eight HMB read requests to obtain 1KB of L2P address translation data as previously described, the controller can dynamically send a total of two HMB read requests for the entire 1KB of L2P address translation data. Therefore, even with fewer, free, contiguous memory slots in the HMB read buffer, performance can still be improved because the controller can use a dynamic HMB transfer size approach instead of using the aforementioned static HMB transfer size to obtain the entire L2P address translation data of the host command in response to fewer HMB read requests.

[0033] Therefore, the controller may set the HMB transfer size of the corresponding HMB read request to the minimum value between the total size of the number of memory slots required to store the entire L2P address translation data of the host command (e.g., 1KB in the case where eight 128-byte slots are required to fully address a 1MB command), and the total size of the number of free contiguous memory slots in the HMB read buffer that can be used to store the L2P address translation data of the host command (e.g., 512 bytes in the case where only four 128-byte slots are available to store the L2P address translation data of the 1MB command). For example, in the aforementioned example in which the memory slot size is 128 bytes, the total size of the memory slots used to address the host command is 1KB, and the total size of the free contiguous memory slots located in the SRAM is 512 bytes, in this example, the HMB transfer size per HMB read request will be the minimum value between 1KB and 512 bytes, or 512 bytes in this case. Thus, even if the HMB read buffer includes a number of free and contiguous memory slots that is less than the amount required to satisfy the L2P address translation of a host command, reduced latency to obtain the L2P address translation associated with the command may still be achieved.

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

[0035] Those skilled in the art will appreciate that other exemplary embodiments may include Figure 1 More or fewer elements than those shown in the figure, and the disclosed process can be implemented in other environments. For example, other exemplary embodiments can include a different number of hosts communicating with the storage device 102, or multiple storage devices 102 communicating with the host.

[0036] The host device 104 may store data to the storage device 102 and / or retrieve data from the storage device. The host device 104 may include any computing device, including, for example, a computer server, a network attached storage (NAS) unit, a desktop computer, a notebook (e.g., laptop) computer, a tablet computer, a mobile computing device such as a smart phone, a television, a camera, a display device, a digital media player, a video game console, a video streaming device, etc. The host device 104 may include a main memory 103 and at least one processor 101. The at least one processor 101 may include any form of hardware capable of processing data, and may include a general-purpose processing unit (such as a central processing unit (CPU)), dedicated hardware (such as an application-specific integrated circuit (ASIC)), a digital signal processor (DSP), configurable hardware (such as a field programmable gate array (FPGA)), or any other form of processing unit configured by software instructions, firmware, etc. The main memory 103 may be used by the host device 104 to store data or instructions processed by the host or data received from the storage device 102. In some examples, the main 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), and any other type of non-volatile memory device. In other examples, the main memory 103 may include volatile memory, such as random access memory (RAM), dynamic random access memory (DRAM), static RAM (SRAM), and synchronous dynamic RAM (SDRAM (e.g., DDR1, DDR2, DDR3, DDR3L, LPDDR3, DDR4, etc.). The main memory 103 may also include both non-volatile memory and volatile memory, whether integrated together or as discrete units.

[0037] The host 104 may also include a host memory buffer (HMB 105). The HMB 105 is a portion of the host memory (e.g., host memory 103 or a different memory in the host 104) that the host 104 can allocate to the storage device 102 for the purpose of the storage device itself. For example, the storage device 102 may utilize the HMB 105 as an address mapping table cache or a data cache. In some examples, the HMB 105 may include volatile memory, such as RAM, DRAM, or SDRAM (e.g., DDR1, DDR2, DDR3, DDR3L, LPDDR3, DDR4, etc.). In other examples, the HMB 105 may include non-volatile memory.

[0038] The host interface 106 is configured to interface the storage device 102 with the host 104 via a bus / network 108, and may use, for example, Ethernet or WiFi, or bus standards such as Serial Advanced Technology Attachment (SATA), PCI express (PCIe), Small Computer System Interface (SCSI), or Serial Attached SCSI (SAS), among other possible candidates. Alternatively, the host interface 106 may be wireless, and may interface the storage device 102 with the host 104 using, for example, cellular communications (e.g., 5G NR, 4G LTE, 3G, 2G, GSM / UMTS, CDMA One / CDMA2000, etc.), wireless distribution methods through access points (IEEE 802.11, WiFi, HiperLAN, etc.), infrared (IR), Bluetooth, Zigbee, or other wireless wide area network (WWAN), wireless local area network (WLAN), wireless personal area network (WPAN) technology, or comparable wide area network, local area network, and personal area network technology.

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

[0040] The storage device 102 also includes a volatile memory 118, which may include, for example, a dynamic random access memory (DRAM) or a static random access memory (SRAM). The data stored in the volatile memory 118 may include data read from the NVM 110 or data to be written to the NVM 110. In this regard, the volatile memory 118 may include a write buffer or a read buffer for temporarily storing data. Figure 1 The volatile memory 118 is shown remote from the controller 123 of the storage device 102 , but the volatile memory 118 may be integrated into the controller 123 .

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

[0042] Each of the data 119 may be associated with a logical address. For example, the NVM 110 may store a logical-to-physical (L2P) mapping table 120 for the storage device 102 that associates each of the data 119 with a logical address. The L2P mapping table 120 stores a mapping of logical addresses specified for data written from the host 104 to physical addresses in the NVM 110 indicating the location of each of the data. This mapping may be performed by a controller 123 of the storage device. The L2P mapping table may be a table or other data structure that includes an identifier, such as a logical block address (LBA), associated with each memory location 112 of the storage data in the NVM. Although Figure 1 A single L2P mapping table 120 is illustrated as being stored in one of the NVM memory locations 112 of the NVM to avoid undue ambiguity. Figure 1 , but the L2P mapping table 120 may actually include multiple tables stored in one or more NVM memory locations of the NVM.

[0043] Figure 2 2 is a conceptual diagram 200 of an example of an L2P mapping table 205, which illustrates data 202 received from a host device to an NVM 201 (eg, Figure 1 The data 202 may be associated with a mapping of logical addresses and physical addresses in the NVM 110. Figure 1 The L2P mapping table 205 corresponds to the data 119 in Figure 1201. In one example, data 202 may be stored in one or more pages 204 (e.g., physical pages) in NVM 201. Each page 204 may be associated with a mapping set (Mset 203) including one or more entries 206 of an L2P mapping table 205, which identifies a logical block address (LBA) 208, a physical address 210 associated with the data written to the NVM, and a length 212 of the data. LBA 208 may be a logical address specified in a write command for data received from a host device. Physical address 210 may indicate a block and offset to which data associated with LBA 208 is physically written. Length 212 may indicate the size of the written data (e.g., 4KB or other size). In the illustrated example, a page 204 including 32KB of data 202 may be associated with an Mset 203 (e.g., Mset 1) including 8192 4KB entries, each occupying 4 bytes of memory. However, in other examples, page 204 may include a different amount of host data (e.g., other than 32KB of host data), Mset 203 may include a different number of entries 206 (e.g., other than 8192 entries), entries 206 may each include a different host data length (e.g., other than 4KB each), or entries 206 may each occupy a different amount of memory (e.g., other than 4 bytes each).

[0044] Return to reference Figure 1 , the volatile memory 118 also stores a cache 122 for the storage device 102. The cache 122 includes entries showing a mapping of a logical address specified for data requested by the host 104 to a physical address in the NVM 110, which indicates 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 a write command for the data 119, the controller checks the cache 122 for the logical to physical mapping of each data. If the mapping does not exist (for example, this is the first request for the data), the controller may check whether the mapping exists in the HMB 105 (for example, whether the HMB is used as an address mapping cache by the storage device 102). If the mapping does not exist in the HMB 105 or the HMB 105 is not used by the storage device 102, the controller accesses the L2P mapping table 120 in the NVM 110, 201 and stores the mapping in the cache 122. When the controller 123 executes a read command or a write command, the controller accesses the mapping from the cache and reads or writes data from or to the NVM 110 at the specified physical address. The cache may be stored in the form of a table or other data structure that includes a logical address associated with each NVM memory location 112 in the NVM where data is being read.

[0045] The NVM 110 includes a sense amplifier 124 and a data latch 126 connected to each NVM memory location 112. For example, the NVM memory location 112 may be a block including cells 116 on a plurality of bit lines, and the NVM 110 may include a sense amplifier 124 on each bit line. In addition, one or more data latches 126 may be connected to the bit lines and / or the sense amplifiers. The data latch may be, for example, a shift register. When data is read from a cell 116 of the NVM memory location 112, the sense amplifier 124 senses the data by amplifying the voltage on the bit line to a logic level (e.g., readable as "0" or "1"), and the sensed data is stored in the data latch 126. The data is then passed from the data latch 126 to the controller 123, after which the data is stored in the volatile memory 118 until it is passed to the host device 104. When data is written to cell 116 of NVM memory location 112 , controller 123 stores the program data in data latches 126 and subsequently transfers the data from data latches 126 to cell 116 .

[0046] The storage device 102 includes a controller 123, which includes circuits such as one or more processors for executing instructions, and may include a microcontroller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a system on a chip (SoC), a field programmable gate array (FPGA), hardwired logic, analog circuits, and / or combinations thereof.

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

[0048] The controller 123 and its components may be implemented using embedded software that performs the various functions of the controller described throughout this disclosure. Alternatively, software for implementing each of the aforementioned functions and components may be stored in NVM 110 or in a memory external to 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 in the controller 123, or may be implemented using a combination of the aforementioned hardware and software.

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

[0050] The host 104 can retrieve data from the storage device 102 by sending a read command that specifies one or more logical addresses associated with the data to be retrieved from the storage device 102 and the length of the data to be read. The interface 106 receives the read command, and the controller 123 accesses the cache 122, the L2P map in the HMB 105, or otherwise accesses the NVM to convert the logical address specified in the read command to a physical address indicating the location of the data. The controller 123 then reads the requested data from the NVM memory location 112 specified by the physical address by sensing the data using the sense amplifier 124 and storing the data in the data latch 126 until the read data is returned to the host 104 via the host interface 106.

[0051] If HMB 105 is used as an address mapping cache by storage device 102, controller 123 may store an Mset (e.g., Mset 203) or an L2P mapping entry (e.g., entry 206) in HMB 105. In order to access the L2P mapping when executing a host command such as a read command that includes data associated with the L2P mapping in HMB 105, controller 123 transmits an HMB read request to host 104 via host interface 106, and host 104 then passes the L2P mapping to volatile memory 118 (e.g., to an HMB read buffer in cache 122 or elsewhere in volatile memory 118), also via host interface 106. Once the L2P mapping is stored in the HMB read buffer, controller 123 may retrieve the L2P mapping from volatile memory 118 and complete execution of the host command. For example, the controller may pass the physical address indicated in the L2P map to a physical sequencer (not shown) in the storage device 102, which activates the sense amplifiers 124 and / or latches 126 to read or write data to the NVM 110, 201 as previously described.

[0052] Figure 3 The example uses the HMB 304 of the host 306 to store L2P address translation data. Figure 1An example 300 of a controller 302 (e.g., an ASIC or SoC) in a storage device 102 of FIG. 304. For example, an HMB 304 may include one or more Msets 308 (e.g., Mset 203) that include a plurality of L2P mapping entries associated with a sequence of logical addresses. In the illustrated example, the HMB 304 may include two Msets 0 and 1 that each include different ranges of LBAs, such as entry 206 for LBAs 0 to 8191 in Mset 0 and entry 206 for LBAs 40960 to 49151 in Mset 1, but in other examples there may be more or fewer Msets that each include different LBAs or amounts of LBAs. In response to receiving a command 310 from the host 306, such as a read command including a logical address in one of the Msets 308 (and failing to locate an associated L2P mapping entry for the command in the cache), the controller 302 determines a quantity (1 to M) of HMB read requests 312 to be transmitted to the host 306 to obtain the L2P mapping entry associated with the command 310 from the HMB 304. The quantity depends on the size of the L2P address translation data that may be transmitted from the host 306 via an interface (e.g., via DDR) to a memory slot 314 within an HMB read buffer 316 in a volatile memory (e.g., SRAM) of the storage device (e.g., via an HMB read / write driver controlled by the controller 302) in response to a single HMB read request. In turn, the size of the L2P address translation data that may be transferred from the HMB 304 to the memory slot 314 in response to a single HMB read request (the HMB transfer size) is based on the SRAM limitation in the storage device 102, i.e., the fixed allocated size of the memory slot 314 in the HMB read buffer 316. For example, if the allocated memory slot size is 128 bytes, the HMB transfer size associated with a single HMB read request may similarly be limited to 128 bytes.

[0053] For host commands associated with relatively small amounts of data (e.g., 128 KB or less), this fixed HMB transfer size may be sufficient to allow controller 302 to transmit a single HMB read request for the entire L2P address translation data associated with command 310. For example, if each L2P map entry occupies 4 bytes of memory and an HMB transfer size of 128 bytes of L2P map entries is transmitted to memory slot 314, the L2P address translation data received in response to a single HMB read request may cover the translation of the entire 128 kB of host data associated with the command. Figure 3In the example of , if command 310 includes a host data length of 128kB, the controller 302 may transmit only one HMB request (e.g., M=1) and one 128-byte transfer of HMB data (M=1) may be stored in one of the memory slots 314 of the HMB read buffer 316. However, for host commands associated with relatively large amounts of data (e.g., greater than 128KB, such as 1MB), this fixed HMB transfer size may no longer be sufficient to retrieve the entire L2P address translation data associated with command 310. For example, if each L2P mapping entry occupies 4 bytes of memory as previously described and the HMB transfer size is 128 bytes (such that one HMB read request covers the translation of 128kB of host data), eight HMB read requests may be required to obtain the entire L2P address translation data associated with command 310 (e.g., 128KB per HMB read request*8 HMB read requests=1MB). Therefore, in Figure 3 In the example of , if the command 310 includes a host data length of 1MB, the controller 302 may transmit eight HMB requests (e.g., M=8) and eight 128-byte transfers of HMB data (M=8) may be stored in eight memory slots in the memory slots 314 of the HMB read buffer 316, respectively.

[0054] In either example, after the L2P address translation data (e.g., L2P mapping entries) for command 310 is received and stored in HMB read buffer 316, controller 302 may extract these entries and continue to execute command 310. However, as a result of executing only a single HMB read request and HMB data transfer, the waiting time for completion of a host command associated with a relatively small amount of data (e.g., 128KB) may be small, but as a result of executing several HMB read requests and HMB data transfers, the waiting time for completion of a host command associated with a relatively large amount of data (e.g., 1MB) may be large. Therefore, a larger host command may result in reduced system performance compared to a smaller host command. Additionally, due to the waiting time involved in completing several HMB read requests and HMB data transfers for a large read command, the physical sequence (PS) layer of controller 302 may not apply a read cache command because an insufficient number of such large read commands may be filled in the memory die being read. For example, for a memory die in the back end of controller 302, large read commands may not be stored in the read cache quickly enough to accommodate the advance reads for that die, potentially resulting in too few commands being cached at read time and, therefore, resulting in such large commands being executed outside of the read cache in a less time-efficient manner.

[0055] Figure 4An example 400 of an HMB read buffer 402 in a volatile memory (e.g., an HMB read buffer 316 in an SRAM of a storage device 102) is illustrated, the HMB read buffer including a plurality of memory slots 404 (1 to N) for storing L2P address translation data obtained from an HMB. The controller 123, 302 may allocate a fixed size 406 (L bytes) to each of the memory slots 404, the size being based on achieving a balance between address translation throughput and HMB transfer latency. For example, the controller may allocate each memory slot to have L=128 bytes, because 128 bytes may provide a balance between the number of L2P address translations obtained in an HMB read request and the number of HMB read requests required to obtain the L2P address translations. For example, for smaller host commands (e.g., 4KB commands), a value of L that is too large may result in a large number of irrelevant L2P mapping entries being fetched from the HMB and thus reducing the bandwidth or throughput available for reads and writes, while for larger commands (e.g., 256KB commands), a value of L that is too small may result in a large number of HMB read requests being transmitted to obtain the L2P mapping entries associated with the command and thus resulting in increased latency for performing reads and writes. Thus, a memory slot size of L=128 bytes may provide a middle ground between these two competing considerations, but it should be understood that the memory slot size L is not limited to 128 bytes and may be allocated different sizes (e.g., L=256 bytes, L=64 bytes, etc.) depending on the degree of balance (e.g., between throughput and latency) desired by the controller.

[0056] In order to obtain the L2P mapping entry for the read command from the HMB, the controller may search for the free (unused) memory slots in the HMB read buffer 402 in fixed units of these L bytes. Once the controller finds the free slot, the controller provides the memory address of the memory slot 404 to the host 104, 306 in the HMB read request (e.g., HMB read request 312) associated with the HMB transfer size of similar L bytes. After extracting HMB data (e.g., L bytes of L2P mapping entries are loaded into the memory slot and submitted to the PS for execution) in response to the HMB read request, the controller may release the memory slot for future use. Therefore, in order to execute a 1MB read command, the controller may provide the memory addresses of eight corresponding free memory slots of the HMB read buffer to the host in eight corresponding HMB read requests, and wait until the L2P mapping entries are loaded into the eight memory slots respectively before completing the execution of the read command. The memory slots may be non-continuous as long as they are free (unused). Since the slot size and HMB transfer size are fixed to L bytes regardless of the size of the read command, large read commands such as 1MB read commands can result in significant HMB transfer latency and thus reduce system performance. More generally, large commands that result in increased HMB transfer latency can refer to commands that include a host data length that is larger than the amount of L2P address translation data in the L-byte memory slot that can be transferred to the HMB read buffer. For example, if L=128 bytes, each L2P mapping entry occupies 4 bytes of memory, and therefore the amount of L2P address translation data that can be accommodated in the 128-byte memory slot covers 128kB of host data, in which example, large read commands that result in increased HMB transfer latency can refer to read commands (sequential or random) that include a host data length greater than 128kB, because such commands will require more HMB read requests than commands of 128kB or less. Therefore, it would be helpful to improve read performance by reducing the HMB transfer latency of such large commands.

[0057] Therefore, in order to improve the read performance of large commands, the controller 123, 302 of the storage device 102 can apply a dynamic HMB transfer size to its HMB read request based on the size of the host command or based on the number of free and continuous memory slots in the HMB read buffer, rather than applying a static HMB transfer size based on the memory slot size as previously described. In one example, in response to receiving a host command, the controller can determine the associated host data length (command size), and determine the number of continuous memory slots that will be needed in the HMB read buffer to accommodate the command size. For example, if the controller receives a 1MB read command and the length of each memory slot of the HMB read buffer is 128 bytes, the controller can determine that eight continuous memory slots can accommodate 1KB of L2P address conversion data for the 1MB read command. The controller can then search the memory space allocated to the HMB read buffer to find the required amount of free and continuous memory slots (e.g., eight in this example). If the controller locates the number of slots, the controller can send a single HMB read request to the host to extract the L2P address conversion data for the associated host command into the memory slot. For example, in the case of a 1MB read command, if the controller locates eight free and consecutive memory slots (each memory slot spanning 128 bytes) in the HMB read buffer, the controller may transmit a single HMB read request indicating the memory address of the initial memory slot and indicating an HMB transfer size of 1KB, and in response to the single HMB read request, 1KB of L2P address translation data may be transferred and loaded into the memory slot accordingly. Therefore, unlike the previously described static approach in which the controller may send 8 HMB read requests with a 128-byte HMB transfer size to satisfy a 1MB host command and in which the HMB data is stored in any free slot (whether consecutive or non-consecutive), a dynamic approach is used here in which the controller may more efficiently send 1 HMB read request with a 1KB HMB transfer size and the HMB data may be stored in free, consecutive or consecutive slots (starting with the memory address indicated in the HMB read request). Therefore, a reduced HMB transfer latency for large commands may be achieved.

[0058] Figure 5An example 500 of an HMB read buffer 502 (HMB read buffers 502a, 502b, 502c, e.g., HMB read buffers 316, 402) including HMB data obtained from an HMB using an HMB read request associated with a dynamic HMB transfer size after receiving and executing different host commands is illustrated. In the illustrated example, the controller 123, 302 receives a command 504 (e.g., command 504 is a 128kB command) including LBA X with a host data length of 128kB. In response to receiving command 504, the controller may determine that a 128-byte memory slot will be sufficient to accommodate the HMB data for the 128kB command, and therefore the controller may search the HMB read buffer to find a free slot. After locating free slot 0, the controller may allocate the slot for command 504, and the controller may send an HMB read request for the associated 128 bytes of L2P address translation data to be loaded into slot 0. Therefore, in HMB read buffer 502a, slot 0 can store HMB data for LBA X after HMB data transfer. Next, the controller receives command 506 including LBAY with a host data length of 256kB (e.g., command 506 is a 256kB command). In response to receiving command 506, the controller can determine that two 128-byte memory slots will be sufficient to accommodate HMB data for the 256kB command, and therefore the controller can search the HMB read buffer to find two consecutive and free slots. After locating free slots 1 and 2, the controller can allocate these slots for command 506, and the controller can send an HMB read request for the associated 256 bytes of L2P address translation data to be loaded into slots 1 and 2. Therefore, in HMB read buffer 502b, slots 1 and 2 can store HMB data for LBA Y after HMB data transfer. Once the controller begins executing command 504 including LBA X (e.g., the translation of LBA X is complete and the translated physical address is passed to the PS to issue a NAND read), the controller may release slot 0 of its HMB data for future use. Thus, in HMB read buffer 502c, slot 0 may be freed from the HMB data of LBA X after initiation of command execution.

[0059] Figure 6An example 600 of an HMB read buffer 602 (e.g., HMB read buffer 316, 402, 502) including HMB data obtained from HMB using HMB read requests associated with dynamic HMB transfer sizes after receiving and executing different host commands is illustrated. In the illustrated example, the controller 123, 302 receives a command 604 (e.g., command 604 is a 256kB command) including LBA V with a host data length of 256kB. In response to receiving command 604, the controller may determine that two memory slots will be sufficient to accommodate HMB data for the 256kB command, and therefore the controller may search the HMB read buffer to find two consecutive and free slots. In this example, during the search, the controller may determine that slots 0 and 1 are used for other HMB data use for other commands, slot 2 is free, and slot 3 is used for other HMB data use for another (or the same) command. Since slot 2 is only one slot and can only store a portion of the L2P address translation data associated with the 256kB command (e.g., 128kB of address translations in 256KB of host data), the controller continues its search for the required number of slots (two in this example). In response to continuing its search in this example, the controller may determine that slots 4 and 5 are free. Therefore, after locating free slots 4 and 5, the controller may allocate these slots for command 604, and the controller may send an HMB read request for the associated 256 bytes of L2P address translation data to be loaded into slots 4 and 5. Therefore, in contrast to statically storing L2P address translation data across non-contiguous slots based on a fixed memory slot size, HMB data may be dynamically stored in contiguous slots of the HMB read buffer based on the command size and the number of available contiguous memory slots, thereby reducing HMB transfer latency. For example, instead of statically providing two HMB transfer requests with corresponding slot addresses for a 256kB command and storing the received HMB data in free slots associated with the corresponding slot addresses as previously described, the controller here may dynamically provide one HMB transfer request with one slot address for a 256kB command and store the received HMB data in consecutive free slots starting from the indicated slot address, thereby improving read performance.

[0060] Figure 7An example 700 is illustrated of an HMB read buffer 702 (e.g., HMB read buffers 316, 402, 502) that includes HMB data obtained from an HMB using an HMB read request associated with a dynamic HMB transfer size after receiving and executing different host commands. In the illustrated example, the controller 123, 302 receives an LBA U command 704 (e.g., command 704 is a 256kB command) having a host data length of 256kB. In response to receiving command 704, the controller may determine that two memory slots will be sufficient to accommodate the HMB data for the 256kB command, and therefore the controller may search the HMB read buffer to find two consecutive and free slots. In this example, during the search, the controller may determine that slots 0 and 1 are being used for other HMB data use for other commands, slot 2 is free, and slot 3 is being used for other HMB data use for another (or the same) command, similar to Figure 6 Example 600. Since slot 2 is only one slot and can only store a portion of the L2P address translation data associated with the 256kB command (e.g., 128kB of address translations out of 256KB of host data), the controller continues its search for the required number of slots (two in this example), also similar to Figure 6 Example 600. However, with Figure 6 Unlike example 600, here in response to continuing its search in this example, the controller may determine that slot 4 and slot 5 are used for other HMB data of other commands. In addition, the controller may determine from its search that there are no other free continuous slot pairs in HMB read buffer 702, but there is a single free and separate non-contiguous slot in the HMB read buffer, such as slot 2. Therefore, the controller may ultimately allocate slot 2 and another separate non-contiguous slot (e.g., slot N) for command 704, and the controller may ultimately send two 128-byte HMB read requests for the associated 256 bytes of L2P address translation data to be loaded into separate slots, respectively.

[0061] Therefore, for the same command size, the controller can end up with Figure 7 In example 700, the sending ratio Figure 6 The controller can operate in this manner because even though the command size in both examples is 256 kB and the associated L2P address translation data can therefore be stored in two free and consecutive memory slots of the HMB read buffer in both examples, the minimum number of actually free and consecutive slots in the HMB read buffer is Figure 7 In the example 700 is less than Figure 6 In example 600 (ie, with Figure 6 Two of the examples 600, Figure 7700 is one). Therefore, the HMB transfer size for a given HMB read request can be considered to be equal to the minimum between: the total size of the number of memory slots required to store the entire L2P address translation data for the host command, and the total size of the number of free continuous memory slots in the HMB read buffer that can be used to store the L2P address translation data for the host command. An example showing how this minimum consideration can result in a different number of HMB read requests for the same read command size is depicted below in Table 1:

[0062]

[0063] Table 1

[0064] In addition to dynamically basing the HMB transfer size for a given HMB read request on the command size of a single current host command being processed (e.g., executed), the controller may also dynamically basing the HMB transfer size on the combined command size of multiple host commands. For example, if the controller receives a sequential read command from the host, the controller may obtain associated L2P address conversion data for the multiple sequential read commands (e.g., the current command for execution and the subsequent command for execution) in response to a single HMB read request. As an example, when the controller 123, 302 uses the aforementioned dynamic approach to determine the amount of HMB read requests required to execute a read command including LBAs 0 to 500 (covering 256kB of host data), the controller may check the LBAs associated with one or more subsequent read commands and determine whether those commands include LBAs that are in sequential order relative to the current read command. For example, the controller may determine that subsequent read commands include LBAs 501 to 1000 (also covering 256kB of host data), which are sequential relative to LBAs 0 to 500 in the current read command. In this case, the controller may determine to base its requested HMB transfer size on the total command size of the two commands (e.g., 512kB for the two commands in this case), and therefore search the HMB read buffer for free and contiguous memory slots (e.g., four 128-byte slots in this case) that can accommodate the L2P address translation data of the two commands. If the search for four contiguous and free slots is successful, the controller may send a single HMB read request for 512 bytes of HMB data to be stored in the four slots (e.g., the first 256 bytes of address translation data covering 256kB in the first two slots and the second 256 bytes of address translation data covering 256kB in the second two slots).

[0065] On the other hand, if the search is unsuccessful (e.g., in this example, the controller locates only three consecutive and free slots), then as a result of the above minimum considerations, the controller may send one HMB read request for 384 bytes of HMB data to be stored in three consecutive slots (e.g., 256 bytes of address translation data covering 256kB in the first two slots and 128 bytes of address translation data covering 128kB in the third slot), and another HMB read request for the remaining 128 bytes of HMB data to be stored in another non-consecutive slot (e.g., 128 bytes of address translation data covering 128kB in the fourth slot). Therefore, even for multiple commands, fewer HMB read requests may be transmitted using the dynamic HMB transfer size approach than using the static HMB transfer size approach. For example, if a static approach based on a fixed memory slot size was used, four HMB read requests would be required (e.g., 4*128 bytes = 512 bytes), whereas a dynamic approach (based on the minimum between the required number of contiguous and free memory slots to accommodate the command size and the actual number of contiguous and free memory slots in the HMB read buffer) results in only two HMB read requests being sent.

[0066] Figure 8 1 illustrates utilizing an HMB 804 (e.g., HMB 105, 304) of a host 806 (e.g., host 104, 306) to store L2P address translation data 808 (e.g., one or more Msets 203, 308 including a plurality of L2P mapping entries associated with a sequence of logical addresses (such as entry 206 including logical address 208 and physical address 210)) for different commands. Figure 1800 of a controller 802 (e.g., controller 123, 302) in a storage device 102. In one example, the controller 802 may receive a command 810 from a host 806, such as a read command including LBA Z and a given host length (e.g., 256 kB), and the controller 802 dynamically determines an amount of HMB read requests 812 to be transmitted to the host 806 to obtain a portion 813 of L2P address translation data 808 associated with the command 810 (e.g., a specific L2P mapping entry within one or more Msets 203, 308 associated with the command 810 including LBA Z). Specifically, the controller 802 may search for two free and consecutive 128-byte slots in the memory slots 814 within the HMB read buffer 816 to accommodate the 256 kB host command, and after determining that two consecutive slots 4 and 5 are free, the controller 802 may transmit one HMB read request including an HMB transfer size of 256 bytes to obtain the portion 813 of the associated L2P address translation data. In response to HMB read request 812, host 806 may transmit portion 813 to controller 802, which may control the HMB read / write driver to load portion 813 of L2P address translation data 808 into memory slots 4 and 5. During execution of command 810, controller 802 may extract portion 813 of L2P address translation data 808 from HMB read buffer 816 to identify the physical address associated with LBA Z, the controller may free memory slots 4 and 5 for later use, and the controller may read the data at the identified physical address.

[0067] In another example, the controller 802 may receive multiple commands 810 from the host 806, such as a first read command including LBA Z and a given host data length (e.g., 256 kB) and a second read command including LBA W and an associated host data length (e.g., 256 kB). The controller may determine whether the commands 810 are sequential (e.g., the first read command includes LBAZ=0 to 250 and the second read command includes LBA W=251 to 500). If the commands are not sequential, the controller 802 dynamically determines the number of HMB read requests 812 for these commands on a separate basis as previously described. However, if the commands are sequential, the controller 802 may consider both commands when dynamically determining the number of HMB read requests 812 to be transmitted to the host 806. For example, when executing one of the commands 810, the controller 802 may request to obtain a portion 813 of the L2P address translation data 808 associated with the combination of the commands 810 (e.g., a specific L2P mapping entry within one or more Msets 203, 308 associated with a first read command including LBA Z and a second read command including LBA W). Specifically, the controller 802 may search for free and consecutive four 128-byte slots in the memory slots 814 within the HMB read buffer 816 to accommodate two combined 256kB host commands (effectively, 512kB sequential commands), and after determining that the four consecutive slots 4 to 7 are free, the controller 802 may transmit an HMB read request including an HMB transfer size of 512 bytes to obtain the portion 813 of the associated L2P address translation data. In response to the HMB read request 812, the host 806 may transmit the portion 813 to the controller 802, which may control the HMB read / write driver to load the portion 813 of the L2P address translation data 808 into the memory slots 4 to 7. During execution of the first read command, controller 802 may extract portion 813 of L2P address translation data 808 from HMB read buffer 816 to identify the physical address associated with LBA Z, the controller may free memory slots 4 to 7 for later use, and the controller may read the data at the identified physical address. During execution of the second read command, controller 802 may identify the physical address associated with LBA W in the previously extracted portion 813 without sending another HMB read request, and the controller may also read the data at the identified physical address.

[0068] exist Figure 8In the illustrated example 800 of , the HMB read buffer 816 is shown as being internal to the controller 802. For example, the storage device 102 may be a DRAM-less device, in which case the HMB read buffer 816 may be allocated within an SRAM internal to the ASIC or SoC that controls the storage device 102 (e.g., the volatile memory 118 including the HMB read buffer 816 may be within the controller 123, 302, 802). In other examples, the HMB read buffer 816 may be external to the controller 802. For example, the storage device 102 may include DRAM (albeit with a lower memory capacity) located external to the ASIC or SoC that controls the storage device 102, in which case the HMB read buffer 816 may be allocated within the DRAM (e.g., the volatile memory 118 including the HMB read buffer 816 may be external to the controller 123, 302, 802). Regardless of whether the storage device 102 is a DRAM-less device or a low-DRAM device, the controller 802 can be configured to dynamically determine the HMB transfer size as described throughout the present disclosure and transmit the HMB read request accordingly, because regardless of whether the HMB read buffer is contained in SRAM or DRAM, the HMB transfer latency is reduced and thus the command execution performance can be similarly improved. However, since HMB can provide a higher memory capacity gain in a DRAM-less device, the performance gain of a DRAM-less device can be higher than the performance gain of a storage device including a low-capacity DRAM.

[0069] Fig. 9 An exemplary flowchart 900 is illustrated of a method for requesting L2P address translation data from an HMB using a dynamically determined HMB transfer size. For example, the method may be performed on a storage device 102 (such as Figure 1 Optional aspects are shown in dashed lines. Each of the steps in the flowchart may be controlled using a controller (e.g., controller 123, 302, 802) as described below, by a component or module of the controller, or by some other suitable component.

[0070] As represented by box 902, the controller may allocate multiple memory locations in a volatile memory for L2P address translation data from the HMB. In one example, the volatile memory may be inside the controller. In another example, the volatile memory may be outside the controller. For example, with reference to the accompanying drawings, the controller 123, 302, 802 may allocate memory slots 314, 404, 814 of a fixed size 406 (e.g., L bytes) in the HMB read buffer 316, 402, 502, 602, 702 in the volatile memory 118 for storing L2P address translation data 808 obtained from the HMB 105, 304, 804 (e.g., entries 206 of the L2P mapping tables 120, 205 in one or more Msets 203, 308). In one example, the volatile memory 118 may be internal to the controller 123, 302, 802 (e.g., SRAM internal to the ASIC or SoC that controls the storage device 102), while in another example, the volatile memory 118 may be external to the controller 123, 302, 802 (e.g., DRAM external to the ASIC or SoC that controls the storage device 102).

[0071] As represented by block 904, the controller may receive one or more commands indicating respective host data lengths. For example, referring to the figures, the controller 123, 302, 802 may receive a command 310, 504, 506, 604, 704, 810 (e.g., a host read command or a host write command) indicating a plurality of logical addresses (e.g., logical addresses 208, such as LBAX, Y, V, U, or Z) and associated host data lengths (e.g., length 212). In addition, the controller 123, 302, 802 may receive a plurality of such commands 810 including respective host data lengths, such as a first read command including LBA Z and a second read command including LBA W, such as Figure 8 as shown in the example.

[0072] As represented by block 906, the controller may transmit a request for a portion of the L2P address translation data stored in the HMB, the portion of the L2P address translation data being used for the one or more commands. For example, with reference to the accompanying drawings, the controller 123, 302, 802 may transmit an HMB read request 312, 812 for a portion 813 of the L2P address translation data 808 associated with a command 310, 504, 506, 604, 704, 810 received from the host to the host 104, 306, 806. In one example, the size of the L2P address translation data associated with the request (HMB transfer size) is based on the host data length indicated accordingly in the command. For example, referring to the accompanying drawings, in order to obtain a portion 813 of the L2P address translation data 808 from the HMB 105, 304, 804, the controller 123, 302, 802 may transmit an HMB read request 312, 812 including an HMB transfer size dynamically determined from a host data length (e.g., length 212) associated with the logical address 208 indicated in the command 310, 504, 506, 604, 704, 810. As an example, if the amount of memory occupied by portion 813 of L2P address translation data 808 for command 310, 504, 506, 604, 704, 810 is not greater than the fixed size 406 of the memory slot (e.g., if the memory slot size of the HMB read buffer is 128 bytes and no more than 128 bytes in the 4kB L2P mapping entry are required to accommodate a 128kB command size or host data length), the controller may transmit a single HMB read request covering the entire L2P address translation data for the command.

[0073] In another example, the size of the L2P address translation data (HMB transfer size) associated with the request transmitted at block 906 may be based on the number of free and contiguous memory locations at the time of the request. For example, with reference to the accompanying drawings, in order to obtain a portion 813 of the L2P address translation data 808 from the HMB 105, 304, 804, the controller 123, 302, 802 may transmit an HMB read request 312, 812 including an HMB transfer size determined dynamically from the number of memory slots 314, 404, 814 that are not used by other HMB data and are adjacent to each other in the HMB read buffer 316, 402, 502, 602, 702 at the time of the HMB read request. As an example, the controller may limit the HMB transfer size associated with a single HMB read request to the maximum total size of the memory slots 314, 404, 814 that are free and contiguous at the time of the request (e.g., the sum of their fixed sizes 406). Thus, if up to eight 128-byte, free, and contiguous memory slots are available for HMB data in the HMB read buffer, the controller can transmit a single HMB read request for up to 1kB in a 4kB L2P mapping entry; if up to four 128-byte, free, and contiguous memory slots are available in the HMB read buffer, the controller can transmit a single HMB read request for up to 512 bytes in a 4kB L2P mapping entry; and if up to two 128-byte, free, and contiguous memory slots are available in the HMB read buffer, the controller can transmit a single HMB read request for up to 256 bytes in a 4kB L2P mapping entry.

[0074] In another example, the size of the L2P address translation data associated with the request may be based on the minimum of the size of a portion of the L2P address translation data for the command and the total size of the number of free and contiguous memory locations at the time of the request. For example, with reference to the above figures and Table 1, in order to obtain a portion 813 of the L2P address translation data 808 from the HMB 105, 304, 804, the controller 123, 302, 802 may transmit an HMB read request 312, 812 including an HMB transfer size dynamically determined from the host data length (e.g., length 212) associated with the logical address 208 indicated in the command 310, 504, 506, 604, 704, 810 and the number of memory slots 314, 404, 814 in the HMB read buffer 316, 402, 502, 602, 702 that are not used by other HMB data and are adjacent to each other. As an example, the controller 123, 302, 802 may determine the amount of memory in the HMB 105, 304, 804 occupied by the portion 813 of the L2P address translation data 808 for the command 310, 504, 506, 604, 704, 810, compare that value to the maximum total size of the memory slots 314, 404, 814 that will be free and contiguous at the time of the HMB read request (e.g., the sum of their fixed sizes 406), and the controller may set the HMB transfer size to the minimum of the two values. Thus, if the amount of memory occupied by portion 813 of L2P address translation data 808 for command 310, 504, 506, 604, 704, 810 is 1kB (e.g., the command is a 1MB command), and if at most eight 128-byte, free, and contiguous memory slots (totaling 1kB in size) are available in the HMB read buffer for HMB data, then the minimum value between 1kB and 1kB is 1kB, and therefore the controller can transmit a single HMB read request for the entire 1kB in the 4kB L2P mapping entry associated with the 1MB command. On the other hand, if up to four 128-byte, free and contiguous memory slots (totaling 512 bytes in size) are available in the HMB read buffer, the minimum value between 1kB and 512 bytes is 512 bytes, and therefore the controller may transmit one HMB read request for 512 bytes in the 4kB L2P mapping entry associated with the 1MB command and another HMB read request for the remaining 512 bytes in the 4kB L2P mapping entry associated with the 1MB command.

[0075] In one example, the controller may transmit the request based on the size of a portion of the L2P address translation data for the command being greater than the size of a corresponding one of the memory locations at block 906. For example, referring to the drawings, before requesting to obtain a portion 813 of the L2P address translation data 808 from the HMB 314, 404, 814, the controller 123, 302, 802 may initially determine whether to apply a static HMB transfer size or a dynamic HMB transfer size based on the fixed size 406 of the memory slot 105, 304, 804. As an example, if the controller determines that the amount of memory occupied by the portion 813 of the L2P address translation data 808 for the command 310, 504, 506, 604, 704, 810 is greater than the fixed size 406 of the memory slot (e.g., if the memory slot size of the HMB read buffer is 128 bytes and more than 128 bytes in the 4kB L2P mapping entry are required to accommodate the command size or host data length), the controller may determine that sending multiple HMB read requests each having a static HMB transfer size may cause increased HMB transfer latency. Therefore, the controller may dynamically determine the HMB transfer size to minimize the HMB transfer latency as previously described. For example, the controller may dynamically determine the HMB transfer size associated with a single HMB read request from the host data length (e.g., length 212) associated with the logical address 208 indicated in the command 310, 504, 506, 604, 704, 810 and / or the number of memory slots 314, 404, 814 in the HMB read buffer 316, 402, 502, 602, 702 that are not used by other HMB data and are adjacent to each other at the time of the HMB read request.

[0076] In one example, the controller may receive multiple commands at block 904 (e.g., a first command indicating a first host data length and a second command indicating a second host data length). In this case, a portion of the L2P address translation data indicated in the request transmitted at block 906 may be for the first command and the second command, and the size of the L2P address translation data associated with the request (HMB transfer size) may be based on the first host data length and the second host data length. For example, referring to Figure 8, the controller 802 may receive multiple commands 810 from the host 806, such as a first read command including LBA Z and a given host data length (e.g., 256 kB) and a second read command including LBA W and an associated host data length (e.g., 256 kB). If the commands are sequential, the controller 123, 302, 802 may transmit to the host 104, 306, 806 an HMB read request 312, 812 for a portion 813 of the L2P address translation data 808 associated with the combination of commands 810 received from the host. For example, to obtain portion 813 of L2P address translation data 808 from HMB 105, 304, 804, the controller may dynamically determine the HMB transfer size associated with a single HMB read request from the host data length (e.g., length 212) associated with the logical address 208 indicated in the plurality of commands 810 and the number of memory slots 314, 404, 814 in the HMB read buffer 316, 402, 502, 602, 702 that are not used by other HMB data and are adjacent to each other at the time of the HMB read request.

[0077] In one example, as represented by block 908, the controller may search for a plurality of contiguous memory locations in the volatile memory to store the portion of the L2P address translation data. If the controller successfully locates the plurality of contiguous memory locations during the search, the controller may transmit a request in response to locating the plurality of contiguous memory locations, as represented by block 910. Thereafter, as represented by block 912, the controller may receive the portion of the L2P address translation data in response to the request, and as represented by block 914, the controller may store the portion of the L2P address translation data in the plurality of contiguous memory locations. For example, referring to Figure 8 , the controller 802 may search for free and consecutive four 128-byte slots in the memory slots 814 within the HMB read buffer 816 to accommodate two combined 256kB host commands (effectively, 512kB sequential commands), and after successfully locating four free and consecutive slots 4 to 7, the controller 802 may transmit an HMB read request including an HMB transfer size of 512 bytes to obtain a portion 813 of the associated L2P address translation data. In response to the HMB read request 812, the host 806 may transmit the portion 813 to the controller 802, which may control the HMB read / write driver to load the portion 813 of the L2P address translation data 808 into the memory slots 4 to 7.

[0078] Otherwise, if the controller fails to locate multiple consecutive memory locations during the search, the controller may transmit multiple requests for the portion of the L2P address translation data, as represented by block 916. Thereafter, the controller may receive portions of the L2P address translation data in response to the multiple requests, as represented by block 918, and may store the portions of the L2P address translation data in non-consecutive memory locations, as represented by block 920. For example, referring to Figure 8 As previously described, the controller 802 may search for free and consecutive four 128-byte slots in the memory slots 814 within the HMB read buffer 816 to accommodate two combined 256 kB host commands (effectively, 512 kB consecutive commands). If the search is unsuccessful (e.g., the controller fails to locate four free and consecutive slots 4 to 7, such as locating only three consecutive and free slots 4 to 6 in this example), the controller may send one HMB read request for 384 bytes of HMB data (a portion of portion 813) to be stored in memory slots 4 to 6 (e.g., 256 bytes of address translation data covering 256 kB in the first two slots and 128 bytes of address translation data covering 128 kB in the third slot), and another HMB read request for the remaining 128 bytes of HMB data (the remainder of portion 813) to be stored in another slot that is non-contiguous with respect to memory slots 4 to 6 (e.g., 128 bytes of address translation data covering 128 kB in the fourth slot). For example, the fourth slot may be memory slot 2, memory slot 8, or another slot that is discontinuous with memory slots 4 to 6 (i.e., a slot different from memory slots 3 or 7). In response to a first HMB read request for 384 bytes of HMB data (a portion of portion 813), the host 806 may transfer the portion of portion 813 to the controller 802, which may control the HMB read / write driver to load the portion of portion 813 of the L2P address translation data 808 into three consecutive and free memory slots. In response to a second HMB read request for 128 bytes of HMB data (the remainder of portion 813), the host 806 may transfer the remainder of portion 813 to the controller 802, which may control the HMB read / write driver to load the remainder of portion 813 of the L2P address translation data 808 into the non-contiguous memory slots.

[0079] Finally, as represented by block 922, after storing the portion of the L2P address translation data at blocks 914 or 920, the controller may release the memory locations after the portion of the L2P address translation data is passed to the physical sequencer for command execution. Figure 8, after the host 806 transfers portion 813 (in one portion or multiple fragments) to the controller 802 (which may control the HMB read / write driver to load portion 813 of the L2P address translation data 808 into memory slots 4 to 7 (or memory slots 4 to 6 and a non-contiguous memory slot)), the controller may execute the associated command. For example, during execution of the command, the controller 802 may extract portion 813 of the L2P address translation data 808 from the HMB read buffer 816 to identify the physical address associated with the command, and pass the physical address to the physical sequencer to read data at the identified physical address. Thereafter, the controller may release memory slots 4 to 7 for later use.

[0080] Fig.10 1 is a conceptual diagram illustrating an example 1000 of a controller 1002 coupled to a memory 1004 in a storage device. For example, the controller 1002 may correspond to the controller 123, 302, 802, and the memory 1004 may correspond to Figure 1 The controller may be implemented in software, hardware, or a combination of hardware and software. In an exemplary embodiment, the controller is implemented using several software modules executed on one or more processors, but as will be appreciated by those skilled in the art, the controller may be implemented in different ways. A skilled person will readily appreciate how to best implement the controller based on the specific design parameters of the system.

[0081] In one example, the controller 1002 includes an allocation module 1006 that can provide a component for allocating multiple memory locations in the volatile memory for L2P address translation data from the HMB. For example, the allocation module 1006 can perform the above-mentioned Fig. 9 For example, the allocation module 1006 may allocate memory slots 314, 404, 814 of fixed size 406 (e.g., L bytes) within the HMB read buffers 316, 402, 502, 602, 702 in the volatile memory 118 for storing L2P address translation data 808 obtained from the HMB 105, 304, 804 (e.g., entries 206 of the L2P mapping tables 120, 205 in one or more Msets 203, 308).

[0082] In one example, the controller 1002 includes a command module 1008, which can provide a component for receiving a command indicating the length of the host data. For example, the command module 1008 can execute the above-mentioned Fig. 9For example, the command module 1008 may receive a command 310, 504, 506, 604, 704, 810 (e.g., a host read command or a host write command) indicating a plurality of logical addresses (e.g., logical addresses 208, such as LBA X, Y, V, U, or Z) and associated host data lengths (e.g., length 212). In addition, the command module 1008 may receive a plurality of such commands 810 including corresponding host data lengths, such as a first read command including LBA Z and a second read command including LBA W, such as Figure 8 exemplified in the example.

[0083] In one example, the controller 1002 includes a request module 1010 that can provide a means for transmitting a request for a portion of the L2P address translation data stored in the HMB, the portion of the L2P address translation data being used for the command. For example, the request module 1010 can execute the above-mentioned Fig. 9 For example, the request module 1010 may transmit to the host 104, 306, 806 an HMB read request 312, 812 for a portion 813 of the L2P address translation data 808 associated with a command 310, 504, 506, 604, 704, 810 received from the host.

[0084] Therefore, the controller of the storage device described throughout the present disclosure can use the dynamically determined HMB transfer size to request L2P address conversion data from HMB for the execution of associated host commands. Therefore, the read latency can be reduced, resulting in higher performance, and the controller efficiency (e.g., CPU cycle efficiency) can be increased. For example, the controller can apply a dynamic HMB transfer size for a single HMB read request based on the host data length of the associated host command and / or based on the number of available continuous memory locations in the HMB read buffer, rather than applying a static HMB transfer size based on the size of the memory slot in the HMB read buffer as previously described. Therefore, the controller can obtain the entire L2P address conversion data for the host command in response to a single HMB read request, thereby allowing the implementation of the reduced latency when obtaining the L2P address conversion associated with the command. In addition, even if the controller experiences a search cycle loss when there are fewer free continuous memory slots available in the HMB read buffer, since the controller can use a dynamic HMB transfer size approach instead of using the aforementioned static HMB transfer size to obtain the entire L2P address conversion data for the host command in response to fewer HMB read requests, performance can still be improved as a whole.

[0085] Various aspects of the present disclosure are provided to enable a person of ordinary skill in the art to practice the present invention. Various modifications to the exemplary embodiments presented throughout the present disclosure will be apparent to those skilled in the art, and the concepts disclosed herein can be extended to other storage devices. Therefore, the claims are not intended to be limited to various aspects of the present disclosure, but are intended to be given a full range consistent with the language of the claims. All structural equivalents and functional equivalents of various components of the exemplary embodiments described in the entire present disclosure known to or to be known by a person of ordinary skill in the art are expressly incorporated herein by reference, and are intended to be covered by the claims. In addition, whether or not this disclosure is explicitly stated in the claims, the contents disclosed herein are not intended to contribute to the general public. According to the sixth paragraph of 35 U.S.C. § 112 of the United States, or similar regulations or rule of law in another jurisdiction, no claim element will be interpreted unless the phrase "device for..." is used to explicitly state the element, or the phrase "step for..." is used to state the element in the case of a method claim.

Claims

1. A storage device, comprising: Volatile memory; and A controller, the controller being configured to: allocating a plurality of memory locations in the volatile memory for logical-to-physical (L2P) address translation data from a host memory buffer (HMB); Receive a command indicating the length of host data; as well as A request for a portion of the L2P address translation data stored in the HMB is transmitted, the portion of the L2P address translation data being used for the command, and a size of the L2P address translation data associated with the request being based on the host data length indicated in the command.

2. The storage device according to claim 1, wherein the controller is further configured to: receiving the portion of the L2P address translation data in response to the request; and The portion of the L2P address translation data is stored in one of the memory locations. 3 . The storage device of claim 2 , wherein the controller is further configured to release the one of the memory locations after the portion of the L2P address translation data is passed to a physical sequencer to execute the command.

4. The storage device according to claim 1, Wherein the size of the L2P address translation data associated with the request is further based on a number of free and contiguous memory locations at the time of the request.

5. The storage device according to claim 4, wherein the controller is further configured to: searching the volatile memory for a plurality of consecutive ones of the memory locations to store the portion of the L2P address translation data; and The request is transmitted in response to being located at the plurality of consecutive ones of the memory locations.

6. The storage device according to claim 5, wherein the controller is further configured to: receiving the portion of the L2P address translation data in response to the request; and The portion of the L2P address translation data is stored in the plurality of consecutive ones of the memory locations.

7. The storage device according to claim 4, wherein the controller is further configured to: searching the volatile memory for a plurality of consecutive ones of the memory locations to store the portion of the L2P address translation data; and In response to a failure to locate the plurality of consecutive ones of the memory locations, transmitting another request for another portion of the L2P address translation data.

8. The storage device according to claim 7, wherein the controller is further configured to: receiving the portion of the L2P address translation data in response to the request; and The further portion of the L2P address translation data is received in response to the further request.

9. The storage device of claim 4, wherein the size of the L2P address translation data associated with the request is further based on a minimum of: a size of the portion of the L2P address translation data for the command, and The total size of the number of the memory locations that are free and contiguous at the time of the request.

10. The storage device of claim 1 , wherein the controller is further configured to receive a second command indicating a second host data length, the portion of the L2P address translation data indicated in the request being used for the command and the second command, and the size of the L2P address translation data associated with the request being further based on the second host data length.

11. A storage device, comprising: Volatile memory; and A controller, the controller being configured to: allocating a plurality of memory locations in the volatile memory for storing logical to physical (L2P) address translation data from a host memory buffer (HMB); as well as A request is transmitted for a portion of the L2P address translation data stored in the HMB, the portion of the L2P address translation data being used for a host command, and a size of the L2P address translation data associated with the request is based on a number of free and contiguous memory locations at the time of the request.

12. The storage device according to claim 11, Wherein the host command indicates a host data length, and the size of the L2P address translation data associated with the request is further based on the host data length indicated in the host command.

13. The storage device according to claim 11, wherein the controller is further configured to: searching the volatile memory for a plurality of consecutive ones of the memory locations to store the portion of the L2P address translation data; transmitting the request in response to locating to the plurality of consecutive ones of the memory locations; as well as The portion of the L2P address translation data is received in response to the request.

14. The storage device according to claim 11, wherein the controller is further configured to: searching the volatile memory for a plurality of consecutive ones of the memory locations to store the portion of the L2P address translation data; and In response to failing to locate the plurality of consecutive ones of the memory locations: transmitting another request for another portion of the L2P address translation data; and The further portion of the L2P address translation data is received in response to the further request.

15. The storage device of claim 11, wherein the host command indicates a host data length, and a size of the L2P address translation data associated with the request is further based on a minimum of: a size of the portion of the L2P address translation data for the host command, and The total size of the number of the memory locations that are free and contiguous at the time of the request.

16. The storage device of claim 11 , wherein the controller is further configured to receive a second host command indicating a second host data length, the portion of the L2P address translation data indicated in the request being used for the host command and the second host command, and the size of the L2P address translation data associated with the request being further based on the second host data length.

17. A storage device, comprising: Volatile memory; and A controller, the controller being configured to: allocating a plurality of memory locations in the volatile memory for storing logical to physical (L2P) address translation data from a host memory buffer (HMB); Receive commands; as well as transmitting a request for a portion of the L2P address translation data stored in the HMB, the portion of the L2P address translation data being used for the command, and a size of the L2P address translation data associated with the request being based on a minimum of: a size of the portion of the L2P address translation data for the command, and The total size of the number of memory locations that are free and contiguous at the time of the request.

18. The storage device according to claim 17, The volatile memory is located inside the controller.

19. The storage device according to claim 17, The volatile memory is external to the controller.

20. The storage device of claim 17, wherein the controller is configured to transmit the request based on the size of the portion of the L2P address translation data for the command being larger than a size of a corresponding one of the memory locations.

Images