Data storage device and method for dynamic controller memory buffer allocation

Abstract

A data storage device and method for dynamic controller memory buffer allocation is disclosed. In one embodiment, a data storage device is provided comprising a memory and a controller having a controller memory buffer. The controller is configured to communicate with the non-volatile memory and is further configured to configure a size of the controller memory buffer, receive a request from a host to modify the size of the controller memory buffer during operation of the data storage device, and determine whether to grant the request to modify the size of the controller memory buffer. Other embodiments are possible, and each of the embodiments can be used alone or together in combination.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Non-Provisional Patent Application No. 18 / 223,144, entitled "Data Storage Device and Method for Dynamic Controller Memory Buffer Allocation," filed with the U.S. Patent and Trademark Office on July 18, 2023, which claims priority to U.S. Provisional Patent Application No. 63 / 437,171, filed on January 5, 2023, the entire contents of which are incorporated herein by reference for all purposes. [Background technology]

[0002] A host can store data in and read data from memory within a data storage device. The data storage device may include a controller that facilitates read and write operations to the memory. The controller may include volatile memory referred to as a controller memory buffer. The size of the controller memory buffer is set by the data storage device during boot-up and remains constant during operation of the data storage device. [Brief explanation of the drawings]

[0003] [Figure 1A] FIG. 2 is a block diagram of a data storage device according to an embodiment. [Figure 1B] FIG. 2 is a block diagram illustrating a storage module of one embodiment. [Figure 1C] FIG. 1 is a block diagram illustrating a hierarchical storage system of one embodiment. [Figure 2A] 1B is a block diagram illustrating components of a controller of the data storage device illustrated in FIG. 1A according to one embodiment. [Figure 2B] 1B is a block diagram illustrating components of the memory data storage device illustrated in FIG. 1A, according to one embodiment. [Figure 3]FIG. 2 is a block diagram of a host and a data storage device of one embodiment. [Figure 4] FIG. 2 is a block diagram of a host and a controller according to one embodiment. [Figure 5] 1 is a flowchart of an embodiment of a method for dynamic controller memory buffer allocation by a host. [Figure 6] 1 is a flowchart of an embodiment method for dynamic controller memory buffer allocation by a data storage device. DETAILED DESCRIPTION OF THE INVENTION

[0004] overview By way of introduction, the following embodiments relate to a data storage device and method for dynamic controller memory buffer allocation. In one embodiment, a data storage device is provided that includes a non-volatile memory and a controller that includes a controller memory buffer. The controller is configured to communicate with the non-volatile memory and is further configured to configure a size of the controller memory buffer, receive a request from a host to modify the size of the controller memory buffer during operation of the data storage device, and determine whether to grant the request to modify the size of the controller memory buffer.

[0005] In some embodiments, the controller is further configured to use excess space in the controller memory buffer that is not being used by the host.

[0006] In some embodiments, the controller is further configured to consider the workload when determining whether to grant the request.

[0007] In some embodiments, the request includes a dedicated command.

[0008] In some embodiments, the controller and the host each include a respective controller memory buffer allocation module.

[0009] In some embodiments, the controller is further configured to, in response to a request to increase the size of the controller memory buffer beyond its maximum size, deny the request.

[0010] In some embodiments, the controller is further configured to evict data in the controller memory buffer in order to grant the request.

[0011] In some embodiments, the controller is further configured to prioritize data in the controller memory buffer for eviction.

[0012] In some embodiments, the controller is further configured to send a confirmation to the host after granting the request.

[0013] In some embodiments, the non-volatile memory comprises a three-dimensional memory.

[0014] In another embodiment, a method executed in a host in communication with a data storage device including a controller having a controller memory buffer is provided, the method including instructing the data storage device to configure a size of the controller memory buffer, receiving a request from the data storage device to modify the size of the controller memory buffer, and determining whether to grant the request from the data storage device to modify the size of the controller memory buffer.

[0015] In some embodiments, the data storage device is configured to use excess space in the controller memory buffer that is not being used by the host.

[0016] In some embodiments, workload is taken into consideration when determining whether to grant a request.

[0017] In some embodiments, the request includes a dedicated command.

[0018] In some embodiments, the controller and the host each include a respective controller memory buffer allocation module.

[0019] In some embodiments, the method further includes determining, in response to a request to increase the size of the controller memory buffer beyond its maximum size, to deny the request.

[0020] In some embodiments, the method further includes causing data to be purged from the controller memory buffer in order to grant the request.

