Data storage device and method for contention-based data access in multi-host memory buffer system

Abstract

A data storage device and method for contention-based data access in a multi-host memory buffer system is provided. In one embodiment, the data storage device stores data in a plurality of host memory buffers in a host rather than only in host memory buffers typically associated with the data. To read the data, the data storage device sends a read command to all of the host memory buffers. In this way, even if some of the host memory buffers are busy, the data may be returned from another of the host memory buffers. In future reads in similar workloads, a read command may be sent to the host memory buffer that returns the data. Other embodiments are possible, and each of these embodiments may be used alone or in combination.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of U.S. Non - Provisional Application No. 18 / 223,150, filed on July 18, 2023, entitled "Data Storage Device and Method for Race - Based Data Access in a Multiple Host Memory Buffer System", and hereby incorporates by reference in its entirety the U.S. Non - Provisional Application for all purposes, which claims the priority of U.S. Provisional Application No. 63 / 437,169, filed on January 5, 2023. Background Art

[0003] In some storage protocols, a data storage device is allowed to utilize a portion of the volatile memory in a host. The use of this memory (sometimes referred to as a host memory buffer (HMB)) can be vendor - specific. In the High - Speed Non - Volatile Memory (NVMe) specification, the host memory buffer is allocated for exclusive use by the controller of the data storage device. The host does not actively modify or access the data in the host memory buffer, and the host notifies the controller of the data storage device before reusing the memory space in the host memory buffer for other purposes. Brief Description of the Drawings

[0004] Figure 1A is a block diagram of a data storage device according to an embodiment.

[0005] Figure 1B is a block diagram showing a storage module according to an embodiment.

[0006] Figure 1C is a block diagram showing a hierarchical storage system according to an embodiment.

[0007] Figure 2A is a block diagram showing according to an embodiment Figure 1A the components of the controller of the data storage device shown in

[0008] Figure 2B is a block diagram showing according to an embodiment Figure 1A the components of the memory data storage device shown in

[0009] Figure 3 is a block diagram of a host and a data storage device according to an embodiment.

[0010] Figure 4Block diagram of a single root input / output virtualization (SR-IOV) system of an embodiment.

[0011] Figure 5 Flowchart of a method of an embodiment for contention-based data access in a multi-host memory buffer system.

[0012] Figure 6 Flowchart of a switching mechanism of an embodiment.

[0013] Figure 7 Block diagram of a host and a controller of an embodiment. Detailed Description

[0014] Overview

[0015] In an introductory manner, the following embodiments relate to a data storage device and method for contention-based data access in a multi-host memory buffer system. In one embodiment, a data storage device is provided that includes a memory, an interface configured to communicate with a host including a plurality of host memory buffers, and a controller. The controller is configured to determine whether data should be stored in only one of the plurality of host memory buffers or in all of the plurality of host memory buffers; and in response to determining that the data should be stored in all of the plurality of host memory buffers, store the data in all of the plurality of host memory buffers.

[0016] In some embodiments, the controller is further configured to send read commands to all of the plurality of host memory buffers to read the data.

[0017] In some embodiments, the controller is further configured to track which of the plurality of host memory buffers first returns the data; and prioritize future read commands to the one host memory buffer of the plurality of host memory buffers.

[0018] In some embodiments, the controller is further configured to track the workload presented when sending the read commands to all of the plurality of host memory buffers; and prioritize the future read commands in response to the workload presented when sending the future read commands matching the workload presented when sending the read commands to all of the plurality of host memory buffers.

[0019] In some embodiments, the controller is further configured to determine that the data should be stored in all of the plurality of host memory buffers in response to determining that the data includes critical data.

[0020] In some embodiments, the controller is further configured to determine that the data should be stored in all of the plurality of host memory buffers in response to determining that the data includes a logical-to-physical address table associated with a frequently accessed region.

[0021] In some embodiments, the controller is further configured to communicate with a first host memory buffer among the plurality of host memory buffers via a first switch in the host and communicate with a second host memory buffer among the plurality of host memory buffers via a second switch in the host.

[0022] In some embodiments, the controller includes: a plurality of host memory buffer controllers; host memory buffer replication logic; and a statistical monitoring module.

[0023] In some embodiments, the plurality of host memory buffers have a unified address space.

[0024] In some embodiments, each host memory buffer in the host memory buffers is associated with a different virtual function.

