Controller memory buffer (CMB) as a cache

Abstract

This provides a data storage device that utilizes the controller memory buffer (CMB) more efficiently. [Solution] In a memory system, the CMB is used by the host for many purposes. One such purpose is to have data placed in the CMB in response to a read command. Data is read from a memory device and placed in the CMB, but the data storage device may prefetch the data for efficiency purposes, and the prefetched data is stored in volatile memory separate from the CMB, but in many cases it is stored in dynamic random access memory (DRAM), and the CMB is part of the DRAM. Rather than copying the data from the DRAM and restoring the data to the CMB, the data storage device can simply provide the DRAM address without moving the data to the CMB, thus eliminating the step of copying the data from the DRAM to the CMB.

Description

Technical Field

[0001] Embodiments of the present disclosure generally relate to efficient utilization of a controller memory buffer (CMB).

Background Art

[0002] Description of Related Art Some forms of non-volatile memory (NVM) express (NVMe) solid state drives (SSDs) hold local dynamic random access memory (DRAM), and a portion of the DRAM is used as a controller memory buffer (CMB). The CMB is a function for a data storage device to hold some local memory for use by a host device. The CMB is managed by the host device. The CMB can be used for a submission queue (SQ), a completion queue (CQ), a physical region page (PRP) / scatter gather list (SGL) (physical region page / scatter gather list, PRP / SGL) list, and most commonly used user data.

[0003] When a host device issues an input / output (I / O) command, the host device can indicate the CMB as the location of the data. In the case of a read command, for example, when the controller sends a completion, the host device knows that the data is in the CMB, and the host device can read the data using MemRd instead of an NVMe I / O command.

[0004] Some data storage devices perform a prefetch process, in which the data storage device attempts to predict what the host device will read next. In this way, the controller prefetches data from the memory device before receiving a read command from the host device to retrieve the data. Prefetched data is stored in volatile memory such as DRAM, but not in the CMB (Common Memory Bag). This is because the data storage device cannot store data in the CMB without a command from the host. The more the data storage device attempts to optimize its operation through prefetching, the more memory it will require. Utilizing more memory can impact effective CMB utilization.

[0005] Therefore, improvements in CMB utilization are needed in this field of technology. [Overview of the project]

[0006] A controller memory buffer (CMB) is used by a host device for many purposes. One such purpose is to place data into the CMB in response to read commands. Data is read from a memory device and placed into the CMB. However, for efficiency purposes, a data storage device may prefetch the data. Prefetched data is stored in volatile memory separate from the CMB, but is often stored in dynamic random access memory (DRAM), where the CMB is part of the DRAM. Rather than copying data from DRAM and restoring it to the CMB, a data storage device can simply provide a DRAM address without moving the data to the CMB, thus eliminating the step of copying data from DRAM to the CMB.

[0007] In one embodiment, the data storage device comprises a memory device and a controller coupled to the memory device, wherein the controller receives a read command from a host device, the read command having a logical block address (LBA), and the read command reads the data of the LBA from the memory device to a location in the controller memory buffer (CMB), transfers the LBA to an LBA-to-dynamic random access memory (DRAM) (L2D) module, scans a list in the L2D module, and determines whether the LBA matches an entry in the list.

[0008] In another embodiment, the data storage device comprises a memory device and a controller coupled to the memory device, wherein the controller is configured to prefetch data from the memory device before receiving a read command to read data from the memory device, the prefetched data having a logical block address (LBA), store the prefetched data in a DRAM address in dynamic random access memory (DRAM), notify an LBA-DRAM (L2D) module of the LBA and DRAM address for the prefetched data, receive a read command to read data from the memory device into a controller memory buffer (CMB), and access the data from the DRAM.

[0009] In another embodiment, the data storage device comprises means for storing data and a controller coupled to the means for storing data, the controller being configured to dynamically remap ranges from a first portion of the means for storing data to a second portion of the means for storing data, which is a controller memory buffer (CMB), and to maintain a module that holds a list of logical block address (LBA)-to-physical area page (PRP) relationships and LBA-to-first portion relationships of prefetched data. [Brief explanation of the drawing]

