Tlc data programming with mixed parity

Abstract

The present disclosure relates generally to improving programming of data storage devices such as solid state drives (SSDs). A first memory device has a first XOR element and a second memory device has a second XOR element. The ratio of the first XOR element to the capacity of the first memory device is substantially less than the ratio of the second XOR element to the capacity of the second memory device. Read verify operations to discover programming failures are performed on a word line by word line basis, on an erase block by erase block basis, or on both a word line by word line basis and an erase block by erase block basis. Because these programming failures are discovered and repaired prior to programming the second memory device, the second XOR element can be substantially reduced.

Description

BACKGROUND TECHNICAL FIELD

[0001] Embodiments of the present disclosure generally relate to improving programming of data storage devices, such as solid state drives (SSDs).

[0002] Description of the Related Art

[0003] Programming or writing data can require two write phases: foggy and fine. In foggy-fine programming, bits to be written cannot be written only once. Instead, data needs to be first written through foggy programming, in which a voltage pulse is provided to push the current state to a higher resolution state, but not a fully resolved state. Fine programming is performed at a point in time after foggy programming to write the data again in a fully resolved state.

[0004] As data is programmed or written to respective locations of a data storage device, programming failures, such as bit errors, can accumulate. To repair the programming failures, exclusive-OR (XOR) parity data is generated by an error correction engine, such as a parity engine or a low density parity check (LDPC) engine. The XOR parity data is stored in each location where data is written. For example, if data is fine programmed to a first non-volatile memory device, the data is first programmed to a volatile memory device cache or a second non-volatile memory device cache. The data is then fog programmed to the first non-volatile memory device. After completing the fog programming to the first non-volatile memory device, the data is fine programmed to the first non-volatile memory device. The XOR parity data can be generated and stored with the programmed data in each location of the data programming sequence, such as the volatile memory device cache, the second non-volatile memory device cache, the fog programming to the first non-volatile memory device, and the fine programming to the first non-volatile memory device. The accumulation of XOR parity data in each of the previously mentioned memory devices increases the XOR parity overhead and reduces the over-provisioning or capacity of user data in the data storage device.

[0005] Accordingly, there is a need in the art to improve programming of non-volatile memory while reducing XOR parity overhead and maintaining or increasing the reliability of the data storage device. SUMMARY

[0006] The present disclosure generally relates to improving programming of data storage devices such as solid state drives (SSDs). A first memory device has a first XOR element and a second memory device has a second XOR element. The ratio of the first XOR element to the capacity of the first memory device is substantially less than the ratio of the second XOR element to the capacity of the second memory device. Read verify operations to discover programming failures are performed on a word line by word line basis, on an erase block by erase block basis, or on both a word line by word line basis and an erase block by erase block basis. Because these programming failures are discovered and repaired prior to programming the second memory device, the second XOR element can be significantly reduced.

[0007] In one embodiment, a data storage device includes a controller and a memory device coupled to the controller. The memory device includes a first superblock having a first parity portion of a first storage size and a second superblock having a second parity portion of a second storage size. The first storage size is less than the second storage size.

[0008] In another embodiment, a data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to receive host data from a host device, generate first exclusive OR (XOR) parity data for the host data, encode the host data and the first XOR parity data with an encoder, write the host data and the first XOR parity data to a first memory superblock, decode valid data and first XOR parity data written to the first memory superblock, where the valid data corresponds to the host data that has not been modified by the host device located in the first memory superblock, generate second XOR parity data for the decoded valid data, re-encode the decoded data and second XOR parity data with the encoder, and write the re-encoded data and parity data to a second memory superblock. The size of the re-encoded second XOR parity data is less than the size of the first XOR parity data.

[0009] In another embodiment, a data storage device includes a memory device including a first memory superblock and a second memory superblock, means for storing host data and parity data in the first memory superblock, and means for storing a copy of the host data and parity data in the second memory superblock, where the copy of the parity data utilizes less parity data storage in the second superblock than the amount of parity data storage in the first superblock. BRIEF DESCRIPTION OF DRAWINGS

[0010] So that the manner in which the above recited features of the present disclosure can be understood in detail, a more particular description of the disclosure, briefly summarized above, can be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this disclosure and are therefore not to be considered limiting of its scope, for the disclosure can admit to other equally effective embodiments.

[0011] Figure 1 is a schematic block diagram illustrating a storage system in accordance with the disclosed embodiments, where data storage devices can be used as storage devices for host devices.

[0012] Figure 2A and Figure 2B is a schematic diagram of scheduling fuzzy-fine programming in accordance with the disclosed embodiments.

[0013] Figure 3 is a schematic diagram of a horizontal exclusive OR (XOR) scheme with full die redundancy of super blocks in accordance with the disclosed embodiments.

[0014] Figure 4 is an illustration of possible options for exclusive OR (XOR) in multi-level cells in accordance with the disclosed embodiments.

[0015] Figure 5A and Figure 5B is an illustration of various programming failure types in accordance with the disclosed embodiments.

[0016] Figure 6A and Figure 6B is a schematic diagram of a reduced horizontal exclusive OR (XOR) scheme of super blocks in accordance with the disclosed embodiments.

[0017] Figure 7 is a schematic diagram of a reduced horizontal exclusive OR (XOR) scheme of super blocks in accordance with the disclosed embodiments.

[0018] Figure 8 is a schematic diagram of a reduced vertical exclusive OR (XOR) scheme of super blocks in accordance with the disclosed embodiments.

[0019] Figure 9 is a flowchart illustrating a method of performing fuzzy-fine programming in accordance with the disclosed embodiments.

