Efficient L2P DRAM for High-Capacity Drives

By splitting the physical block address between a buffer and a metadata buffer, the SSD technology improves space efficiency and aligns data within L2P entries, addressing misalignment issues and enhancing DRAM performance.

JP2025517744AActive Publication Date: 2025-06-10SANDISK TECHNOLOGIES LLC
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
JP2024568347
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2022-09-15
Filing Date
2023-06-13
Publication Date
2025-06-10
Estimated Expiration
2043-06-13

AI Technical Summary

Technical Problem

Existing SSD technologies face challenges in maintaining space efficiency when storing logical-to-physical (L2P) entries, particularly as drive capacities increase, leading to misalignment issues in physical addresses stored in DDR devices.

Method used

The solution involves splitting the physical block address (PBA) between a first portion stored in a buffer and the remaining bits stored in a metadata buffer, optimizing the metadata buffer size to preserve alignment and improve DRAM access efficiency.

Benefits of technology

This approach enhances spatial efficiency, minimizes waste due to misalignment, and optimizes DRAM performance by aligning data within L2P entries and adapting the metadata buffer for efficient storage and retrieval.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025517744000001_ABST
    Figure 2025517744000001_ABST
Patent Text Reader

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.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] (Cross - reference to Related Applications) This application incorporates by reference in its entirety the content of U.S. Non - Provisional Application No. 17 / 945,586, entitled "EFFICIENT L2P DRAM FOR HIGH - CAPACITY DRIVES", filed on September 15, 2022, for all purposes.

Background Art

[0002] Embodiments of the present disclosure generally relate to improving the spatial 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). The data is provided by a host system that addresses each logical block with a logical block address (LBA). For various reasons, such as when the NVM is lost, the SSD must store the logical blocks at various physical locations (physical block addresses (PBA)) 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 retrieves the logical block from the NVM and looks up the PBA in the L2P table to send it to the host system.

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

[0005] Therefore, there is a need in the art to improve the space efficiency when storing L2P entries. SUMMARY OF THE INVENTION

[0006] The present disclosure generally relates to improving the space 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.

[0007] In one embodiment, the data storage device includes a memory device and a controller coupled to the memory device. 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, 32 bits of at least one memory device physical address are stored in a single entry of the 32 L2P entries, and the remaining bits of at least one memory device physical address are stored in a location separate from the L2P table.

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

[0009] In another embodiment, the data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to identify the memory means capacity, determine that double data rate (DDR) is embedded, configure the L2P table to store the 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 the remaining bits of the physical address together with metadata, wherein the metadata table is different from the L2P table and the remaining data corresponds to the LSB of the physical address.

Brief Description of the Drawings

[0010] To enable a more specific understanding of the above features of the present disclosure, a more detailed description of the present disclosure, briefly summarized above, may be made by reference to the embodiments, some of which are illustrated in the accompanying drawings. However, it should be noted that the accompanying drawings illustrate only typical embodiments of the present disclosure and should not be considered as limiting its scope, as the present disclosure may admit other equally effective embodiments.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

[0011] For ease of understanding, the same reference numbers are used as much as possible to denote the same elements common to the drawings. It is contemplated that elements disclosed in one embodiment may be beneficially utilized in other embodiments without particular recitation. DETAILED DESCRIPTION OF THE INVENTION

[0012] In the following, embodiments of the present disclosure are referred to. 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 is contemplated to implement and practice the present disclosure, regardless of whether they relate to different embodiments. Further, embodiments of the present disclosure may achieve advantages over other possible solutions and / or over the prior art, but whether a particular advantage is achieved by a given embodiment is not limiting of the present disclosure. Accordingly, the following aspects, features, embodiments, and advantages are merely illustrative and are not to be considered elements or limitations of the appended claims, except where explicitly recited in the claims. Similarly, references to "the present disclosure" are not to be construed as generalizations of the subject matter of any invention disclosed herein and are not to be considered elements or limitations of the appended claims, except where explicitly recited in the claims.

[0013] The present disclosure generally relates to improving the spatial efficiency when storing logical-physical (L2P) entries. Instead of writing physical block addresses (PBAs) that span 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.

[0014] The disclosure herein results in the alignment of data within each L2P entry in DRAM. When the L2P entries are aligned, the potential for waste is reduced. The most significant bit (MSB) of the L2P is stored in DRAM. On the other hand, the least significant bit (LSB) is stored in the metadata buffer.

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