[0010] A more detailed description of the Disclosure, which is concisely summarized above, may be obtained by reference to embodiments, some of which are shown in the accompanying drawings, so that the above-mentioned features of the Disclosure may be understood in detail. However, it should be noted that the accompanying drawings show only typical embodiments of the Disclosure and should not be considered to limit its scope, as the Disclosure may allow for other equally valid embodiments. [Figure 1] This is a schematic block diagram showing a storage system in which, according to a particular embodiment, a data storage device may function as a storage device for a host device. [Figure 2] This is a schematic diagram of the command flow for a data storage device according to one embodiment. [Figure 3] This is a schematic diagram of the data storage device command flow according to another embodiment. [Figure 4] A flowchart showing the prefetch operation according to one embodiment. [Figure 5] This is a flowchart showing the read command processing according to one embodiment.

[0011] For ease of understanding, the same reference numerals are used to designate identical elements common to the drawings where possible. Elements disclosed in one embodiment are intended to be usefully utilized in other embodiments without specific description. [Modes for carrying out the invention]

[0012] The following refers to embodiments of the Disclosure. However, it should be understood that the Disclosure is not limited to any specific embodiment described. Instead, any combination of the following features and elements, whether related to a different embodiment or not, is intended to implement and practice the Disclosure. Furthermore, embodiments of the Disclosure may achieve advantages over other possible solutions and / or prior art, but whether a particular advantage is achieved by a given embodiment does not limit the Disclosure. Accordingly, the following aspects, features, embodiments, and advantages are merely illustrative and shall not be considered elements or limitations of the appended claims unless expressly enumerated in the claims. Similarly, references to “the Disclosure” shall not be construed as a generalization of the subject matter of any invention disclosed herein and shall not be considered elements or limitations of the appended claims unless expressly enumerated in the claims.

[0013] A controller memory buffer (CMB) is used by a host device for many purposes. One such purpose is to place data into the CMB in response to read commands. Data is read from a memory device and placed into the CMB. However, for efficiency purposes, a data storage device may prefetch the data. Prefetched data is stored in volatile memory separate from the CMB, but is often stored in dynamic random access memory (DRAM), where the CMB is part of the DRAM. Rather than copying data from DRAM and restoring it to the CMB, a data storage device can simply provide a DRAM address without moving the data to the CMB, thus eliminating the step of copying data from DRAM to the CMB.

[0014] Figure 1 is a schematic block diagram showing a storage system 100 having a data storage device 106 which may function as a storage device for a host device 104 according to a particular embodiment. For example, the host device 104 may store and retrieve data using non-volatile memory (NVM) 110 contained in the data storage device 106. The host device 104 includes host dynamic random access memory (DRAM) 138. In some examples, the storage system 100 may include multiple storage devices, such as the data storage device 106, which 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 high-capacity storage device for the host device 104.

[0015] The host device 104 may store data in and / or retrieve data from one or more storage devices, such as the data storage device 106. As shown in Figure 1, the host device 104 may communicate with the data storage device 106 via the interface 114. The host device 104 may include any of a wide range of devices, including 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 handset 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 devices capable of sending or receiving data from a data storage device.

[0016] The host DRAM 138 may optionally include a host memory buffer (HMB) 150. The HMB 150 is a portion of the host DRAM 138 allocated to the data storage device 106 for exclusive use by the controller 108. For example, the controller 108 may store mapping data, buffered commands, logical-to-physical (L2P) tables, metadata, etc., in the HMB 150. In other words, the HMB 150 may be used by the controller 108 to store data that would normally be stored in the controller 108's internal memory, such as volatile memory 112, buffers 116, or static random access memory (SRAM). In an example where the data storage device 106 does not include DRAM (i.e., the optional DRAM 118), the controller 108 may use the HMB 150 as the DRAM for the data storage device 106.