[0020] To facilitate the understanding of this description, like reference numerals are used to identify common elements throughout the description and / or drawings. It is contemplated that elements disclosed in one embodiment can be advantageously used in other embodiments without specific recitation. DETAILED DESCRIPTION

[0021] In the following, reference is made to embodiments of the disclosure. However, it should be understood that the disclosure is not limited to the particularly described embodiments. Rather, any combination of the following features and elements, whether related to different embodiments or not, is contemplated to implement and practice the disclosure. Additionally, while the embodiments of the disclosure can achieve advantages over other possible solutions and / or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the disclosure. Thus, the following aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim. Likewise, reference to "the disclosure" should not be construed as applying to any invention disclosed herein, and should not be considered an element of the scope of the claims except where explicitly recited in a claim.

[0022] The present disclosure generally relates to improving programming of data storage devices such as solid state drives (SSDs). A first memory device has a first XOR element and a second memory device has a second XOR element. The ratio of the first XOR element to the capacity of the first memory device is substantially less than the ratio of the second XOR element to the capacity of the second memory device. Read verify operations to discover programming failures are performed on a word line by word line basis, on an erase block by erase block basis, or both. Because these programming failures are discovered and repaired prior to programming the second memory device, the second XOR element can be significantly reduced.

[0023] Figure 1 is a schematic block diagram illustrating a storage system 100 in accordance with embodiments of the disclosure, in which a data storage device 106 can be used as a storage device for a host device 104. For example, the host device 104 can utilize non-volatile memory (NVM) 110 included in the data storage device 106 to store and retrieve data. The host device 104 includes host DRAM 138. In some examples, the storage system 100 can include multiple storage devices, such as the data storage device 106, which can operate as a storage array. For example, the storage system 100 can include multiple data storage devices 106 configured to collectively operate as a redundant array of inexpensive / independent disks (RAID) for the host device 104.

[0024] The storage system 100 includes a host device 104 that can store data to and / or retrieve data from one or more storage devices, such as the data storage device 106. As Figure 1As 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 computer servers, network attached storage (NAS) units, desktop computers, laptops, tablets, set-top boxes, mobile phones such as so-called "smart" phones, so-called "smart" tablets, televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, or other devices capable of sending or receiving data from data storage devices.

[0025] Data storage device 106 includes a controller 108, an NVM 110, a power supply 111, volatile memory 112, an interface 114, and a write buffer 116. In some examples, for clarity, data storage device 106 may include... Figure 1 Additional components not shown. For example, data storage device 106 may include a printed circuit board (PCB) to which components of data storage device 106 are mechanically attached, and the PCB includes conductive traces for electrically interconnecting components of data storage device 106, etc. In some examples, the physical dimensions and connector configuration of data storage device 106 may conform to one or more standard form factors. Some exemplary standard form factors include, but are not limited to, 3.5” data storage devices (e.g., HDDs or SSDs), 2.5” data storage devices, 1.8” data storage devices, peripheral component interconnects (PCI), PCI expansion (PCI-X), PCI Express (PCIe) (e.g., PCIe x1, x4, x8, x16, PCIe Mini cards, MiniPCI, etc.). In some examples, data storage device 106 may be directly coupled (e.g., directly soldered) to the motherboard of host device 104.

[0026] The interface 114 of the data storage device 106 can 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 can operate according to any suitable protocol. For example, the 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), Serial Attached SCSI (SAS), PCI and PCIe, Non-Volatile Memory express (NVMe), OpenCAPI, GenZ, Cache Coherent Interface Accelerator (CCIX), Open Channel SSD (OCSSD), etc. Electrical connections of the interface 114 (e.g., data bus, control bus, or both) are electrically connected to the controller 108, providing electrical connections 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 connections of the interface 114 can also allow the data storage device 106 to receive power from the host device 104. For example, as shown in FIG. 1, the power supply 111 can receive power from the host device 104 via the interface 114. Figure 1

[0027] The NVM 110 can include a plurality of memory devices or memory 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 receive a message from the controller 108 instructing the storage unit to store the data. Similarly, a storage unit of the NVM 110 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, a single physical chip can include multiple dies (i.e., multiple storage units). In some examples, each storage unit can be configured to store a relatively large amount of data (e.g., 128 MB, 256 MB, 512 MB, 1 GB, 2 GB, 4 GB, 8 GB, 16 GB, 32 GB, 64 GB, 128 GB, 256 GB, 512 GB, 1 TB, etc.).

[0028] In some examples, each storage unit of the NVM 110 can 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.

[0029] ​The NVM 110 can include a plurality of flash memory devices or storage units. The NVM flash memory devices can include NAND or NOR based flash memory devices and can store data based on charge contained in a floating gate of a transistor for each flash memory cell. In NVM flash memory devices, a flash memory device can be divided into a plurality of dies, where each die of the plurality of dies includes a plurality of blocks that can be further divided into a plurality of pages. Each block of the plurality of blocks within a particular memory device can include a plurality of NVM cells. Rows of NVM cells can be electrically connected using word lines to define a page of the plurality of pages. Respective cells in each page of the plurality of pages can be electrically connected to a respective bit line. Further, the NVM flash memory devices can be 2D or 3D devices and can be single level cell (SLC), multi-level cell (MLC), triple level cell (TLC), or quad level cell (QLC). The controller 108 can write data to and read data from the NVM flash memory devices at a page level and erase data from the NVM flash memory devices at a block level.