[0016] The host device 104 may store and / or retrieve data to and / or from one or more storage devices such as the data storage device 106. As illustrated in FIG. 1, the host device 104 may communicate with the data storage device 106 via an interface 114. The host device 104 may comprise any of a wide range of devices including, for example, 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] The data storage device 106 includes a controller 108, an NVM 110, a power supply 111, a volatile memory 112, an interface 114, and a write buffer 116. In some embodiments, the data storage device 106 may include additional components not shown in FIG. 1 for clarity. The controller 108 may include a volatile memory such as a DRAM 152 and a controller memory buffer (CMB) 154 dedicated to the use of the host device 104. For example, the data storage device 106 may include a printed circuit board (PCB) to which components such as the data storage device 106 are mechanically attached and which includes conductive traces for electrically interconnecting the components of the data storage device 106. In some embodiments, 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, 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 extension (PCI-X), a PCI express (PCIe) (e.g., PCIe×1, ×4, ×8, ×16, PCIe mini card, mini PCI, etc.). In some embodiments, the data storage device 106 may be directly coupled (e.g., soldered directly to a connector or plugged in) to the motherboard of the host device 104.

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

[0019] The NVM 110 may include a plurality of memory devices or memory units. The NVM 110 may be configured to store and / or retrieve data. For example, the memory units of the NVM 110 may receive data and a message instructing the memory units to store the data from the controller 108. Similarly, the memory units may receive a message instructing the memory units to retrieve the data from the controller 108. In some embodiments, each of the memory units may be referred to as a die. In some embodiments, the NVM 110 may include a plurality of dies (i.e., a plurality of 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 a plurality of flash memory devices or memory units. The NVM flash memory device may include a NAND or NOR-based flash memory device, and may store data based on the charge contained in the floating gate of the transistor of each flash memory cell. In the NVM flash memory device, the flash memory device may be divided into a plurality of dies, each die of the plurality of dies includes a plurality of physical blocks or logical blocks, and the plurality of physical blocks or logical blocks may be further divided into a plurality of pages. Each block of the plurality of blocks within a specific memory device may include a plurality of NVM cells. The rows of the NVM cells may be electrically connected using word lines to define each page of the plurality of pages. Each cell in each of the plurality of pages may be electrically connected to its respective bit line. Further, 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 may write data to the NVM flash memory device 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] Power supply 111 can supply power to one or more components of data storage device 106. When operating in standard mode, power supply 111 can supply power to one or more components using power provided by an external device such as host device 104. For example, power supply 111 can supply power to one or more components using power received from host device 104 via interface 114. In some embodiments, power supply 111 can include one or more power storage components configured to supply power to one or more components when operating in a shutdown mode, such as when power reception from an external device is stopped. Thus, power supply 111 can function as an on-board power supply. Some examples of 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 one or more power storage components can be a function of the cost and / or size (e.g., area / volume) of the one or more power storage components. In other words, as the amount of power stored by one or more power storage components increases, the cost and / or size of the one or more power storage components also increases.

[0023] Volatile memory 112 can be used by controller 108 to store information. Volatile memory 112 can include one or more volatile memory devices. In some embodiments, controller 108 can use volatile memory 112 as a cache. For example, controller 108 can store information cached in volatile memory 112 until the cached information is written to NVM 110. As illustrated in FIG. 1, volatile memory 112 can 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 the reading of data from the NVM 110 and / or the writing of 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 a data storage command to 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 may temporarily store the data associated with the write command in the internal memory or the write buffer 116 before transmitting the data to the NVM 110.

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

[0026] Up to 32 bits per L2P entry are stored in a single word line within the DRAM. A 4k indirect up to 8 terabyte (TB) drive enables storage of 32-bit L2P entries, which is ideal when all L2P entries are 32-bit sized. Currently, 32-bit L2P entries 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 has to be. A 4k indirect up to 16TB enables storage of 33-bit L2P entries. Additionally, a 4k indirect up to 32TB drive enables storage of 34-bit L2P entries. A 4k indirect up to 64TB drive enables storage of 35-bit L2P entries. Further, a 4k indirect up to 128TB drive enables storage of 36-bit L2P entries. In previous approaches, L2P entries larger than 32 bits were written across multiple lines of codewords within the DRAM.

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