[0025] In some embodiments, the host includes a single root input / output virtualization (SR-IOV) interface.

[0026] In some embodiments, the memory includes three-dimensional memory.

[0027] In another embodiment, a method is provided that is performed in a data storage device communicating with a host including a plurality of host memory buffers, each host memory buffer associated with a different virtual function. The method includes: storing data associated with one of the plurality of virtual functions in all of the plurality of host memory buffers rather than only in the host memory buffer associated with the one of the plurality of virtual functions; sending a read command to the plurality of host memory buffers to read the data; and tracking the order in which the plurality of host memory buffers return the data.

[0028] In some embodiments, the method further includes determining that the data should be stored in the plurality of host memory buffers rather than only in the host memory buffer associated with the one of the plurality of virtual functions.

[0029] In some embodiments, the read commands are serially sent to the plurality of host memory buffers.

[0030] In some embodiments, the method further includes prioritizing future read commands to one of the plurality of host memory buffers.

[0031] In some embodiments, the data includes a logical-to-physical address table associated with frequently accessed regions.

[0032] In some embodiments, the plurality of host memory buffers have a unified address space.

[0033] In some embodiments, the host includes a single root input / output virtualization (SR-IOV) interface.

[0034] In another embodiment, a data storage device is provided that includes: a memory; an interface configured to communicate with a host including a plurality of host memory buffers and a plurality of virtual functions; means for storing data associated with one of the plurality of virtual functions in all of the plurality of host memory buffers rather than only in the host memory buffer associated with the one of the plurality of virtual functions; means for sending read commands to the plurality of host memory buffers to read the data; and means for prioritizing the read commands to the host memory buffer among the plurality of host memory buffers that first responds to a future read command.

[0035] Other embodiments are possible, and each of these embodiments can be used alone or in combination with each other. Accordingly, various embodiments will now be described with reference to the drawings.

[0036] Embodiment

[0037] The following embodiments relate to a data storage device (DSD). As used herein, a "data storage device" refers to a device that stores data. Examples of DSDs include, but are not limited to, hard disk drives (HDDs), solid state drives (SSDs), tape drives, hybrid drives, etc. Details of example DSDs are provided below.

[0038] Figures 1A to 1C A data storage device suitable for implementing aspects of these embodiments is shown. Figure 1A is a block diagram showing a data storage device 100 according to an embodiment of the subject matter described herein. Refer to Figure 1A, the data storage device 100 includes a controller 102 and a non-volatile memory that may consist of one or more non-volatile memory dies 104. As used herein, the term die refers to a collection of non-volatile memory cells formed on a single semiconductor substrate and the associated circuitry for managing the physical operations of those non-volatile memory cells. The controller 102 interfaces with the host system and transmits command sequences for read, program, and erase operations to the non-volatile memory die 104.

[0039] For example, the controller 102 (which may be a non-volatile memory controller (e.g., a flash, resistive random access memory (ReRAM), phase change memory (PCM), or magnetoresistive random access memory (MRAM) controller)) may take the form of a processing circuit, a microprocessor or a processor and a computer-readable medium storing computer-readable program code (e.g., firmware) executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. The controller 102 may be configured with hardware and / or firmware to perform the various functions described below and shown in the flowcharts. Also, some components shown to be within the controller may also be stored outside the controller and other components may be used. Additionally, the phrase "operatively communicate with" may mean directly communicate with or indirectly (wired or wirelessly) communicate with through one or more components, which may or may not be shown or described herein.

[0040] As used herein, a non-volatile memory controller is a device that manages data stored on a non-volatile memory and communicates with a host (such as a computer or an electronic device). The non-volatile memory controller may have various functionalities in addition to the specific functionalities described herein. For example, the non-volatile memory controller may format the non-volatile memory to ensure that the memory operates correctly, map out bad non-volatile memory cells, and allocate spare cells to replace future failing cells. A portion of the spare cells may be used to hold firmware to operate the non-volatile memory controller and implement other features. In operation, when the host needs to read data from or write data to the non-volatile memory, it may communicate with the non-volatile memory controller. If the host provides a logical address at which the data is to be read / written, the non-volatile memory controller may convert the logical address received from the host into a physical address in the non-volatile memory. (Alternatively, the host may provide a physical address.) The non-volatile memory controller may also perform various memory management functions, such as (but not limited to) wear leveling (distributing writes to avoid wearing out specific blocks of memory that would otherwise be repeatedly written) and garbage collection (after a block is full, only moving valid data pages to a new block so that the full block can be erased and reused).