[0030] The data storage device 106 includes a power source 111 that can provide power to one or more components of the data storage device 106. When operating in a standard mode, the power source 111 can use power provided by an external device, such as the host device 104, to power the one or more components. For example, the power source 111 can use power received from the host device 104 via the interface 114 to power the one or more components. In some examples, the power source 111 can include one or more power storage components configured to power the one or more components when operating in an off mode, such as in the event that power is stopped being received from the external device. In this way, the power source 111 can act as an on-board backup power source. Some examples of the 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 the one or more power storage components can be a function of the cost and / or size (e.g., area / volume) of the one or more power storage components. In other words, as the amount of power stored by the one or more power storage components increases, the cost and / or size of the one or more power storage components also increases.

[0031] The data storage device 106 also includes a volatile memory 112 that 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 non-volatile memory 110. As Figure 1As shown, the volatile memory 112 can consume power received from the power source 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.).

[0032] The data storage device 106 includes a controller 108, which 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 to the NVM 110 and monitor the progress of the data storage command. The controller 108 can determine at least one operational characteristic of the storage system 100 and store the at least one operational 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 data associated with the write command in an internal memory or write buffer 116 before sending the data to the NVM 110.

[0033] Figure 2A is a schematic diagram of scheduling fuzzy-fine programming according to the disclosed embodiments. A front end (FE) module 202 includes a first XOR engine 204 and a first static random access memory (SRAM) 206. Host data can be initially delivered to the FE module 202. The data passes through the first XOR engine 204 and is written to the first SRAM 206. The first XOR engine 204 generates XOR parity information prior to writing to the SRAM 206. The exclusive OR (XOR) parity information is used to improve the reliability of a storage device used to store the data, such as to enable data recovery for data write failures or data read failures to and from the NVM, or to enable data recovery in the event of a power loss. The storage device can be Figure 1 The data storage device 106. Reliability can be provided by using XOR parity information that is generated or calculated based on data stored to the storage device. The first XOR engine 204 can generate a first parity stream to be written to the first SRAM 206. The first SRAM 206 can contain a plurality of dies to which data can be written.

[0034] The second flash manager (FM2) module 210 includes an encoder 212, a second SRAM 216, a decoder 214, and a second XOR engine 232, where the second XOR engine 232 is configured to generate a second parity stream to be written to the second SRAM 216. The decoder 214 can include a low-grade (LG) decoder and a high-grade (HG) decoder. The LG decoder can implement a low-power bit flip algorithm, such as a low-density parity check (LDPC) algorithm. The LG decoder can be used to decode data and correct bit flips where such data has a low bit error rate (BER). The HG decoder can implement a full-power decoding and error correction algorithm that can be initiated when the LG decoder fails to decode and correct bit flips in the data. The HG decoder can be used to correct bit flips where such data has a high BER. Alternatively, the FM2 can be replaced with a combined FE-FM monolithic.

[0035] For example, the encoder 212 and the decoder 214 (including the LG decoder and the HG decoder) can include processing circuitry or processors (with computer-readable media storing computer-readable program code (e.g., firmware) executable by the processors), logic circuitry, application-specific integrated circuits (ASICs), programmable logic controllers, embedded microcontrollers, combinations thereof, and the like. In some examples, the encoder 212 and the decoder 214 are separate from the memory controller, and in other examples, the encoder 212 and the decoder 214 are embedded in or part of the memory controller. In some examples, the LG decoder is a hardening circuit, such as logic circuitry, ASICs, and the like. In some examples, the HG decoder can be a soft decoder (e.g., implemented by a processor). Data can be written to the second SRAM 216 after decoding at the decoder 214. Data at the second SRAM 216 can be further delivered to the encoder 212, as discussed below.

[0036] The memory device 220 can be a NAND memory device. The memory device 220 can include TLC memory 222. It should be understood that the embodiments discussed herein can not be limited to TLC memory and can be applicable to any multi-level cell memory, such as MLC memory, QLC memory, and the like. SLC memory, MLC memory, TLC memory, QLC memory, and PLC memory are named according to the number of bits that can be accepted by a memory cell. For example, SLC memory can accept one bit per memory cell, and QLC memory can accept four bits per memory cell. Each bit is registered as a 1 or 0 on the storage device.

[0037] Further, the TLC memory 222 includes a TLC exclusive-OR (XOR) partition 226, where the TLC XOR partition 226 stores parity or XOR data. Host data is written to the first SRAM 206 of the FE module 202. As the host data is written to the first SRAM 206, first XOR parity data can be simultaneously generated at the first XOR engine 204 of the FE module 202. The host data and the generated first XOR parity data are passed from the first SRAM 206 to the encoder 212 for encoding along stream 1. The host data is encoded and fog write to the TLC memory 222. Likewise, the generated first XOR parity data is encoded and fog write to the TLC XOR partition 226 of the memory device 220 along stream 2. During the fog write, the controller can selectively select data to be read in order to allow the data to be sorted into the relevant stream or streams. The TLC memory 222 can be a region of the memory device 220 that is dedicated to protecting data in the event of a power loss event.

[0038] At stream 3, the host data is read from the TLC memory 222 at the decoder 214. After the host data is decoded at the decoder 214, the host data is written to the second SRAM 216 of the FM2 210 along stream 4, where second XOR parity data is further generated for the host data at the second XOR engine 232 of the FM2 210. The host data and the second XOR parity data are passed through the encoder 212 for encoding along stream 5 and fine write to the TLC memory 222 and the respective locations of the TLC XOR partition 226 along stream 6.

