Efficient L2P DRAM for high-capacity drives

Abstract

The present disclosure generally relates to improving the spatial efficiency when storing logical-physical (L2P) entries. Instead of writing a physical block address (PBA) that spans multiple entries, the PBA is split between a first portion stored in a buffer and the remaining bits of the PBA added to a metadata buffer. The metadata buffer is sub-optimal due to the small size of the metadata for an entry, and thus adding extra bits to the metadata buffer makes the metadata buffer more optimal. In this way, alignment is preserved, the system becomes more optimal with respect to DRAM access, and the metadata buffer can be easily optimized and adapted.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application incorporates by reference herein the entire contents of U.S. Non-Provisional Application No. 17 / 945,586, filed September 15, 2022, entitled "EFFICIENT L2P DRAM FOR HIGH-CAPACITY DRIVES," for all purposes. [Background technology]

[0002] FIELD OF THE DISCLOSURE Embodiments of the present disclosure generally relate to improving space efficiency when storing logical to physical (L2P) entries.

[0003] A solid-state drive (SSD) stores logical blocks of data on non-volatile (e.g., NAND) media / memory (NVM). Data is provided by a host system that addresses each logical block with a logical block address (LBA). For various reasons, such as the NVM being lost, the SSD must store logical blocks in various physical locations (physical block addresses (PBAs)) on the NVM. The mapping from LBA to PBA is stored in a table referred to herein as the logical-to-physical (L2P) table. When the host system reads a particular LBA, the SSD looks up the PBA in the L2P table to retrieve the logical block from the NVM and send it to the host system.

[0004] L2P tables are large. Enterprise SSDs generally store L2P tables in dynamic random access memory (DRAM) and try to do so as space-efficiently as possible, minimizing the number of DRAM devices to save costs. A typical ratio is 1000:1 between DRAM capacity and NAND capacity (e.g., a 4TB drive has 4GiB of physical DRAM). However, a 1000:1 ratio is only effective for low-capacity drives, when 32 bits are sufficient to represent a NAND physical address. As capacity increases, more bits are required for the physical address, resulting in misalignment issues in physical addresses stored on double data rate (DDR) devices.

[0005] Therefore, there is a need in the art to improve space efficiency when storing L2P entries. Summary of the Invention

[0006] The present disclosure generally relates to improving space efficiency when storing logical-to-physical (L2P) entries. Rather than writing a physical block address (PBA) across multiple entries, the PBA is split between a first portion stored in a buffer and the remaining bits of the PBA added to a metadata buffer. The metadata buffer is suboptimal due to the small size of the metadata for the entries, so adding extra bits to the metadata buffer makes it more optimal. In this manner, alignment is preserved, the system is more optimal with respect to DRAM accesses, and the metadata buffer can be easily optimized and adapted.

[0007] In one embodiment, a data storage device includes a memory device and a controller coupled to the memory device, wherein the controller is configured to: manage an L2P table including 32 L2P entries, each L2P entry including 32 bits; and store the L2P entries in the L2P table, wherein at least one memory device physical address includes more than 32 bits, and 32 bits of the at least one memory device physical address are stored in a single entry of the 32 L2P entries, and the remaining bits of the at least one memory device physical address are stored in a location separate from the L2P table.

[0008] In another embodiment, a data storage device comprises a memory device and a controller coupled to the memory device, the controller configured to determine a most significant bit (MSB) and a least significant bit (LSB) for a physical address of the memory device, where the physical address includes at least 33 bits, store the MSB in an L2P table, and store the LSB in a table different from the L2P table.

[0009] In another embodiment, a data storage device comprises a memory device and a controller coupled to the memory device, wherein the controller is configured to: identify a memory means capacity; determine that double data rate (DDR) is embedded; configure an L2P table to store a physical address of the memory means, wherein the L2P table includes 32-bit entries and the physical address includes more than 32 bits; and configure a metadata table to store remaining bits of the physical address along with metadata, wherein the metadata table differs from the L2P table and the remaining data corresponds to the LSB of the physical address. [Brief explanation of the drawings]

