Host Memory Buffer Cache Management

Abstract

The present disclosure generally relates to host memory buffer (HMB) cache management. The HMB is a temporary memory and is not always available. For example, if the link between the data storage device and the host device is not active, the data storage device cannot access the HMB. Locating an HMB log in an HMB controller located in the data storage device provides access to data that would otherwise be inaccessible in the HMB. The HMB log contains any deltas that have occurred since the last copy to the HMB cache in the memory device or since the link became inactive. The HMB cache mirrors the HMB. In this way, data in the HMB is available to the data storage device not only when the link is active, but also when the link is inactive.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application incorporates by reference herein the entire contents of U.S. Non-Provisional Application No. 17 / 454,880, entitled “HOST MEMORY BUFFER CACHE MANAGEMENT,” filed November 15, 2021, for all purposes. [Background technology]

[0002] TECHNICAL FIELD Embodiments of the present disclosure generally relate to host memory buffer (HMB) cache management.

[0003] 2. Description of Related Art SSDs are connected to host devices through a PCIe interface. The PCIe interface is used to meet the required protocols by meeting given performance requirements. Client storage devices typically use a host memory buffer (HMB) to cache metadata such as logical-to-physical (L2P) tables, parity buffers, and other internal information. Metadata is paged in and out of internal SRAM to balance controller cost and performance. The HMB is provided by the host device and allocated from host dynamic random access memory (DRAM). Data storage devices directly access the HMB using peripheral component interconnect express (PCIe) transactions after an initial setup using a set of non-volatile memory express (NVMe) commands.

[0004] To achieve optimal performance, data storage devices may need to perform maintenance during idle times. Ideally, the maintenance can utilize the HMB to provide buffer space for table and operational data. However, host power management guidelines often limit link power and prevent use of the HMB while the host device is idle, since the host power required to keep the link, PCIe root complex, and DRAM active can be significantly higher than the storage device power.

[0005] Thus, a storage device may need to maintain multiple flows: one for active power with HMB access, and a secondary flow for the same operations where HMB is limited or not used. Such multiple flows increase the complexity of the device and provide a potential surface for firmware (FW) problems.

[0006] Thus, there is a need in the art for improved HMB cache management. Summary of the Invention

[0007] The present disclosure generally relates to host memory buffer (HMB) cache management. The HMB is a temporary memory and is not always available. For example, if the link between the data storage device and the host device is not active, the data storage device cannot access the HMB. Locating an HMB log in an HMB controller located in the data storage device provides access to data that would otherwise be inaccessible in the HMB. The HMB log contains any deltas that have occurred since the last copy to the HMB cache in the memory device or since the link became inactive. The HMB cache mirrors the HMB. In this way, data in the HMB is available to the data storage device not only when the link is active, but also when the link is inactive.

[0008] In one embodiment, a data storage device includes a memory device and a controller coupled to the memory device, the controller configured to determine whether a link between a host memory buffer (HMB) and the controller is active, write data to a cache, the data written to the cache is data intended to be written to the HMB, is delta data, and update an HMB log to indicate the presence of the delta data.

[0009] In another embodiment, a data storage device includes a memory device and a controller coupled to the memory device configured to receive a request to write data to a host memory buffer (HMB), record an indication of the write in an HMB log, write data, which is delta data, to a cache, receive a read request to read data from the HMB, retrieve a portion of the requested data from a location other than the HMB, retrieve the delta data, and return the delta data and the portion of the requested data to satisfy the read request.

[0010] In another embodiment, a data storage device comprises a memory means and a controller coupled to the memory means, the controller configured to receive requests to read data from a host memory buffer (HMB) and to write data to the host memory buffer (HMB), process the read requests by retrieving the requested data from a location other than the HMB, and process the write requests by writing the data to a location other than the HMB, wherein the data is written to the HMB after writing the data to the location other than the HMB. [Brief description of the drawings]