[0039] Figure 2B is a schematic diagram of scheduling fog-fine programming according to the disclosed embodiments. The TLC memory 222 can be further divided into a first TLC memory partition 222A and a second TLC memory partition 222B. The second TLC memory partition 222B can be larger than the first TLC memory partition 222A. Further, the TLC XOR partition 226 can be further divided into a first TLC XOR partition 226A and a second TLC XOR partition 226B. The second TLC XOR partition 226B can be smaller than the first TLC XOR partition 226B. In one embodiment, the size of the second TLC XOR partition 226B is less than the size of the first TLX XOR partition 226A by a range of about 50%. In another embodiment, the size of the second TLC XOR partition 226B is less than the size of the first TLX XOR partition 226A by a range of about 50%.

[0040] In some examples, the size of the second TLC XOR zone 226B can be configurable such that the controller 108 can determine the size of the second TLC XOR zone 226B during the lifetime of the data storage device 106 based on factors such as a threshold, TLC memory 222 health (such as a failed bit count (FBC) of the TLC memory), and the like. The first TLC memory zone 222A and the first TLC XOR zone 226A can be a first TLC superblock, and the second TLC memory zone 222B and the second TLC XOR zone 226B can be a second superblock.

[0041] When fuzz programmed to the TLC memory 222, host data is programmed to the first TLC XOR zone 222A. Likewise, XOR parity data is programmed to the first TLC XOR zone 226A. The first TLC memory zone 222A and the first TLC XOR zone 226A can be considered a "host write" area, where data programmed in the "host write" area can be lost or corrupted. However, when fine programmed to the TLC memory 222, the host data is copied (i.e., a recycle copy) from the first TLC XOR zone 222A, which is still valid (i.e., has not been re-written or pruned by another host command), re-encoded, and programmed to the second TLC memory zone 222B, and XOR parity data is programmed to the second TLC XOR zone 226B. After fine programming to the second TLC memory zone 222B and the second TLC XOR zone 226B, the data and XOR parity data are protected when the first copy of the data is stored in the first TLC memory zone 222A. For the reasons described above, the second TLC memory zone 222B and the second TLC XOR zone 226B can be considered a "recycle copy" area.

[0042] As fine programming can utilize a reduced XOR parity scheme, such as the scheme described below, the required XOR parity zone size can be reduced. For example, a reduction of about 50% in XOR parity data can release about 100 GB of capacity in a 7680 GB SSD. The released 100 GB of capacity can then be utilized to store additional host data. Thus, over-provisioning of memory to XOR parity data can be reduced, and memory that would have been used to store XOR parity data can be utilized to store host data or similar data.

[0043] Figure 3is a schematic diagram of a horizontal exclusive OR (XOR) scheme with full die redundancy of a super block 300 according to the disclosed embodiments. The super block 300 includes a plurality of dies (e.g., die 0 - die 7) and a plurality of word lines (WLs) (e.g., WL 0 - WL 95). The number of dies and word lines listed are not intended to be limiting, but are shown to illustrate possible embodiments. For example, a super block can include about 32 dies and more or less than about 96 WLs. Each of the plurality of dies includes a first plane indicated by PL0 and a second plane indicated by PL1. Further, each of the plurality of word lines includes four strings (STRs). The number of strings per word line is based on the type of memory cell of the super block. For example, QLC memory includes four strings per word line, TLC memory includes three strings per word line, and SLC memory includes one string per word line.

[0044] The super block 300 can be an example of a zone namespace architecture that includes seven dies for data and an eighth die for XOR parity data. Die 7 of the super block 300 is associated with XOR parity data 302. Because die 7 includes only XOR parity data 302, the XOR parity data 302 can recover another failed die 304, such as die 1, where recovering another failed die 304 includes recovering all data of the failed die (i.e., full die redundancy). Further, because each string, such as string 2 of WL 0, spans each of the eight dies, each string includes 16 planes. Because die 7 includes XOR parity data 302, the parity group ratio is about 1:7, where the XOR parity data overhead is about 12.5% (i.e., 1 / 8). The values listed are not intended to be limiting, but provide an example of possible embodiments.

[0045] Figure 4 is an illustration of possible options for exclusive OR (XOR) in multi-level cells according to the disclosed embodiments. Sources of uncorrectable error correction code (UECC) data errors include program state failure (PSF), silent program failure, and random failures related to wearout and data retention. PSF and silent program failure can be associated with bit failure ratio (BFR) and / or program-erase (PE) cycles. Wearout and DR related random failures can be associated with sector failure ratio (SFR).

[0046] The "XOR Parity" column lists the type of XOR parity included in each embodiment. For example, full die redundancy (FDR) can recover an entire failed die. However, the XOR parity data associated with FDR can require a large amount of storage space in a superblock, thereby reducing the amount of data that can be stored in the superblock. XOR parity data or any other parity scheme for multiple error correction code (ECC) codewords, such as low density parity check (LDPC), can be used to recover failed data bits. For example, when a failed bit count (FBC) is greater than a threshold, a controller, such as Figure 1 controller 108 can utilize XOR parity data to recover failed bits such that data associated with the failed bits does not include the failed bits.

[0047] Another example of a data error is a program failure, where a program failure size varies from one WL-string-plane to two planes for a 2-erase block failure. Unlike FBC errors, where both XOR parity data and LDPC can be used to correct FBC errors, XOR parity data and similar parity schemes can be used to correct program failures. Program failures, such as PSF, can be repaired by writing data in different locations of a superblock. For example, when a cell has an unacceptable bit error rate (UBER), a controller can avoid programming data to the cell with UBER. However, a silent program failure can not be detected by the controller and is unknowingly passed to the NVM, such as Figure 1 NVM 110 of FIG. 1. The silent program failure can cause a double error, a triple error, or a higher error that reduces the reliability of a data storage device, such as Figure 1 data storage device 106 of FIG. 1.

