NVMe-guided partition error correction code enhancements

Abstract

A data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to compare a first copy of a boot partition to a second copy of the boot partition. The first copy of the boot partition and the second copy of the boot partition each include a same number of a plurality of boot blocks. The boot partition corresponds to data of a boot operation of the host device. The controller is further configured to mark one or more of the compared boot blocks that are equal to or exceed a similarity threshold, and update a reliability index based on the mark. Based on the flag and the reliability index, the controller may increase or decrease an amount of error correction required for the boot data.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of, and is hereby incorporated by reference in its entirety, U.S. Non-Provisional Application No. 17 / 887,687, filed on August 15, 2022, and entitled “NVMe Boot Partition Error Correction Code Enhancement,” for all purposes. Background Art Technical Field

[0003] Embodiments of the present disclosure are generally directed to a data storage device, such as a solid state drive (SSD), that stores a boot partition corresponding to a host device boot operation.

[0004] Description of Related Art

[0005] A boot partition is an optional area of ​​a non-volatile memory (NVM) device of a data storage device that can be read by a host device without requiring the host device to initialize a queue or enable a controller of the data storage device. An NVMexpress (NVMe) controller that supports boot partitions stores two boot partitions of equal size using boot partition identifiers 0h and 1h. The two boot partitions allow the host device to update one and verify the content before marking the boot partition as active. The two boot partitions can also be used to store two different boot images or different versions of the same boot image. Typically, the two boot partition copies are similar to each other. Unlike the boot operation of a data storage device, where a copy of a boot partition can be used to improve error correction, the host device does not utilize the redundant nature of the boot partition copy of the host boot partition. In other words, each copy of the host boot partition is encoded and decoded by itself.

[0006] Therefore, there is a need in the art to improve error correction capabilities of data provided directly to a data storage device or retrieved from a data storage device by a host device using a host boot partition copy without initializing a queue or enabling a controller of the data storage device. Summary of the invention

[0007] The present disclosure as a whole relates to a data storage device, such as a solid-state drive (SSD), that stores a boot partition corresponding to a boot operation of a host device. A data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to compare a first copy of a boot partition with a second copy of the boot partition. The first copy of the boot partition and the second copy of the boot partition each include a plurality of boot blocks of the same number. The boot partition corresponds to data of a boot operation of a host device. The controller is further configured to mark one or more boot blocks in the compared boot blocks that are equal to or exceed a similarity threshold, and update a reliability index based on the mark. Based on the mark and the reliability index, the controller can increase or decrease the amount of error correction required for the boot data.

[0008] In one embodiment, a data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to compare a first copy of a boot partition with a second copy of the boot partition, wherein the first copy of the boot partition and the second copy of the boot partition each include a plurality of boot blocks, wherein the plurality of boot blocks of the first copy of the boot partition are equal to the plurality of boot blocks of the second copy of the boot partition, wherein the first copy of the boot partition and the second copy of the boot partition are stored in the memory device, wherein the boot partition corresponds to data of a boot operation of a host device; based on the comparison, mark one or more boot blocks in the plurality of boot blocks of the first copy of the boot partition that are equal to or exceed a similarity threshold and one or more boot blocks in the plurality of boot blocks of the second copy of the boot partition that are equal to or exceed a similarity threshold; and update a reliability index based on the mark.

[0009] In another embodiment, a data storage device includes a memory device that stores a first copy of a boot partition and a second copy of the boot partition, wherein the first copy and the second copy include the same number of boot blocks, wherein the first boot block of the second copy corresponds to data of the first boot block of the first copy, and wherein the boot partition corresponds to data associated with a boot operation of a host device; and a controller coupled to the memory device. The controller is configured to maintain a delta table, wherein the delta table tracks which boot block of the first copy matches the corresponding boot block of the second copy and which boot block of the first copy is different from the corresponding boot block of the second copy; determine that a boot operation is occurring; and provide the boot partition to the host device using the first copy, the second copy, and the delta table in a decode operation.