[0041] The non-volatile memory die 104 may include any suitable non-volatile storage medium, including resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), phase change memory (PCM), NAND flash memory cells, and / or NOR flash memory cells. The memory cells may take the form of solid-state (e.g., flash) memory cells and may be one-time programmable, several times programmable, or multiple times programmable. The memory cells may also be single-level cells (SLCs), multi-level cells (MLCs) (e.g., dual-level cells, triple-level cells (TLCs), quad-level cells (QLCs), etc.), or use other memory cell-level technologies known now or developed later. Moreover, the memory cells may be fabricated in two-dimensional or three-dimensional fashions.

[0042] The interface between the controller 102 and the non-volatile memory die 104 may be any suitable flash memory interface, such as Toggle Mode 200, 400, or 800. In one embodiment, the data storage device 100 may be a card-based system, such as a Secure Digital (SD) or a micro Secure Digital (microSD) card. In an alternative embodiment, the data storage device 100 may be part of an embedded data storage device.

[0043] Although in Figure 1A the example shown, the data storage device 100 (sometimes referred to herein as a storage module) includes a single channel between the controller 102 and the non-volatile memory die 104, the subject matter described herein is not limited to having a single memory channel. For example, in some architectures (such as Figure 1B and Figure 1C the architectures shown), depending on the controller capabilities, there may be two, four, eight, or more memory channels between the controller and the memory device. In any of the embodiments described herein, there may be more than one channel between the controller and the memory die, even if a single channel is shown in the figures.

[0044] Figure 1BA storage module 200 including a plurality of non-volatile data storage devices 100 is shown. Thus, the storage module 200 may include a storage controller 202 that interfaces with a host and with a data storage device 204 including the plurality of data storage devices 100. The interface between the storage controller 202 and the data storage device 100 may be a bus interface such as a Serial Advanced Technology Attachment (SATA), a Peripheral Component Interconnect Express (PCIe) interface, or a Double Data Rate (DDR) interface. In one embodiment, the storage module 200 may be a Solid State Drive (SSD) or a Non-Volatile Dual In-line Memory Module (NVDIMM), such as those found in a server PC or a portable computing device such as a laptop computer and a tablet computer.

[0045] Figure 1C is a block diagram showing a hierarchical storage system. The hierarchical storage system 250 includes a plurality of storage controllers 202, each of the plurality of storage controllers controlling a corresponding data storage device 204. A host system 252 may access the memory within the storage system 250 via a bus interface. In one embodiment, the bus interface may be a Non-Volatile Memory Express (NVMe) or an Ethernet Fibre Channel (FCoE) interface. In one embodiment, Figure 1C the system shown may be a rack-mounted mass storage system that can be accessed by a plurality of host computers, such as those found in a data center or other locations requiring mass storage.

[0046] Figure 2A is a block diagram showing the components of the controller 102 in more detail. The controller 102 includes a front-end module 108 that interfaces with a host, a back-end module 110 that interfaces with one or more non-volatile memory dies 104, and various other modules that perform functions that will now be described in detail. For example, the modules may take the form of a packaged functional hardware unit designed to work with other components, a portion of program code (e.g., software or firmware) executable by a (micro)processor or processing circuitry of a specific function that normally performs the relevant function, or a self-contained hardware or software component that interfaces with a larger system. Additionally, the "means" for performing a function may be implemented in at least any of the structures described herein for the controller and may be pure hardware or a combination of hardware and computer-readable program code.

[0047] Referring again to the modules of the controller 102, a buffer manager / bus controller 114 manages buffers in a Random Access Memory (RAM) 116 and controls internal bus arbitration of the controller 102. A Read-Only Memory (ROM) 118 stores system boot code. Although in Figure 2Ais shown as being located separately from the controller 102, but in other embodiments, one or both of the RAM 116 and the ROM 118 may be located within the controller. In other embodiments, portions of the RAM and the ROM may be located within and outside of the controller 102.

[0048] The front-end module 108 includes a host interface 120 that provides an electrical interface to a host or a next-level storage controller and a physical layer interface (PHY) 122. The choice of the type of the host interface 120 may depend on the type of the memory being used. Examples of the host interface 120 include, but are not limited to, SATA, SATA Express, Serial Attached SCSI (SAS), Fibre Channel, Universal Serial Bus (USB), PCIe, and NVMe. The host interface 120 generally facilitates the transfer of data, control signals, and timing signals.