[0048] To protect user data from failure due to program failures, an XOR parity data scheme needs to be large enough (i.e., low XOR parity ratio) to prevent any combination of the previously described program failures and any program failures not described but contemplated, and also has the correct geometry. However, the XOR parity data scheme size has limitations. For example, by increasing the size of the XOR parity data scheme, less user data or any other data can be stored in the NVM because the XOR parity data takes up more memory in the NVM that can be used to store more user data.

[0049] The "extra measures" column refers to the level of temporary storage of data in a cache or buffer or read verify / enhanced post write read (EPWR) for checksum repair of errors. For example, a buffer or cache can store up to the last two word lines (2 WL depth) of data written to a super block. When another word line is written to the super block, the oldest word line of the last two word lines stored in the buffer or cache is released such that releasing a word line refers to erasing data. Further, the read verify / EPWR level refers to the frequency of read verify / EPWR operations. For example, a read verify / EPWR level of a word line indicates that a read verify / EPWR operation occurs after the word line is programmed.

[0050] As shown in FIG. 4, the XOR parity ratio decreases each time there is an additional firmware (FW) read verify / EPWR check. For example, at a first FW read verify / EPWR check implementation 404, the XOR parity ratio is about 1 : 127 in the case of copying data from a first TLC memory partition, such as a first TLC memory 222A, to a second TLC memory, such as a second TLC memory 222B. As a comparison, the XOR parity ratio for the no extra check implementation 402 is about 1 : 63. The first FW read verify / EPWR check implementation 404 includes a read verify / EPWR level of a word line. Further, a cache or buffer stores the last two word lines of data written to a super block (e.g., 2 WL depth). By further performing read verify / EPWR checks, such as a fourth FW read verify / EPWR check implementation 406, the XOR parity ratio can substantially decrease to about 0, where the buffer or cache stores the last erase block written to a super block and a read verify / EPWR operation occurs after each time a word line, an erase block, or both a word line and an erase block are programmed. Figure 4 Figure 2B As shown in FIG. 4, the XOR parity ratio decreases each time there is an additional firmware (FW) read verify / EPWR check. For example, at a first FW read verify / EPWR check implementation 404, the XOR parity ratio is about 1 : 127 in the case of copying data from a first TLC memory partition, such as a first TLC memory 222A, to a second TLC memory, such as a second TLC memory 222B. As a comparison, the XOR parity ratio for the no extra check implementation 402 is about 1 : 63. The first FW read verify / EPWR check implementation 404 includes a read verify / EPWR level of a word line. Further, a cache or buffer stores the last two word lines of data written to a super block (e.g., 2 WL depth). By further performing read verify / EPWR checks, such as a fourth FW read verify / EPWR check implementation 406, the XOR parity ratio can substantially decrease to about 0, where the buffer or cache stores the last erase block written to a super block and a read verify / EPWR operation occurs after each time a word line, an erase block, or both a word line and an erase block are programmed. Figure 2B

[0051] If a PSF is not needed to be corrected, the XOR parity data ratio and overhead can be reduced. For example, if data, such as up to the last two word lines written or the last erase block programmed, is still available in a source block, such as SLC memory, a buffer, and / or a cache, the data in the source block can be programmed over the PSF failure. In another example, temporary XOR parity data can be stored in a buffer, a cache, and / or a volatile memory, such as volatile memory 112, where one XOR parity element (i.e., XOR parity data) per cache's XOR stripe (i.e., one die, last two word lines) can be repaired in terms of PSF. Figure 1

[0052] ​​​Additionally, the XOR parity ratio and overhead can be reduced if a silent program failure need not be repaired. For example, if data (such as up to the last two word lines written or the last erase block programmed) is still available in a source block (such as the first TLC memory partition 222A, a buffer, and / or a cache), the data in the source block can be programmed over a PSF failure. Additionally, the XOR parity ratio and overhead can be reduced if an additional FW read verify / EPWR operation detects a silent program failure by looking for an error signature of a type of silent program failure. Referring to Figure 2B The XOR parity ratio for the first TLC memory partition 222A and the first TLC XOR partition 226A can be about 1 :7, where for every 1 die of XOR parity data, 7 dies are suitable for data. Likewise, the XOR parity ratio for the second TLC memory partition 226A and the second TLC XOR partition 226B can be about 1 :7. However, by performing an additional FW read verify / EPWR operation on data programmed to the second TLC memory partition 226B, the XOR parity ratio for the second TLC memory partition 222B and the second TLC XOR partition 226B can be about 1 : 15, about 1 :31, about 1 :63, about 1 : 127, about 1 :255, about 1 :383, etc. It is contemplated that the XOR parity ratio for the second TLC memory partition 222B and the second TLC XOR partition 226B can be about 0, where no XOR parity data is stored in the second TLC XOR partition 226B.

[0053] For example, when a super block is written to the second TLC memory partition 222B, each word line can be checked for a silent program failure. In some embodiments, each plane and / or each string of a word line is also checked for a silent program failure. Although the overhead of the operation can be large, a silent program failure is not programmed to the second TLC memory partition 222B undetected. Additionally, because each word line is checked, only a minimal number of word lines, such as up to about two word lines, can be stored in a buffer, a cache, and / or a volatile memory. Thus, the latency to copy a word line from a storage location to the second TLC memory partition 222B or the latency to release a word line from a storage location can be negligible or can be small.