[0028] FIG. 4 is a graph 400 illustrating the structure of an L2P chunk held in a DRAM according to one embodiment. In previous approaches, when a 36-bit L2P entry is required for a physical address (128TB 4K indirect drive), the entry is spilled across multiple lines. As shown in FIG. 4, the 32-bit L2P entries are still held within the DRAM structure, but each entry starts at the same location and is aligned. The DRAM holds the 32 most significant bits (MSB) of each physical address within a contiguous single word line, while the metadata buffer holds the remaining 4 bits per entry. The remaining 4 bits are the least significant bits (LSB) 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 holds the 4 LSBs and the ECC bits of each physical address. The 4 LSBs are what remains 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 for each physical address, similar to the 4 LSBs in the metadata. Thus, the read proceeds by reading one entry from the DRAM buffer and one entry from the metadata buffer to collectively obtain 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 of the DRAM buffer and one entry of the metadata buffer for the ECC information. Due to the split between the MSBs and LSBs in the DRAM buffer and the metadata buffer, the total number of 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. Further, the entries in the DRAM buffer are all 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 a DRAM according to one embodiment. When a 35-bit L2P entry is needed for a physical address (64TB 4K indirect drive), the entry is spread across multiple lines. As can be shown, only 29 physical addresses can be stored in the codeword, with 9 bytes of waste. Since the 35-bit L2P entries are contiguous, each entry is written to at least two word lines. Reading multiple word lines is an inefficient use of the DRAM. Writing an L2P larger than 32 bits across multiple word lines causes misalignment in the DRAM. Further, the entire entry always starts on a word line different from the word line where the entry ends. Each time the L2P is written across multiple word lines, several bytes of waste occur. This waste reduces the net capacity of the DRAM. As a result, fewer physical addresses can be stored in one chunk of the DRAM. The use of multiple word lines can be avoided.

[0031] FIG. 6 is a graph 600 illustrating the structure of an L2P chunk held in a DRAM according to one embodiment. In this example, a better approach for FIG. 5 is shown. In the previous approach, when a 35-bit L2P entry was needed for a physical address (64TB 4K indirect drive), the entry was spread across multiple lines. As shown in FIG. 6, 32-bit L2P entries are still held within the DRAM structure, but each entry starts in the same place and is aligned. The DRAM holds the 32 MSBs of each physical address within a contiguous single word line, while the metadata buffer holds the remaining 4 bits for each 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 that hold the 3 LSBs of each physical address and the ECC bits. The 3 LSBs are what remains from each 35-bit L2P entry. The 12-byte metadata buffer size is much more optimal than the original 2-byte metadata buffer and can store the LSBs.

[0032] When each 35-bit L2P entry is read, only the 32 MSBs are stored in DRAM for each physical address, similar to the 3 LSBs in the metadata. Thus, the read proceeds by reading one entry from the DRAM buffer and one entry from the metadata buffer to collectively obtain 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 performed by reading two entries of the DRAM buffer and one entry of the metadata buffer for the ECC information. Due to the split between the MSBs and LSBs in the DRAM buffer and the metadata buffer, the total number of entries to be read can still be three entries if the ECC and the LSB are in different entries, but only two entries if the ECC and the LSB are in the same entry. Further, the entries in the DRAM buffer are all 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] FIG. 7 is a flowchart 700 illustrating L2P in DRAM according to a particular embodiment. In the initialization phase, the firmware (FW) identifies the maximum capacity supported by the product (such as a function of the number of dies). Then, if internal DDR is embedded, the FW configures the system to operate in a specific and optimized mode. The optimized mode determines where to store each L2P entry within the structure of the data and metadata buffers. The same concept applies to HMB when used to store L2P entries.

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

[0035] In operation 704, the system determines whether potential L2P entries are stored in the HMB. The determination of where the L2P entries are stored yields the same result regardless of whether the L2P entries are stored in the HMB. The system begins to determine the optimized method for implementation for the L2P entries.

[0036] In operation 706, the FW configures the HW to operate in a manner optimized for the HMB for the L2P entries. The method determines the number of bits the L2P entry has. Next, the system 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 in the metadata buffer along with the ECC bits. The metadata buffer becomes 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 a manner optimized for the HMB for the L2P entries. The method determines the number of bits the L2P entry has. Next, the system 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 the metadata buffer. The metadata buffer will be larger than a normal 2-byte buffer if the L2P entry is larger than 32 bits.

[0040] FIG. 8 is a flowchart 800 illustrating L2P in DRAM according to a particular embodiment. In block 802, initialization occurs and the maximum NVM (e.g., NAND) capacity is determined. Next, in block 804, the location where the L2P table is to 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, and subsequently, at 808, the FW configures the HW to operate in a manner optimized for L2P entries. Finally, at 810, the HW writes the 32 MSBs to DRAM and the remaining LSBs to the metadata buffer.

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

