Optimized XOR loading in SRAM and HMB

Abstract

Selectively writing relevant bins directly to a controller's volatile memory (e.g., SRAM) based on a next-to-write address, and writing the remaining bins to a host's volatile memory (e.g., DRAM or HMB), avoids the need for additional reads from the host's volatile memory and writes from the controller's volatile memory. By avoiding the need for additional reads from the host's volatile memory, which has a slower access time than the controller's volatile memory, exit latency from boot and low-power-state exit flows is improved. Before writing the parity bins to the controller or host, the controller can store parity bins and / or the next-to-write address in non-volatile memory.The next-to-write address is then evaluated to determine whether a parity bin is written to the controller's volatile memory or to the host's volatile memory.

Description

CROSS-REFERENCE TO RELATED REGISTRATIONS This application claims the benefit and priority of non-provisional US patent application No. 18 / 584,081. BACKGROUND Territory of Revelation Embodiments of the present disclosure generally relate to improving parity storage. Description of the state of the art Most storage devices implement schemes, such as XOR, to protect data stored on non-volatile memory (e.g., NAND flash memory). In an XOR scheme, data from the word lines (WLs) are subjected to an XOR operation to generate XOR parity. The XOR parity generated by accumulating the results of the XOR operation between the current WL and one or more other WLs is stored in a parity bin. If data in any WL is lost (e.g., due to a physical defect or otherwise), the XOR parity is used to recover the data stored on that WL. Currently, during a proper shutdown (GSD), the bin parities in the NAND are stored in a special XOR block for all open blocks (i.e., blocks that are not yet full). During the current boot flow and exit from the low-power state flow, the parity bins are loaded from the NAND into a host memory buffer (HMB), and then the relevant bins are read from the HMB and written to static random-access memory (SRAM). Because the HMB is located outside the device, the access time for the device controller to read and write to it is slow. There is a need in engineering for improved XOR loading for a data storage device. SUMMARY Selectively writing relevant bins directly to the controller's volatile memory (e.g., SRAM) based on a next-to-write address, and writing the remaining bins to the host's volatile memory (e.g., DRAM or HMB), avoids the need for additional reads from the host's volatile memory and writes from the controller's volatile memory. By avoiding the need for additional reads from the host's volatile memory, which has a slower access time than the controller's volatile memory, exit latency from boot and low-power-state exit flows is improved. Before writing the parity bins to the controller or the host, the controller can store parity bins and / or the next-to-write address in non-volatile memory.The next-to-write address is then evaluated to determine whether a parity bin is written to the controller's volatile memory or to the host's volatile memory. In one embodiment, a data storage device comprises: a storage device; and a controller coupled to the storage device, the controller being configured to: store a plurality of parity bins in the non-volatile memory; select at least one parity bin from the plurality of parity bins to write to a first volatile memory; write the at least one parity bin to the first volatile memory; and write the remaining parity bins of the plurality of parity bins to a second volatile memory. In another embodiment, a data storage device comprises: a storage device; and a controller coupled to the storage device, the controller being configured to: determine the address of an open block in a first volatile memory, wherein the address of the open block in the first volatile memory is the next address in the first volatile memory to which the next data will be written; store the address of the open block in the non-volatile memory; select at least one first parity bin to write to the first volatile memory; write the at least one first parity bin to the open block in the first volatile memory; and write at least one second parity bin to a second volatile memory. In another embodiment, a data storage device comprises: means for storing data; and a controller coupled to the means for storing data, the controller being configured to: store a plurality of parity bins in non-volatile memory in response to a predetermined event; determine the address of an open block in a first volatile memory, wherein the address of the open block in the first volatile memory is the next address in the first volatile memory to which the next data will be written; store the address of the open block in the first volatile memory; select at least one parity bin from the plurality of parity bins to write to a first volatile memory during a boot exit flow or a low-power-state exit flow; and write the at least one parity bin to the first volatile memory.and writing the remaining parity bins of the multitude of parity bins to a second volatile memory. BRIEF DESCRIPTION OF THE DRAWINGS To clarify in detail how the aforementioned features of the present disclosure are to be understood, a more detailed description of the disclosure, which has been briefly summarized above, follows with reference to embodiments, some of which are illustrated in the accompanying drawings. It should be noted, however, that the accompanying drawings illustrate only common embodiments of this disclosure and are therefore not to be regarded as limiting its scope of protection, since the disclosure may also permit other, equally effective embodiments. Fig. 1 is a schematic block diagram illustrating a storage system in which a data storage device according to certain embodiments can function as a storage device for a host device. Fig. 2 is a schematic block diagram illustrating a storage system with an HMB according to one embodiment.Figure 3 is a schematic diagram illustrating a physical flash memory block according to another embodiment. Figure 4 is a schematic block diagram illustrating a flash memory die side according to another embodiment. Figure 5 is a schematic block diagram illustrating an XOR scheme for a single-level cell jumbo block (SLC jumbo block) according to another embodiment. Figure 6 is a schematic block diagram illustrating an XOR block in volatile memory according to another embodiment. Figure 7 is a flowchart illustrating a write flow of triple-level cell parity (TLC parity) according to another embodiment. Figure 8 is a schematic diagram illustrating an XOR scheme for a jumbo block according to another embodiment.Figure 9 is a flowchart illustrating a write flow of triple-level cell parity (TLC parity) according to another embodiment. Figure 10 is a flowchart illustrating a parity binning process according to yet another embodiment. To facilitate understanding, identical reference numerals have been used wherever possible to denote identical elements present in all figures. It is assumed that elements disclosed in one embodiment can also be advantageously used in other embodiments without specific mention. DETAILED DESCRIPTION The following refers to embodiments of the disclosure. It is understood, however, that the disclosure is not limited to specifically described embodiments. Instead, any combination of the following features and elements, regardless of whether they relate to different embodiments or not, is considered for implementing and practically realizing the disclosure. Furthermore, although embodiments of the disclosure may offer advantages over other possible solutions and / or over the prior art, the fact that a given embodiment offers a particular advantage or not does not constitute a limitation of the disclosure.Therefore, the following aspects, features, embodiments, and advantages are merely illustrative and are not considered elements or limitations of the accompanying claims unless expressly stated in one or more claims. Likewise, a reference to "the disclosure" is not to be construed as a generalization of any subject matter disclosed herein and is not to be considered as part of or a limitation of the accompanying claims unless expressly stated in one or more claims. Selectively writing relevant bins directly to the controller's volatile memory (e.g., SRAM) based on a next-to-write address, and writing the remaining bins to the host's volatile memory (e.g., DRAM or HMB), avoids the need for additional reads from the host's volatile memory and writes from the controller's volatile memory. By avoiding the need for additional reads from the host's volatile memory, which has a slower access time than the controller's volatile memory, exit latency from boot and low-power-state exit flows is improved. Before writing the parity bins to the controller or the host, the controller can store parity bins and / or the next-to-write address in non-volatile memory.The next-to-write address is then evaluated to determine whether a parity bin is written to the controller's volatile memory or to the host's volatile memory. Fig. 1 is a schematic block diagram illustrating a storage system 100 with a data storage device 106, which, according to certain embodiments, can function as a storage device for a host device 104. For example, the host device 104 can utilize non-volatile memory (NVM) 110 enclosed in the data storage device 106 for storing and retrieving data. The host device 104 includes a host DRAM (dynamic random-access memory) 138. In some examples, the storage system 100 can include a plurality of storage devices, such as the data storage device 106, which can function as a storage array.For example, the storage system 100 can include a variety of data storage devices 106 configured as a redundant array of low-cost / independent hard disks (RAID) that together act as a mass storage device for the host device 104. The host device 104 can store data on and / or retrieve data from one or more storage devices, such as the data storage device 106. As illustrated in Fig. 1, the host device 104 can communicate with the data storage device 106 via an interface 114. The host device 104 can include a wide range of devices, including computer servers, network attached storage (NAS) units, desktop computers, notebooks (i.e., laptops), tablet computers, set-top boxes, mobile devices such as smartphones or smart tablets, televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, or other devices capable of sending data to or receiving data from a data storage device. The host DRAM 138 can optionally include a host memory buffer (HMB) 150. The HMB 150 is a section of the host DRAM 138 that is allocated to the data storage device 106 for the exclusive use of a controller 108 of the data storage device 106. For example, the controller 108 can store mapping data, buffered instructions, logic-physical tables (L2P tables), metadata, and the like in the HMB 150. In other words, the HMB 150 can be used by the controller 108 to store data that would normally be stored in volatile memory 112, a buffer 116, internal memory of the controller 108 such as static random-access memory (SRAM), and the like. In examples where the data storage device 106 does not include DRAM (i.e., optional DRAM 118), the controller 108 can use the HMB 150 as the DRAM of the data storage device 106. The data storage device 106 includes the controller 108, NVM 110, a power supply 111, volatile memory 112, the interface 114, a write buffer 116, and optional DRAM 118. In some examples, the data storage device 106 may include additional components not shown in Fig. 1 for clarity. For example, the data storage device 106 may include a printed circuit board (PCB) to which components of the data storage device 106 are mechanically attached and which includes electrically conductive traces that electrically connect components of the data storage device 106 or the like. In some examples, the physical dimensions and connection configurations of the data storage device 106 may conform to one or more standard form factors. Some examples of standard form factors include 3.5-inch data storage devices (e.g.,The following are supported, but not limited to: an HDD or SSD), 2.5-inch data storage devices, 1.8-inch data storage devices, Peripheral Component Interconnect (PCI), PCI-Extended (PCI-X), PCI Express (PCIe) (e.g., PCIe x1, x4, x8, x16, PCIe Mini Card, MiniPCI, etc.). In some examples, the data storage device 106 may be directly coupled to a mainboard of the host device 104 (e.g., directly soldered or plugged into a connector). Interface 114 can include a data bus for data exchange with the host device 104 and / or a controller bus for exchanging commands with the host device 104. Interface 114 can operate according to any suitable protocol. For example, interface 114 can 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), or the like. Interface 114 (e.g.,The data bus, the control bus, or both are electrically connected to the controller 108 and provide an electrical connection between the host device 104 and the controller 108, allowing data to be exchanged between them. In some examples, the electrical connection of the interface 114 can 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 can receive power from the host device 104 via the interface 114. The NVM 110 can include a variety of storage devices or storage units. The NVM 110 can be configured to store and / or retrieve data. For example, a storage unit of the NVM 110 can receive data and a message from the Controller 108 instructing the storage unit to store the data. Likewise, the storage unit can receive a message from the Controller 108 instructing the storage unit to retrieve data. In some examples, each of the storage units can be referred to as a die. In some examples, the NVM 110 can include a variety of dies (i.e., a variety of storage units). In some examples, each storage unit can be configured to store relatively large amounts 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.). In some examples, each storage unit can include any type of non-volatile storage device, such as flash memory devices, phase-change memory (PCM), resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), holographic storage devices, and any other type of non-volatile storage device. The NVM 110 can incorporate a variety of flash storage devices or units. NVMe flash storage devices can include NAND- or NOR-based flash memory devices and can store data based on a charge contained in a floating gate of a transistor for each flash memory cell. In NVMe flash storage devices, the flash storage device can be subdivided into a multitude of dies, with each die of the multitude containing a multitude of physical or logical blocks, which can be further subdivided into a multitude of pages. Each block of the multitude of blocks within a given storage device can contain a multitude of NVMe cells. Rows of NVM cells can be electrically connected using a word line to define a page from a multitude of pages.The individual cells in each of the multitude of pages can be electrically connected to the respective bit lines. Furthermore, NVMe flash storage devices can be 2D or 3D devices and can be single-level cells (SLC), multi-level cells (MLC), triple-level cells (TLC), or quad-level cells (QLC). The Controller 108 can write data to and read from NVMe flash storage devices at the page level and erase data from NVMe flash storage devices at the block level. The power supply 111 can power one or more components of the data storage device 106. In standard mode, the power supply 111 can power one or more components using power provided by an external device, such as the host device 104. For example, the power supply 111 can power the one or more components using power received from the host device 104 via interface 114. In some examples, the power supply 111 can include one or more power storage components configured to power the one or more components when they are in a shutdown mode, such as when no more power is being received from the external device. In this way, the power supply 111 can function as an integrated backup power source.Examples of one or more energy storage components include capacitors, supercapacitors, batteries, and the like. In some cases, the amount of electricity that can be stored by one or more energy storage components may depend on the cost and / or size (e.g., area / volume) of the one or more energy storage components. In other words, as the amount of electricity stored by one or more energy storage components increases, so do the cost and / or size of the one or more energy storage components. The volatile memory 112 can be used by the controller 108 to store information. The volatile memory 112 can include one or more volatile memory devices. In some examples, the controller 108 can use the volatile memory 112 as a cache. For example, the controller 108 can store cached information in the volatile memory 112 until the cached information is written to the NVM 110. As illustrated in Fig. 1, the volatile memory 112 can consume power, which is received from the power supply 111. Examples of volatile memory 112 include, but are not limited to, random access memory (RAM), DRAM, SRAM, and synchronous dynamic RAM (SDRAM (e.g., DDR1, DDR2, DDR3, DDR3L, LPDDR3, DDR4, LPDDR4, and the like)).The optional DRAM 118 can also be used to store mapping data, buffered instructions, logic-physical tables (L2P tables), metadata, cached data, and the like. In some examples, the data storage device 106 does not include the optional DRAM 118, so the data storage device 106 has no DRAM. In other examples, the data storage device 106 does include the optional DRAM 118. 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 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 can initiate a data storage command to store data in the NVM 110 and monitor the progress of the data storage command. The controller 108 can determine at least one operating property of the storage system 100 and store at least one operating property 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 the data associated with the write command in the internal memory or write buffer 116 before sending the data to the NVM 110.The controller 108 can include an optional second volatile memory 120. The optional second volatile memory 120 can be similar to the volatile memory 112. For example, the optional second volatile memory 120 can be SRAM. The controller 108 can allocate a portion of the optional second volatile memory to the host device 104 as a controller memory buffer (CMB) 122. The CMB 122 can be accessed directly by the host device 104. For example, instead of managing one or more delivery queues in the host device 104, the host device 104 can use the CMB 122 to store the one or more delivery queues that are normally managed in the host device 104.In other words, the host device 104 can generate commands and store the generated commands with or without the associated data in the CMB 122, with the controller 108 accessing the CMB 122 to retrieve the stored generated commands and / or the associated data. It is understood that while the host memory buffer (HMB) is used as volatile host memory, the host can also use DRAM as volatile memory. Rather, the HMB is an exemplary volatile memory used by a host device. Aspects of the disclosure are equally applicable to DRAM. Fig. 2 is a schematic block diagram illustrating a storage system 200 with an HMB according to one embodiment. The storage system 200 can be further divided into a host side 220 and a device side 230. The host side 220 of the storage system 200 comprises a host device 202. The host device 202 comprises a host central processing unit (CPU) 204 and a DRAM 206. The host CPU 204 and the DRAM 206 are communicatively coupled. The host memory buffer (HMB) 208 is part of the host DRAM 206. The device side 230 of the storage system 200 includes a storage device 212. The storage system 200 further includes a Peripheral Component Interconnect Express bus (PCIe bus) 210. The host CPU and the PCIe bus 210 are communicatively coupled. The PCIe bus 210 and the storage device 212 are communicatively coupled. The HMB 208 is allocated from the host DRAM 206 as extended SRAM. The HMB 208 can also be allocated to the storage device 212 for internal operations. The HMB 208 is reserved solely for the storage device 212, and the host software should not modify the HMB 208 at all. Because the HMB 208 is located outside the storage device 212, the read and write access time between the HMB 208 and a device controller of the storage device 212, such as the controller 108 of Fig. 1, is slower than the read and write access time between a device controller of the storage device 212 and the internal SRAM of the storage device 212. In other words, during read and write operations, a device controller of the storage device 212 can access the internal SRAM of the storage device 212 faster than the external HMB 208.The loading and saving of parities in the HMB occurs dynamically during operation. Fig. 3 is a schematic diagram illustrating a physical flash memory block 300 according to another embodiment. The physical flash memory block 300 comprises WLs 302, strings 304, and pages 306. Flash memory cells are connected in a specific sequence to enable efficient access. A sequence of memory cells is connected in a string 304. A WL 302 is a line that connects all the control gates of the memory cells at the same position in the strings 304 and defines a page 306 within the block. A page 306, or a logical WL, is a logical structure that encloses one bit from each cell in a WL 302. Programming can be performed on all pages, whereas reading is performed on portions of a page. In the physical flash memory block 300, each WL 302 is connected to five strings 304 (numbered 0, 1, 2, 3, and 4).The strings 304 are repeated in the order 0, 1, 2, 3, and 4 in each WL block. Each page 306 is associated with a string 304. Error Correction Code (ECC) protection algorithms provide data protection for user and internal data. Storage devices store user and internal data on NAND flash memory dies with redundant parity data used by ECC protection algorithms. The two main methods of ECC protection are low-density parity check (LDPC) algorithms and XOR protection. XOR protection is used to protect contiguous memory blocks from physical defects that can occur in the memory elements of BiCS technology. For example, physical short circuits can occur in BiCS6 memory due to WL-to-WL interactions. To protect against WL-to-WL short circuit problems, two adjacent WLs in a single layer are protected by unique bins. BiCS6 memory technology uses 10 bins for single-level cell blocks (SLC blocks) and 30 bins for triple-level cell blocks (TLC blocks). Figure 4 is a schematic block diagram illustrating a flash memory die page 400 according to another embodiment. In one embodiment, the flash memory die page 400 is a die page (64 KB) 402. Each bin (16 KB) is a group of die pages 404, 406, 408, and 410 that are XORed. A parity bin is determined using Parity Bin = Data1^Data2^...Data3. Each bin parity result is calculated during data accumulation. When the block reaches full capacity, the results of the last parity bins are stored within the data block, at the end of the block, or at other parity locations. When the device begins writing to a new block, the parity for the block is set to 0, which occurs before writing the data that accumulates the parity bins. The parity accumulation is temporarily stored in the controller's SRAM memory.During GSD, the bin parities are stored in a special XOR block of non-volatile memory (e.g., NAND) with all open blocks that are not yet full. During the boot and low-power-state exit flows, the parities are loaded from the NAND into the controller SRAM to continue the accumulation process. Figure 5 is a schematic block diagram illustrating an XOR 500 scheme for a single-level cell jumbo block (SLC jumbo block) according to another embodiment. The XOR 500 scheme for a single-level cell jumbo block (SLC jumbo block) comprises four dies: Die0 502, Die1 504, Die2 506, and Die3 508. Parities can be computed for the jumbo block, which is a logic block composed of multiple die blocks, thus improving performance and performing parallel read and write operations. In a storage device, there are multiple jumbo blocks managed in parallel to store controller and host data. However, the controller SRAM used to store parities is limited to only a few slots for SLC parity and a few slots for TLC parity.The remaining parities are stored in an HMB or a special XOR block, which is used to store all accumulated parities during a GSD. Figure 6 is a schematic block diagram illustrating a jumbo block containing XOR data 600 in volatile memory according to another embodiment. In certain embodiments, loading and writing parities to non-volatile memory (e.g., NAND (XOR blocks)) from the HMB typically occurs during the flows of proper shutdown or upon entering low-power mode. The SLC jumbo block parity contains 10 bins (160 KB) in the SRAM slot. The TLC jumbo block parity contains 30 bins (480 KB) in the SRAM slot. Because the parity bins are only partially stored in the SRAM, the NAND only holds the nearest bins that are used. The controller continues to copy bins to and from the HMB, where the complete set is stored. The SRAM holds two SLC parities with 8 bins each (128 KB*2) and two TLC parities with 12 bins each (192 KB*2).Since the size of the SRAM is limited and the parity data is large, only a portion of the parity bins is held in the SRAM. The complete set of parity data is stored in the HMB. However, the problem is that during the current boot flow and when exiting low-power or active-idle states, the parity bins are loaded from the NAND flash memory into the HMB, and then the relevant bins are read from the HMB and written to the SRAM. This significantly increases the boot flow and low-power exit time. Selectively loading only the relevant bins directly into the controller's SRAM and the remaining bins into the HMB reduces the time required to get the HMB ready and then write to the SRAM. An example jumbo block containing XOR block data 600 comprises multiple dies. For example, DIE0 602, DIE1 604, DIE2 606, and DIE3 608. Within the jumbo block containing XOR block data 600, four different parities are written from the XRAM (i.e., SRAM or DRAM) to the XOR jumbo block in NAND. A parity, such as parity 650, has 10 bins, which corresponds to the size of 10 levels. However, the firmware can write to four levels simultaneously, so a pad (PAD) of two levels (e.g., 16 KB * 2) is added. The pad can consist of dummy data or zeros. The first parity 610, second parity 620, third parity 630, and fourth parity 640 are different parities for different open blocks written from the HMB to the NAND. Each parity takes up to 160 KB in the HMB and 196 KB in the NAND-XOR jumbo block. Figure 7 is a flowchart illustrating a write flow 700 of a single TLC parity according to another embodiment. During the TLC parity write flow 700, the controller loads every 10 / 30 bins from a NAND XOR block into an HMB. The bins are then read from the HMB and written to volatile memory (e.g., SRAM), specifically the relevant bins, which are 128 KB / 192 KB. The TLC parity write flow 700 includes interactions with NAND 702, SRAM 704, physical storage (PS) 706, flash junction (FTL) 708, and HMB 710. Load lines 720, 730, 740, and 750 express the loading of the parity bins into the HMB 710. In SLC mode, 10 bins are loaded, and in TLC mode, 30 bins are loaded from NAND-XOR block 702 into HMB 710. Write flow 700 represents the loading of the TLC parity, so that 30 bins from NAND-XOR block 702 are loaded into HMB 710. On load line 720 (index 0), 4 bins are loaded into HMB 710.At load line 730 (index 4), an additional 4 bins are loaded into the HMB 710. The controller then continues to load bins from the NAND-XOR block 702 into the HMB 710 step by step, a process referred to as "further loading operations." At load line 740 (index 24), another 4 bins are loaded into the HMB 710. At load line 750 (index 28), the last 2 bins are loaded into the HMB 710. After load line 750, 30 bins are stored in the HMB 710. Each time bins are loaded into the HMB 710, the HMB 710 acknowledges the completion of the loading process by sending an acknowledgment of completion (722, 732, 742, 752) to the FTL 708. After the bins are loaded into the HMB 710 (i.e., after load line 750), the controller then copies specific bins from a start bin. The PS 706 sends a request to the FTL 708 (on load line 760), which is then forwarded to the HMB 710 (on load line 762) to copy 12 specific bins from the start bin. The PS 706 calculates the value of the start bin, which is determined according to the next-to-write address of the host block position. On read line 770, the controller copies the 12 specific bins into the SRAM 704. After read line 770, both the HMB 710 and the FTL 708 send read acknowledgments 772 and 780, respectively, confirming that the 12 specific bins have been read.The write flow 700 is executed a total of four times: twice for SLC-open blocks and twice for TLC-open blocks. Figure 8 is a schematic diagram illustrating an XOR scheme for a Jumbo Block 800 according to another embodiment. During boot and low-power-state exit flows, the controller must load the bin parities from the NAND into the SRAM so that it can continue updating the XOR parities. The controller is configured to load the relevant bins directly into the SRAM. The XOR scheme 800 comprises four dies: Die0 802, Die1 804, Die2 806, and Die3 808. The XOR scheme 800 represents that a specific logical WL is associated with a specific bin, and that each row represents a different bin. The controller stores the state of an open host and the address to which the next data should be written (i.e., the "next-to-write" address). The next-to-write address determines which parity bin is "relevant." Relevant parity bins are the next bins to be written. For example, if the next address to be written to a TLC block is on line 4, the controller loads the following 12 bins directly into SRAM: 4, 5, 6, 7; 8, 9, 10, 11; and 12, 13, 14, 15. If the next address to be written is on line 24, the controller loads bins 24, 25, 26, 27; 28, 29; 0, 1; and 2, 3, 4, 5 into SRAM. The bins not loaded into SRAM are written to the HMB. Therefore, no additional read operation from the HMB and write operation to the SRAM is required for the bins written directly to the SRAM. Figure 9 is a flowchart illustrating a write flow 900 of triple-level cell parity (TLC parity) according to another embodiment. The write flow 900 includes interactions with the NAND 902, the SRAM 904, the PS 906, the FTL 908, and the HMB 910. In a copy line 920, the controller copies 12 specific bins (i.e., the relevant bins) from a start bin in the PS 906 to the NAND 902, based on the position of the next host block to be written. In the load lines 930, 940, and 950, the controller loads the 12 specific bins into the SRAM 904, with each load line loading 4 bins into the SRAM 904. After loading the 12 specific bins into SRAM 904, the controller begins loading the remaining (i.e., non-specific and irrelevant) bins into HMB 910. On load line 960 (index 12), the controller loads 4 non-specific bins into HMB 910. The index number (e.g.,Index 12 indicates the space in a memory buffer in the HMB. Four bins are loaded into the HMB 910 on load lines 970 (Index 16) and 980 (Index 28) for each load line. Two further load operations occur between load lines 970 and 980, each loading four additional bins, indicated by "2 further load operations...". This means four bins are loaded into the HMB (Index 20) and another four bins into the HMB (Index 24). After load line 980, the remaining 18 non-specific bins have been loaded into the HMB 910. When the bins are uploaded to the HMB 910, the HMB 910 confirms the completion of the load operation by sending the load completion acknowledgments 962, 972, and 982 to the FTL 908. Since the relevant bins are loaded into the SRAM 904 and the remaining bins are loaded into the HMB 910, no additional read operations from the HMB 910 and write operations to the SRAM 904 are required.As a result, the exit latency from the boot and low-power state exit flows is improved. Figure 10 is a flowchart illustrating a parity bin storage process 1000 according to another embodiment. The parity bin storage process 1000 reads parity bins from the NAND and stores the relevant parity bins (i.e., parity bins to be written next) in the SRAM. Only the minimum amount of relevant XOR parities is stored in the SRAM during the boot and low-power-state exit flows. The remaining XOR parities are stored in the HMB, thus reducing the number of read and write operations from the HMB back to the storage device's internal SRAM. These time-sensitive flows can save microseconds during the boot and low-power-state exit flows, while avoiding the complexity of additional messages on the bus (a set of data that is not read).Storing parity bins thus reduces the time required to read from the HMB and write to the relevant bins in volatile memory (e.g., SRAM). In certain embodiments, the stored data size can be 640 KB, since SLC parity (128 KB) times the number of open SLC jumbo blocks (2) plus TLC parity (192 KB) times the number of open TLC jumbo blocks (2) equals 128 KB * 2 + 192 KB * 2 = 640 KB. In block 1002, the controller detects a proper shutdown of the data storage device. In block 1004, the controller stores a variety of parity bins in non-volatile memory (i.e., NAND). In block 1006, the controller determines the address of an open block in the SRAM. In block 1008, the controller stores the address of the open block in the non-volatile memory. In block 1010, the controller detects a boot or low-power state exit flow. In block 1012, the controller determines whether to write the parity bin to the SRAM based on the next-to-write address. If the parity bin is to be written to the SRAM, the controller writes the parity bin to the open block in the SRAM in block 1014. If the parity bin is not to be written to the SRAM, the controller writes the parity bin to the DRAM or HMB in block 1016. Selectively writing relevant bins directly to the controller's volatile memory (e.g., SRAM) based on a "next-to-write" address, and writing the remaining bins to the host's volatile memory (e.g., DRAM or HMB), avoids the need for additional reads from the host's volatile memory and writes from the controller's volatile memory. By avoiding additional reads from the host's volatile memory, which has a slower access time than the controller's volatile memory, exit latency from boot and low-power-state exit flows is improved. Before writing the parity bins to the controller or the host, the controller can store parity bins and / or the next-to-write address in non-volatile memory.The next-to-write address is then evaluated to determine whether a parity bin is written to the controller's volatile memory or to the host's volatile memory. In one embodiment, a data storage device comprises: a storage device; and a controller coupled to the storage device, the controller being configured to: store a plurality of parity bins in the non-volatile memory; select at least one parity bin from the plurality of parity bins to write to a first volatile memory; write the at least one parity bin to the first volatile memory; and write the remaining parity bins of the plurality of parity bins to a second volatile memory. The non-volatile memory is NAND. The first volatile memory is static random-access memory (SRAM). The second volatile memory is dynamic random-access memory (DRAM) or a host memory buffer (HMB). The selection of the at least one parity bin is based on the next data to be written to the first volatile memory.The controller is further configured to store the plurality of parity bins in non-volatile memory during a proper shutdown flow. The controller is further configured to write the one or more parity bins to the first volatile memory during a boot exit flow. The controller is further configured to write the one or more parity bins to the first volatile memory during a low-power-state exit flow. The controller is further configured to receive an acknowledgment from the second volatile memory after writing the remaining parity bins of the plurality of parity bins to the second volatile memory. The controller does not receive an acknowledgment from the first volatile memory after writing the one or more parity bins to the first volatile memory.The controller is further configured to: determine the address of an open block in the first volatile memory, where the address of the open block in the first volatile memory is the next address in the first volatile memory into which the next data will be written; store the address of the open block in the non-volatile memory; write at least one first parity bin to the open block in the first volatile memory; and write at least one second parity bin to the second volatile memory.The controller is further configured to: store the plurality of parity bins in a non-volatile memory in response to a predetermined event; determine the address of an open block in the first volatile memory, where the address of the open block in the first volatile memory is the next address in the first volatile memory into which the next data will be written; store the address of the open block in the first non-volatile memory; and select at least one parity bin from the plurality of parity bins to write to a first volatile memory during a boot exit flow or a low-power-state exit flow. In another embodiment, a data storage device comprises: a storage device; and a controller coupled to the storage device, the controller being configured to: determine the address of an open block in a first volatile memory, wherein the address of the open block in the first volatile memory is the next address in the first volatile memory to which the next data will be written; store the address of the open block in the non-volatile memory; select at least one first parity bin to write to the first volatile memory; write the at least one first parity bin to the open block in the first volatile memory; and write at least one second parity bin to a second volatile memory.The controller is further configured to select the first parity bin, or at least one, based on the next data to be written to the first volatile memory. The first parity bin is triple-level cell parity (TLC parity). The second parity bin is single-level cell parity (SLC parity). The controller is also configured to store the first and second parity bins in non-volatile memory before writing them to volatile memory. In another embodiment, a data storage device comprises: means for storing data; and a controller coupled to the means for storing data, the controller being configured to: store a plurality of parity bins in non-volatile memory in response to a predetermined event; determine the address of an open block in a first volatile memory, wherein the address of the open block in the first volatile memory is the next address in the first volatile memory to which the next data will be written; store the address of the open block in the first non-volatile memory; select at least one parity bin from the plurality of parity bins to write to a first volatile memory during a boot exit flow or a low-power-state exit flow; and write the at least one parity bin to the first volatile memory.and writing the remaining parity bins of the plurality of parity bins to a second volatile memory. The predetermined event is a proper shutdown of the data storage device. The controller is further configured to write the one or more parity bins to the open block in the first volatile memory. While the foregoing relates to embodiments of the present disclosure, other and further embodiments of the disclosure may be conceived without deviating from its basic scope of protection, and the scope of protection thereof is determined by the following claims. QUOTES INCLUDED IN THE DESCRIPTION This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature US 18 / 584,081

[0001]

Claims

Data storage device comprising: a storage device; and a controller coupled to the storage device, the controller being configured to: store a plurality of parity bins in non-volatile memory; select at least one parity bin from the plurality of parity bins to write to a first volatile memory; write the at least one parity bin to the first volatile memory; and write the remaining parity bins of the plurality of parity bins to a second volatile memory. Data storage device according to claim 1, wherein the non-volatile memory is NAND. Data storage device according to claim 1, wherein the first volatile memory is a static random access memory (SRAM). Data storage device according to claim 1, wherein the second volatile memory is a dynamic random access memory (DRAM) or a host memory buffer (HMB). Data storage device according to claim 1, wherein the selection of the at least one parity bin is based on the next data to be written to the first volatile memory. Data storage device according to claim 1, wherein the controller is further configured to store the plurality of parity bins in non-volatile memory during a flow of proper shutdown. Data storage device according to claim 1, wherein the controller is further configured to write the at least one parity bin to the first volatile memory during a boot exit flow. Data storage device according to claim 1, wherein the controller is further configured to write the at least one parity bin to the first volatile memory during a low-power-state exit flow. Data storage device according to claim 1, wherein the controller is further configured to receive an acknowledgment from the second volatile memory after the remaining parity bins of the plurality of parity bins have been written to the second volatile memory. Data storage device according to claim 1, wherein the controller does not receive an acknowledgment from the first volatile memory after writing the at least one parity bin to the first volatile memory. Data storage device according to claim 1, wherein the controller is further configured to: determine an address of an open block in the first volatile memory, wherein the address of the open block in the first volatile memory is a next address in the first volatile memory to which the next data is to be written; store the address of the open block in the non-volatile memory; write at least one first parity bin to the open block in the first volatile memory; and write at least one second parity bin to the second volatile memory. Data storage device according to claim 1, wherein the controller is further configured to: store the plurality of parity bins in a non-volatile memory in response to a predetermined event; determine an address of an open block in the first volatile memory, wherein the address of the open block in the first volatile memory is the next address in the first volatile memory to which the next data will be written; store the address of the open block in the first volatile memory; and select at least one parity bin from the plurality of parity bins to write to the first volatile memory during a boot exit flow or a low-power-state exit flow. A data storage device comprising: a storage device; and a controller coupled to the storage device, the controller being configured to: determine the address of an open block in a first volatile memory, wherein the address of the open block in the first volatile memory is the next address in the first volatile memory to which the next data will be written; store the address of the open block in a non-volatile memory; select at least one first parity bin to write to the first volatile memory; write the at least one first parity bin to the open block in the first volatile memory; and write at least one second parity bin to a second volatile memory. Data storage device according to claim 13, wherein the controller is further configured to select the at least one first parity bin based on the next data to be written to the first volatile memory. Data storage device according to claim 13, wherein the at least one first parity bin is a triple-level cell parity (TLC parity). Data storage device according to claim 13, wherein the at least one first parity bin is a single-level cell parity (SLC parity). Data storage device according to claim 13, wherein the controller is further configured to store the at least one first and second parity bin in the non-volatile memory before writing the at least one first and second parity bin to the volatile memory. A data storage device comprising: means for storing data; and a controller coupled to the means for storing data, the controller being configured to: store a plurality of parity bins in non-volatile memory in response to a predetermined event; determine the address of an open block in a first volatile memory, wherein the address of the open block in the first volatile memory is the next address in the first volatile memory to which the next data will be written; store the address of the open block in the first volatile memory; select at least one parity bin from the plurality of parity bins to write to a first volatile memory during a boot exit flow or a low-power-state exit flow; write the at least one parity bin to the first volatile memory;and writing the remaining parity bins of the multitude of parity bins to a second volatile memory. Data storage device according to claim 18, wherein the predetermined event is a proper shutdown of the data storage device. Data storage device according to claim 18, wherein the controller is further configured to write the at least one parity bin to the open block in the first volatile memory.

Images