[0054] In another example, the FW read verify / EPWR operation can check for an entire erase block failure. When checking for an entire erase block failure, only a few word lines need to be checked at the end of programming an erase block, thereby making the overhead of the operation less than the overhead of checking every word line. In one embodiment, the number of word lines checked can be about two word lines, where the about two word lines checked are the last word lines of the programmed erase block. However, because the erase block is checked at the completion of erase block programming to the second TLC memory partition 222B, the source block associated with the data of the erase block can need to be stored in the first TLC memory partition 222A, a buffer, and / or a cache. Because storing the source block associated with the erase block is greater than storing the last two word lines programmed to the second TLC memory partition 222B, the latency of freeing the source block from the associated location can be greater than the latency of freeing at most about two word lines.

[0055] In yet another example, the FW read verify / EPWR operation can check for both an erase block failure and a word line failure. After the erase block has been programmed to the second TLC memory partition 222B, every word line of the erase block is checked for a word line failure. In some embodiments, every plane and / or every string of the word line is checked for a program failure. Because every word line of the erase block is checked at the completion of erase block programming to the second TLC memory partition 222B, the source block associated with the data of the erase block can need to be stored in the first TLC memory partition 222A, a buffer, and / or a cache. Because storing the source block associated with the erase block is greater than storing the last two word lines programmed to the second TLC memory partition 222B, the latency of freeing the source block from the associated location can be greater than the latency of freeing at most about two word lines. Although the overhead of the operation can be greater than the previous two examples, silent program failures can not be passed unnoticed to the second TLC memory partition 222B, thereby enabling a maximum reduction in XOR parity data stored, which can be a minimum or substantially about zero. In some embodiments, the only XOR parity data stored can be used for wear and DR related random failures.

[0056] Figure 5A and Figure 5B are illustrations of various program failure types according to the disclosed embodiments. It should be understood that Figure 5A and Figure 5B collectively represent a single figure that is divided into two pages labeled Figure 5A and Figure 5B Silent errors (i.e., silent program failures) do not include any PSF failures. Thus, silent errors can be passed to an MLC memory, such as the MLC memory 224 of FIG. 2. However, as Figure 5A andFigure 5B As shown by other examples, by including at least one cell with PSF, the controller can notice the error and the controller can correct the error with XOR parity data, LDPC, etc. Various program failure types can be UECC / short and PSF. In some embodiments, the program failure is along a boundary of a super block, such as the last word line programmed (i.e., WL(n)) and / or the last string programmed (i.e., S3). By implementing a read verify / EPWR operation, such as Figure 4 the read verify / EPWR operation described in Figure 5A and Figure 5B Program failures as shown can not be programmed to MLC memory. It is contemplated that other failure types, not shown, are applicable to the embodiments described herein.

[0057] Figure 6A and Figure 6B are schematic diagrams of a reduced horizontal XOR scheme for super blocks 600, 650 according to the disclosed embodiments. Figure 3 Aspects of super block 300 of Figure 6A super block 600 and Figure 6B super block 650. Although super block schemes are exemplified, it is contemplated that the disclosed embodiments can be applicable to non-super block schemes. Super block schemes can refer to data striping across multiple dies in order to enable higher levels of parallelism. Non-super block schemes can refer to data striping across a single die. Further, it is to be understood that while horizontal XOR schemes are exemplified, embodiments can be applicable to reduced vertical XOR schemes. According to a horizontal XOR scheme, XOR parity groups / strips horizontally across data strips such that the last block or set of blocks of a horizontal data strip is programmed with XOR parity data. The XOR parity data can prevent data failure of the respective horizontal data strip. According to a vertical XOR parity scheme, XOR parity groups vertically across a single plane, for example, such that the last block of a plane or set of blocks of a plane is programmed with XOR parity data. The XOR parity data can prevent data failure of the respective vertical data strip.

[0058] and Figure 3XOR parity data of super block 600 (specifically, die 7) is reduced by about 50% when compared to super block 300. XOR parity data 602 can be located on a single plane of a single die, such as PL1 of die 7. Similar to super block 600, super block 650 has about 50% less XOR parity data when compared to super block 300. However, rather than having the XOR parity data on a single plane of a single die, the XOR parity data 602 can be stored on alternating strings, such as on STR1 and STR3 of WL0, where the XOR parity data 602 is stored on both PL0 and PL1 of a single die, such as die 7. Likewise, 1:15 parity group 652 illustrates a case where parity (P) can be located on alternating word lines.

[0059] The reduced XOR parity data can be due to additional read verify / EPWR operations to check for PSF and silent program failures. The about 50% XOR parity data of super blocks 600, 650 can only recover a block or plane of die 604, rather than an entire die, failing. The parity group ratio can be about 1:15 rather than 1:7 as shown in previous Figure 3 embodiments. However, because additional read verify / EPWR operations are performed on the program word lines and / or erase blocks of the super block, the UBER can be significantly less than the program word lines and / or erase blocks of a super block that do not have additional read verify / EPWR operations performed on the word lines and / or erase blocks of the super block.