[0011] So that the above-mentioned features of the present disclosure can be understood in detail, a more particular description of the present disclosure briefly summarized above can be made by reference to embodiments, some of which are illustrated in the accompanying drawings. It should be noted, however, that the accompanying drawings illustrate only typical embodiments of the present disclosure and therefore should not be considered as limiting its scope, as the present disclosure may admit of other equally effective embodiments. [Figure 1] 1 is a schematic block diagram illustrating a storage system in which a data storage device may function as a storage device for a host device, according to certain embodiments. [Diagram 2] 1 is an illustration of a link power management flow diagram in accordance with certain embodiments. [Diagram 3] FIG. 1 is a schematic diagram of an HMB controller with cache management according to one embodiment. [Figure 4A] 1 is a flow chart illustrating the logic of the cache management engine of the HMB according to one embodiment. [Figure 4B] 1 is a flow chart illustrating the logic of the cache management engine of the HMB according to one embodiment. [Figure 4C] 1 is a flow chart illustrating the logic of the cache management engine of the HMB according to one embodiment. [Diagram 5] 13 is a flowchart illustrating HMB cache management according to one embodiment.

[0012] To facilitate understanding, the same reference numbers have been used, whenever possible, to designate identical elements common to the figures. It is contemplated that elements disclosed in one embodiment may be beneficially utilized on other embodiments without specific mention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] In the following, reference will be made to embodiments of the present disclosure. However, it should be understood that the present disclosure is not limited to the specifically described embodiments. Instead, any combination of the following features and elements, whether associated with different embodiments or not, is contemplated to implement and practice the present disclosure. Furthermore, although embodiments of the present disclosure may achieve advantages over other possible solutions and / or over the prior art, whether or not a particular advantage is achieved by a given embodiment does not limit the present disclosure. Thus, the following aspects, features, embodiments, and advantages are merely illustrative and are not considered elements or limitations of the appended claims unless expressly recited in the claim(s). Similarly, references to "the present disclosure" are not to be construed as a generalization of any inventive subject matter disclosed herein, and should not be considered elements or limitations of the appended claims unless expressly recited in the claims.

[0014] The present disclosure generally relates to host memory buffer (HMB) cache management. The HMB is a temporary memory and is not always available. For example, if the link between the data storage device and the host device is not active, the data storage device cannot access the HMB. Locating an HMB log in an HMB controller located in the data storage device provides access to data that would otherwise be inaccessible in the HMB. The HMB log contains any deltas that have occurred since the last copy to the HMB cache in the memory device or since the link became inactive. The HMB cache mirrors the HMB. In this way, data in the HMB is available to the data storage device not only when the link is active, but also when the link is inactive.

[0015] 1 is a schematic block diagram illustrating a storage system 100 in which a host device 104 communicates with a data storage device 106, according to certain embodiments. For example, the host device 104 may utilize a non-volatile memory (NVM) 110 included in the data storage device 106 to store and retrieve data. The host device 104 includes a host DRAM 138. In some implementations, the storage system 100 may include multiple storage devices, such as the data storage device 106, that may operate as a storage array. For example, the storage system 100 may include multiple data storage devices 106 configured as a Redundant Array of Inexpensive / Independent Disks (RAID) that collectively function as a mass storage device for the host device 104.

[0016] The host device 104 may store and / or retrieve data to and / or from one or more storage devices, such as the data storage device 106. As illustrated in Figure 1, the host device 104 may communicate with the data storage device 106 via an interface 114. The host device 104 may comprise any of a wide range of devices, such as a computer server, a network attached storage (NAS) unit, a desktop computer, a notebook (i.e., laptop) computer, a tablet computer, a set-top box, a telephone, such as a so-called "smart" phone, a so-called "smart" pad, a television, a camera, a display device, a digital media player, a video game console, a video streaming device, or other device that can transmit or receive data from a data storage device.

[0017] Data storage device 106 includes controller 108, NVM 110, power supply 111, volatile memory 112, interface 114, and write buffer 116. In some embodiments, data storage device 106 may include additional components not shown in FIG. 1 for clarity. For example, data storage device 106 may include a printed circuit board (PCB) to which the components of data storage device 106 are mechanically attached and which includes conductive traces that electrically interconnect the components of data storage device 106. In some embodiments, the physical dimensions and connector configuration of data storage device 106 may conform to one or more standard form factors. Some exemplary standard form factors include, but are not limited to, a 3.5" data storage device (e.g., HDD or SSD), a 2.5" data storage device, a 1.8" data storage device, Peripheral Component Interconnect (PCI), PCI Expansion (PCI-X), PCI Express (PCIe) (e.g., PCIe x1, x4, x8, x16, PCIe Mini Card, Mini PCI, etc.). In some embodiments, the data storage device 106 may be directly coupled to the motherboard of the host device 104 (e.g., soldered or plugged directly into a connector).