[0017] The data storage device 106 includes a controller 108, an NVM 110, a power supply 111, volatile memory 112, an interface 114, a write buffer 116, and an optional DRAM 118. In some examples, the data storage device 106 may include additional components not shown in Figure 1 for clarity. For example, the data storage device 106 may include a printed circuit board (PCB) on which the components of the data storage device 106 are mechanically mounted and which includes conductive traces that electrically interconnect the components such as the data storage device 106. In some examples, the physical dimensions and connector configuration of the data storage device 106 may conform to one or more standard form factors. Some exemplary standard form factors include, but are not limited to, 3.5-inch data storage devices (e.g., HDD or SSD), 2.5-inch data storage devices, 1.8-inch data storage devices, peripheral component interconnect (PCI), PCI-extended (PCI-X), and PCI Express (PCIe) (e.g., PCIe x1, x4, x8, x16, PCIe MiniCard, MiniPCI, etc.). In some examples, the data storage device 106 may be directly coupled to the motherboard of the host device 104 (e.g., directly soldered or plugged into a connector).

[0018] Interface 114 may include one or both of the following: a data bus for exchanging data with the host device 104, and a control bus for exchanging commands with the host device 104. Interface 114 may operate according to any preferred protocol. For example, interface 114 may operate according to one or more of the following protocols: advanced technology attachment (ATA) (e.g., serial-ATA (SATA) and parallel-ATA (PATA)), Fibre Channel Protocol (FCP), small computer system interface (SCSI), serially attached SCSI (SAS), PCI, and PCIe, non-volatile memory express (NVMe), OpenCAPI, GenZ, cache-coherent interface accelerator (CCIX), open channel SSD (OCSSD), etc. Interface 114 (e.g., a data bus, a control bus, or both) is electrically connected to the controller 108 to provide an electrical connection between the host device 104 and the controller 108, enabling data to be exchanged between the host device 104 and the controller 108. In some examples, the electrical connection of interface 114 may also allow a data storage device 106 to receive power from the host device 104. For example, as shown in Figure 1, a power supply 111 may receive power from the host device 104 via interface 114.

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

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

[0021] The NVM110 may include multiple flash memory devices or memory units. The 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, each die containing multiple physical or logical blocks, and the multiple physical or logical blocks may be further divided into multiple pages. Each block of multiple blocks in a particular memory device may contain multiple NVM cells. Rows of NVM cells may be electrically connected using word lines to define one of the multiple pages. Each cell in each of the multiple pages may be electrically connected to its respective bit line. Furthermore, the NVM flash memory device may be a 2D or 3D device and may be a single-level cell (SLC), multi-level cell (MLC), triple-level cell (TLC), or quad-level cell (QLC). The controller 108 can write data to the NVM flash memory device at the page level, read data from the NVM flash memory device, and erase data from the NVM flash memory device at the block level.

[0022] Power supply 111 may provide power to one or more components of data storage device 106. When operating in standard mode, power supply 111 may use power provided by an external device such as host device 104 to provide power to one or more components. For example, power supply 111 may use power received from host device 104 via interface 114 to provide power to one or more components. In some examples, power supply 111 may include one or more power storage components configured to provide power to one or more components when operating in shutdown mode, such as when power is no longer received from an external device. In this way, power supply 111 may function as an on-board backup power supply. Some examples of one or more power storage components include, but are not limited to, capacitors, supercapacitors, batteries, etc. In some examples, the amount of power that may be stored by one or more power storage components may 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 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 examples, the controller 108 can 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 shown in Figure 1, the volatile memory 112 may consume power received from the power supply 111. Examples of 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.)). Similarly, an optional DRAM 118 may be used to store mapping data, buffered commands, logical-to-physical (L2P) tables, metadata, cached data, etc. In some examples, the data storage device 106 does not include an optional DRAM 118, and is therefore DRAM-less. In other examples, the data storage device 106 includes an optional DRAM 118.

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

[0025] Controller 108 may include an optional second volatile memory 120. The optional second volatile memory 120 may be similar to volatile memory 112. For example, the optional second volatile memory 120 may be SRAM. Controller 108 may allocate a portion of the optional second volatile memory as a controller memory buffer (CMB) 122 to host device 104. CMB 122 may be directly accessed by host device 104. For example, instead of maintaining one or more transmit queues within host device 104, host device 104 may use CMB 122 to store one or more transmit queues that are normally maintained within host device 104. In other words, host device 104 may generate a command and store the generated command, with or without associated data, in CMB 122, and controller 108 may access CMB 122 to retrieve the stored generated command and / or associated data.