[0060] Figure 7 is a schematic diagram of a reduced horizontal exclusive OR (XOR) scheme of super block 700 according to the disclosed embodiments. Figure 6B Aspects of super block 650 of FIG. 6B can be similar to super block 700. Although super block schemes are illustrated, it is contemplated that the disclosed embodiments can be applicable to non-super block schemes. Further, it is to be appreciated that although vertical XOR schemes are illustrated, embodiments can be applicable to reduced horizontal XOR schemes. For example, super block 700 has a 1:15 parity group ratio, where the XOR parity data 702 is stored on alternating strings. With respect to super block 700, the fourth string STR3 of the fourth word line WL3 is being programmed. The data at risk due to program failure is the two previously programmed word lines WL2 and WL1. However, the source blocks of the data of WL2 and WL1 are stored in a TLC memory, such as first TLC memory partition 222A of FIG. 2A. WL0 can be considered “safe” where a successful read verify / EPWR operation, such as read verify / EPWR operation 604, is performed on the data of WL0. The data of WL0 is not at risk of being lost due to a program failure. The data of WL2 and WL1 is at risk of being lost due to a program failure. The data of WL2 and WL1 is not at risk of being lost due to a program failure because the source blocks of the data of WL2 and WL1 are stored in a TLC memory, such as first TLC memory partition 222A of FIG. 2A. The data of WL3 is at risk of being lost due to a program failure. The data of WL3 is not at risk of being lost due to a program failure because the source blocks of the data of WL3 are stored in a TLC memory, such as first TLC memory partition 222A of FIG. 2A. Figure 2B Figure 4 ​The read verify / EPWR operation described in the middle has completed on the data of WL0. Program failures 704 (both PSF and silent program failures) can still exist in WL1, WL2, and WL3 because the read verify / EPWR operation has not been performed.

[0061] Figure 8 is a schematic diagram of a reduced vertical exclusive OR (XOR) scheme of a super block 800 according to the disclosed embodiments. Although a super block scheme is illustrated, it is contemplated that the disclosed embodiments can be applied to non-super block schemes. Further, it is understood that while a vertical XOR scheme is illustrated, embodiments can be applied to a reduced horizontal XOR scheme. The super block 800 illustrates a 1:383 parity group scheme as shown in Figure 4 where 1:383 refers to 1 XOR parity data for 383 other cells in a TLC memory including 96 word lines and 8 dies. In some examples, the number of parity groups per super block can be reduced to one-half or one-quarter of the super block such that the super block includes between about 2 and about 4 parity groups. For example, each of the parity groups can protect data of a respective die and an adjacent neighboring die.

[0062] Rather than programming XOR parity data to the last die of each word line, the XOR parity data 802 is programmed to the last string of the last word line such that the XOR parity data protects previous word lines and previous strings of each plane and / or die. In some examples, the XOR parity data 802 can be stored in a volatile memory (such as the volatile memory 112 of FIG. 1) until programming of the previous strings and word lines is complete in order to maintain sequential programming of the super block. Figure 1

[0063] In one example, the XOR parity data can protect along the same die and / or plane such that the first XOR parity data 806 in die 7, PL1, WL 95, STR3 can protect the fourth location 808d in die 7, PL0, WL0, STR1. In another example, the first XOR parity data 806 in die 7, PL1, WL 95, STR3 can protect a scattered group of cells such as the first location 808a, the second location 808b, the third location 808c, and the fourth location 808d. Further, the volatile memory and / or NVM (such as the first TLC memory partition 222A of FIG. 2) can store the last erase block of data such that the first erase block 804 can be recovered. Figure 2B

[0064] Figure 9 is a flow diagram illustrating a method 900 of fuzzy-fine programming according to the disclosed embodiments. At block 902, a controller such as the controller 102 of FIG. 1​​Figure 1 The controller 108 receives a write command. At block 904, the controller executes a write command to a non-volatile memory such as... Figure 2B The second TLC memory partition 222B is fuzzy / fine programmed. Data associated with fine programming can be written to one or more word lines of the NVM (such as the first word line and the second word line) or to the erase block of the NVM.