[0018] The interface 114 may include one or both of a data bus for exchanging data with the host device 104 and a control bus for exchanging commands with the host device 104. The interface 114 may operate according to any suitable protocol. For example, the interface 114 may operate according to one or more of the following protocols: PCIe, Non-Volatile Memory Express (NVMe), OpenCAPI, GenZ, Cache Coherent Interface Accelerator (CCIX), Open Channel SSD (OCSSD), and the like. The interface 114 (e.g., a data bus, a control bus, or both) is electrically connected to the controller 108, which provides an electrical connection between the host device 104 and the controller 108 and allows data to be exchanged between the host device 104 and the controller 108. In some embodiments, the electrical connection of the interface 114 may also allow the data storage device 106 to receive power from the host device 104. For example, as illustrated in FIG. 1, the power supply 111 may receive power from the host device 104 via the interface 114.

[0019] The NVM 110 may include multiple memory devices or memory units. The NVM 110 may be configured to store and / or retrieve data. For example, a memory unit of the NVM 110 may receive data and a message from the controller 108 instructing the memory unit to store the data. Similarly, the memory unit may receive a message from the controller 108 instructing the memory unit to retrieve data. In some embodiments, each of the memory units may be referred to as a die. In some examples, the NVM 110 may include multiple dies (i.e., multiple memory units). In some embodiments, each memory unit may be configured to store a relatively large amount of data (e.g., 128MB, 256MB, 512MB, 1GB, 2GB, 4GB, 8GB, 16GB, 32GB, 64GB, 128GB, 256GB, 512GB, 1TB, etc.).

[0020] In some embodiments, each memory unit may include any type of non-volatile memory device, such as a flash memory device, a phase change memory (PCM) device, a resistive random access memory (ReRAM) device, a magnetoresistive random access memory (MRAM) device, a ferroelectric random access memory (F-RAM), a holographic memory device, and any other type of non-volatile memory device.

[0021] NVM 110 may include multiple flash memory devices or memory units. NVM flash memory devices may include NAND or NOR based flash memory devices and may store data based on the charge contained in the floating gate of the transistor of each flash memory cell. In an NVM flash memory device, the flash memory device may be divided into multiple dies, and each die of the multiple dies may include multiple blocks, which may be further divided into multiple pages. Each block of the multiple blocks in a particular memory device may include multiple NVM cells. Rows of NVM cells may be electrically connected using word lines to define each page of the multiple pages. Each cell in each of the multiple pages may be electrically connected to a respective bit line. Furthermore, the NVM flash memory device may be a 2D or 3D device and may be single level cell (SLC), multi-level cell (MLC), triple level cell (TLC), or quad level cell (QLC). Controller 108 may write data to and read data from the NVM flash memory device at the page level and erase data from the NVM flash memory device at the block level.

[0022] The power source 111 can provide power to one or more components of the data storage device 106. When operating in a standard mode, the power source 111 can provide power to one or more components using power provided by an external device, such as the host device 104. For example, the power source 111 can provide power to one or more components using power received from the host device 104 via the interface 114. In some embodiments, the power source 111 can include one or more power storage components configured to provide power to one or more components when operating in a shutdown mode, such as when the power source 111 stops receiving power from an external device. In this manner, the power source 111 can function as an on-board power source. Some examples of the one or more power storage components include, but are not limited to, capacitors, supercapacitors, batteries, and the like. In some embodiments, the amount of power that can be stored by the one or more power storage components can be a function of the cost and / or size (e.g., area / volume) of the one or more power storage components. In other words, as the amount of power stored by the one or more power storage components increases, the cost and / or size of the one or more power storage components also increases.