[0010] In another embodiment, a data storage device includes a memory device that stores a first copy of a boot partition and a second copy of the boot partition, wherein the first copy and the second copy include the same number of boot blocks, wherein the first boot block of the second copy corresponds to data of the first boot block of the first copy, and wherein the boot partition corresponds to data associated with a boot operation of a host device; and a controller coupled to the memory device. The controller is configured to compare a plurality of boot blocks of the first copy with a corresponding plurality of boot blocks of the second copy, wherein the result of the comparison is stored in a delta table; increase a correction capability associated with one or more boot blocks of the first copy corresponding to different one or more boot blocks of the second copy; and provide the boot partition to the host device, wherein providing the boot partition includes increasing error correction capability during a boot operation using the first copy, the second copy, and the delta table. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Thus, a detailed understanding of the manner in which the above-described features of the present disclosure are understood, a more particular description of the present disclosure, the above brief overview, may be obtained by reference to the embodiments, some of which are illustrated in the accompanying drawings. It should be noted, however, that the drawings illustrate only typical embodiments of the present disclosure and are therefore not to be considered limiting of its scope, as the present disclosure may admit to other equally effective embodiments.

[0012] Figure 1 is a schematic block diagram illustrating a storage system according to certain embodiments, in which a data storage device may be used as a storage device for a host device.

[0013] Figure 2 is an exemplary diagram showing an overview of a boot partition according to certain embodiments.

[0014] Figure 3 is an exemplary illustration of a graph showing a comparison of correction capabilities between using only hard bits and using both hard bits and soft bits according to certain embodiments.

[0015] Figure 4 is a schematic block diagram illustrating enhanced error correction capabilities using a copy of a boot partition according to certain embodiments.

[0016] Figure 5A is a flow chart illustrating a method of determining whether a first boot block of a first copy of a boot partition matches a first boot block of a second copy of a boot block according to certain embodiments.

[0017] Figure 5B is a diagram showing the use of Figure 5A A flow chart of a method for determining an updated reliability index.

[0018] To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements disclosed in one embodiment may be beneficially utilized on other embodiments without specific recitation. DETAILED DESCRIPTION

[0019] Hereinafter, reference is made to embodiments of the present disclosure. However, it should be understood that the present disclosure is not limited to the specifically described embodiments. On the contrary, any combination of the following features and elements (whether or not related to different embodiments) is considered to realize and practice the present disclosure. In addition, although the embodiments of the present disclosure can achieve advantages that are superior to other possible solutions and / or superior to the prior art, whether a specific advantage is achieved by a given embodiment is not a limitation to the present disclosure. Therefore, the following aspects, features, embodiments and advantages are merely illustrative, and are not considered to be elements or limitations of the appended claims, unless explicitly stated in the claims. Similarly, reference to "the present disclosure" should not be interpreted as a summary of any inventive subject matter disclosed herein, and should not be considered to be elements or limitations of the appended claims, unless explicitly stated in the claims.

[0020] The present disclosure as a whole relates to a data storage device, such as a solid-state drive (SSD), that stores a boot partition corresponding to a boot operation of a host device. A data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to compare a first copy of a boot partition with a second copy of the boot partition. The first copy of the boot partition and the second copy of the boot partition each include a plurality of boot blocks of the same number. The boot partition corresponds to data of a boot operation of a host device. The controller is further configured to mark one or more boot blocks in the compared boot blocks that are equal to or exceed a similarity threshold, and update a reliability index based on the mark. Based on the mark and the reliability index, the controller can increase or decrease the amount of error correction required for the boot data.

[0021] Figure 1 1 is a schematic block diagram illustrating a storage system 100 having a data storage device 106 that can be used as a storage device for a host device 104 according to certain embodiments. For example, the host device 104 can 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. In some examples, the storage system 100 can include multiple storage devices, such as the data storage device 106, that can operate as a storage array. For example, the storage system 100 may include multiple data storage devices 106 that are configured as a redundant array of inexpensive / independent disks (RAID) that are collectively used as a mass storage device for the host device 104.

[0022] Host device 104 may store data to and / or retrieve data from one or more storage devices, such as data storage device 106. Figure 1 As shown, host device 104 can communicate with data storage device 106 via interface 114. Host device 104 can include any of a variety 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" tablet computer, a television, a camera, a display device, a digital media player, a video game console, a video streaming device, or other device capable of sending or receiving data from a data storage device.

[0023] The host DRAM 138 may optionally include a host memory buffer (HMB) 150. The HMB 150 is a portion of the host DRAM 138 that is allocated to the data storage device 106 for exclusive use by the controller 108 of the data storage device 106. For example, the controller 108 may store mapping data, buffer 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 volatile memory 112, the buffer 116, the internal memory of the controller 108 (such as static random access memory (SRAM)), etc. In examples where the data storage device 106 does not include DRAM (i.e., the optional DRAM 118), the controller 108 may utilize the HMB 150 as the DRAM of the data storage device 106.