[0049] The back-end module 110 includes an error correction code (ECC) engine 124 that encodes data bytes received from a host and decodes and corrects error of data bytes read from the non-volatile memory. A command sequencer 126 generates command sequences to be transmitted to the non-volatile memory die 104, such as programming and erase command sequences. A RAID (Redundant Array of Independent Disks) module 128 manages the generation of RAID parity and the recovery of failed data. The RAID parity may be used as an additional level of integrity protection for the data being written to the memory device 104. In some cases, the RAID module 128 may be part of the ECC engine 124. A memory interface 130 provides command sequences to the non-volatile memory die 104 and receives status information from the non-volatile memory die 104. In one embodiment, the memory interface 130 may be a double data rate (DDR) interface, such as a toggle mode 200, 400, or 800 interface. A flash control layer 132 controls the overall operation of the back-end module 110.

[0050] The data storage device 100 also includes other discrete components 140, such as an external electrical interface, external RAM, resistors, capacitors, or other components that may interface with the controller 102. In an alternative embodiment, one or more of the physical layer interface 122, the RAID module 128, the media management layer 138, and the buffer management / bus controller 114 are optional components that are not necessary in the controller 102.

[0051] Figure 2BFIG. 0 is a block diagram showing components of the non-volatile memory die 104 in more detail. The non-volatile memory die 104 includes a peripheral circuit 141 and a non-volatile memory array 142. The non-volatile memory array 142 includes non-volatile memory cells for storing data. The non-volatile memory cells can be any suitable non-volatile memory cells, including ReRAM, MRAM, PCM, NAND flash memory cells, and / or NOR flash memory cells in a two-dimensional and / or three-dimensional configuration. The non-volatile memory die 104 also includes a data cache 156 for caching data. The peripheral circuit 141 includes a state machine 152 that provides status information to the controller 102.

[0052] Returning again to Figure 2A , the flash control layer 132 (referred to herein as the flash translation layer (FTL), or more generally as the "media management layer" since the memory may not be flash) handles flash errors and interfaces with the host. In particular, the FTL (which can be an algorithm in firmware) is responsible for the internals of memory management and converts writes from the host into writes to the memory 104. The FTL may be needed because the memory 104 may have limited endurance, may only write in multiple pages, and / or may not write unless it is erased as a block. The FTL understands these potential limitations of the memory 104, which may be invisible to the host. Thus, the FTL attempts to convert writes from the host into writes to the memory 104.

[0053] The FTL can include a logical-to-physical address (L2P) mapping (sometimes referred to herein as a table or data structure) and an allocated cache memory. In this way, the FTL converts the logical block address ("LBA") from the host into a physical address in the memory 104. The FTL can include other features such as (but not limited to) power-fail recovery (so that the data structures of the FTL can be recovered in the event of a sudden power loss) and wear leveling (so that wear is evenly distributed across memory blocks to prevent some blocks from wearing out excessively, which would lead to a greater chance of failure).

[0054] Turning again to the drawings, Figure 3FIG. 0 is a block diagram of a host 300 and a data storage device 100 of an embodiment. The host 300 can take any suitable form, including but not limited to a computer, a mobile phone, a tablet, a wearable device, a digital video recorder, a monitoring system, etc. The host 300 (here a computing device) in this embodiment includes a processor 330 and a memory 340. In one embodiment, the computer-readable program code stored in the host memory 340 configures the host processor 330 to perform the actions described herein. Thus, the actions performed by the host 300 are sometimes referred to herein as being performed by an application program (computer-readable program code) running on the host 300. For example, the host 300 can be configured to send data (e.g., initially stored in the memory 340 of the host) to the data storage device 100 for storage in the memory 104 of the data storage device.