[0023] The volatile memory 112 may be used by the controller 108 to store information. The volatile memory 112 may include one or more volatile memory devices. In some embodiments, the controller 108 may use the volatile memory 112 as a cache. For example, the controller 108 may store cached information in the volatile memory 112 until the cached information is written to the NVM 110. As illustrated in FIG. 1, the volatile memory 112 may consume power received from the power source 111. Examples of the volatile memory 112 include, but are not limited to, 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, LPDDR4, etc.)).

[0024] The controller 108 may manage one or more operations of the data storage device 106. For example, the controller 108 may manage reading data from and / or writing data to the NVM 110. In some embodiments, when the data storage device 106 receives a write command from the host device 104, the controller 108 may initiate the data storage command, store the data in the NVM 110, and monitor the progress of the data storage command. The controller 108 may determine at least one operating characteristic of the storage system 100 and store the at least one operating characteristic in the NVM 110. In some embodiments, when the data storage device 106 receives a write command from the host device 104, the controller 108 temporarily stores data associated with the write command in an internal memory or write buffer 116 before sending the data to the NVM 110.

[0025] 2 is an illustration of a link state flow diagram 200 according to certain embodiments. Aspects of the storage system 100 may be referenced in the description herein for illustrative purposes. The data storage device 106 includes several link states. For example, the data storage device 106 may have the following five link states: L0, L0s, L1, L2, and L3, where L1 includes an L1.1 sub-state and an L1.2 sub-state. Each of the link states is associated with a separate operation of the data storage device 106. Link states L0, L0s, and L1 are considered operational link states and utilize a first power range, while link states L2 and L3 are considered non-operational link states and utilize a second power range, where the first power range is greater than the second power range.

[0026] An operational link state refers to the ability of the host device 104 to communicate with the NVM 110 of the data storage device 106. A non-operational link state refers to the inability of the host device 104 to communicate with the NVM 110 of the data storage device 106 due to a shutdown or disconnection of the link between the host device 104 and the controller 108. The listed non-operational link states are not intended to be limiting and may include other link states, such as the L1.1 and L1.2 link states. Additionally, it is contemplated that more or fewer link states may be available than the number of link states illustrated in the link state flow diagram 200, and that more or fewer low power link states may be applicable to the embodiments described herein.

[0027] The link states are numbered sequentially, with higher numbers representing lower power requirements due to a greater number of offline circuits and correspondingly higher exit latency. Additionally, each link state has an associated power requirement and exit latency. L0 and L0s may require 4.5W with the lowest exit latency. L1 may require less power than L0, such as 3W, and may have an exit latency equal to or greater than that of L0. L2 may require less power than L1 and may have an exit latency equal to or greater than that of L1. L3 may require less power than L2 and may have an exit latency equal to or greater than that of L2. The values ​​of the link states and exit latency are not intended to be limiting, but are intended to provide an example of one possible embodiment.

[0028] L0 is called the fully operational state, I / O commands are enabled, and devices can generate interrupts. L0 is the link state in which the link is operating normally. An interrupt is an automatic transfer of firmware execution due to a system timer or user command. Link states L0s and L1 are also operational states. However, L0s and L1 may have less functionality than L0. For example, L0s has similar power requirements as L0, but only allows for a unidirectional serial link. In the L0s link state, data can be transferred in one direction but not the other. Thus, when a first device is coupled to a second device via a link, the first device can idle the transmitter of the first device independently and separately from the second device idling the transmitter of the second device, and / or vice versa.

[0029] However, L1 allows for a bidirectional serial link and allows for a greater reduction in power requirements, but has a longer exit latency than those of L0 and L0s. In the L1 link state, significant portions of the PCIe transceiver logic may be turned off since no data is being transferred. Link states L2 and L3 are non-operational link states that have power requirements that are less than those of the operational link state. The difference between the L2 and L3 link states is that auxiliary power has not yet been removed from the L2 link state. Additionally, memory devices of the NVM 110 that are not being used are placed in the non-operational link states L2 and L3 to limit idle power consumption to a minimum.