[0024] Data storage device 106 includes controller 108, NVM 110, power supply 111, volatile memory 112, interface 114, write buffer 116, and optional DRAM 118. In some examples, for clarity, data storage device 106 may include Figure 1. For example, the data storage device 106 may include a printed circuit board (PCB) to which the components of the data storage device 106 are mechanically attached, and the printed board includes conductive traces that electrically interconnect the components of the data storage device 106, etc. In some examples, the physical size 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., an 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 x1, x4, x8, x16, PCIe Mini card, MiniPCI, etc.). In some examples, the data storage device 106 can be directly coupled (e.g., directly soldered or inserted into a connector) to a motherboard of the host device 104.

[0025] 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), Serial 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, thereby providing 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 examples, 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 Figure 1 As shown, power supply 111 may receive power from host device 104 via interface 114 .

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

[0027] In some examples, each memory cell 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 magnetoresistive 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.

[0028] NVM 110 may include multiple flash memory devices or memory cells. 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 for each flash memory cell. In NVM flash memory devices, the flash memory device may be divided into multiple dies, wherein each of the multiple dies includes multiple physical or logical blocks, which may be further divided into multiple pages. Each of the multiple blocks within a particular memory device may include multiple NVM cells. The rows of NVM cells may be electrically connected using word lines to define pages in multiple pages. The corresponding cells in each of the multiple pages may be electrically connected to the corresponding bit lines. In addition, the NVM flash memory device may be a 2D or 3D device, and may be a single-level cell (SLC), a multi-level cell (MLC), a three-level cell (TLC), or a four-level cell (QLC). The controller 108 may write data to and read data from the NVM flash memory device at the page level, and erase data from the NVM flash memory device at the block level.

[0029] The power supply 111 can provide power to one or more components of the data storage device 106. When operating in standard mode, the power supply 111 can use power provided by an external device such as the host device 104 to power one or more components. For example, the power supply 111 can use power received from the host device 104 via the interface 114 to power one or more components. In some examples, the power supply 111 may include one or more power storage components that are configured to power one or more components when operating in a shutdown mode, such as when power is stopped from being received from an external device. In this way, the power supply 111 can be used as an onboard backup power supply. Some examples of one or more power storage components include, but are not limited to, capacitors, supercapacitors, batteries, and the like. In some examples, 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 such 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.

[0030] 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 examples, 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. Figure 1 As shown, 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.)). Similarly, optional DRAM 118 can be used to store mapping data, buffered commands, logical to physical (L2P) tables, metadata, cached data, etc. in optional DRAM 118. In some examples, data storage device 106 does not include optional DRAM 118, so that data storage device 106 is DRAM-free. In other examples, data storage device 106 includes optional DRAM 118.

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

[0032] Figure 2 is an exemplary illustration of a boot partition overview 200 according to some embodiments. A host device such as Figure 1 The host device 104 allocates a portion of the host memory 202 as a boot partition memory buffer 204 to store a boot partition 206. The boot partition 206 can store data related to the boot operation of the host device 104. For example, to read the contents of the boot partition 206 using the NVMe protocol, the host device 104 allocates the boot partition memory buffer 204 in the host memory 202. It should be understood that the previously proposed protocol is not intended to be limiting, but rather to provide an example of a possible implementation. The host device 104 initializes the base address of the boot partition 206 to point to the boot partition memory buffer 204. The host device 104 sets the boot partition identifier (ID), the boot partition read size, and the boot partition read offset to initiate a read operation (e.g., data 208 to be read) of the boot partition 206. The host device 104 can continue to read from the boot partition 206 by polling and incrementing the relevant registers until the entire boot partition 206 has been read.