[0055] As described above, in some storage protocols, the data storage device 100 is allowed to utilize a specified portion of the volatile memory 340 in the host 300 specifically for the use of the controller 102. That is, the specified memory resources allocated on the host 300 are for the exclusive use of the controller 102 (e.g., the host software should not modify the range) until the host software requests the controller 102 to release the range. In one embodiment, the controller 102 is responsible for initializing the host memory resources. The use of this memory 340 (which is sometimes referred to as the host memory buffer (HMB)) can be vendor-specific. For example, in the Non-Volatile Memory Express (NVMe) specification, the host memory buffer is allocated for the exclusive use of the controller 102 of the data storage device, the host 300 does not actively modify or access the data in the host memory buffer 340 (i.e., the data is guaranteed to be valid), and the host 300 is obliged to notify the controller 102 of the data storage device before any operation that may cause data loss (e.g., in the case of power loss or when the host 300 may need the buffer) (in this case, the host 300 asks the controller 102 to confirm the operation before data loss). The HMB descriptor list on the host 300 can maintain a list of entries associated with the host data buffer for the exclusive use of the controller 102. During initialization, the host software can provide the HMB descriptor list to the data storage device 100 for the exclusive use of the controller 102.

[0056] Similarly as described above, the interface between the controller 102 and the host 300 can be a Peripheral Component Interconnect Express (PCIe) interface. A Single Root Input / Output Virtualization (SR-IOV) interface is an extension to the Peripheral Component Interconnect Express (PCIe) specification and allows a device such as a network adapter to individually access its resources among various PCIe hardware functions. The SR-IOV interface allows a PCIe device to act as multiple PCIe devices and introduces the concepts of Physical Functions (PFs) (full-featured PCIe functions) and Virtual Functions (VFs) ("lightweight" functions lacking some configuration resources). Figure 4 is a diagram of the SR-IOV interface of an embodiment. As Figure 4 shown, the system includes a root complex, CPU cores, a hypervisor having two Physical Functions (PFs), and two virtual machines (VM1, VM2) each having two Virtual Functions (VF1, VF2).

[0057] Each PF function can have Host Memory Buffer (HMB) space, which is currently shared equally among the VFs on demand. The HMB has "global" uses such as storing flash translation layer (FTL) data related to all VFs corresponding to the same PF, and "local" uses such as operating as a cache buffer (for data and control information) or storing read-look-ahead (RLA) or history pattern matcher (HPM) information individually related to each VF. There are many different uses for the VF space. For example, the VF space can be used as a cache buffer to cache FTL entries dedicated to the namespace specifically attached to the VF, to store recently read / written data or other "hot" data that can be used for faster performance, or to store control data such as NVMe-related pointers. The VF space can also be used for a read-look-ahead (RLA) mechanism to read data from the memory 104 prior to a host read command for the data, which can be used for sequential reads. Additionally, the VF space can be used for a history pattern matcher (HPM) RAM (HPM-RAM) to store tables used during the operation of predicting the next random read address prior to a host random read command by analyzing the history of the read patterns of the host random read commands. The controller 102 can allocate a different HPM-RAM budget for each VF and dynamically change the budget. It should be noted that these are merely examples, and other use cases can be used.

[0058] As described above, the NVMe standard supports the allocation of different HMBs for different physical functions. The current reference method is to unify all allocated HMB ranges into one large address space, at least for global use of the HMB (e.g., FTL tables). This method of connecting all allocated HMB RAM spaces into a unified address space is practical for simple handling of HMB RAM allocation; however, it does not utilize the diversity provided by the different sources of the allocated HMB RAM spaces. The following embodiments can be used to provide a hybrid method for handling multi-HMB allocations (from different hosts) to optimize the latency and performance of the data storage device 100.

[0059] In one embodiment, critical data (e.g., the logical-to-physical address table for hot zones) is copied and placed in several available HMBs. During a read, the controller 102 sends read commands to all HMBs and will use the first HMB available for the read. When the read commands are issued serially, the controller 102 can further track the first HMB to respond according to each typical workload and prioritize the command order accordingly, such that the first read command will be sent to the HMB with the fastest response with a similar workload latency. With this embodiment, even if one HMB is busy, a copy of the critical data can still be read from another HMB among the HMBs with low latency. In another embodiment, hybrid multi-HMB handling is available, where the unified address space method (which is easy to handle) can be used, but the multi-HMB method can also be used to compose the overall allocated HMB RAM to improve the response time and device performance.

[0060] Turning back to the drawings again, Figure 5 is a flowchart 500 of a method for an embodiment of contention-based data access in a multi-host memory buffer system. As Figure 5 shown, the controller 102 of the data storage device 100 determines whether certain data is critical (action 510). In this example, the critical data is part of the logical-to-physical address table (originally stored in the non-volatile memory 104) that relates to regions of logical addresses that are frequently accessed (i.e., "hot zones"). Critical data can be defined in any suitable manner. For example, the controller 102 can maintain a data structure listing the data or address ranges considered to be critical, or can provide some other threshold or criterion for evaluating whether a given data is critical.