[0030] To issue an I / O command, a link, such as a data bus between the host device 104 and the controller 108, is woken up and placed in a L0 link state. The controller 108 changes the link state of the link between the host device 104 and the controller 108 from an operational link state, such as L0, L0s, or L1, to a different operational link state, such as L0, L0s, or L1, or a non-operational link state, such as L2 or L3, depending on the circumstances. However, for a link to be placed in L2 or L3, the link must be in link state L2 / L3 ready, which is a pseudo state to prepare components for loss of power and reference clock. The controller 108 allocates an appropriate amount of power to return all link states L0s, L1, L2, L3 to link state L0 when a full operational state is required. For example, to return from L2 or L3 to L0, the link transitions to a transient pseudo state LDn before transitioning to L0. The LDn state may be a fundamental reset state by an upstream component (eg, the host device 104), a hot reset state, or a link disable transmission state.

[0031] Link state L1, in some embodiments, includes additional sub-states L1.1 and L1.2, and link state L1 may be referred to as L1.0. The L1 sub-states (L1SS), L1.1 and L1.2, may require more power to operate than L2 and L3. However, L1SS utilizes less power than the L1.0 state. In L1SS, the link remains operational and requires less power to return to a more operational state, such as L1.0 or L0. Additionally, L1SS requires less time to return to a fully active link state L0 than the L2 and / or L3 link states.

[0032] As described below, when the link between the host device and the data storage device is not active (i.e., when the power state is L1 or lower), a transparent cache and management engine in the HMB controller allows access to data in the HMB. The HMB controller mirrors the HMB to the memory device. The engine captures HMB write transactions when the PCIe link is limited and replays the write transactions after the link becomes active. Read transactions are redirected to corresponding memory locations in the memory device. Suitable memory locations include, for example, an SLC buffer, any non-volatile storage medium, or a power failure protection medium.

[0033] FIG. 3 is a schematic diagram 300 of an HMB controller with cache management, according to one embodiment. As shown in FIG. 3, host memory 302 includes an HMB 304 that is accessed by a data storage device via a PCIe interface / front-end controller 306. The controller 306 includes an HMB controller 308. An HMB log 310 is located within the HMB controller 308. The controller 306 sends any data for an HMB cache 318 located within a memory device 316 through a flash management and application processor 312 and a memory device interface / back-end 314. The HMB controller 308 with HMB log 310 takes advantage of several key features of HMB usage in a client environment: the HMB footprint is relatively small (e.g., 64MB or less), while L2P updates can be made to the HMB before the L2P updates are saved to the memory device, most metadata ends up on the memory device, and the performance-dependent access to the HMB is always when the link is fully active, whereas idle access to the HMB is not performance-dependent.

[0034] The manageability engine 322 resides in the HMB controller 308 and maintains a local SRAM cache 320 that mirrors the most active portion of the HMB 304. A HMB log 310 of HMB accesses is also maintained in the SRAM cache 320, but accesses beyond the most recent may spill over to a dedicated log space in a memory device or other non-volatile medium. When the PCIe link is reduced to L1 or below (L1.2 or L2 / L3 ready), all outstanding HMB accesses are redirected to the engine and executed from either the SRAM cache 320 or the HMB cache 318 in the memory device 316. However, from the device firmware's perspective, the manageability engine 322 is transparent and HMB requests continue to be made and responded to. Although the SRAM cache 320 has been described and illustrated, it should be understood that the local storage is not limited to the SRAM cache 320. Rather, the local storage may be any volatile or non-volatile high-speed storage medium.

[0035] Thus, even when the link is not active, the appearance that the HMB is always available is maintained because the HMB controller 308 ensures that data that is present or expected to be present in the HMB 304 is always accessible via the HMB controller 308. All entries in the HMB 304 are shadowed in the memory device 316, or more specifically, the HMB cache 318, and any deltas are tracked in the HMB log 310 and maintained in the SRAM cache 320. Although the SRAM cache 320 has been described and illustrated, it should be understood that the local storage is not limited to the SRAM cache 320. Rather, the local storage may be any volatile or non-volatile high speed storage medium. Thus, any read operation may go through the HMB 304 when the link is active, and may go through the memory device 316 with deltas from the HMB controller 308 when the link is not active.