[0026] Figure 2 is a schematic diagram 200 of a data storage device command flow according to one embodiment. Although Figure 200 shows a read flow, the same write flow is intended. Figure 200 includes a host device coupled to an SSD. The SSD includes a controller, CMB (volatile memory, e.g., in DRAM), and NVM (e.g., NAND). The controller includes a PCIe interface, a control path, a data path, and a CMB manager (CMBM). The data path includes a flash interface module (FIM), an error correction module (ECC), a decryption engine module (XTS), and a direct memory access (DMA) module used to transfer data to a destination.

[0027] DMA can transfer data to either the host device or the CMB via CMBM. The destination of the data depends on where the host device chooses to write the data. The CMBM must support both burst writes from DMA and random reads from the PCIe interface.

[0028] Figure 2 shows three "subflows": the command path, from NAND to CMB, and from CMB to host device. In subflow 1, the host device sends a command to the controller. Part of the information in the command is the location where the data will be placed (e.g., CMB). Subflow 1 ends when the controller's control path triggers the operation of the data path engine. In subflow 2, the FIM reads the required data from the NAND. The data passes through ECC, XTS, and finally through DMA, which determines where to send the data. In this case, DMA sends the data to the CMB via CMBM. In subflow 3, the host device reads from the CMB and receives the data for the read command through CMBM.

[0029] A portion of the DRAM (e.g., a DRAM range) is reserved for use by the host device. A DRAM range allocated to the host device (e.g., a CMB) cannot be used by the controller for its own needs. For example, the host device may use a buffer for write commands instead of read commands, or for SQ, in which case the CMB may function as a buffer or cache.

[0030] Controllers are often optimized to detect certain LBAs as "special" ranges. These include read look-ahead (RLAs) and frequently accessed LBAs (i.e., hot LBAs). RLAs are LBA ranges that the data storage device anticipates the host device intends to read. Therefore, the data storage device fetches LBAs from the memory device (e.g., NAND) and data from LBAs in on-chip SRAM or DRAM until data is requested by the host device. Hot LBAs are LBAs that the data storage device detects as having been read and repeatedly reread. In this case, the controller maintains this information in local SRAM or DRAM for high-speed access.

[0031] The table below shows the various data paths that occur during typical operation of a data storage device. The left side is the data origin. The Host column is for entries where the command destination is the host device. The CMB column is for entries where the command destination is the CMB.

[0032] [Table 1]

[0033] Entry (1) indicates the case where the command destination is the host and the LBA was not prefetched. In this case, the data is fetched from the NAND, passes through the SRAM in the data storage device, and is then sent from there to the host device.

[0034] Entry (2) indicates the case where the command destination is the CMB and the LBA was not prefetched. In this case, the data is fetched from the NAND, passes through the SRAM in the data storage device, and is sent from there to the CMB in the DRAM.

[0035] Entry (3) indicates that the command destination is a host device and the LBA is prefetched to SRAM in the controller. In this case, the data is sent directly from SRAM to the host device.

[0036] Entry (4) indicates that the command destination is the CMB and the LBA is prefetched to the SRAM within the controller. In this case, the data is sent directly from the SRAM to the CMB.

[0037] Entry (5) indicates that the command destination is the host device and the LBA is prefetched to DRAM. In this case, the data proceeds from the local DRAM range to SRAM and then to the host device.

[0038] Entry (6) indicates that the command destination is the CMB and the LBA is prefetched to DRAM. In this case, data is copied from DRAM (local, non-CMB range) to DRAM (CMB range) via SRAM in the controller.

[0039] Hot LBA, RLA, or other cases where data can be prefetched require memory. The more the controller tries to optimize, the more memory it uses to store data. Therefore, since DRAM is generally more affordable than SRAM, the use of DRAM is preferred over the use of SRAM. However, if the data storage device supports CMB, this creates a situation where data needs to be copied from the “local DRAM” range to the “CMB” range, particularly in entry (6). In other words, in entry (6), data in DRAM is moved to a different location within the same DRAM, but in order to perform the move, the data passes through SRAM. Thus, the data moves from a first location in DRAM to SRAM, and then back to the same DRAM, but to a different location than the first location.