[0061] When the controller 102 determines that the data is critical, the controller 102 places a copy of the data in several HMBs on the host 300 (action 520). In Figure 5In the example shown, copies of the data are stored in two HMBs (HMB1 and HMB2). Of course, this is just an example, and more than two HMBs can be used. Additionally, one of the "copies" of the data can be the "original" data. Thus, in this example, out of the two copies, one is the source data and the other is a copy of the source data. For convenience, the term "copy" will be used herein to refer to either data. When the controller 102 wants to read the data, the controller 102 sends read commands to all HMBs (action 530). In this example, since there are two HMBs, the controller 102 sends two read commands 540, 550. The controller 102 then selects the data from the first HMB that responds (action 560). As described above, the controller 102 can use this information to prioritize commands to the faster / fastest HMB in the future.

[0062] Now turning to Figure 6 , Figure 6 depicts an example when two HMBs are provided and their access attributes are different. As Figure 6 shown, when the data storage device 100 sends a command to the host 300, the switch (switch A) 610 in the host 300 is used to determine whether to route the command to the host processor 330 or to one of the HMBs. If the command is to access the first HMB 52, the command passes through a single switch (switch A) 610. However, if the command is to access the second HMB 54, the command passes through two switches (switch A and switch B) 610, 620. This means that the access latency is higher when accessing the second HMB 54. Additionally, there may be a scenario where switch A is almost idle while switch B is locally stressed. In this scenario, the access latency to the second HMB 54 will be even higher.

[0063] Figure 7 is a block diagram of an example implementation of the host 300 and the controller 102 that can be used to implement the above-described embodiments. As Figure 7As shown, in this example, the host 300 includes multiple host memory buffers (HMB A, HMB B, etc.). The controller 102 includes a host interface module 120, an encryption / decryption module 124, a data path error correction code (ECC) and redundant array of independent disks (RAID) module 125, and a flash interface module 130 that communicates with non-volatile memory (e.g., NAND) 104. The controller 102 also includes one or more processors 750 and a multi-HMB manager 700 that is responsible for the interaction and management of the HMBs. The multi-HMB manager 700 includes controllers for each HMB (e.g., HMB A controller, HMB B controller, etc.), HMB replication logic 720 (e.g., for detecting potential HMB hot data and replicating it across multiple HMBs), and monitor and statistics logic 730 (e.g., for monitoring HMB latency and statistical aggregates), which can be algorithmically adaptive based on history. The manager 700 can be implemented by one or more processors 750 executing computer-readable program code that can be stored in the controller 102 or elsewhere in the data storage device 100.

[0064] The following is an example statistical table for collecting statistics whenever multiple parallel HMBs are accessed to obtain the same data. For each workload, the number of times each HMB was the fastest is presented. Based on this information, the logic can be adapted to make more informed decisions.

[0065]

[0066] In one embodiment, if one HMB is always faster, the "replication" logic can be disabled. In another embodiment, the logic can still continue to store and obtain the same data with multiple HMBs, but the command ordering will be history-based.

[0067] There are several advantages associated with these embodiments. For example, these embodiments can be used to maximize the utilization of a multi-HMB environment while obtaining the minimum possible latency for critical items stored in the HMBs. This can have a direct impact on random read performance, especially in a low queue depth environment.

[0068] Finally, as described above, any suitable type of memory can be used. Semiconductor memory devices include volatile memory devices (such as dynamic random access memory (“DRAM”) or static random access memory (“SRAM”) devices), non-volatile memory devices (such as resistive random access memory (“ReRAM”), electrically erasable programmable read only memory (“EEPROM”), flash memory (which can also be considered a subset of EEPROM), ferroelectric random access memory (“FRAM”), and magnetoresistive random access memory (“MRAM”)), and other semiconductor elements capable of storing information. Each type of memory device can have a different configuration. For example, a flash memory device can be configured in a NAND or NOR configuration.

[0069] Memory devices can be formed from passive and / or active elements in any combination. As a non-limiting example, passive semiconductor memory elements include ReRAM device elements, which in some embodiments include resistivity switching memory elements such as antifuses, phase change materials, etc., and optionally include manipulation elements such as diodes. Additionally as a non-limiting example, active semiconductor memory elements include EEPROM and flash memory devices, which in some embodiments include elements containing charge storage regions such as floating gates, conductive nanoparticles, or charge storage dielectric materials.