[0036] The HMB controller 308, which may be either firmware or hardware, controls the HMB 304 and error correction. The HMB log 310 shadows everything in the HMB 304 and sends the shadowed information to the HMB cache 318. When the link between the host device and the data storage device is active, all HMB reads / writes go to the HMB 304 and are recorded in the HMB log 310 with any deltas not mirrored to the HMB cache 318 residing in the SRAM cache 320. Eventually the data is mirrored to the HMB cache 318. When the link between the host device and the data storage device is not active, all HMB reads / writes go to the HMB cache 318 with any deltas recorded in the HMB log 310 retrieved from the SRAM cache 320.

[0037] 4A-4C are flow charts 400, 430, 450 illustrating the logic of the cache management engine of the HMB according to one embodiment. As shown in FIG. 4A, HMB initialization occurs at 402, and the L2P table is copied from a memory device (e.g., NAND) to the HMB at 404. The source location of the table is kept in the HMB controller to serve as a baseline when the HMB is offline. Other sources may be used as well, or a dedicated SLC buffer may be designated for that purpose. The memory device source location is kept for future update replay at 406, and an SRAM-based structure for tracking modifications is initialized at 408. Although a dedicated SRAM buffer has been described and illustrated, it should be understood that the local storage is not limited to a dedicated SRAM buffer. Rather, the local storage may be any volatile or non-volatile high-speed storage medium.

[0038] A delta list of modifications is maintained in SRAM and also in the memory device (e.g., NAND). The delta list is initially empty because the HMB and memory device are synchronized. When the storage firmware writes incremental updates to the HMB, the updates are automatically recorded in the SRAM delta list. The deltas are then consolidated back to the original source when the SRAM list reaches a maximum size, or may be propagated to a memory device (e.g., NAND) based location. Periodically, the original location is resynchronized with the HMB and the delta list is reset. Residuals are typically done after a threshold is reached or before performing a maintenance operation.

[0039] As shown in FIG. 4B, when the storage firmware issues a HMB read command to the HMB controller at 432, the HMB controller checks at 434 whether the PCIe link is active. If the link is active, then the command is passed to the HMB at 436, and the read payload is fetched from the HMB at 436. However, if the link is in a low power state, the read command is resolved by using a combination of the original source in the memory device (or any other buffer holding the source content) and any deltas applied since the last consolidation. More specifically, at 438, the SRAM structure is checked for the memory device version or read payload, and if necessary, at 440, the deltas recorded during the incremental write are applied. Although an SRAM structure has been described and illustrated, it should be understood that the local storage is not limited to an SRAM structure. Rather, the local storage may be any volatile or non-volatile high speed storage medium. When the link resumes, all incremental deltas are replayed to the HMB, and thus new reads can be sourced directly from the HMB instead of applying new updates on every read.

[0040] As shown in FIG. 4C, when the storage firmware issues an HMB incremental write command to the HMB controller at 452, the HMB controller records the write command in the SRAM delta list at 454 and performs two checks. One check is to see if the link is active at 458. If the link is active at 458, the data is written to the HMB at 464. If the link is not active, a write is made to the SRAM cache at 462 and ultimately to the HMB cache in the memory device. An additional check is to determine if the delta list is full at 456. If the delta list is not full, a write is made to the SRAM cache at 462 and ultimately to the HMB cache in the memory device. If the delta list is full at 456, the delta is consolidated to the memory device target at 460.

[0041] If the memory device HMB cache has not yet been updated, the delta is necessary and must be kept even if consolidated. Furthermore, the HMB may be updated before updating the HMB cache in the memory device with the delta. Furthermore, if a write to the HMB occurs when the link is not active, the only update to the HMB that is required when the link is restored is the delta that is kept in SRAM. The delta stored in SRAM is sent to the HMB when the link becomes active. If there are too many deltas, they are sent to the memory device, specifically the HMB cache, so that they can be later resynchronized with the HMB when the link is restored. The incremental cache buffer for writes is transparent to the firmware logic.

[0042] FIG. 5 is a flow chart 500 illustrating HMB cache management according to one embodiment. First, at 502, a determination is made that data needs to be written to the HMB. Based on this determination, another determination is made. Specifically, at 504, a determination is made as to whether the HMB log located in the HMB controller located in the data storage device is full. If the HMB log is full, then at 508, the data in the HMB log needs to be consolidated and sent to the memory device. However, if the HMB log is not full, then at 506, the HMB log is updated to indicate that a delta write is to be performed. A delta write is a write to the HMB that modifies data already in the HMB or causes a delta. The delta can be new data for the HMB or updated data already in the HMB. In any case, at 510, the HMB log is updated and the actual delta data is written to SRAM.