[0010] So that the above-mentioned features of the present disclosure can be understood in detail, a more particular description of the present disclosure briefly summarized above can be had by reference to embodiments, some of which are illustrated in the accompanying drawings. It should be noted, however, that the accompanying drawings illustrate only typical embodiments of the present disclosure and therefore should not be considered as limiting its scope, as the present disclosure may admit of other equally effective embodiments. [Figure 1] 1 is a schematic block diagram illustrating a storage system in which a data storage device can function as a storage device for a host device, according to certain embodiments. [Figure 2] 1 is a graph illustrating the structure of a logical-to-physical (L2P) chunk held in a dynamic random access memory (DRAM), according to one embodiment. [Figure 3] 10 is a graph illustrating the structure of an L2P chunk held in DRAM, according to another embodiment. [Figure 4] 10 is a graph illustrating the structure of an L2P chunk held in DRAM, according to another embodiment. [Figure 5] 10 is a graph illustrating the structure of an L2P chunk held in DRAM, according to another embodiment. [Figure 6] 10 is a graph illustrating the structure of an L2P chunk held in DRAM, according to another embodiment. [Figure 7] 1 is a flowchart illustrating L2P in DRAM, in accordance with certain embodiments. [Figure 8] 1 is a flowchart illustrating L2P in DRAM, in accordance with certain embodiments.

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

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

[0013] The present disclosure generally relates to improving space efficiency when storing logical-to-physical (L2P) entries. Rather than writing a physical block address (PBA) across multiple entries, the PBA is split between a first portion stored in a buffer and the remaining bits of the PBA added to a metadata buffer. The metadata buffer is suboptimal due to the small size of the metadata for the entries, so adding extra bits to the metadata buffer makes it more optimal. In this manner, alignment is preserved, the system is more optimal with respect to DRAM accesses, and the metadata buffer can be easily optimized and adapted.

[0014] The disclosure herein provides for alignment of data within each L2P entry in DRAM. When L2P entries are aligned, there is less potential for waste. The most significant bits (MSBs) of the L2P are stored in DRAM, while the least significant bits (LSBs) are stored in the metadata buffer.

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

[0016] Host device 104 may store and / or retrieve data to and / or from one or more storage devices, such as data storage device 106. As illustrated in Figure 1, host device 104 may communicate with data storage device 106 via interface 114. Host device 104 may comprise 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 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 any other device capable of transmitting or receiving data from a data storage device.

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

[0018] The interface 114 may include one or both of a data bus for exchanging data with the host device 104 and a control bus for exchanging commands with the host device 104. The interface 114 may operate according to any suitable protocol. For example, the interface 114 may operate according to one or more of the following protocols: 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. The interface 114 (e.g., a data bus, a control bus, or both) is electrically connected to the controller 108 and provides an electrical connection between the host device 104 and the controller 108, allowing data to be exchanged between the host device 104 and the controller 108. In some embodiments, the electrical connection of the interface 114 may also allow the data storage device 106 to receive power from the host device 104. For example, as illustrated in FIG. 1, the power supply 111 may receive power from the host device 104 via the interface 114.

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

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

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

[0022] The power supply 111 may provide power to one or more components of the data storage device 106. When operating in a standard mode, the power supply 111 may provide power to one or more components using power provided by an external device, such as the host device 104. For example, the power supply 111 may provide power to one or more components using power received from the host device 104 via the interface 114. In some embodiments, the power supply 111 may include one or more power storage components configured to provide power to one or more components when operating in a shutdown mode, such as when the power supply 111 stops receiving power from an external device. In this manner, the power supply 111 may function as an on-board power source. Some examples of the one or more power storage components include, but are not limited to, capacitors, supercapacitors, batteries, etc. In some embodiments, the amount of power that can be stored by the 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 the one or more power storage components increases, the cost and / or size of the one or more power storage components also increase.

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

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

[0025] Figure 2 is a graph 200 illustrating the structure of an L2P chunk held in DRAM, according to one embodiment. Data is structured in double data rate (DDR) format, which is prevalent in client and enterprise SSD platforms. In a codeword, 128 bytes of data are protected by two bytes of error correction code (ECC). The data and ECC bits are written to two different locations in the DRAM. A single wordline encapsulates a 32-bit L2P entry. If more than 32 bits are required for each entry, the structure becomes more complex because they are not all aligned. L2P entries larger than 32 bits also add complexity and inconvenience to firmware (FW).

[0026] Up to 32 bits per L2P entry are stored in a single word line in DRAM. Up to 8 terabyte (TB) drives with 4k indirection allow for storage of 32-bit L2P entries, which is ideal if all L2P entries are 32 bits in size. Currently, a 32-bit L2P entry can fit on a single word line. This is not the case for L2P entries larger than 32 bits. The larger the L2P entry, the larger the drive must be. Up to 16 TB with 4k indirection allows for storage of 33-bit L2P entries. Additionally, up to 32 TB drives with 4k indirection allow for storage of 34-bit L2P entries. Up to 64 TB drives with 4k indirection allow for storage of 35-bit L2P entries. Furthermore, up to 128 TB drives with 4k indirection allow for storage of 36-bit L2P entries. In previous approaches, L2P entries larger than 32 bits are written to multiple lines of codewords in DRAM.