[0021] In some embodiments, the method further includes causing prioritization of data for eviction.

[0022] In some embodiments, the method further includes sending a confirmation to the data storage device after granting the request.

[0023] In another embodiment, a data storage device is provided, comprising: a non-volatile memory; a controller configured to communicate with the non-volatile memory and comprising a controller memory buffer; and means for changing the size of the controller memory buffer from an initial size to a modified size during operation of the data storage device.

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

[0025] Embodiment The following embodiments relate to data storage devices (DSDs). As used herein, "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 exemplary DSDs are provided below.

[0026] A data storage device suitable for use in implementing aspects of these embodiments is shown in Figures 1A-1C. Figure 1A is a block diagram illustrating a data storage device 100 in accordance with one embodiment of the subject matter described herein. Referring to Figure 1A, the data storage device 100 includes a controller 102 and non-volatile memory, which may be comprised of one or more non-volatile memory dies 104. As used herein, the term die refers to a collection of non-volatile memory cells and associated circuitry for managing the physical operation of those non-volatile memory cells formed on a single semiconductor substrate. The controller 102 interfaces with a host system and sends command sequences for read, program, and erase operations to the non-volatile memory dies 104.

[0027] The controller 102 (which may be a non-volatile memory controller (e.g., flash, resistive random-access memory (ReRAM), phase-change memory (PCM), or magnetoresistive random-access memory (MRAM) controller)) may take the form of, for example, a processing circuit, a microprocessor or processor, and a computer-readable medium storing computer-readable program code (e.g., firmware) executable by (micro)processors, logic gates, switches, application specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. The controller 102 may be configured with hardware and / or firmware to perform the various functions described below and illustrated in the flow diagrams. Also, some of the components shown as internal to the controller may be stored external to the controller, and other components may be used. Additionally, the phrase "in operative communication with" can mean in direct communication with one or more components, or indirect communication (wired or wireless) through one or more components, which may or may not be shown or described herein.

[0028] As used herein, a nonvolatile memory controller is a device that manages data stored on nonvolatile memory and communicates with a host, such as a computer or electronic device. A nonvolatile memory controller can have a variety of functions in addition to the specific functions described herein. For example, the nonvolatile memory controller can format the nonvolatile memory to ensure the memory is operating properly, map out defective nonvolatile memory cells, and allocate spare cells to replace future failed cells. Some of the spare cells can be used to hold firmware for operating the nonvolatile memory controller and implementing other features. During operation, a host can communicate with the nonvolatile memory controller when it needs to read data from or write data to the nonvolatile memory. When the host provides a logical address where data is to be read / written, the nonvolatile memory controller can translate the logical address received from the host into a physical address in the nonvolatile memory. (Alternatively, the host can provide the physical address.) The non-volatile memory controller can also perform various memory management functions, such as, but not limited to, wear leveling (distributing writes to avoid wearing out particular blocks of memory that would otherwise be written to repeatedly) and garbage collection (moving only valid pages of data to a new block after a block becomes full so that the full block can be erased and reused).

[0029] 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 programmable once, a few times, or many times. The memory cells may also be single-level cells (SLC), multi-level cells (MLC) (e.g., dual-level cells, triple-level cells (TLC), quad-level cells (QLC), etc.), or may use other memory cell level technologies now known or later developed. The memory cells may also be fabricated using two-dimensional or three-dimensional methods.

[0030] The interface between the controller 102 and the non-volatile memory die 104 may be any suitable flash interface, such as toggle mode 200, 400, or 800. In one embodiment, the data storage device 100 may be a solid-state drive. In another embodiment, the data storage device 100 may be part of an embedded data storage device.

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

[0032] 1B illustrates a storage module 200 including multiple non-volatile data storage devices 100. Accordingly, the storage module 200 may include a storage controller 202 that interfaces with a host and a data storage device 204 including multiple 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. The storage module 200, in one embodiment, may be a solid-state drive (SSD) or a non-volatile dual in-line memory module (NVDIMM) such as those found in server PCs or portable computing devices such as laptop computers and tablet computers.

[0033] FIG. 1C is a block diagram illustrating a hierarchical storage system. The hierarchical storage system 250 includes multiple storage controllers 202, each of which controls a respective data storage device 204. A host system 252 may access memory in the storage system 250 through a bus interface. In one embodiment, the bus interface may be a Non-Volatile Memory Express (NVMe) or Fibre Channel over Ethernet (FCoE) interface. In one embodiment, the system illustrated in FIG. 1C may be a rack-mountable mass storage system accessible by multiple host computers, such as those found in data centers or other locations where mass storage is needed.