[0070] Multiple memory elements can be configured such that they are connected in series or such that each element is individually accessible. As a non-limiting example, flash memory devices in a NAND configuration (NAND memories) typically contain memory elements connected in series. A NAND memory array can be configured such that the array consists of multiple memory strings, where a string consists of multiple memory elements sharing a single bit line and accessed as a group. Alternatively, the memory elements can be configured such that each element is individually accessible, for example, a NOR memory array. NAND and NOR memory configurations are examples, and the memory elements can be configured in other ways.

[0071] Semiconductor memory elements located within and / or on a substrate can be arranged in a two-dimensional or three-dimensional manner, such as a two-dimensional memory structure or a three-dimensional memory structure.

[0072] In a two-dimensional memory structure, semiconductor memory elements are arranged in a single plane or a single memory device level. Generally, in a two-dimensional memory structure, the memory elements are arranged in a plane that extends substantially parallel to the main surface of the substrate that supports the memory elements (e.g., in the x-z plane). The substrate can be a wafer on which or in which a layer of memory elements is formed, or the substrate can be a carrier substrate that is attached to the memory elements after the memory elements are formed. As a non-limiting example, the substrate can include a semiconductor such as silicon.

[0073] Memory elements can be arranged in an ordered array (such as, in multiple rows and / or columns) within a single memory device level. However, the memory elements can be arranged in a non-regular or non-orthogonal configuration. Each memory element can have two or more electrodes or contact lines, such as bit lines and word lines.

[0074] A three-dimensional memory array is arranged such that the memory elements occupy multiple planes or multiple memory device levels, thereby forming a three-dimensional structure (i.e., in the x, y, and z directions, where the y direction is substantially perpendicular to the main surface of the substrate and the x and z directions are substantially parallel to the main surface of the substrate).

[0075] As a non-limiting example, a three-dimensional memory structure can be vertically arranged as a stack of multiple two-dimensional memory device levels. As another non-limiting example, a three-dimensional memory array can be arranged as multiple vertical columns (e.g., columns that extend substantially perpendicular to the main surface of the substrate (i.e., in the y direction)), where each column has multiple memory elements. The columns can be arranged in a two-dimensional configuration (e.g., in the x-z plane), thereby resulting in a three-dimensional arrangement of memory elements with elements on multiple vertically stacked memory planes. Other configurations of three-dimensional memory elements can also constitute a three-dimensional memory array.

[0076] As a non-limiting example, in a three-dimensional NAND memory array, the memory elements can be coupled together to form a NAND string within a single horizontal (e.g., x-z) memory device level. Alternatively, the memory elements can be coupled together to form a vertical NAND string that spans multiple horizontal memory device levels. Other three-dimensional configurations can be envisioned, where some NAND strings contain memory elements within a single memory level, while other strings contain memory elements that span multiple memory levels. A three-dimensional memory array can also be designed in a NOR configuration and a ReRAM configuration.

[0077] Typically, in a monolithic three-dimensional memory array, one or more memory device levels are formed above a single substrate. Optionally, a monolithic three-dimensional memory array can also have one or more memory layers at least partially within a single substrate. As a non-limiting example, the substrate can include a semiconductor such as silicon. In a monolithic three-dimensional array, the layers that make up each memory device level of the array are typically formed on the layers of the underlying memory device level of the array. However, the layers of adjacent memory device levels of a monolithic three-dimensional memory array can share or have intervening layers between the memory device levels.

[0078] Again, two-dimensional arrays can be formed separately and then packaged together to form a non-monolithic memory device with multiple memory layers. For example, a non-monolithic stacked memory can be constructed by forming memory levels on separate substrates and then stacking the memory levels on top of each other. The substrate can be thinned or removed from the memory device level before stacking, but since the memory device levels are initially formed on separate substrates, the resulting memory array is not a monolithic three-dimensional memory array. Additionally, multiple two-dimensional memory arrays or three-dimensional memory arrays (monolithic or non-monolithic) can be formed on separate chips and then packaged together to form a stacked chip memory device.

[0079] The operation of memory elements and communication with memory elements typically require associated circuitry. As a non-limiting example, a memory device can have circuitry for controlling and driving the memory elements to perform functions such as programming and reading. This associated circuitry can be on the same substrate as the memory elements and / or on a separate substrate. For example, a controller for memory read and write operations can be located on a separate controller chip and / or on the same substrate as the memory elements.