[0027] FIG. 3 is a graph 300 illustrating the structure of an L2P chunk held in DRAM, according to one embodiment. When a 36-bit L2P entry is required for a physical address (128TB 4K indirect drive), the entry is carried over multiple lines. As shown, only 28 physical addresses can be stored in a codeword, with 2 bytes wasted. Because the 36-bit L2P entries are contiguous, each entry is written to at least two wordlines. Reading multiple wordlines is an inefficient use of DRAM. Writing an L2P larger than 32 bits to multiple wordlines causes misalignment in the DRAM. Furthermore, an entire entry always starts on a different wordline than the wordline on which the entry ends. Each time an L2P is written to multiple wordlines, several bytes are wasted. This waste reduces the net capacity of the DRAM. As a result, fewer physical addresses can be stored in one chunk of DRAM. The use of multiple wordlines should be avoided.

[0028] FIG. 4 is a graph 400 illustrating the structure of an L2P chunk stored in DRAM according to one embodiment. In previous approaches, when 36-bit L2P entries were required for a physical address (128TB 4K indirect drive), the entries were rolled over to multiple lines. As shown in FIG. 4, 32-bit L2P entries are still stored in the DRAM structure, but each entry starts in the same place and is aligned. The DRAM stores the 32 most significant bits (MSBs) of each physical address in a single contiguous word line, while the metadata buffer stores the remaining 4 bits per entry. The remaining 4 bits are the least significant bits (LSBs) of the entry. The size of the metadata buffer depends on the maximum NVM capacity supported by the device. In this example, the size of the metadata is 16 bytes, which stores the 4 LSBs of each physical address and ECC bits. The 4 LSBs are left over from each 36-bit L2P entry. The 16-byte metadata buffer size is much more optimal than the original 2-byte metadata buffer, and can store the LSBs.

[0029] When each 36-bit L2P entry is read, only the 32 MSBs are stored in DRAM per physical address, as well as the 4 LSBs in the metadata. Thus, a read proceeds by reading one entry from the DRAM buffer and one entry from the metadata buffer to collectively obtain the 36 bits. Another entry in the metadata buffer may need to be read if the ECC bits of the entry from DRAM are located in a different entry in the metadata buffer. When all 36 bits are stored in the DRAM buffer, the read is performed by reading two entries in the DRAM buffer and one entry in the metadata buffer for the ECC information. Due to the division between the MSB and LSB in the DRAM buffer and the metadata buffer, the total entries to be read can still be three entries if the ECC and LSB are in different entries, but only two entries if the ECC and LSB are in the same entry. Furthermore, all entries in the DRAM buffer are aligned, and the metadata buffer is also aligned. Thus, both the DRAM buffer and the metadata buffer are optimized for efficient data storage and retrieval.

[0030] FIG. 5 is a graph 500 illustrating the structure of an L2P chunk held in DRAM, according to one embodiment. When a 35-bit L2P entry is required for a physical address (64TB 4K indirect drive), the entry is carried over to multiple lines. As can be seen, only 29 physical addresses can be stored in a codeword, with 9 bytes wasted. Because the 35-bit L2P entries are contiguous, each entry is written to at least two wordlines. Reading multiple wordlines is an inefficient use of DRAM. Writing an L2P greater than 32 bits to multiple wordlines causes misalignment in the DRAM. Furthermore, an entire entry always starts on a different wordline than the one on which the entry ends. Each time an L2P is written to multiple wordlines, several bytes are wasted. This waste reduces the net capacity of the DRAM. As a result, fewer physical addresses can be stored in one chunk of DRAM. The use of multiple wordlines can be avoided.

[0031] FIG. 6 is a graph 600 illustrating the structure of an L2P chunk stored in DRAM, according to one embodiment. This example shows a better approach than FIG. 5. In the previous approach, when a 35-bit L2P entry was required for a physical address (64TB 4K indirect drive), the entry was rolled over to multiple lines. As shown in FIG. 6, 32-bit L2P entries are still stored in the DRAM structure, but each entry starts in the same place and is aligned. The DRAM stores the 32 MSBs of each physical address in a single contiguous word line, while the metadata buffer stores the remaining 4 bits per entry. The remaining 4 bits are the least significant bits (LSBs) of the entry. The size of the metadata buffer depends on the maximum NVM capacity supported by the device. In this example, the size of the metadata is 12 bytes, which stores the 3 LSBs of each physical address and the ECC bits. The 3 LSBs are left over from each 35-bit L2P entry. The 12-byte metadata buffer size is much more optimal than the original 2-byte metadata buffer, which can store the LSBs.