[0040] As described herein, this disclosure focuses on a technique for sharing CMB ranges and local DRAM ranges so that DRAM-to-DRAM copying does not occur. More specifically, this disclosure focuses on the idea of ​​using non-static memory allocation to the CMB so that when the host device decides to read from the CMB, the controller directs the host device to the correct location in DRAM rather than the CMB. The fact that the correct location is DRAM and not the CMB is not visible to the host device.

[0041] Figure 3 is a schematic diagram 300 of a data storage device command flow according to one embodiment. Figure 300 includes the same components as Figure 2, but further includes an LBA-DRAM (L2D) module located within the controller and coupled to the CMBM and control path. Subflows 1 to 3 shown in Figure 3 are identical to subflows 1 to 3 described above with respect to Figure 2. There are additional subflows, subflows 4a, 4b, and 5, shown in Figure 3.

[0042] In subflow 4a, when the control path decides to prefetch the LBA into DRAM, it notifies the L2D module of the LBA address and the corresponding local DRAM address where the prefetched data will be stored. Then, in subflow 4b, when the controller detects that the host device is attempting to read the LBA into the CMB and that the LBA has already been prefetched into local DRAM, the control path obtains a PRP for the command and sends the PRP to the L2D module. Here, the L2D module maintains the "LBA to PRP" relationship and the "LBA to DRAM address" relationship.

[0043] Generally speaking, there is virtualization or mapping between the location where the data resides (i.e., local DRAM) and the location where the host device believes the data resides (i.e., CMB). When the host device instructs the data storage device to copy the data to the CMB, the host device provides a PRP for the data. The host device also provides the location of the CMB as the destination for the data. The PRP is for a specific LBA located within the CMB. The mapping provides information about where the data actually resides (i.e., local DRAM). The data storage device modifies the PRP to point to a different location (i.e., local DRAM) that the host device believes to be the CMB. Local DRAM is the location where the data is pre-filled. The L2D module maintains a table that tracks everything. When a read command arrives, the table is checked to determine whether the data is prefetched and where it is located. If prefetched, the address provided to the L2D by the CMB is updated to the location in local DRAM instead of the CMB, but the host device is unaware of this. The table is updated each time data is prefetched and stored in DRAM, and each time data is erased from DRAM.

[0044] The host device reads from the provided PRP. The CMBM checks the L2D module first, instead of going directly to DRAM. If there is a match, the CMBM reads from the address provided by the L2D module, instead of reading from the address provided in the read command. Essentially, instead of copying the data from DRAM to SRAM and back to the CMB (in the same DRAM), the table in the L2D module is simply updated and referenced.

[0045] Figure 4 is a flowchart 400 showing a prefetch operation according to one embodiment. First, in block 402, a decision is made to prefetch the data of the first LBA. Next, in block 404, the data is retrieved from the memory device and placed into the DRAM address of the DRAM. Next, in block 406, the L2D module is notified of the first LBA address and DRAM address of the prefetched data.

[0046] At a later point, the host device may decide in block 408 to read the second LBA into the CMB. The data storage device knows to read the second LBA into the CMB based on the physical area page (PRP) address provided with the second LBA. The second LBA is sent to the L2D module 410 to check whether the second LBA is listed in a table maintained by the L2D module. The determination of whether a match exists is made in block 412. If the second LBA matches an entry in the table, such as the second LBA matching the first LBA, in block 416 the L2D module provides the DRAM address corresponding to the second LBA to the CMB. If there is no match in block 412, in block 414 the data is fetched from the memory device and placed into the CMB as instructed by the host device.

[0047] Figure 5 is a flowchart 500 illustrating the read command processing according to one embodiment. Flowchart 500 is an embodiment of subflow 5. Subflow 5 is part of subflow 3 and begins when the host device attempts to read from the CMB. The CMBM passes the CMB address in the L2D module to obtain a new address-local DRAM range where the PRP data for the read command resides. The CMBM then continues to fetch data from the DRAM and passes the data to the host device.