[0034] 2A is a block diagram illustrating 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 the functions described in detail herein. The modules may take the form of, for example, packaged functional hardware units designed for use with other components, portions of program code (e.g., software or firmware) executable by a (micro)processor or processing circuitry that typically performs specific functions of the associated functionality, or self-contained hardware or software components that interface with a larger system. Additionally, the "means" for performing a function may be implemented using at least one of the structures described herein for the controller and may be pure hardware or a combination of hardware and computer-readable program code.

[0035] Referring again to the modules of controller 102, buffer manager / bus controller 114 manages buffers in random access memory (RAM) 116 and controls internal bus arbitration for controller 102. Read only memory (ROM) 118 stores system boot code. While illustrated in FIG. 2A as being located separately from controller 102, in other embodiments, one or both of RAM 116 and ROM 118 may be located within the controller. In still other embodiments, portions of the RAM and ROM may be located both within and outside of controller 102.

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

[0037] The back-end module 110 includes an error correction code (ECC) engine 124 that encodes data bytes received from the host and decodes and corrects errors in data bytes read from the non-volatile memory. A command sequencer 126 generates command sequences, such as program and erase command sequences, that are sent to the non-volatile memory die 104. A redundant array of independent drives (RAID) module 128 manages the generation of RAID parity and the recovery of failed data. RAID parity can be used as an additional level of integrity protection for data being written to the memory device 104. In some cases, the RAID module 128 can 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 can be a double data rate (DDR) interface, such as a toggle mode 200, 400, or 800 interface. The flash control layer 132 controls the overall operation of the backend module 110 .

[0038] 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 controller 102. In alternative embodiments, one or more of physical layer interface 122, RAID module 128, media management layer 138, and buffer management / bus controller 114 are optional components not required for controller 102.

[0039] 2B is a block diagram illustrating the components of the non-volatile memory die 104 in more detail. The non-volatile memory die 104 includes peripheral circuits 141 and a non-volatile memory array 142. The non-volatile memory array 142 includes non-volatile memory cells used to store data. The non-volatile memory cells may be any suitable non-volatile memory cells, including ReRAM, MRAM, PCM, NAND flash memory cells, and / or NOR flash memory cells in two-dimensional and / or three-dimensional configurations. The non-volatile memory die 104 further includes a data cache 156 for caching data. The peripheral circuits 141 include a state machine 152 that provides status information to the controller 102.

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