[0080] Those skilled in the art will recognize that the present invention is not limited to the two-dimensional and three-dimensional structures described, but encompasses all relevant memory structures within the spirit and scope of the present invention as described herein and as understood by those skilled in the art.

[0081] The foregoing detailed description is to be understood as illustrative of selected forms that the invention can take, and not as a definition of the invention. Only the following claims (including all equivalents) are intended to define the scope of the claimed invention. Finally, it should be noted that any aspect of any embodiment described herein can be used alone or in combination with each other.

Claims

1. A data storage device, the data storage device comprises: a memory; an interface configured to communicate with a host including a plurality of host memory buffers; and a controller configured to communicate with the memory and the interface, wherein the controller is further configured to: determine whether data should be stored in only one of the plurality of host memory buffers or in all of the plurality of host memory buffers; and in response to determining that the data should be stored in all of the plurality of host memory buffers, store the data in all of the plurality of host memory buffers.

2. The data storage device according to claim 1, wherein the controller is further configured to: send a read command to all of the plurality of host memory buffers to read the data.

3. The data storage device according to claim 2, wherein the controller is further configured to: track which one of the plurality of host memory buffers first returns the data; and prioritize future read commands to the one host memory buffer among the plurality of host memory buffers.

4. The data storage device according to claim 3, wherein the controller is further configured to: track the workload presented when sending the read command to all of the plurality of host memory buffers; and prioritize the future read command in response to the workload presented when sending the future read command matching the workload presented when sending the read command to all of the plurality of host memory buffers.

5. The data storage device according to claim 1, wherein the controller is further configured to determine that the data should be stored in all of the plurality of host memory buffers in response to determining that the data includes critical data.

6. The data storage device according to claim 1, wherein the controller is further configured to determine that the data should be stored in all of the plurality of host memory buffers in response to determining that the data includes a logical-to-physical address table related to a frequently accessed area.

7. The data storage device according to claim 1, wherein the controller is further configured to communicate with a first host memory buffer among the plurality of host memory buffers via a first switch in the host and communicate with a second host memory buffer among the plurality of host memory buffers via a second switch in the host.

8. The data storage device according to claim 1, wherein the controller comprises: a plurality of host memory buffer controllers; host memory buffer replication logic; and a statistical monitoring module.

9. The data storage device according to claim 1, wherein the plurality of host memory buffers have a unified address space.

10. The data storage device according to claim 1, wherein each of the host memory buffers is associated with a different virtual function.

11. The data storage device according to claim 1, wherein the host includes a single root input / output virtualization (SR-IOV) interface.

12. The data storage device according to claim 1, wherein the memory includes a three-dimensional memory.

13. A method, the method comprising: performing the following operations in a data storage device communicating with a host including a plurality of host memory buffers, each host memory buffer being associated with a different virtual function: storing data associated with one of the plurality of virtual functions in all of the plurality of host memory buffers rather than only in the host memory buffer associated with the one of the plurality of virtual functions; sending a read command to the plurality of host memory buffers to read the data; and tracking the order in which the plurality of host memory buffers return the data.

14. The method according to claim 13, the method further comprising determining that the data should be stored in the plurality of host memory buffers rather than only in the host memory buffer associated with the one of the plurality of virtual functions.

15. The method according to claim 13, wherein the read command is sent serially to the plurality of host memory buffers.

16. The method according to claim 13, the method further comprising prioritizing future read commands to one of the plurality of host memory buffers.

17. The method according to claim 13, wherein the data includes a logical-to-physical address table related to a frequently accessed area.

18. The method according to claim 13, wherein the plurality of host memory buffers have a unified address space.

19. The method according to claim 13, wherein the host includes a single root input / output virtualization (SR-IOV) interface.

20. A data storage device, the data storage device comprising: a memory; an interface configured to communicate with a host including a plurality of host memory buffers and a plurality of virtual functions; means for storing data associated with one of the plurality of virtual functions in all of the plurality of host memory buffers rather than only in the host memory buffer associated with the one of the plurality of virtual functions; means for sending a read command to the plurality of host memory buffers to read the data; and means for prioritizing future read commands to the host memory buffer that first responds to the read command among the plurality of host memory buffers.

Images