[0065] At box 906, the data source (i.e., the data associated with the write command at box 902) is held in volatile memory (such as...). Figure 1 volatile memory 112) and / or NVM (such as Figure 2B In the first TLC memory partition 222B, the data source can store at most the last two word lines of fine-programmed or written data to the NVM, or the last erase block of fine-programmed data to the NVM. At block 908, a read verification operation is performed on the fine-programmed data to the NVM. The read verification operation can be an enhanced write-read operation. Furthermore, read verification operations can be performed on the last two word lines of previously programmed data (such as the first and second word lines), the last erase block of previously written data, or each word line of the last erase block of previously written data. The read verification operation verifies for programming failures, such as PSF (Program for Free Programming), silent programming failures, etc.

[0066] At box 910, the controller determines whether the read verification operation was successful. If the read verification operation at box 910 is unsuccessful (i.e., a programming failure exists), then at box 912, the data source stored in the first TLC memory partition 222A is copied to the second TLC memory partition 222B, where copying the data to the second TLC memory partition 222B is fine programming. At box 908, the controller then performs a read verification operation on the copied data. However, if the read verification operation at box 910 is successful, then at box 914, the amount of XOR parity data programmed with the data is reduced, such that the programmed XOR parity data can be approximately 50% of the XOR parity data programmed using the previous method. The amount of programmed XOR parity data can depend on the level of programming redundancy performed, such as previously... Figure 4 The different redundancy levels described in the document.

[0067] For example, when programming data to the second TLC memory partition 222B, the planes of the dies across each of the plurality of word lines can include XOR parity elements (i.e., XOR parity data). The plurality of word lines includes a plurality of strings, where the XOR parity elements are written to alternating strings of the dies, and at least one of the plurality of strings does not include XOR parity data. Rather than programming the entire die with XOR parity data after a successful read verify operation, about half of the die is programmed with XOR parity data. It should be appreciated that the reduced XOR parity data scheme can be a reduced horizontal parity scheme, a reduced vertical parity scheme, or a combination of the previously mentioned schemes. Further, in some examples, the reduced vertical parity scheme can be a scattered vertical parity scheme such that the XOR parity data does protect different cells or bits of each plane of each die. In some embodiments, the first TLC memory partition 222A and the second TLC memory partition 222B can not have the same XOR parity scheme. For example, the first TLC memory partition 222A has a first ratio, where the first ratio is about a 1 :7 parity group ratio, and the second TLC memory partition 222B has a second ratio, where the second ratio is about a 1 : 15 parity group ratio. Further, in some examples, the second TLC memory partition 222B can not have any XOR parity data, such as Figure 4 the fourth FW read verify / EPWR check implementation 406 described in the background.

[0068] At block 916, the data source associated with the data of the successful read verify operation is released from the first TLC memory partition 222A, the buffer, and / or the cache. At block 918, the fine programming is completed.

[0069] By performing read verify operations on different levels of the non-volatile memory, such as on a word line by word line basis, on an erase block basis, or on a per word line of erase block basis, and storing the data source in SLC memory, a buffer, and / or a cache, the size of the XOR parity data for fine programming to the NVM can be reduced, and the reliability of the data can be increased.

[0070] In one embodiment, a data storage device includes a controller and a memory device coupled to the controller. The memory device includes a first super block having a first parity portion of a first storage size and a second super block having a second parity portion of a second storage size. The first storage size is less than the second storage size.

[0071] The first superblock has a third storage size and the second superblock has a fourth storage size. The third storage size is less than the fourth storage size. The first superblock is configured to process host write data. The second superblock is configured to process a recycled copy of the host write data. The first superblock is TLC memory. The second superblock is TLC memory. The first parity portion and the second parity portion are XOR parity. The second storage size is less than the first storage size by a difference ranging from about 50%. The second superblock includes a plurality of word lines. Each word line includes a plurality of strings. At least one string of the plurality of strings does not include exclusive OR (XOR) data.

[0072] In another embodiment, a data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to: receive host data from a host device; generate first exclusive OR (XOR) parity data for the host data; encode the host data and the first XOR parity data with an encoder; write the encoded host data and the first XOR parity data to a first memory superblock; decode valid data and first XOR parity data written to the first memory superblock, wherein the valid data corresponds to the host data that has not been retired when located in the first memory superblock; generate second XOR parity data for the decoded valid data; re-encode the decoded valid data and the second XOR parity data with the encoder; and write the re-encoded data and the second XOR parity data to a second memory superblock. A size of the re-encoded second XOR parity data is less than the size of the first XOR parity data.

[0073] The memory device includes a plurality of dies. Each die of the plurality of dies includes a first plane and a second plane. At least one of the first plane and the second plane includes exclusive OR (XOR) data. The controller is further configured to write data to a first word line of a plurality of word lines of the memory device, write data to a second word line of the plurality of word lines, perform a read verify operation on the first word line, and perform a read verify operation on the second word line. At least one of the first word line and the second word line does not include an XOR parity element. The read verify operation is an enhanced post-write read (EPWR). The XOR parity element is at least one of a full die redundancy, a full plane redundancy, and an erase block redundancy. The decoder and the encoder are disposed in a front-end module of the data storage device. The first XOR parity data is generated in a front-end module separate from the front-end module.

[0074] In another embodiment, a data storage device includes a memory device including a first memory superblock and a second memory superblock, means for storing host data and parity data in the first memory superblock, and means for storing a copy of the host data and parity data in the second memory superblock, wherein the copy of the parity data utilizes less parity data storage in the second superblock compared to an amount of parity data storage in the first superblock.

[0075] The data storage device also includes means for performing a read verify operation to detect a program failure. The read verify operation is a post-boost read. The means for performing a read verify operation includes verifying each word line of a plurality of word lines of the memory device for a program failure, verifying each erase block of a plurality of erase blocks of the memory device for a program failure, or both verifying each word line of the plurality of word lines and each erase block of the plurality of erase blocks for a program failure.

[0076] While the foregoing is directed to embodiments of the present disclosure, other and further embodiments of the disclosure can be devised without departing from the basic scope thereof, and the scope of the present disclosure is determined by the claims that follow.

Claims

1. A data storage device, the data storage device comprising: Memory devices; and A controller, coupled to the memory device, wherein the controller is configured to: Receive host data from the host device; Generate the first XOR parity data, i.e., the first XOR parity data, for the host data; The host data and the first XOR parity data are encoded using an encoder; The encoded host data and the first XOR parity data are written into the first memory superblock; Decode the valid data written to the first memory superblock and the first XOR parity data, wherein the valid data corresponds to the host data that was not discarded when it was in the first memory superblock; Generate a second XOR parity data for the valid data to be decoded; The encoder is used to re-encode the decoded valid data and the second XOR parity data; as well as The re-encoded valid data and the second XOR parity data are written to the second memory superblock, wherein the size of the re-encoded second XOR parity data is smaller than the size of the first XOR parity data.

2. The data storage device according to claim 1, wherein, The memory device includes a plurality of dies, and each of the plurality of dies includes a first plane and a second plane.

3. The data storage device according to claim 2, wherein, At least one of the first plane and the second plane includes XOR data.

4. The data storage device according to claim 1, wherein, The controller is further configured to: Data is written to the first word line of the multiple word lines of the memory device; Write the data to the second word line among the multiple word lines; Perform a read verification operation on the first word line; as well as Perform a read verification operation on the second word line, wherein at least one of the first word line and the second word line does not include an XOR parity element.

5. The data storage device according to claim 4, wherein, The read verification operation is enhanced post-write read, i.e., EPWR.

6. The data storage device according to claim 4, wherein, The XOR parity element is at least one of full die redundancy, full planar redundancy, and erase block redundancy.

7. The data storage device according to claim 1, wherein, The decoder and the encoder are located in the front-end module of the data storage device.

8. The data storage device according to claim 7, wherein, The first XOR parity data is generated in a front-end module that is separate from the front-end module.

Images