[0041] The FTL may include a logical-to-physical address (L2P) map (sometimes referred to herein as a table or data structure) and allocated cache memory. In this manner, the FTL translates logical block addresses ("LBA") from the host into physical addresses in memory 104. The FTL may include other features such as, but not limited to, power-off recovery (so that the FTL's data structures can be recovered in the event of a sudden power loss) and wear leveling (so that wear across memory blocks is uniform to prevent excessive wear in any one block that would result in a greater likelihood of failure).

[0042] Referring again to the drawings, FIG. 3 is a block diagram of a host 300 and a data storage device 100 in one embodiment. The host 300 may take any suitable form, including, but not limited to, a computer, a mobile phone, a tablet, a wearable device, a digital video recorder, a surveillance system, etc. The host 300 (here, a computing device) in this embodiment comprises a processor 330 and a memory 340. In one embodiment, computer-readable program code stored in the host memory 340 configures the host processor 330 to perform the operations described herein. Accordingly, actions performed by the host 300 may be referred to herein as being performed by an application (computer-readable program code) executing on the host 300. For example, the host 300 may be configured to send data (e.g., initially stored in the host's memory 340) to the data storage device 100 for storage in the data storage device's memory 104.

[0043] 2A, the controller 102 in this embodiment also includes volatile memory (e.g., DRAM) referred to herein as a controller memory buffer (CMB) 103. In one embodiment, the CMB 103 is a general-purpose read / write memory that can be used by the data storage device 100 and / or by the host 300 for any suitable purpose, including, but not limited to, caching portions of the logical-to-physical address map stored in non-volatile memory 104, storing submission and / or completion queues, storing control or other data, etc.

[0044] The following paragraphs provide details of the implementation of the CMB 103 under the NVMe specification. It should be understood that these details are provided merely as examples, and that no details discussed herein (related to the NVMe specification or otherwise) should be read into the claims unless explicitly stated.

[0045] In one embodiment, the controller 102 indicates support for the CMB 103 by setting CAP.CMBS to "1." When this bit is set to "1," the controller 102 indicates the properties of the CMB 103 via the CMBLOC and CMBSZ properties. The host 300 indicates its intent to use the CMB 102 by setting CMBMSC.CRE to "1." As mentioned above, the CMB 103 can be used for various purposes, and the controller 102 can indicate which purposes the CMB 103 can be used for by setting the support flag in the CMBSZ property. The PCI Express address range of the CMB can be used for external memory read and write requests to the CMB 103. The PCI Express base address of the CMB 103 can be defined by the PCI Base Address Register (BAR), indicated by CMBLOC.BIR, and the offset can be indicated by CMBLOC.OFST. The size of the CMB 103 can be indicated by CMBSZ.SZ. The controller 102 can reference the CMB 103 at an address provided by the host 300 using the CMB's controller address range. Although the PCI Express address range and the CMB 103's controller address range may differ, both ranges can have the same size and equivalent offsets within each range can have a one-to-one correspondence.

[0046] The host 300 can configure the controller address range via the CMBMSC property. The host 300 can enable the controller memory space of the CMB via the CMBMSC.CMSE bit. Once the controller memory space is enabled, if the host 300 supplies an address that references the controller address range of the CMB, the controller 102 can direct memory read or write requests for this address to the CMB 103. The CMB 103 can be used by the host 300 to store a submission queue so that the controller 102 can read the address directly from the CMB 103 when a read command is issued. A completion queue in the CMB 103 can be used for peer-to-peer or other applications. For writes of small amounts of data, it can be advantageous to have the host 300 write the data and / or metadata to the CMB 103 rather than having the controller 102 fetch the data and / or metadata from the host memory 340.

[0047] The controller 102 may support physical region pages (PRPs) and scatter gather lists (SGLs) within the CMB 103. If the CMBLOC.CDPMLS bit is cleared to '0', for a particular PRP list or SGL associated with a single command, all memory associated with the PRP list or SGL can be located entirely within the CMB 103 or entirely outside the CMB 103. The controller 102 may support data and metadata within the CMB 103. If the CMBLOC.CDMMMS bit is cleared to '0', all data and metadata, if any, associated with a particular command can be located either entirely within the CMB 103 or entirely outside the CMB 103. The address space allocated for the CMB 103 may be 4 KiB aligned. The controller 102 may allocate the CMB 103 on an 8 KiB boundary. The controller 102 supports burst transactions up to the maximum payload size, supports byte enables, and can support any byte alignment.

[0048] The size of CMB 103 can be indicated by the CMBSZ.SZ field from the NVMe specification. This configuration is set during boot by data storage device 100. The size of CMB 103 remains constant during operation of data storage device 100, and the space dedicated to CMB 103 can remain empty if host 300 does not utilize it.

[0049] The following embodiments can be used to modify the size of CMB 103 during operation of data storage device 100. These embodiments can improve the flexibility of CMB implementation and DRAM utilization, resulting in faster high-end storage controller operation. In one embodiment, host 300 can modify the CMB size according to its current needs and conditions, and data storage device 100 can use the excess space in CMB 103 when host 300 does not need it (and coordinate operations with host 300 to better utilize controller RAM). In one embodiment, a modified interface between host 300 and data storage device 100 can be used, and host 300 can use a dedicated command to indicate the CMB size required for its operation (e.g., larger or smaller than the currently used CMB size). To do this, host 300 can have a host CMB allocation module 55, and controller 102 in data storage device 100 can have a storage controller CMB allocation module 455 (see FIG. 4). Storage controller CMB allocation module 455, which may be computer-readable program code executed by a processor in controller 102, may control CMB size according to a host command or another triggering event (e.g., to dynamically change the host control address). Host CMB allocation module 55, which may be computer-readable program code executed by processor 330 in host 300, may issue and receive commands related to CMB size modification.

[0050] The allocation module 55, 455 can take into account the current workload to change the CMB size according to the expected load. For example, in a low-intensity workload with short lengths of data, the data storage device 100 may decide to use the CMB 103 to store user data because the CMB is relatively small and the associated overhead is not large. In a high-intensity, long sequential workload, CMB transfers and fetches may have additional unnecessary overhead that the host 300 can avoid, while the host 300 can use the CMB 103 for its own purposes.

[0051] 5 is a flowchart 500 of an embodiment method for dynamic controller memory buffer allocation by host 300. As shown in FIG. 5, initially, host 300 sets some initial CMB size (and / or objective) (operation 510). Then, after some workload change or other trigger (e.g., environmental change, change in workload locality, power instability, bit error rate (BER) increase, etc.), host CMB allocation module 55 issues a command to change the CMB size (and / or objective) (operation 520). Controller CMB allocation module 455 then analyzes current CMB usage and, depending on host 300, confirms or denies the request (operation 530). For example, if host 300 is requesting to expand CMB 103 beyond its maximum size, controller CMB allocation module 455 can deny the request (operation 540). However, if controller CMB allocation module 455 can grant the request, controller CMB allocation module 455 modifies the CMB size accordingly (operation 550). This may include evicting some of the controller data currently residing in DRAM to free up space. Controller CMB allocation module 455 may prioritize which data can be evicted with minimal impact to controller performance. After freeing up the corresponding space requested by host 300, controller CMB allocation module 455 may return a confirmation note to host 300 (operation 560).

[0052] FIG. 6 is a flowchart 600 of one embodiment method for dynamic controller memory buffer allocation by data storage device 100. In this embodiment, controller 102 may issue a request to modify the CMB size. The request may come in the form of an asynchronous event and may be triggered by the controller needing to use DRAM (such as some critical management operation, identification of an abnormally low hit rate for controller metadata cached in DRAM, or identification that host 300 has not fully used the allocated space for an extended period of time). As shown in FIG. 6, first, host 300 sets some initial CMB size (and / or objective) (operation 610). Then, after a critical management operation or other trigger, controller CMB allocation module 455 issues an asynchronous event to host 300 to change the CMB size (operation 620). Host CMB allocation module 55 then responds to the controller command (operation 630). For example, if the controller 102 requests that the CMB 103 be expanded beyond its maximum size, the host CMB allocation module 55 may deny the request (operation 640). However, if the host CMB allocation module 55 can grant the request, the host CMB allocation module 55 modifies the CMB size accordingly (operation 650). The controller CMB allocation module 455 then issues an asynchronous event to the host 300 to use the modified CMB size (operation 660).

[0053] There are several advantages associated with these embodiments. For example, when CMBs are used in certain NVMe data storage devices to support high-throughput use cases, these embodiments can be used to enable better integration of the CMBs with those data storage devices. This can improve utilization of those CMBs / DRAM, resulting in reduced power consumption and improved performance in certain workloads.

[0054] Finally, as mentioned 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"), as well as other semiconductor elements capable of storing information. Each type of memory device can have a different configuration. For example, flash memory devices can be configured in a NAND or NOR configuration.

[0055] Memory devices can be formed from passive and / or active elements in any combination. By way of non-limiting example, passive semiconductor memory elements include ReRAM device elements, which in some embodiments include a resistivity-switching storage element such as an antifuse, a phase-change material, and optionally a steering element such as a diode. Further, by way of non-limiting example, active semiconductor memory elements include EEPROM and flash memory device elements, which in some embodiments include elements that include charge storage regions such as floating gates, conductive nanoparticles, or charge storage dielectric materials.

[0056] Multiple memory elements may be configured so that they are connected in series or so that each element is individually accessible. As a non-limiting example, a NAND-configured flash memory device (NAND memory) typically includes memory elements connected in series. A NAND memory array may be configured so that the array is made up of multiple strings of memory, where a string is made up of multiple memory elements that share a single bit line and are accessed as a group. Alternatively, the memory elements may be configured so that each element is individually accessible (e.g., a NOR memory array). NAND and NOR memory configurations are examples, and memory elements may be configured in other ways.

[0057] The semiconductor memory elements located in and / or on the substrate may be arranged in two or three dimensions, such as in a two or three dimensional memory structure.

[0058] In a two-dimensional memory structure, semiconductor memory elements are arranged in a single plane or a single memory device level. Typically, in a two-dimensional memory structure, the memory elements are arranged in a plane (e.g., an xz-direction plane) that extends substantially parallel to a major surface of a substrate that supports the memory elements. The substrate may be a wafer on or in which a layer of memory elements is formed, or may be a carrier substrate to which the memory elements are attached after they are formed. As a non-limiting example, the substrate may include a semiconductor such as silicon.

[0059] The memory elements may be arranged in an ordered array, such as multiple rows and / or columns, in a single memory device level. However, the memory elements may be arranged in an irregular or non-orthogonal configuration. The memory elements may each have two or more electrodes or contact lines, such as bit lines and word lines.

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

[0061] As a non-limiting example, a three-dimensional memory structure can be arranged vertically 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 extending substantially perpendicular to the major surface of the substrate, i.e., in the y-direction), with each column having multiple memory elements within each column. The columns can be arranged in a two-dimensional configuration, e.g., in the xz plane, 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 make up a three-dimensional memory array.

[0062] As a non-limiting example, in a three-dimensional NAND memory array, memory elements can be coupled together to form NAND strings within a single horizontal (e.g., xz) memory device level. Alternatively, memory elements can be coupled together to form vertical NAND strings that traverse multiple horizontal memory device levels. Other three-dimensional configurations can be envisioned, in which some NAND strings contain memory elements within a single memory level and other strings contain memory elements that span multiple memory levels. Three-dimensional memory arrays can also be designed in NOR and ReRAM configurations.

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

[0064] Again, two-dimensional arrays can be formed separately and then packaged together to form a non-monolithic memory device having 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 may be thinned or removed from the memory device levels before stacking, but the resulting memory array is not a monolithic three-dimensional memory array because the memory device levels are first formed on separate substrates. Furthermore, multiple two-dimensional 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.

[0065] Associated circuitry is typically required for operation of and communication with the memory elements. As a non-limiting example, a memory device may have circuitry used to control and drive the memory elements to accomplish functions such as programming and reading. This associated circuitry may be on the same substrate as the memory elements and / or on a separate substrate. For example, a controller for memory read-write operations may be located on a separate controller chip and / or on the same substrate as the memory elements.

[0066] Those skilled in the art will recognize that the present invention is not limited to the two-dimensional and three-dimensional structures described, but rather 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.

[0067] The foregoing detailed description is intended to be understood as an illustration of selected forms that the invention can take, rather than as a definition of the invention. It is only the following claims, including all equivalents, that are intended to define the scope of the invention as claimed. Finally, it should be noted that any aspect of any of the embodiments described herein can be used alone or in combination with each other.

Claims

1. 1. A data storage device comprising: a non-volatile memory; a controller comprising a controller memory buffer, the controller configured to communicate with the non-volatile memory; and configuring the size of the controller memory buffer; receiving a request from a host to modify the size of the controller memory buffer during operation of the data storage device; The data storage device is further configured to determine whether to grant the request to modify the size of the controller memory buffer.

2. 10. The data storage device of claim 1, wherein the controller is further configured to use excess space in the controller memory buffer that is not being used by the host.

3. The data storage device of claim 1 , wherein the controller is further configured to consider workload when determining whether to grant the request.

4. The data storage device of claim 1 , wherein the request comprises a dedicated command.

5. 10. The data storage device of claim 1, wherein the controller and the host each include a respective controller memory buffer allocation module.

6. 10. The data storage device of claim 1, wherein the controller is further configured, in response to the request to expand the size of the controller memory buffer beyond its maximum size, to deny the request.

7. 2. The data storage device of claim 1, wherein the controller is further configured to evict data in the controller memory buffer to grant the request.

8. The data storage device of claim 7 , wherein the controller is further configured to prioritize data in the controller memory buffer for eviction.

9. The data storage device of claim 1 , wherein the controller is further configured to send a confirmation to the host after granting the request.

10. The data storage device of claim 1 , wherein the non-volatile memory comprises a three-dimensional memory.

11. 1. A method comprising:

1. A host in communication with a data storage device having a controller with a controller memory buffer, instructing the data storage device to configure the size of the controller memory buffer; receiving a request from the data storage device to modify the size of the controller memory buffer; determining whether to grant the request from the data storage device to modify the size of the controller memory buffer.

12. 12. The method of claim 11, wherein the data storage device is configured to use excess space in the controller memory buffer that is not being used by the host.

13. The method of claim 11 , wherein workload is taken into consideration when determining whether to grant the request.

14. The method of claim 11 , wherein the request comprises a proprietary command.

15. The method of claim 11 , wherein the controller and host each include a respective controller memory buffer allocation module.

16. 12. The method of claim 11, further comprising, in response to the request to expand the size of the controller memory buffer beyond its maximum size, determining to deny the request.

17. 12. The method of claim 11, further comprising: causing data to be purged from the controller memory buffer to grant the request.

18. 20. The method of claim 17, further comprising causing prioritization of data for eviction.

19. The method of claim 11 , further comprising sending a confirmation to the data storage device after granting the request.

20. 1. A data storage device comprising: a non-volatile memory; a controller configured to communicate with the non-volatile memory and comprising a controller memory buffer; means for changing the size of the controller memory buffer from an initial size to a modified size during operation of the data storage device.

Images