[0048] More specifically regarding subflow 5, the subflow begins when an address translation request arrives from the CMBM. The L2D module then scans the PRP list generated during subflow 4b. If no match is found, the flow ends and the original address is returned to the CMBM. However, if a match is found, the LBA from that match is used to find the location within the prefetched local DRAM range of the associated data. The matched location within the local DRAM is the new address of the associated data. The L2D module provides the new address to the CMBM, and this can then proceed as usual.

[0049] More specifically regarding Figure 5, the host device first reads from the CMB at address X in block 502. Address X belongs to a previous PRP. Next, in block 504, the read request arrives at the CMB. Both blocks 502 and 504 are from subflow 3. Then subflow 5 begins.

[0050] In block 506, the CMBM passes the address to the L2D module, and then in block 508, the L2D module scans the PRP list from subflow 4b. In block 510, a determination is made as to whether there is a match between the entry in the list and the address.

[0051] If there is no match in block 510, in block 512 the L2D module returns the original address (i.e., the address provided by the host device) to the CMBM, and in block 514 the CMBM continues to access the DRAM using the address provided by the L2D module, which is the same address provided by the host device in the no-match scenario. If there is no match in block 510, the data is not prefetched.

[0052] If a match is found in block 510, the data is prefetched. The match results in an LBA index in block 516, and the L2D module looks up the local DRAM address belonging to the LBA index filled in subflow 4a in block 518. Then, in block 520, the L2D module returns the local DRAM address to the CMBM, and in block 514, the CMBM continues to access the DRAM using the address provided by the L2D module. Blocks 502, 504, and 520 are from subflow 3, and blocks 506, 508, 510, 512, 516, 518, and 520 are from subflow 5.

[0053] In one embodiment, content-addressable memory (CAM) is used for the functionality of the L2D module. It is intended that other implementations besides CAM may be used for the L2D module. CAM can provide translation from PRP addresses to LBA-DRAM addresses without requiring iterative scanning of tables, which can affect performance.

[0054] By dynamically remapping the local DRAM area to the CMB area, the copy of data from DRAM (local) to DRAM (CMB) may be skipped. Therefore, latency is improved for the predicted LBA read and the workload on DRAM is reduced.

[0055] In one embodiment, the data storage device comprises a memory device and a controller coupled to the memory device, the controller receiving a read command from a host device, the read command having a logical block address (LBA), and the read command reading the data of the LBA from the memory device to a location in the controller memory buffer (CMB), the controller being configured to forward the LBA to an LBA-Dynamic Random Access Memory (DRAM) (L2D) module, scan a list in the L2D module, and determine whether the LBA matches an entry in the list. If the controller determines that the LBA does not match an entry in the list, it is configured to return the LBA to the CMB manager and read the data from the memory device. If the controller determines that the LBA matches an entry on the list, the L2D module is configured to return a new address to the CMB manager. The new address corresponds to a location in the DRAM. The CMB is located in the DRAM, and the new address is not in the CMB. The list contains addresses prefetched by the controller from the memory device. The controller is configured to prefetch data for at least one LBA from a memory device and store the prefetched data in a DRAM address within the DRAM. The controller is configured to notify the L2D module of the LBA and DRAM address. The controller is configured to receive a physical area page (PRP) along with a read command and send the PRP to the L2D module. The L2D contains LBA-PRP information and LBA-DRAM address information.

[0056] In another embodiment, the data storage device comprises a memory device and a controller coupled to the memory device, the controller configured to prefetch data from the memory device before receiving a read command to read data from the memory device, the prefetched data having a logical block address (LBA), store the prefetched data in a DRAM address in dynamic random access memory (DRAM), notify an LBA-DRAM (L2D) module of the LBA and DRAM address for the prefetched data, receive a read command to read data from the memory device into a controller memory buffer (CMB), and access the data from the DRAM. The controller is configured to look up a table in the L2D module for an LBA match. The controller is configured to receive a physical area page (PRP) for a read command. The controller is configured to send the PRP to the L2D module. The controller is configured to dynamically remap the PRP to a DRAM address. When the controller receives a read command, it is configured not to copy the data from the DRAM to the CMB. The L2D module is configured to maintain the LBA-Physical Area Page (PRP) relationship and the LBA-DRAM address list.