[0032] When each 35-bit L2P entry is read, only the 32 MSBs are stored in DRAM per physical address, as well as the 3 LSBs in the metadata. Thus, a read proceeds by reading one entry from the DRAM buffer and one entry from the metadata buffer to collectively obtain the 35 bits. Another entry in the metadata buffer may need to be read if the ECC bits of the entry from DRAM are located in a different entry in the metadata buffer. When all 35 bits are stored in the DRAM buffer, the read is accomplished by reading two entries in the DRAM buffer and one entry in the metadata buffer for the ECC information. Due to the division between the MSB and LSB in the DRAM buffer and the metadata buffer, the total entries to be read can still be three entries if the ECC and LSBs are in different entries, but only two entries if the ECC and LSBs are in the same entry. Furthermore, all entries in the DRAM buffer are aligned, and the metadata buffer is also aligned. Thus, both the DRAM buffer and the metadata buffer are optimized for efficient data storage and retrieval.

[0033] 7 is a flowchart 700 illustrating L2P in DRAM, according to a specific embodiment. During the initialization phase, firmware (FW) identifies the maximum capacity (e.g., a function of the number of dies) supported by the product. Then, if internal DDR is embedded, FW configures the system to operate in a specific, optimized mode. The optimized mode determines where within the data and metadata buffer structures to store each L2P entry. The same concept applies to the HMB when used to store L2P entries.

[0034] In operation 702, the system enters an initialization process to determine the maximum NVM (i.e., NAND) capacity, which determines how many L2P entries can be written to the DDR.

[0035] In operation 704, the system determines whether the potential L2P entry is stored in the HMB. The determination of where the L2P entry is stored yields the same result whether the L2P entry is stored in the HMB or not. The system then begins determining an optimized scheme to implement for the L2P entry.

[0036] In operation 706, the FW configures the HW to operate in an optimized manner for the HMB for the L2P entry. The manner determines the number of bits the L2P entry has. The system then determines the number of MSBs to be stored in the DDR. The system also determines the number of LSBs to be stored in the metadata buffer along with the ECC bits.

[0037] In operation 708, the system proceeds to store the 32 MSBs of the L2P entry. The system also stores the remaining bits or LSBs of the L2P entry along with the ECC bits in a metadata buffer, which is larger than a normal 2-byte buffer if the L2P entry is larger than 32 bits.

[0038] In operation 710, the FW configures the HW to operate in an optimized manner for the HMB for the L2P entry. The manner determines the number of bits the L2P entry has. The system then determines the number of MSBs to be stored in the DDR. The system also determines the number of LSBs to be stored in the metadata buffer along with the ECC bits.

[0039] In operation 712, the system proceeds to store the 32 MSBs of the L2P entry. The system also stores the remaining bits or LSBs of the L2P entry along with the ECC bits in a metadata buffer, which is larger than a normal 2-byte buffer if the L2P entry is larger than 32 bits.

[0040] 8 is a flowchart 800 illustrating L2P in DRAM, according to a particular embodiment. In block 802, initialization is performed and the maximum NVM (e.g., NAND) capacity is determined. Next, in block 804, the location where the L2P table will be stored is determined. For example, the L2P table may be stored in controller volatile memory or HMB. Next, in block 806, the size of the L2P table is determined, followed by the FW configuring the HW to operate in an optimized manner for L2P entries in 808. Finally, in 810, the HW writes the 32 MSBs to DRAM and the remaining LSBs to the metadata buffer.

[0041] In one embodiment, a data storage device includes a memory device and a controller coupled to the memory device, the controller being configured to: manage a logical-to-physical (L2P) table including 32 L2P entries, each L2P entry including 32 bits; and store the L2P entries in the L2P table, wherein at least one memory device physical address includes more than 32 bits, 32 bits of the at least one memory device physical address being stored in a single entry of the 32 L2P entries, and remaining bits of the at least one memory device physical address being stored in a location separate from the L2P table. The separate location is an error correcting code (ECC) table. The ECC table includes at least one entry, the at least one entry being 32 bits, and the at least one entry including ECC data and remaining bits. The at least one entry includes a first entry and a second entry, the first entry including the remaining bits and the second entry including at least a portion of the ECC data. The first entry includes at least another portion of the ECC data. 32 bits of the at least one memory device physical address as the most significant bits (MSBs) of the more than 32 bits. The remaining bits of the more than 32 bits of the at least one memory device are the least significant bits (LSBs) of the more than 32 bits. The L2P table is located in a host memory buffer (HMB). The L2P table is located in a controller. The remaining bits include one or more bits. The separate locations are not L2P entries directly adjacent to a single entry.