[0033] However, when the boot partition is stored in an NVM (such as Figure 1 When the NVM 110 is in the boot partition 206, the host device can read a portion of the boot partition 206 (e.g., the data to be read 208) at any time when the NVM 110 subsystem is powered on (i.e., it can be read regardless of whether CC.EN is set to "1"). Figure 1 When the controller 108 of the host device 108 supports boot partitions, the controller uses boot partition IDs 0h and 1h to store two boot partitions of equal size in the NVM 110. Therefore, when the host device 104 reads the boot partition from the NVM 110, the stored two boot partitions of equal size are provided to the host device 104.

[0034] Figure 3 is an exemplary illustration of a graph 300 showing a comparison of correction capabilities between using only hard bits and using both hard bits and soft bits according to certain embodiments. Figure 1 The data storage device 106 of the present invention utilizes a strong error correction code (ECC) in order to meet the performance requirements. For example, due to the capacity-performance tradeoff, a low-density parity check (LDPC) code can be used.

[0035] LDPC codes utilize soft bits in addition to using hard bits to correct errors in data with erroneous bits, which may have better correction capabilities than using only hard bits to correct errors in data with erroneous bits. Soft bits are generated by performing additional sensing to the left side (i.e., decreasing voltage direction) and to the right side (i.e., increasing voltage direction) of a hard bit threshold. The additional sensing may be at a predetermined difference from the hard bit threshold or dynamically adjusted as part of a soft bit read threshold training method. The additional sensing indicates whether each bit sensed or read is closer to the hard bit threshold (i.e., closer to a threshold voltage between cell states), indicating a lower reliability that the bit will be read without error, or further away from the hard bit threshold (i.e., closer to the middle of the standard deviation of the voltage for a certain cell state), indicating a higher reliability that the bit will be read without error. See Figure 3 3 , decoding the data using soft bits along with hard bits allows for higher correction capability than decoding the data using only hard bits, as shown by the increased BER % of the hard bits only curve relative to the hard bits and soft bits curve.

[0036] Figure 4 402a, 402b. 402b is a schematic block diagram illustrating the use of a copy of a boot partition 402a, 402b to enhance error correction capabilities according to certain embodiments. For exemplary purposes, reference may be made to aspects of a storage system 100 herein. Boot partition ID 0 402a and boot partition ID 1 402b are the same or different versions of a boot partition corresponding to a host boot operation. Boot partition ID 0 402a and boot partition ID 1 402b may be stored in NVM 110. Similarly, controller 108 may generate, maintain, and update a delta table 404 storing a comparison result between boot partition ID 0 402a and boot partition ID 1 402b. Delta table 404 may be stored in a volatile memory, such as optional DRAM 118, volatile memory 112, internal volatile memory of controller 108 (such as SRAM), etc.

[0037] Boot partition ID 0 402a and boot partition ID 1 402b each include a plurality of boot blocks, wherein the number of the plurality of boot blocks of boot partition ID 0 402a is equal to the number of the plurality of boot blocks of boot partition ID 1 402b. In the current example, boot partition ID 0 402a and boot partition ID 1 402b each include 8 boot blocks. It should be understood that Figure 4 The number of boot blocks proposed and shown is not intended to be limiting, but to provide examples of possible implementations. Likewise, in an exemplary embodiment, each boot block can be a granularity of 4KB. In addition, the same reference boot block of boot partition ID 0 402a and boot partition ID 1 402b references the same boot data of the boot partition. For example, if the boot block 1 of boot partition ID 0 402a references data 0-10 of the boot partition, the boot block 1 of boot partition ID 1 402b references data 0-10 of the boot partition.

[0038] The corresponding boot blocks of boot partition ID 0 402a and boot partition ID 1 402b are provided to a comparison unit, which can be a controller 108 or part of the logic of the controller 108, wherein the comparison unit determines whether the corresponding boot blocks of boot partition ID 0 402a and boot partition ID 1 402b are different from each other (i.e., different versions) or the same as each other (i.e., the same version). In addition, the comparison can be based on a similarity threshold, so that the corresponding boot blocks of boot partition ID 0 402a and boot partition ID 1 402b can have a difference less than the similarity threshold and are considered to be the same. In other words, although the corresponding boot blocks of boot partition ID 0 402a and boot partition ID 1 402b do not completely match, the corresponding boot blocks of boot partition ID 0 402a and boot partition ID 1 402b are within the expected difference range.

[0039] The comparison unit outputs the result to the delta table 404, wherein the corresponding boot blocks of the boot partition ID 0 402a and the boot partition ID 1 402b marked as matching are stored in the delta table 404, and the corresponding boot blocks of the boot partition ID 0 402a and the boot partition ID 1 402b marked as different are stored in the delta table 404. The controller 108 can update the reliability index, which can be a log likelihood ratio (LLR), for each boot block indicated as having a matching identical boot block. During the boot read operation, the boot partition ID 0 402a, the boot partition ID 1 402b, and the delta table 404 are provided to an error correction code (ECC) engine 406, wherein the ECC engine 406 decodes and corrects errors of the boot partition before providing the boot partition back to the host device 408. In other words, when providing a boot partition to the host device 408, the boot partition ID 0 402a, the boot partition ID 1 402b, and the delta table 404 are used to enhance the error correction capabilities of the ECC engine 406. The comparison and marking of the corresponding boot blocks of the boot partition ID 0 402a and the boot partition ID 1 402b may be done incrementally for each boot block during the firmware download phase of the host boot operation.

[0040] The ECC engine 406 can use the LDPC code to indicate the reliability (i.e., reliability index) of the read bit to the decoder of the controller 108. The LLR table provides a decoder initialization value for each codeword bit based on the hard bit and soft bit values ​​corresponding to the codeword bit read. The LLR sign indicates a bit estimate, and the LLR magnitude indicates the reliability associated with the bit estimate. A larger LLR magnitude indicates that the bit estimate is more reliable, while a lower magnitude indicates that the bit estimate is less reliable. For the case of 1SB, the LLR can be calculated as:

[0041]

[0042] Wherein the numerator indicates the probability of the bit being 0 based on the hard bit (HB) value and the soft bit (SB) value, and wherein the denominator indicates the probability of the bit being 1 based on the HB value and the SB value. In some examples, when the corresponding boot blocks of boot partition ID 0 402a and boot partition ID1 402b match, the boot block of boot partition ID 1 402b may be used as the soft bit data of boot partition ID 0 402a.

[0043] When the delta table 404 indicates that the corresponding boot blocks of the boot partition ID 0 402a and the boot partition ID 1 402b are different (e.g., boot block 5), then the ECC engine 406 may utilize standard reliability, which may correspond to a general or increased ECC operation applied to the boot partitions corresponding to the different boot partition IDs 0 402a and 1 402b. However, when the delta table 404 indicates that the corresponding boot blocks of the boot partition ID 0 402a and the boot partition ID 1 402b are the same (e.g., boot block 1), the value of the boot block of the boot partition ID 0 402a (e.g., boot block 1) is compared with the value of the boot block of the boot partition ID 1 402b (e.g., boot block 1).

[0044] When these values ​​are equal, then the LLR can be modified with increased reliability. However, when these values ​​are not equal, then the LLR can be modified with reduced reliability. The optimized value of LLR modification (reliability increased or decreased due to replication matching) can be generated by offline simulation or calibrated online by LLR calibration mechanism (such as, in a non-limiting example, mismatch decoding (MMD)). The LLR modification operation can be generalized to work with conventional soft bits so that when the conventional soft bits of each replica indicate corresponding reliability, the LLR has different values. In some examples, matching a block with a higher LLR may require a lower amount of error correction capability compared to matching a block with a lower LLR or a mismatched block. Similarly, matching a block with a lower LLR may require a lower amount of error correction capability compared to a mismatched block.

[0045] In some examples, a copy of the boot partition is stored in an SLC memory. In other examples, the selective placement of the boot blocks of each copy of the boot partition may be stored in an SLC memory or a TLC memory. For example, matching boot blocks may be stored in a TLC memory, which may reduce the amount of ECC capability required, and mismatched boot blocks may be stored in an SLC memory, which may increase the protection against errors and bit flips of mismatched boot blocks. The reduced ECC capability caused by TLC memory placement may be mitigated by information exchange (i.e., reliability index / LLR) between matching copies. In other examples, matching boot blocks may be stored in blocks with lower health (e.g., higher program / erase cycle counts, higher bit error rate (BER) history, etc.) compared to other blocks. Although matching boot blocks are stored in blocks with lower health, placement may be mitigated by information exchange (i.e., reliability index / LLR) between matching copies.

[0046] Figure 5Ais a flow chart illustrating a method 500 of determining whether a first boot block of a first copy of a boot partition matches a first boot block of a second copy of a boot block according to some embodiments. Figure 4 all aspects and Figure 1 The method 500 may describe preliminary steps for improving error correction capabilities of non-identical copies of the same data, such as host device boot partition data.

[0047] At block 502, the controller 108 receives a boot partition trigger from the host device 104. The boot partition trigger may be received during an NVMe firmware download phase (e.g., NVMe management command 11h), a boot partition submission phase to the NVM 110 (e.g., NVMe management command 10h), or after a boot partition submission phase to the NVM 110. For example, the boot partition trigger may be received when the host device 104 programs a new version of the boot partition to the NVM 110. At block 504, the controller 108 begins scanning the corresponding copy of the boot block (e.g., boot block 1 of boot partition ID 0 402a and boot block 1 of boot partition ID 1 402b) and sets I=0, where I represents the boot block number (e.g., boot block 1). The scan may occur while the second copy (e.g., boot partition ID 1 402b) is being written to NVM 110 by host device 104, where controller 108 concurrently retrieves the boot block of the first copy (e.g., boot partition ID 0 402a) and the programmed boot block of the second copy and scans the corresponding copies of the boot blocks.

[0048] At box 506, the controller 108 compares the corresponding boot blocks scanned at box 504. At box 508, the controller 108 determines whether the first boot block of the first boot partition matches the first boot block of the second boot partition. If at box 508, the first boot block of the first boot partition matches the first boot block of the second boot partition, then at box 510a, the controller 108 marks the corresponding entry in the delta table 404 with a "1" that can correspond to a check mark. However, if at box 508, the first boot block of the first boot partition does not match the first boot block of the second boot partition, then at box 510b, the controller 108 marks the corresponding entry in the delta table 404 with a "0" that can correspond to an x ​​mark. At box 512, the controller 108 increments I by one. At box 514, the controller 108 determines whether the end of the boot partition has been reached. For example, when the controller 108 increments I by one and the new value of I corresponds to a boot block that does not exist, the controller 108 can determine that the end of the boot partition has been reached. If the end of the boot partition has not been reached at block 514, the method 500 returns to block 506. However, if the end of the boot partition has been reached at block 514, the method 500 ends at block 516.

[0049] Figure 5B is a diagram showing the use of Figure 5A A flowchart of a method 550 for determining an updated reliability index of method 500 is provided. For exemplary purposes, reference may be made here to Figure 4 all aspects and Figure 1 The method 500 may be implemented by the controller 108 during a boot operation of the host device 104, where the host device 104 obtains a copy of the boot partition (eg, boot partition ID 0 402a and boot partition ID 1 402b) from the NVM 110.

[0050] At block 552, a boot read operation is initiated, where the boot read operation corresponds to reading a boot partition associated with a boot operation of the host device 104 from the NVM 110. At block 554, the controller 108 begins reading a corresponding copy of the boot block (e.g., boot block 1 of boot partition ID 0 402a and boot block 1 of boot partition ID 1 402b) from the NVM 110 and sets I=0, where I represents the boot block number (e.g., boot block 1). At block 556, the controller 108 determines whether the corresponding entry in the delta table 404 is equal to 1. If the corresponding entry is equal to 1 at block 556, then at block 558, the controller 108 updates the LLR value (e.g., updates the reliability index of the LLR) based on the comparison of the corresponding boot block. However, if the corresponding entry is not equal to 1 (i.e., equal to 0) at block 556 or after block 558, then at block 560, the controller 108 increments I by one.

[0051] At block 562, the controller 108 determines whether the end of the boot partition has been reached. For example, when the controller 108 increments I by one and the new value of I corresponds to a boot block that does not exist, the controller 108 can determine that the end of the boot partition has been reached. If the end of the boot partition has not been reached at block 562, the method 550 returns to block 556. However, if the end of the boot partition has been reached at block 562, the method 550 ends at block 564. When the boot partition ID 0 402a, the boot partition ID 1 402b, and the delta table 404 are provided to the ECC engine 406, the ECC engine 406 can utilize information about whether the corresponding boot blocks match and the reliability index, which can enhance the correction capabilities of the ECC engine 406.

[0052] By utilizing a boot partition copy associated with a boot operation of the host device, wherein the boot partition copy is stored in a data storage device, data reliability of the host device may be improved when the host device accesses the boot partition copy without initializing a queue or enabling a controller of the data storage device.

[0053] In one embodiment, a data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to compare a first copy of a boot partition with a second copy of the boot partition, wherein the first copy of the boot partition and the second copy of the boot partition each include a plurality of boot blocks, wherein the plurality of boot blocks of the first copy of the boot partition are equal to the plurality of boot blocks of the second copy of the boot partition, wherein the first copy of the boot partition and the second copy of the boot partition are stored in the memory device, wherein the boot partition corresponds to data of a boot operation of a host device; based on the comparison, mark one or more boot blocks in the plurality of boot blocks of the first copy of the boot partition that are equal to or exceed a similarity threshold and one or more boot blocks in the plurality of boot blocks of the second copy of the boot partition that are equal to or exceed a similarity threshold; and update a reliability index based on the mark.

[0054] A boot block in a plurality of boot blocks of a first copy of a boot partition is compared with a corresponding boot block in a plurality of boot blocks of a second copy of a boot partition. The reliability index is a log likelihood ratio (LLR). When the boot block of the first copy of the boot partition matches the corresponding boot block in a plurality of boot blocks of the second copy of the boot partition, the magnitude of the LLR is increased. When the boot block of the first copy of the boot partition is different from the corresponding boot block in a plurality of boot blocks of the second copy of the boot partition, the magnitude of the LLR is reduced. The controller is further configured to repeat the comparison and marking for each of the plurality of boot blocks of the first copy of the boot partition and the plurality of boot blocks of the second copy of the boot partition. The comparison is triggered in response to a boot partition corresponding to a firmware download phase of a host boot operation. The comparison and marking occur incrementally for each boot block downloaded during the firmware download phase. The controller is further configured to obtain the first copy of the boot partition when the second copy of the boot partition is programmed into a memory device, and to perform the comparison in response to the acquisition. The marked different one or more boot blocks are recorded in an incremental table. The controller is further configured to utilize the first copy of the boot partition, the second copy of the boot partition, and the delta table during error correction code (ECC) decoding during a boot operation of the host device. One or more boot blocks within a similarity threshold among the plurality of boot blocks of the first copy of the boot partition and one or more boot blocks within a similarity threshold among the plurality of boot blocks of the second copy of the boot partition are stored in a first location of the memory device. One or more boot blocks equal to or exceeding the similarity threshold among the plurality of boot blocks of the first copy of the boot partition and one or more boot blocks equal to or exceeding the similarity threshold among the plurality of boot blocks of the second copy of the boot partition are stored in a second location of the memory device. The second location is associated with a greater error correction code (ECC) capability than the first location.

[0055] In another embodiment, a data storage device includes a memory device that stores a first copy of a boot partition and a second copy of the boot partition, wherein the first copy and the second copy include the same number of boot blocks, wherein the first boot block of the second copy corresponds to data of the first boot block of the first copy, and wherein the boot partition corresponds to data associated with a boot operation of a host device; and a controller coupled to the memory device. The controller is configured to maintain a delta table, wherein the delta table tracks which boot block of the first copy matches the corresponding boot block of the second copy and which boot block of the first copy is different from the corresponding boot block of the second copy; determine that a boot operation is occurring; and provide the boot partition to the host device using the first copy, the second copy, and the delta table in a decode operation.

[0056] The delta table is stored in a volatile memory. The delta table also includes a reliability index corresponding to each boot block of the first replica and the corresponding boot block of the second replica. The reliability index of the boot block that is different corresponds to a greater decoding requirement than the reliability index of the matching boot block. The boot blocks of the first replica that match the corresponding boot blocks of the second replica are stored in a triple level cell (TLC) memory, and the boot blocks of the first replica that are different from the corresponding boot blocks of the second replica are stored in a single level cell (SLC) memory.

[0057] In another embodiment, a data storage device includes a memory device that stores a first copy of a boot partition and a second copy of the boot partition, wherein the first copy and the second copy include the same number of boot blocks, wherein the first boot block of the second copy corresponds to data of the first boot block of the first copy, and wherein the boot partition corresponds to data associated with a boot operation of a host device; and a controller coupled to the memory device. The controller is configured to compare a plurality of boot blocks of the first copy with a corresponding plurality of boot blocks of the second copy, wherein the result of the comparison is stored in an incremental table; increase a correction capability associated with one or more boot blocks of the first copy corresponding to different one or more boot blocks of the second copy; and provide the boot partition to the host device, wherein providing the boot partition includes increasing error correction capability during a boot operation using the first copy, the second copy, and the incremental table. The second copy is used as soft bit information for the first copy.

[0058] While the foregoing is directed to embodiments of the present disclosure, other and further embodiments of the present disclosure may be envisaged without departing from the basic scope of the present disclosure, and the scope of the present disclosure is determined by the appended claims.

Claims

1. A data storage device, comprising: Memory devices; and a controller coupled to the memory device, wherein the controller is configured to: A first copy of a boot partition is compared to a second copy of the boot partition, wherein: The first copy of the boot partition and the second copy of the boot partition each include a plurality of boot blocks; the plurality of boot blocks of the first copy of the boot partition and the plurality of boot blocks of the second copy of the boot partition are equal; The first copy of the boot partition and the second copy of the boot partition are stored in the memory device; and The boot partition corresponds to data of a boot operation of the host device; Based on the comparison, marking one or more boot blocks of the plurality of boot blocks of the first copy of the boot partition that equal or exceed a similarity threshold and one or more boot blocks of the plurality of boot blocks of the second copy of the boot partition that equal or exceed the similarity threshold; and Based on the marking, the reliability index is updated.

2. The data storage device of claim 1, wherein a boot block of the plurality of boot blocks of the first copy of the boot partition is compared with a corresponding boot block of the plurality of boot blocks of the second copy of the boot partition.

3. The data storage device of claim 1, wherein the reliability index is a log-likelihood ratio (LLR).

4. The data storage device of claim 3, wherein the magnitude of the LLR is increased when the boot block of the first copy of the boot partition matches a corresponding boot block of the plurality of boot blocks of the second copy of the boot partition.

5. The data storage device of claim 3, wherein a magnitude of the LLR is reduced when the boot block of the first copy of the boot partition is different from a corresponding boot block of the plurality of boot blocks of the second copy of the boot partition.

6. The data storage device of claim 1, wherein the controller is further configured to repeat the comparing and the marking for each of the plurality of boot blocks of the first copy of the boot partition and the plurality of boot blocks of the second copy of the boot partition.

7. The data storage device of claim 1, wherein the comparison is responsive to a boot partition trigger corresponding to a firmware download phase of a host boot operation.

8. The data storage device of claim 7, wherein said comparing and said marking occurs incrementally for each boot block downloaded during said firmware download phase.

9. The data storage device of claim 1 , wherein the controller is further configured to: while the second copy of the boot partition is programmed to the memory device, retrieving the first copy of the boot partition; and In response to the acquiring, the comparing is performed.

10. The data storage device of claim 1, wherein the marked different one or more boot blocks are recorded in a delta table.

11. The data storage device of claim 10, wherein the controller is further configured to utilize the first copy of the boot partition, the second copy of the boot partition, and the delta table during error correction code (ECC) decoding during the boot operation of the host device.

12. The data storage device of claim 1, wherein: the one or more of the plurality of boot blocks of the first copy of the boot partition that are within the similarity threshold and the one or more of the plurality of boot blocks of the second copy of the boot partition that are within the similarity threshold are stored in a first location of the memory device; and The one or more boot blocks of the plurality of boot blocks of the first copy of the boot partition that equal or exceed the similarity threshold and the one or more boot blocks of the plurality of boot blocks of the second copy of the boot partition that equal or exceed the similarity threshold are stored in a second location of the memory device.

13. The data storage device of claim 12, wherein the second location is associated with a greater error correction code (ECC) capability than the first location.

14. A data storage device, comprising: a memory device storing a first copy of a boot partition and a second copy of the boot partition, wherein the first copy and the second copy include the same number of boot blocks, wherein a first boot block of the second copy corresponds to data of a first boot block of the first copy, and wherein the boot partition corresponds to data associated with a boot operation of a host device; and a controller coupled to the memory device, wherein the controller is configured to: maintaining a delta table, wherein the delta table tracks which boot block of the first replica matches a corresponding boot block of the second replica and which boot block of the first replica is different from a corresponding boot block of the second replica; determining that the boot operation is occurring; and The boot partition is provided to the host device using the first copy, the second copy, and the delta table in a decoding operation.

15. The data storage device of claim 14, wherein the delta table is stored in a volatile memory. 16 . The data storage device of claim 14 , wherein the delta table further comprises a reliability index corresponding to each boot block of the first replica and the corresponding boot block of the second replica.

17. The data storage device of claim 16, wherein the reliability index of a different boot block corresponds to a greater decoding requirement than the reliability index of a matching boot block.

18. A data storage device according to claim 14, wherein the boot block of the first copy that matches the corresponding boot block of the second copy is stored in a triple-level cell (TLC) memory, and the boot block of the first copy that is different from the corresponding boot block of the second copy is stored in a single-level cell (SLC) memory.

19. A data storage device, the data storage device comprising: a storage device storing a first copy of a boot partition and a second copy of the boot partition, wherein the first copy and the second copy include the same number of boot blocks, wherein a first boot block of the second copy corresponds to data of a first boot block of the first copy, and wherein the boot partition corresponds to data associated with a boot operation of a host device; and a controller coupled to the memory device, wherein the controller is configured to: comparing a plurality of boot blocks of the first replica with a corresponding plurality of boot blocks of the second replica, wherein a result of the comparison is stored in a delta table; increasing a correction capability associated with one or more guide blocks of the first copy corresponding to a different one or more guide blocks of the second copy; as well as The boot partition is provided to the host device, wherein providing the boot partition includes increasing error correction capabilities during the boot operation using the first copy, the second copy, and the delta table.

20. The data storage device of claim 19, wherein the second copy is used as soft bit information of the first copy.

Images