[0057] In another embodiment, the data storage device comprises means for storing data and a controller coupled to the means for storing data, the controller configured to dynamically remap ranges from a first portion of the means for storing data to a second portion of the means for storing data, which is a controller memory buffer (CMB), and to maintain a module that holds a list of logical block address (LBA)-physical area page (PRP) relationships and LBA-first portion relationships of prefetched data. The functionality of the module is achieved by using a content-addressable memory (CAM) separate from the means for storing data. The module is coupled to a CMB management module.

[0058] While the above applies to embodiments of the present disclosure, other embodiments and further embodiments of the present disclosure can be devised without departing from the basic scope of the present disclosure, and the scope of the present disclosure is determined by the following claims.

Claims

1. A data storage device, Memory devices and, The memory device is coupled to a controller, and the controller is A read command is received from a host device, wherein the read command has a logical block address (LBA), and the read command reads the data of the LBA from the memory device to a location in the controller memory buffer (CMB). The LBA is transferred to the LBA-Dynamic Random Access Memory (DRAM) (L2D) module. Scan the list within the L2D module, A data storage device configured to determine whether the LBA matches an entry in the list.

2. The aforementioned controller If the LBA determines that it does not match an entry in the list, it returns the LBA to the CMB manager. The data storage device according to claim 1, configured to read the aforementioned data from the memory device.

3. The data storage device according to claim 1, wherein the controller is configured to determine that the LBA matches an entry on the list, and the L2D module is configured to return a new address to the CMB manager.

4. The data storage device according to claim 3, wherein the new address corresponds to a location in the DRAM.

5. The data storage device according to claim 4, wherein the CMB is located within the DRAM and the new address is not located within the CMB.

6. The data storage device according to claim 1, wherein the list includes addresses prefetched from the memory device by the controller.

7. The data storage device according to claim 1, wherein the controller is configured to prefetch data for at least one LBA from the memory device and store the prefetched data in a DRAM address in the DRAM.

8. The data storage device according to claim 7, wherein the controller is configured to notify the LBA and the DRAM address to the L2D module.

9. The data storage device according to claim 8, wherein the controller is configured to receive a physical area page (PRP) along with the read command and transmit the PRP to the L2D module.

10. The data storage device according to claim 9, wherein the L2D includes LBA-PRP information and LBA-DRAM address information.

11. A data storage device, Memory devices and, The memory device is coupled to a controller, and the controller is The process of prefetching data from the memory device before receiving a read command to read data from the memory device, wherein the prefetched data has a logical block address (LBA), The prefetched data is stored in a DRAM address within the Dynamic Random Access Memory (DRAM), To notify the LBA-DRAM (L2D) module of the LBA and the DRAM address for the prefetched data, Receiving the aforementioned read command, wherein the read command reads the data from the memory device into the controller memory buffer (CMB), A data storage device configured to access the data from the DRAM.

12. The data storage device according to claim 11, wherein the controller is configured to search a table in the L2D module for a match of the LBA.

13. The data storage device according to claim 11, wherein the controller is configured to receive physical area pages (PRPs) for the read command.

14. The data storage device according to claim 13, wherein the controller is configured to transmit the PRP to the L2D module.

15. The data storage device according to claim 14, wherein the controller is configured to dynamically remap the PRP to the DRAM address.

16. The data storage device according to claim 11, wherein the controller is configured not to copy the data from the DRAM to the CMB when it receives the read command.

17. The data storage device according to claim 11, wherein the L2D module is configured to maintain LBA-physical area page (PRP) relationships and a list of LBA-DRAM addresses.

18. A data storage device, Means of storing data, The system comprises a controller coupled to means for storing the aforementioned data, and the controller is The range is dynamically remapped from the first part of the means for storing the data to the second part of the means for storing the data, which is the controller memory buffer (CMB). A data storage device configured to maintain a module that holds a list of logical block address (LBA)-physical area page (PRP) relationships and LBA-first portion relationships of prefetched data.

19. The data storage device according to claim 18, wherein the function of the module is achieved by using a content-addressable memory (CAM) separate from the means for storing the data.

20. The data storage device according to claim 18, wherein the module is coupled to a CMB management module.

Images