[0042] In another embodiment, a data storage device comprises a memory device and a controller coupled to the memory device, the controller configured to: determine a most significant bit (MSB) and a least significant bit (LSB) for a physical address of the memory device, the physical address including at least 33 bits; store the MSB in a logical-to-physical (L2P) table; and store the LSB in a table separate from the L2P table. The MSB is stored as a single entry in the L2P table. The LSB is stored in the table along with error correcting code (ECC) data. The table separate from the L2P table is less than one-quarter the size of the L2P table. The entry in the table separate from the L2P table includes 32 bits. The MSB includes 32 bits.

[0043] In another embodiment, a data storage device includes a memory device and a controller coupled to the memory device, the controller being configured to: identify a memory means capacity; determine that double data rate (DDR) is embedded; configure a logical-to-physical (L2P) table to store physical addresses of the memory means, where the L2P table includes 32-bit entries and the physical addresses include more than 32 bits; and configure a metadata table to store remaining bits of the physical addresses along with metadata, where the metadata table differs from the L2P table and the remaining data corresponds to least significant bits (LSBs) of the physical addresses. The controller is configured to determine whether the L2P table is stored in a host memory buffer (HMB) or on the data storage device. If the L2P table is stored on the data storage device, the L2P table is stored in a DRAM within the controller.

[0044] As discussed herein, efficient use of DRAM capacity is obtained while minimizing waste due to misalignment as much as possible. Another benefit can be measured in DRAM performance by issuing optimized transactions on the DRAM. By storing the 32 MSBs in a single wordline while storing the remaining LSBs in a metadata buffer, L2P storage efficiency is improved.

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

Claims

1. 1. A data storage device comprising: a memory device; a controller coupled to the memory device, the controller comprising: managing a logical-to-physical (L2P) table containing 32 L2P entries with each L2P entry containing 32 bits; 1. A data storage device configured to: store L2P entries in the L2P table, wherein at least one memory device physical address includes more than 32 bits, 32 bits of the at least one memory device physical address are stored in a single entry of the 32 L2P entries, and remaining bits of the at least one memory device physical address are stored in a location separate from the L2P table.

2. 2. The data storage device of claim 1, wherein the separate location is an error correcting code (ECC) table.

3. 3. The data storage device of claim 2, wherein the ECC table includes at least one entry, the at least one entry being 32 bits, and the at least one entry including ECC data and the remaining bits.

4. 4. The data storage device of claim 3, wherein the at least one entry includes a first entry and a second entry, the first entry including the remaining bits and the second entry including at least a portion of the ECC data.

5. 5. The data storage device of claim 4, wherein the first entry includes at least another portion of the ECC data.

6. The data storage device of claim 1, wherein the 32 bits of the at least one memory device physical address are most significant bits (MSBs).

7. 2. The data storage device of claim 1, wherein the remaining bits of the at least one memory device physical address are least significant bits (LSBs).

8. 2. The data storage device of claim 1, wherein the L2P table is located in a host memory buffer (HMB).

9. The data storage device of claim 1 , wherein the L2P table is located within the controller.

10. The data storage device of claim 1 , wherein the remaining bits comprise one or more bits.

11. 2. The data storage device of claim 1, wherein the separate locations are not L2P entries immediately adjacent to the single entry.

12. 1. A data storage device comprising: a memory device; a controller coupled to the memory device, the controller comprising: determining a most significant bit (MSB) and a least significant bit (LSB) for a physical address of the memory device, the physical address comprising at least 33 bits; storing said MSBs in a logical-to-physical (L2P) table; storing the LSBs in a table separate from the L2P table.

13. 13. The data storage device of claim 12, wherein the MSB is stored as a single entry in the L2P table.

14. 13. The data storage device of claim 12, wherein the least significant bits are stored in a table along with error correcting code (ECC) data.

15. 13. The data storage device of claim 12, wherein the table that is different from the L2P table is less than one-quarter the size of the L2P table.

16. 16. The data storage device of claim 15, wherein entries in the table that are different from the L2P table comprise 32 bits.

17. 17. The data storage device of claim 16, wherein the MSB comprises 32 bits.

18. 1. A data storage device comprising: memory means; a controller coupled to said memory means, said controller comprising: configuring a logical-to-physical (L2P) table to store physical addresses of said memory means, said L2P table including 32-bit entries, said physical addresses including more than 32 bits, 32 bits corresponding to most significant bits (MSBs) in said physical addresses being stored in said L2P table; and configuring a metadata table to store remaining bits of the physical address along with metadata, the metadata table being different from the L2P table, and the remaining bits corresponding to least significant bits (LSBs) of the physical address.

Images