[0043] At this point, the delta data, and the log of the delta data, resides in the data storage device, and more specifically, in the HMB controller of the data storage device. The delta data needs to be written to the HMB, so the HMB controller determines at 512 whether the link between the HMB and the data storage device is active. If the link is not active, the HMB controller waits until the link eventually becomes active. Meanwhile, while the link is not active, any new incremental write requests to the HMB are processed according to the process beginning at 502.

[0044] If the link is active at 512, the delta data is written to the HMB at 514. If a threshold is met at 516, the data is mirrored to the memory device as the HMB cache at 518, the HMB log is emptied at 520, and the delta data is removed from the SRAM at 522 since the HMB cache and HMB are now identical. The threshold may be, for example, a time threshold or a number of write delta writes. If the threshold is not met, the memory device is not updated and therefore the HMB and HMB cache are different and the difference is the delta data indicated in the HMB log and contained in the SRAM.

[0045] HMB read requests are processed normally when the link between the HMB and the HMB controller is active. When the link is active, data is simply read from the HMB. However, it is believed that the HMB has not yet been updated with the delta data. Therefore, any delta data is written to the HMB before performing the HMB read.

[0046] When the link is not active, data is fetched from the HMB cache instead, and delta data is fetched from the SRAM cache. In this way, HMB read requests can be satisfied even if the HMB is not accessible. Delta data, which is an incremental write that has not yet been written to the HMB, can actually be read. If there is no incremental write or delta data stored outside the HMB, the HMB read request cannot be fulfilled or may return invalid data, since the data retrieved from the HMB cache is incomplete (i.e., the delta data is missing). With the delta data stored, the HMB request can be fulfilled and provide valid data.

[0047] By shadowing the HMB with the HMB log, HMB data can be easily retrieved when the link between the data storage device and the host device is inactive. Additionally, any deltas that have occurred since the last copy of the HMB to the HMB cache in the memory device are found in the HMB log. Additionally, any deltas that have occurred while the link was inactive can be copied to the HMB upon link activation. Additionally, better control of HMB cache management in hardware allows for full alignment with the NVMe protocol, reducing potential host power without complicating firmware logic that utilizes the HMB. Implementation of features in the controller can eliminate potential corner cases where firmware is not fully synchronized with link power management. The embodiments described herein improve HMB management and simplify HMB interaction when aggressive host-side power management policies are applied.

[0048] In one embodiment, the data storage device comprises a memory device and a controller coupled to the memory device, the controller configured to determine whether a link between a host memory buffer (HMB) and the controller is active, write data to a cache, the data written to the cache is data intended to be written to the HMB and is delta data, and update an HMB log to indicate the presence of the delta data. The controller is further configured to update the HMB with the delta data when the link becomes active, the controller is further configured to mirror the data in the HMB by writing the data to an HMB cache located in the memory device. The determining step determines that the link is not active and updates the HMB log such that the data in the HMB is different from the data stored in the HMB cache. The data in the HMB is identical to a combination of the data stored in the HMB cache and the delta data.

[0049] In another embodiment, a data storage device comprises a memory device and a controller coupled to the memory device, the controller configured to receive a request to write data to a host memory buffer (HMB), record an indication of the write in an HMB log, write the data, which is delta data, to a cache, receive a read request to read data from the HMB, retrieve a portion of the requested data from a location other than the HMB, retrieve the delta data, and return the delta data and the portion of the requested data to satisfy the read request. The controller is further configured to determine that a link between the controller and the HMB is not active. The link is not active when the portion of the requested data and the delta data are retrieved. The cache is located within the controller. The portion of the requested data is retrieved from the HMB cache. The HMB cache is located within the memory device. The controller is further configured to write the delta data to the HMB when the controller determines that the link between the HMB and the controller is active. The controller is configured to write the delta data to the HMB before receiving the read request. The controller is configured to determine whether the HMB log is full. The controller is configured to consolidate data from the HMB log and flush the consolidated data to the memory device.