[0042] In another embodiment, the data storage device comprises a memory device and a controller coupled to the memory device, and the controller is configured to determine a most significant bit (MSB) and a least significant bit (LSB) for a physical address of the memory device, the determining including that the physical address includes at least 33 bits, store the MSB in a logical-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 together with error correction code (ECC) data. The table different from the L2P table is less than a quarter of the size of the L2P table. Entries in the table different from the L2P table include 32 bits. The MSB includes 32 bits.

[0043] In another embodiment, the data storage device comprises a memory device and a controller coupled to the memory device, and the controller is configured to identify the memory means capacity, determine that double data rate (DDR) is embedded, and configure a logical-physical (L2P) table to store a physical address of the memory means, the configuring including that the L2P table includes 32-bit entries and the physical address includes more than 32 bits, and configure a metadata table to store the remaining bits of the physical address together with metadata, the configuring including that the metadata table is different from the L2P table and the remaining data corresponds to the least significant bit (LSB) of the physical address. The controller is configured to determine whether the L2P table is stored in a host memory buffer (HMB) or in the data storage device. When the L2P table is stored in the data storage device, the L2P table is stored in DRAM within the controller.

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

[0045] The foregoing is intended to be illustrative of embodiments of the present disclosure, but other and further embodiments of the present disclosure may be devised without departing from its basic scope, which is determined by the following claims.

Claims

**Claim 1** A data storage device, comprising: a memory device; and a controller coupled to the memory device, the controller being configured to: manage an L2P table including 32 L2P entries each having a logical-to-physical (L2P) entry including 32 bits; and 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. **Claim 2** The data storage device according to claim 1, wherein the separate location is an error correction code (ECC) table. **Claim 3** The data storage device according to claim 2, wherein the ECC table includes at least one entry, the at least one entry is 32 bits, and the at least one entry includes ECC data and the remaining bits. **Claim 4** The data storage device according to claim 3, wherein the at least one entry includes a first entry and a second entry, the first entry includes the remaining bits, and the second entry includes at least a portion of the ECC data. **Claim 5** The data storage device according to claim 4, wherein the first entry includes at least another portion of the ECC data. **Claim 6** The 32 bits of the at least one memory device physical address as the most significant bits (MSBs) more than 32 bits, the data storage device according to claim 1. **Claim 7** The data storage device according to claim 1, wherein the remaining bits more than 32 bits of the at least one memory device are the least significant bits (LSBs) more than 32 bits. **Claim 8** The data storage device according to claim 1, wherein the L2P table is disposed within a host memory buffer (HMB). **Claim 9** The data storage device according to claim 1, wherein the L2P table is disposed within the controller. **Claim 10** The data storage device according to claim 1, wherein the remaining bits include one or more bits. **Claim 11** The data storage device according to claim 1, wherein the separate location is not an L2P entry directly adjacent to the single entry.

12. A data storage device, comprising: a memory device; and a controller coupled to the memory device, the controller being 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-physical (L2P) table; and store the LSB in a table different from the L2P table.

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

14. The data storage device according to claim 12, wherein the LSB is stored in a table together with error correction code (ECC) data.

15. The data storage device according to claim 12, wherein the table different from the L2P table is less than one-fourth the size of the L2P table.

16. The data storage device according to claim 15, wherein an entry in the table different from the L2P table includes 32 bits.

17. The data storage device according to claim 16, wherein the MSB includes 32 bits.

18. A data storage device, comprising: memory means; and a controller coupled to the memory means, the controller being configured to: specify the memory means capacity; determine that double data rate (DDR) is embedded; configure a logical-physical (L2P) table to store a physical address of the memory means, the L2P table including 32-bit entries and the physical address including more than 32 bits; and configure a metadata table to store the remaining bits of the physical address together with metadata, the metadata table being different from the L2P table and the remaining data corresponding to the least significant bit (LSB) of the physical address.

19. The data storage device according to claim 18, wherein the controller is configured to determine whether the L2P table is stored in a host memory buffer (HMB) or in the data storage device.

20. The data storage device according to claim 19, wherein when the L2P table is stored in the data storage device, the L2P table is stored in a DRAM in the controller.

Citation Information

Patent Citations

  • Access method to data recording medium, information processor, and access program to data storage medium

    JP2005301885A

  • Storage device

    JP2012194993A

  • Multi-Level Logical to Physical Address Mapping Using Distributed Processors in Non-Volatile Storage Device

    US20170147499A1

  • Method and system for logical to physical (L2P) mapping for data-storage device comprising non-volatile memory

    US20220050784A1

  • Logical-to-physical mapping

    US20220058135A1