[0050] In another embodiment, a data storage device comprises a memory means and a controller coupled to the memory means, the controller configured to receive requests to read data from and write data to a host memory buffer (HMB), process the read requests by retrieving the requested data from a location other than the HMB, and process the write requests by writing the data to a location other than the HMB, where the data is written to the HMB after writing the data to the location other than the HMB. Data associated with the read requests is located in the HMB, the memory means, and an SRAM cache. The controller further comprises a management engine, the management engine comprising an HMB log and an SRAM cache. The location other than the HMB includes a cache located within the controller. The controller is further configured to log the writing of the data to the location other than the HMB. The controller is further configured to copy data from the location other than the HMB to the HMB upon determining that a link between the HMB and the controller is active.

[0051] While the above is directed to embodiments of the present disclosure, other and further embodiments of the present disclosure may be devised without departing from the basic scope thereof, which scope is determined by the following claims.

Claims

1. 1. A data storage device comprising: A memory device; a controller coupled to the memory device, the controller comprising: determining whether a link between a host memory buffer (HMB) and the controller is active; writing data to a cache, the data written to the cache being data intended to be written to the HMB, the data being delta data; and a controller configured to update the HMB log to indicate the presence of the delta data.

2. 2. The data storage device of claim 1, wherein the controller is further configured to update the HMB with the delta data when the link becomes active, and the controller is further configured to mirror the data in the HMB by writing the data to an HMB cache located in the memory device.

3. 2. The data storage device of claim 1, wherein said determining determines that the link is not active and updating said HMB log causes data in said HMB to differ from data stored in an HMB cache.

4. 4. The data storage device of claim 3, wherein the data in the HMB is identical to a combination of the data stored in an HMB cache and the delta data.

5. 1. A data storage device comprising: A memory device; a controller coupled to the memory device, the controller comprising: receiving a request to write data to a host memory buffer (HMB); Recording the write instruction in an HMB log; writing said data, which is delta data, into a cache; receiving a read request to read data from the HMB; Retrieving a portion of the requested data from a location other than the HMB; Extracting the delta data; a controller configured to return the delta data and the portion of the requested data to satisfy the read request.

6. The data storage device of claim 5 , wherein the controller is further configured to determine that a link between the controller and the HMB is not active.

7. 7. The data storage device of claim 6, wherein the link is inactive when the portion of the requested data and the delta data are retrieved.

8. The data storage device of claim 5 , wherein the cache is located within the controller.

9. 6. The data storage device of claim 5, wherein the portion of the requested data is retrieved from an HMB cache.

10. The data storage device of claim 9 , wherein the HMB cache is located within the memory device.

11. 6. The data storage device of claim 5, wherein the controller is further configured to write the delta data to the HMB upon determining that a link between the HMB and the controller is active.

12. The data storage device of claim 5 , wherein the controller is configured to write the delta data to a HMB before receiving the read request.

13. The data storage device of claim 5 , wherein the controller is configured to determine whether the HMB log is full.

14. The data storage device of claim 5 , wherein the controller is configured to consolidate data from the HMB log and flush the consolidated data to the memory device.

15. 1. A data storage device comprising: A memory means; a controller coupled to the memory means, the controller comprising: receiving requests to read data from a host memory buffer (HMB) and to write data to a host memory buffer (HMB); processing the read request by retrieving the requested data from a location other than the HMB; a controller configured to process the write request by writing data to a location other than the HMB, the data being written to the HMB after writing the data to the location other than the HMB.

16. 16. The data storage device of claim 15, wherein the data associated with the read request is located within a HMB, the memory means, and an SRAM cache.

17. 16. The data storage device of claim 15, wherein the controller further comprises a manageability engine, the manageability engine comprising an HMB log and an SRAM cache.

18. 16. The data storage device of claim 15, wherein the location other than the HMB comprises a cache located within the controller.

19. 16. The data storage device of claim 15, wherein the controller is further configured to record writing of data to the locations other than the HMB.

20. 16. The data storage device of claim 15, wherein the controller is further configured to copy data to the HMB from a location other than the HMB upon determining that a link between the HMB and the controller is active.

Images