Controlling memory overhead for storing integrity data on solid-state drives

By separating user data and integrity data storage and discarding integrity data after validation, the inefficiencies of SSDs due to overprovisioning are addressed, improving storage efficiency and capacity.

JP2026508275APending Publication Date: 2026-03-10SK HYNIX NAND PRODUCT SOLUTIONS CORP
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-02-22
Publication Date
2026-03-10

AI Technical Summary

Technical Problem

Existing memory systems, particularly solid-state drives (SSDs), suffer from inefficiencies due to overprovisioning of memory space for storing integrity data, which reduces the effective capacity and necessitates additional data migration operations.

Method used

User data and integrity data are stored in separate memory blocks, with integrity data being verified and discarded after user data validation, thereby eliminating the need for dedicated memory space and reducing unnecessary operations.

Benefits of technology

This approach optimizes memory usage by minimizing the need for overprovisioning and eliminating redundant data operations, enhancing storage efficiency and capacity utilization.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2026508275000001_ABST
    Figure 2026508275000001_ABST
Patent Text Reader

Abstract

This application relates to data protection in a memory system of an electronic device. The memory system has a first memory block and a second memory block, each memory block including one or more individual memory dies. Each memory die of the second memory block is different from the one or more individual memory dies of the first memory block. The electronic device stores user data in the first memory block, the user data including a plurality of user data items, and integrity data in the second memory block, the integrity data including a plurality of integrity data items. Each of the plurality of user data items is configured to be verified based on each of the plurality of integrity data items. The electronic device invalidates the integrity data in the second memory block and reads the user data from the first memory block independently of the integrity data.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application is a continuation of and claims priority to U.S. patent application Ser. No. 18 / 113,495, entitled "Controlling Memory Overhead for Storing Integrity Data on Solid State Drives," filed on February 23, 2023, the entire contents of which are incorporated herein by reference.

[0002] This application relates generally to memory management, including but not limited to methods, systems, devices, and non-transitory computer-readable media for storing user data in a memory device with high fidelity while saving overhead memory space from storing integrity data. [Background technology]

[0003] Memory is used in computer systems to store instructions and data, and data is processed by one or more processors according to the instructions stored in the memory. Primary memory (e.g., registers and cache) is used within one or more processors to support calculations and operations on data in real time. One or more processors are coupled to main memory, which often includes random access memory (RAM), via a memory bus. The main memory provides instructions and data to one or more processors when the instructions and data are not found in the primary memory. Both primary and main memories are volatile memories that must be periodically refreshed and lose stored data when disconnected from power. In addition, one or more processors are further coupled to secondary memory (e.g., hard disk drives (HDDs) or solid-state drives (SSDs)), which are nonvolatile memories that retain stored data even when disconnected from power. Each data item in the memory is often associated with and stored with integrity data, and each data item is often verified based on the integrity data when retrieved from the memory. The integrity data is stored in additional memory blocks within the memory, resulting in memory overprovisioning of, for example, 4-5% of the memory space of an SSD. During internal copy-back operations, integrity data is copied as dummy data along with the data items, thereby reducing the efficiency of the copy-back operation. It would be advantageous to effectively and efficiently manage data protection and verification to reduce the associated over-provisioned space and dummy data operations in a memory system. Summary of the Invention

[0004] Various embodiments of the present application relate to methods, systems, devices, and non-transitory computer-readable media for managing data protection and verification in a memory system (e.g., SSD, HDD). User data and associated integrity data are stored in two different memory blocks of the memory system. After the user data and integrity data are stored, the user data is read back and the validity of the user data is checked with respect to the integrity data. In response to the verification of the user data, the corresponding integrity data is invalidated and discarded from the memory system. Conversely, in response to the invalidation of the user data, the user data is corrected based on the integrity data. Following the correction of the user data, the corresponding integrity data is invalidated and discarded from the memory system. By these means, the memory system verifies the user data in advance and discards the integrity data after the user data is verified or corrected. The memory system does not need to reserve a large amount of dedicated memory space for storing the integrity data, nor does it need to perform additional data migration operations on the user data and the integrity data.

[0005] In one example, XOR logic is applied to a memory management policy that verifies user data and protects the user data from NAND defects in the SSD. XOR-based integrity data is stored in memory space that needs to be addressed by over-provisioning availability in the NAND memory blocks of the SSD. In some implementations, the XOR-based integrity data is invalidated and discarded from the SSD, thereby saving memory space for storing the XOR-based integrity data (e.g., 90%). The XOR-based parity data is stored in memory blocks that do not store any user data. In some cases, the memory blocks are closed and then reused as open memory blocks for storing additional user data. In some embodiments, the XOR logic generates each integrity data item based on a subset of user data having an XOR parity size (e.g., equivalent to one-quarter of a memory plane, half a memory plane, a memory plane, or a memory die). The XOR-based integrity data is invalidated and discarded from the SSD independently of the XOR parity size. Firmware programs are scaled based on the XOR parity size.

[0006] In one aspect, a method for storing and protecting data in a memory system (e.g., an SSD) of an electronic device is implemented on the electronic device. The memory system has a first memory block and a second memory block, each memory block including one or more individual memory dies. The method includes storing user data in the first memory block, the user data including a plurality of user data items, each of the plurality of user data items configured to be verified based on a respective one of a plurality of integrity data items. The method further includes storing integrity data in the second memory block, the integrity data including the plurality of integrity data items, each memory die of the second memory block being different from the one or more individual dies of the first memory block. The method further includes invalidating the integrity data in the second memory block and reading the user data from the first memory block independently of the integrity data.

[0007] In some embodiments, the method further includes, before invalidating the integrity data in the second memory block, reading the user data back from the first memory block, determining that the user data is valid based on the integrity data, and discarding the integrity data in the second memory block, wherein the integrity data in the second memory block is invalidated in response to determining that the user data is valid based on the integrity data.

[0008] In some embodiments, the method further includes storing the user data in a third memory block different from the first and second memory blocks before storing the user data in the first memory block, reading the user data back from the third memory block, and determining that the user data read from the third block is invalid based on the integrity data stored in the second memory block.Furthermore, in some embodiments, storing the user data in the first memory block further includes, in response to determining that the subset of the user data stored in the third memory block is invalid, copying the user data from the third memory block to the first memory block, correcting the user data in the first memory block based on the integrity data, and erasing the user data in the third memory block.

[0009] In another aspect, some implementations include an electronic device including one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the processors to perform any of the above methods to store and protect data in a memory system having a first memory block and a second memory block.

[0010] In yet another aspect, some implementations include a non-transitory computer-readable storage medium storing one or more programs, the one or more programs including instructions that, when executed by one or more processors, cause the processors to perform any of the methods described above to store and protect data in a memory system having a first memory block and a second memory block.

[0011] These exemplary embodiments and implementations mentioned are not intended to limit or define the present disclosure, but rather to provide examples to aid in its understanding. Additional embodiments are discussed in the Detailed Description section, and further description is provided.

[0012] For a better understanding of the various implementations described, please refer to the following detailed description in connection with the following drawings, in which like reference numerals refer to corresponding parts throughout: [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 2 is a block diagram of example system modules in a typical electronic device, according to some embodiments of the present invention. [Figure 2] 1 is a block diagram of a memory system of an example electronic device having one or more memory access queues, according to some embodiments of the present invention. [Figure 3] FIG. 2 illustrates a data structure of user data stored along with integrity data in a memory block of a memory system according to some embodiments of the present invention. [Figure 4] FIG. 2 illustrates a data structure of user data stored separately from integrity data in two different memory blocks of a memory system according to some embodiments of the present invention. [Figure 5] 1 is a flow diagram of an example method for storing data, according to some embodiments of the present invention. [Figure 6] FIG. 4 is a flow diagram of an example data write process for writing user data to a first memory block of a memory system according to some embodiments of the present invention. [Figure 7] FIG. 4 is a flow diagram of another example method for storing data, according to some embodiments of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0014] Like reference numerals refer to corresponding parts throughout the several views of the drawings.

[0015] Reference will now be made in detail to specific embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous non-limiting details are set forth to aid in understanding the subject matter presented herein. However, it will be apparent to those skilled in the art that various alternatives may be used without departing from the scope of the claims, and that the subject matter may be practiced without these specific details. For example, it will be apparent to those skilled in the art that the subject matter presented herein may be practiced in many types of electronic devices with digital video capabilities.

[0016] 1 is a block diagram of an example system module 100 in a typical electronic device according to some embodiments. The system module 100 in this electronic device includes at least a processor module 102, a memory module 104 for storing programs, instructions, and data, an input / output (I / O) controller 106, one or more communication interfaces, such as a network interface 108, and one or more communication buses 140 for interconnecting these components. In some embodiments, the I / O controller 106 enables the processor module 102 to communicate with I / O devices (e.g., a keyboard, mouse, or trackpad) via a Universal Serial Bus interface. In some embodiments, the network interface 108 includes one or more separate interfaces for Wi-Fi, Ethernet, and Bluetooth networks, allowing the electronic device to exchange data with external sources, such as a server or another electronic device. In some embodiments, the communication bus 150 includes circuitry (sometimes referred to as a chipset) that interconnects and controls communication between various system components included in the system module 100.

[0017] In some embodiments, memory module 104 includes high-speed random access memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), double data rate (DDR) random access memory (RAM), or other random access solid-state memory devices. In some embodiments, memory module 104 includes non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. In some embodiments, memory module 104, or alternatively, the non-volatile memory devices within memory module 104, include non-transitory computer-readable storage media. In some embodiments, a memory slot is reserved on system module 100 to receive memory module 104. When inserted into the memory slot, memory module 104 is integrated into system module 100.

[0018] In some embodiments, the system module 100 further includes one or more components selected from a memory controller 110, a solid-state drive (SSD) 112, a hard disk drive (HDD) 114, a power management integrated circuit (PMIC) 118, a graphics module 120, and a sound module 122. The memory controller 110 is configured to control communication between the processor module 102 and memory components, including the memory module 104, in the electronic device. The SSD 112 is configured to employ integrated circuits as an assembly for storing data in the electronic device, and in many embodiments, is based on a NAND or NOR memory configuration. The HDD 114 is a conventional data storage device for storing and retrieving digital information based on an electromechanical magnetic disk. The power connector 116 is electrically coupled to accept an external power source. The PMIC 118 is configured to regulate the accepted external power source to a desired DC voltage level, such as 5V, 3.3V, or 1.8V, as required by various components or circuits (e.g., the processor module 102) within the electronic device. The graphics module 120 is configured to generate output image feeds for one or more display devices according to their desired image / video formats. The sound module 122 is configured to facilitate the input and output of audio signals to electronic devices under the control of a computer program.

[0019] It should be noted that communication bus 150 also interconnects and controls communication between various system components, including components 110-122.

[0020] Furthermore, those skilled in the art will appreciate that other non-transitory computer-readable storage media may be used as new data storage technologies are developed for storing information on non-transitory computer-readable storage media within memory module 104, SSD 112, and / or hard drive 114. These new non-transitory computer-readable storage media include, but are not limited to, those made from biological materials, nanowires, carbon nanotubes, and discrete modules, although these data storage technologies are currently under development and have not yet been commercialized.

[0021] Some implementations of the present application relate to effectively and efficiently managing data protection and verification to reduce associated over-provisioned space and dummy data operations in a memory system (e.g., SSD 112, memory module 104) of system module 100. User data and associated integrity data are stored in two different memory blocks of the memory system. After the user data and integrity data are stored, the user data is read back and the validity of the user data is checked with respect to the integrity data. In response to the verification of the user data, the corresponding integrity data is invalidated and discarded from the memory system. Conversely, in response to the invalidation of the user data, the user data is corrected based on the integrity data, and the corresponding integrity data is then invalidated and discarded from the memory system. By these means, the memory system verifies the user data before receiving any read request for the user data and discards the integrity data after the user data is verified or corrected. The system module 100 does not need to reserve a large amount of dedicated memory space in SSD 112 or memory module 104 for storing integrity data, nor does it need to perform additional data migration operations on the integrity data when user data needs to be migrated (e.g., in an internal copyback).

[0022] FIG. 2 is a block diagram of an example memory system 200 of an electronic device having one or more memory access queues, according to some embodiments. The memory system 200 is coupled to a host device 220 (e.g., processor module 102 in FIG. 1 ) and is configured to store instructions and data for extended periods of time, such as when the electronic device is sleeping, hibernating, or shut down. The host device 220 is configured to access the instructions and data stored in the memory system 200 and process the instructions and data to run an operating system and execute user applications. The memory system 200 further includes a controller 202 and multiple memory channels 204. Each memory channel 204 includes multiple memory cells. The controller 202 is configured to execute firmware-level software to bridge the multiple memory channels 204 to the host device 220. Specifically, the controller 202 is configured to communicate with the host device 220, manage a file system directory (FSD) 212 to track data locations in the memory channels 204, organize the multiple memory channels 204, and facilitate access to the memory channels 204 for internal and external requests.

[0023] Each memory channel 204 includes one or more memory packages 206 (e.g., two memory chips, two memory dies). In one example, each memory package 206 corresponds to a memory die. Each memory package 206 includes multiple memory planes 208, each of which further includes multiple memory pages 210. Each memory page 210 includes an ordered set of memory cells, each identified by a respective physical address. In some embodiments, memory system 200 includes a single-level cell (SLC) memory system, where each memory cell stores a single data bit. In some embodiments, memory system 200 includes an MLC memory system, where each memory cell stores multiple data bits. In one example, each memory cell in a multi-level cell (MLC) memory system stores two data bits. In one example, each memory cell in a triple-level cell (TLC) memory system stores three data bits. In another example, each memory cell in a quad-level cell (QLC) memory system stores four data bits. In yet another example, each memory cell in a penta-level cell (PLC) memory system stores five data bits. In some embodiments, each memory cell can store any suitable number of data bits with six or more levels of memory cells. Compared to MLC, TLC, QLC, or PLC memory systems, SLC memory systems operate at higher speeds, higher reliability, and longer service life, but have lower device density and higher price. In some embodiments, the SLC, MLC, TLC, QLC, PLC, or six or more levels of cell memory systems comprise one or more SSDs.

[0024] Each memory channel 204 is coupled to a respective channel controller 214 configured to control internal and external requests to access memory cells within each memory channel 204. In some embodiments, each memory package 206 (e.g., each memory die) corresponds to a respective queue 216 of memory access requests. In some embodiments, each memory channel 204 corresponds to a respective queue 216 of memory access requests. Further, in some embodiments, each memory channel 204 corresponds to a separate, different queue 216 of memory access requests. In some embodiments, a subset of (less than all of) the multiple memory channels 204 corresponds to a different queue 216 of memory access requests. In some embodiments, all of the multiple memory channels 204 of memory system 200 correspond to a single queue 216 of memory access requests. Each memory access request is optionally received internally from memory system 200 to manage a respective memory channel 204, or externally from a host device 220 to read or write data stored in a respective channel 204. Specifically, each memory access request includes one of a system write request received from memory system 200 to write to the respective memory channel 204, a system read request received from memory system 200 to read from the respective memory channel 204, a host write request issued from host device 220 to write to the respective memory channel 204, and a host read request received from host device 220 to read from the respective memory channel 204.

[0025] Additionally, in some embodiments, the queue of memory access requests 216 includes a memory read queue that includes only system read requests, host read requests, or a combination thereof. Alternatively, in some embodiments, the queue of memory access requests 216 includes a mixed memory access queue that includes at least write requests and read requests, where the write requests are optionally system write requests or host write requests, and the read requests are optionally system read requests or read / write requests.

[0026] The memory workload of memory system 200 includes one or more queues 216 of memory access requests. In some embodiments, the memory workload includes a host read workload that begins with a host read request and does not include any host write requests. The memory workload further includes system read requests, system write requests, or both, where the one or more queues 216 include host read requests and one or more of system read requests, system write requests, or a combination thereof. Alternatively, in some embodiments, the memory workload includes a host write workload, where the one or more queues 216 include only system write requests that begin with a host write request and do not include any host read requests. The memory workload further includes system read requests, system write requests, or both, where the one or more queues 216 include host write requests and one or more of system read requests, system write requests, or a combination thereof. Additionally and alternatively, in some embodiments, the memory workload comprises a mixed host workload further having both host read requests and host write requests, and further including system read requests, system write requests, or both. One or more queues 216 comprise at least write requests and read requests, where the write requests are optionally system write requests or host write requests, and the read requests are optionally system read requests or read / write requests.

[0027] It should be noted that system read requests (also called background read requests or non-host read requests) and system write requests are dispatched by the memory controller to perform internal memory management functions, including, but not limited to, garbage collection, read disturb, memory snapshot capturing, memory mirroring, caching, and memory sparing.

[0028] In some embodiments, in addition to the FSD 212 and the channel controller 214, the controller 202 further includes a local memory processor 218, a host interface controller 222, an SRAM buffer 224, and a home memory buffer (HMB) controller 226. The local memory processor 218 accesses the multiple memory channels 204 based on one or more queues 216 of memory access requests. In some embodiments, the local memory processor 218 reads and writes to the multiple memory channels 204 in units of memory chunks. Data from one or more memory chunks is jointly read and written to the multiple channels. There is no more than one operation to write data within the same memory chunk. Each memory chunk optionally corresponds to one or more memory pages 210. In one example, the size of each memory chunk read from or written to the multiple memory channels 204 is 16 KB (e.g., one memory page 210). In another example, the size of each memory chunk read from or written to the multiple memory channels 204 is 64 KB (e.g., four memory pages 210). In some embodiments, each memory page 210 has 16 KB of user data and 2 KB of metadata. In addition, the number of jointly accessed memory chunks and the size of each memory chunk are configurable for each of system read, host read, system write, and host write operations. In other words, the number of jointly accessed memory chunks and the size of each memory chunk are not limited to the examples shown in this application and may have different sizes not specifically shown in this application.

[0029] In some embodiments, the local memory processor 218 temporarily stores data read from or written to the memory channel 204 in an SRAM buffer 224 of the controller 202. Alternatively, in some embodiments, the local memory processor 218 is coupled to an HMB controller 226 and temporarily stores data read from or written to the memory channel 204 in a host memory buffer (HMB) 228 via the HMB controller 226 or the host interface controller 222. The HMB 228 is external to the controller 202 and is main memory used by the processor module 102 ( FIG. 1 ). In some embodiments, the HMB 228 is one of SRAM, DRAM, 3D XPOINT, and magnetoresistive RAM (MRAM), or other RAM devices. Furthermore, in some embodiments, the memory system 200 includes an SSD coupled to a DRAM-based HMB 228. Alternatively, in some embodiments, the memory system 200 includes an SSD coupled to an HMB 228 that does not include DRAM.

[0030] FIG. 3 illustrates a data structure 300 of user data 302 stored in a memory block 306 of a memory system 200 (e.g., SSD 112) along with integrity data 304, according to some embodiments. The integrity data 304 is generated from the user data 302 based on a parity check scheme (e.g., using XOR logic) and applied to verify the validity of the user data 302. The user data 302 includes multiple user data items, and the integrity data 304 includes multiple integrity data items. The user data 302 and the integrity data 304 are temporarily stored in an SRAM buffer 224 of a controller 202 of the memory system 200 (e.g., SSD 112) or in an HMB 228 ( FIG. 2 ) external to the controller 202. In some embodiments, the user data 302 and the integrity data 304 are stored in two separate areas of the SRAM buffer 224. After temporarily storing the user data 302 and integrity data 304 in the SRAM buffer 224 or the HMB 228, the controller 202 moves the user data 302 and integrity data 304 into a memory block 306 of the memory system 200 (e.g., the SSD 112). In some cases, the memory block 306 is completely filled with the user data 302 and integrity data 304 copied from the SRAM buffer 224 or the HMB 228. Alternatively, in some cases, a first subset of the memory block 306 is filled with the user data 302 and integrity data 304, and a second subset of the memory block 306 remains empty because the memory block 306 is closed (i.e., no more data can be written to the memory block 306). For example, the last memory page 210-3 of the memory planes 208-3 through 208-7 is empty.

[0031] According to the data structure 300, the memory block 306 includes a plurality of memory pages 210. The plurality of memory pages 210 are distributed across a first number L of memory dies 206. Each memory die 206 has a second number M of memory planes 208 (e.g., 208-0 through 208-7), where M is equal to 8 in FIG. 3 . Each memory plane 208 corresponds to a third number N of memory pages 210 (e.g., 210-0 through 210-N). The first number L, the second number M, and the third number N are each positive integers. In this example, the first number L, the second number M, and the third number N are equal to 2, 8, and 4, respectively, and the memory block 306 includes a total of 64 memory pages. Each superpage or stripe includes a row of pages 210. In some embodiments, each superpage or stripe is identified by a physical address when the controller 202 accesses memory cells in the memory system 200. In some embodiments, each superpage or stripe is a basic memory unit, and multiple superpages or stripes are jointly identified by a single physical address when controller 202 accesses memory cells in memory system 200.

[0032] 3, in some embodiments, one or more last pages 210 of each superpage or stripe are used to store integrity data 304, and the remaining pages 210 of each superpage or stripe are used to store user data 302. Specifically, each row of a memory page 210 (e.g., superpage or stripe 210-0) corresponds to a subset of user data 302 and a subset of integrity data 304. The subset of user data 302 is stored in each row of a memory page 210 (e.g., superpage 210-0) in a first subset of memory planes 208 (e.g., 208-0 through 208-6), and the subset of integrity data 304 is stored in each row of a memory page 210 (e.g., 210-0) in a second subset of a different memory plane 208 (e.g., 208-7). In some embodiments, each user data item of user data 302 has a data item size (e.g., 32 bits) and is stored with an integrity data item having an integrity item size (4 bits). For example, each user data item of user data 302 is stored in a corresponding memory page 210-0 in one of memory planes 208-0 through 208-6, and its corresponding integrity data item is stored in the same memory page 210-0 in memory plane 208-7. In some embodiments, XOR logic is applied to generate an integrity data item for each user data item of user data 302. Every 8 bits of the user data item of user data 302 are combined by the XOR logic to determine the parity bit of the integrity data item of integrity data 304.

[0033] In some embodiments, for each memory block 306, user data 302 and integrity data 304 are provided by a host device 220 ( FIG. 2 ) coupled to memory system 200 and prepared in an SRAM buffer 224 by controller 202. At the same time that user data 302 is written to SRAM buffer 224, integrity data 304 is determined based on each individual user data item (e.g., 32-bit, 64-bit), the user data 302 stored in each memory page 210 (e.g., 16 KB), or the user data 302 stored in each row of memory page 210. In other words, each integrity data item of integrity data 304 is generated based on data chunks having a configurable size (e.g., 4 KB, 8 KB, 16 KB, or any other suitable size) and number of data chunks of user data 302. In some embodiments, user data 302 and integrity data 304 are stored in two separate SRAM buffers 224. In some embodiments, the user data 302 is further encoded by a low-density parity check (LDPC) engine based on an LDPC coding scheme. Each user data item of the user data 302 corresponds to each integrity data item of the integrity data 304. Each user data item of the user data 302 is encoded by the LDPC engine to generate a respective LDPC code, and each integrity data item of the integrity data 304 includes an LDPC code. The user data 302 and associated integrity data 304 stored in the SRAM buffer 224 are jointly copied to and coexist in a memory block 306 of the memory system 200 (e.g., SSD 112).

[0034] Specifically, for example, on each row of memory page 210 in memory block 306, user data 302 is stored in a first subset of memory planes 208-0 to 208-6, and integrity data 304 corresponding to user data 302 on the same row is stored in the last memory plane 208-7. Thus, user data 302 and corresponding integrity data 304 are jointly stored in the same memory block 306 of memory system 200 on a superpage-by-superpage or block-by-block basis.

[0035] FIG. 4 illustrates a data structure 400 of user data 302 stored separately from integrity data 304 in two different memory blocks 306A and 306B of memory system 200 (e.g., SSD 112), according to some embodiments. The integrity data 304 is generated from the user data 302 based on a parity check scheme and applied to verify the validity of the user data 302. The user data 302 and integrity data 304 are temporarily stored in SRAM buffer 224 or HMB 228 (FIG. 2). In some embodiments, each of the two different memory blocks 306A and 306B corresponds to a different memory block in SRAM buffer 224 or HMB 228 (FIG. 2). The user data 302 is copied from the different memory blocks in SRAM buffer 224 or HMB 228 to a first memory block 306A. The integrity data 304 is copied from the different memory blocks in SRAM buffer 224 to a second memory block 306B. After the user data 302 stored in the first memory block 306A of the memory system 200 is verified or corrected, the integrity data 304 corresponding to the user data 302 is invalidated and discarded from the second memory block 306B, thereby allowing the second memory block 306B to be reused for storing additional user data 302 or integrity data 304.

[0036] According to data structure 400, each of memory blocks 306A and 306B includes a plurality of memory pages 210. The plurality of memory pages 210 are distributed across a first number L of memory dies 206. Each memory die 206 has a second number M of memory planes 208 (e.g., 208-0 through 208-7, where M equals 8). Each memory plane 208 corresponds to a third number N of memory pages 210 (e.g., 210-0 through 210-N). Each of the first number L, the second number M, and the third number N is a positive integer. In some embodiments, each memory die 206 (e.g., 206-0 or 206-1) in the first memory block 306A is different from the memory die 206 (e.g., 206-2 and 206-3) in the second memory block 306B, and each memory die 206 (e.g., 206-2 or 206-3) in the second memory block 306B is different from the memory die 206 (e.g., 206-0 and 206-1) in the first memory block 306A. No memory die belongs to both memory blocks 306A and 306B. In some cases, the first memory block 306A is completely filled with user data 302 copied from the SRAM buffer 224 or the HMB 228. Alternatively, in some cases, a first subset of the first memory block 306A is filled with user data 302, and a second subset of the first memory block 306A remains empty. For example, half of the last memory page 210-3 of the second number M of memory planes 208 is empty. In some cases, the second memory block 306B is completely filled with integrity data 304 copied from the SRAM buffer 224 or the HMB 228. Alternatively, in some cases, a first subset of the second memory block 306B is filled with integrity data 304, and a second subset of the second memory block 306B remains empty.

[0037] 4, the first memory block 306A has a block size equal to the block size of the second memory block 306B, or in some embodiments not shown, the first memory block 306A has a block size different from (e.g., larger or smaller than) the block size of the second memory block 306B.

[0038] In some embodiments, the user data 302 stored in the first memory block 306A includes multiple user data sets 402 (e.g., a first user data set 402-1, a second user data set 402-2), each configured to occupy one or more individual first memory pages 210 (e.g., two memory pages). The number of memory pages in each user data set 402 is reconfigurable. The user data in each user data set 402 is jointly stored in the first memory block 306A, for example, in response to a write command. After retrieving each of the multiple user data sets 402 in a buffer (e.g., the SRAM buffer 224, the HMB 228), the controller 202 contiguously stores each user data set 402 as a whole (e.g., jointly in response to a respective write command) in one or more individual memory pages 210 of the first memory block 306A. In some embodiments, the integrity data 304 stored in the second memory block 306B includes multiple integrity data sets 404 (e.g., a first integrity data set 404-1, a second integrity data set 404-2), each configured to occupy one or more separate second memory pages 210 (e.g., four memory pages). The number of memory pages in each integrity data set 404 is reconfigurable. The integrity data in each integrity data set 404 is jointly stored in the second memory block 306B, for example, in response to a write command. After retrieving each of the multiple integrity data sets 404 in a buffer (e.g., the SRAM buffer 224, the HMB 228), the controller 202 contiguously stores each integrity data set 404 as a whole (e.g., jointly in response to a respective write command) in one or more separate second memory pages 210 of the second memory block 306B.

[0039] For the first memory block 306A, a subset of the user data 302 corresponds to and is verified based on a subset of the integrity data 304 of the second memory block 306B. For example, the subset of the user data 302 is stored in rows of memory pages 210 (also called superpages) distributed across a second number M of memory planes 208 of a first number L of memory dies 206 of the first memory block 306A. A subset of the integrity data 304 is stored in each memory page 210 of each memory plane 208 of the memory die 206 of the second memory block 306B. In one example, a subset of user data 302A is stored in a first row of eight memory pages (i.e., first superpage 210-0) of a first memory block 306A, and a subset of integrity data 304A corresponding to the subset of user data 302A is stored in a single memory page 210-0 on memory plane 208-0 of a second memory block 306B. A subset of user data 302B is stored in a second row of eight memory pages below the first row of first memory block 306A (i.e., second superpage 210-1), and a subset of integrity data 304B corresponding to the subset of user data 302B is stored in a single memory page 210-0 on memory plane 208-1 that is closely adjacent to plane 208-0 of the second memory block 306B. Each memory page 210 in memory blocks 306A and 306B has a page size of 16 KB. In some embodiments, XOR logic or a lookup table is applied to generate an integrity data item for each user data item. Every eighth 16 KB memory page 210 in the first memory block 306A corresponds to a 16 KB memory page 210 in the second memory block 306B.

[0040] After the user data 302 and the integrity data 304 are written to the first memory block 306A and the second memory block 306B, respectively, the controller 202 of the memory system 200 reads back the user data 302 from the first memory block 306A. Optionally, the controller 202 further determines that the user data 302 is valid based on the integrity data 304. In response to determining that the user data 302 is valid based on the integrity data 304, the integrity data 304 is invalidated in the second memory block 306B and discarded therefrom.

[0041] In some cases, before the user data 302 is stored in the first memory block 306A, the user data 302 is stored in a third memory block 306C, which is different from the first and second memory blocks 306A and 306B. The user data 302 is read back from the third memory block 306C. The controller 202 of the memory system 200 determines that the user data 302 read back from the third memory block 306C is invalid based on the integrity data 304 stored in the second memory block 306B. Furthermore, in some embodiments, in response to determining that the subset of the user data 302 stored in the third memory block 306C is invalid, the controller 202 copies the user data from the third memory block 306C to the first memory block 306A (operation 308) and corrects the user data 302 in the first memory block 306A based on the integrity data 304. The user data 302 is erased in the third memory block 306C. The user data 302 replicated in the first memory block 306A is optionally read back and verified based on the integrity data 304 in the second memory block 306B. In response to determining that the user data 302 is valid, the integrity data 304 is invalidated with the second memory block 306B reused for storing additional user data 302 or integrity data 304.

[0042] In some embodiments, the user data 302 stored in the first memory block 306A corresponds to a first subset of (less than all of) the integrity data 304 stored in the second memory block 306B. The second memory block 306B is reused after all of the integrity data 304 stored in the second memory block 306B has been invalidated, i.e., after verification of the user data stored in the first memory block 306A and one or more additional memory blocks 306. Alternatively, in some embodiments, the second memory block 306B is partially filled, and the user data 302 stored in the first memory block 306A corresponds to all of the integrity data 304 stored in the second memory block 306B. The second memory block 306B is reused after the user data 302 in the first memory block 306A has been verified. Alternatively and additionally, in some embodiments, the second memory block 306B is completely filled with integrity data 304 corresponding to the user data 302 in the first memory block 306A. The second memory block 306B is reused after the user data 302 in the first memory block 306A is verified.

[0043] After the integrity data 304 in the second memory block 306 is invalidated, the user data 302 is read from the first memory block 306A independently of the integrity data 304. In some embodiments, the first memory block 306A includes a plurality of first cells of a first cell type (e.g., SLC). The memory system 200 further includes a fourth memory block 306D having a plurality of second cells of a second cell type (e.g., QLC). In an internal copyback 310, the user data 302 is copied from the first memory block 306A to the fourth memory block 306D without the integrity data 304. Each of the first and second cell types is one of SLC, MLC, TLC, QLC, PLC, and six-level or higher cells, and the first cell type is distinct and different from the second cell type.

[0044] 5 is a flow diagram of an example data storage method 500, according to some embodiments. A host device 220 (e.g., processor module 102 in FIG. 1) is coupled to a memory system 200 that includes a plurality of memory blocks 306. Each memory block 306 includes an SLC memory block. The host device 220 provides user data 302 to a controller 202 of the memory system 200 (operation 502). In some embodiments, the controller 202 temporarily writes the user data 302 to an SRAM buffer 224 (FIG. 2) within the controller 202 (operation 504). Alternatively, in some embodiments, the controller 202 temporarily writes the user data 302 to an HMB 228 (FIG. 2) external to the controller 202.

[0045] The controller 202 of the memory system 200 determines integrity data 304 corresponding to the user data 302 and applicable to verifying the user data 302 (operation 506). The user data 302 includes a configurable first number of data chunks, each data chunk having a configurable first chunk size (e.g., 4KB, 8KB, 16KB). The integrity data 304 corresponding to the user data 302 includes a configurable second number of data chunks, each data chunk having a second chunk size (e.g., 4KB, 8KB, 16KB). The configurable second number (e.g., 8) is optionally equal to or different from the configurable first number (e.g., 32). The configurable second chunk size (e.g., 4KB) is optionally equal to or different from the configurable first chunk size (e.g., 16KB). In one example, XOR logic is applied to generate an integrity data item for each user data item. Each 8-bit user data item is combined with XOR logic to determine a parity check unit of integrity data 304. In some embodiments, integrity data 304 is stored in the same buffer 224 or 228 (FIG. 2) as user data 302. Alternatively, integrity data 304 and user data 302 are stored separately in SRAM buffer 224 and HMB 228 (FIG. 2).

[0046] In some embodiments, the user data 302 is further encoded by the LDPC engine to generate integrity data 304 based on an LDPC encoding scheme (operation 508). The user data 302 is written to a first memory block 306A of the memory system 200 (e.g., the SSD 112), and the integrity data 304 corresponding to the user data 302 is copied to a second memory block 306B of the memory system 200 (e.g., the SSD 112). In one example, each memory cell on the memory block 306 includes an SLC and is formed based on NAND logic. Each memory cell may have two or more levels. Furthermore, in some cases, XOR logic is implemented by the LDPC engine to encode the user data 302 and generate the LDPC code as the integrity data 304. Thus, the integrity data 304 corresponding to the user data 302 includes the LDPC code and is written to the second memory block 306B.

[0047] The integrity data 304 includes multiple integrity data sets 404 (FIG. 4), each configured to occupy one or more separate second memory pages 210 in the second memory block 306B. The integrity data in each integrity data set 404 is jointly stored in the second memory block 306B, for example, in response to a write command. In some embodiments, when a predetermined number of integrity data sets 404 are available, the integrity data of the integrity data sets 404 is written to the second memory block 306B (operation 510). In some embodiments, the user data 302 in the first memory block 306A is encoded by an LDPC engine based on an LDPC encoding scheme. Each user data item of the user data 302 corresponds to each integrity data item of the integrity data 304 in the second memory block 306B. Each of the user data items of the user data 302 in the first memory block 306A is encoded by the LDPC engine to generate a respective LDPC code, and the integrity data items of the integrity data 304 in the second memory block 306B include the LDPC codes. In some embodiments, the integrity data 304 in the second memory block 306B includes XOR parity. In some embodiments, the integrity data 304 in the second memory block 306B includes both the LDPC code and the XOR parity associated with the user data 302 stored in the first memory block 306A.

[0048] When the integrity data sets 404 fill the second memory block 306B or when the second memory block 306B does not need to be completely filled, the second memory block 306B is closed. In some embodiments, a firmware application is applied to control the predetermined number of integrity data sets 404 written to the second memory block 306B in each write operation. In some embodiments, the second memory block 306B stores only the integrity data 304 associated with the user data 302 stored in the first memory block 306A. Alternatively, in some embodiments, the second memory block 306B stores the integrity data 304 associated with the user data 302 stored in the first memory block 306A and one or more additional memory blocks 306B.

[0049] In some embodiments, readback and data verification are performed when the first memory block 306A is closed for additional data storage. The second memory block 306B does not need to be closed to store additional integrity data different from the integrity data 304 associated with the user data 302 in the first memory block 306A. However, the integrity data 304 associated with the user data 302 stored in the first memory block 306A is assumed to have been written to the second memory block 306B.

[0050] In response to determining that the first memory block 306A used to store user data 302 has not yet been closed (operation 512), more user data 302 and integrity data 304 are generated (operations 502-510) to write to the first memory block 306A and the second memory block 306B, respectively, until the first memory block 306A is closed. In response to determining that the first memory block 306A used to store user data 302 has been closed (operation 512), the integrity data 304 corresponding to the first memory block 306A is copied from the buffer 224 or 228 to the second memory block 306B. The user data 302 in the first memory block 306A is read back from the first memory block 306A (operation 514) and verified based on the corresponding integrity data 304 stored in the second memory block 306B. The integrity data 304 corresponding to the user data 302 stored in the first memory block 306A is invalidated in response to determining that the user data 302 is valid. The integrity data 304 is then discarded. After all of the integrity data 304 stored in the second memory block 306B has been invalidated, the second memory block 306B is reused to store additional user data 302 or integrity data 304.

[0051] After the integrity data 304 stored in the second memory block 306B is invalidated and discarded, the controller 202 of the memory system 200 repeats operations 502-516 to store the user data 302 provided by the host device 220 in the next first memory block 306A (FIG. 2). The next first memory block 306A of the user data 302 is verified based on the next second memory block 306B that stores the corresponding integrity data 304, but is not co-stored with the corresponding integrity data 304. Upon verification of the next first memory block 306A of the user data 302, the next second memory block 306B of the integrity data 304 is also invalidated and discarded. By these measures, the integrity data 304 is not stored to reduce over-provisioning of the memory system 202, and the integrity data 304 does not need to be copied during subsequent copy-back operations for the user data 302.

[0052] In some embodiments, XOR parity checking is one of the important memory management functions implemented in SSD 112 to protect data integrity from NAND defects. This function enables firmware (FW) and application specific integrated circuits (ASICs) to recover user data 302 using integrity data 304 (e.g., XOR parity) stored in volatile media and determined when writing user data 302 to NAND-based memory cells of SSD 112. XOR parity is optionally determined at the die level (e.g., 64 KB), plane level (e.g., 16 KB), half plane level (e.g., 8 KB), or quarter plane level (e.g., 4 KB). The quarter plane level uses less space (e.g., 4 KB) and has weaker correction capabilities than the plane level, which uses less space (e.g., 16 KB) and has weaker correction capabilities than the die level. The method 500 invalidates the integrity data 304 and is performed regardless of any XOR parity size requirements (eg, half-plane level, quarter-plane level, or plane level).

[0053] In other words, in some embodiments, the electronic device divides the user data 302 into multiple data chunks. Each data chunk has a data chunk size. The electronic device determines each integrity data item of the subset of integrity data 304 based on the respective subset of data chunks. Each subset of data chunks includes a predetermined number of data chunks of the user data 302 (e.g., four data chunks). For example, each data chunk corresponds to two memory pages 210, and each integrity data item corresponds to four data chunks (i.e., eight memory pages 210). In some embodiments, each of the multiple integrity data items of the integrity data 304 is determined based on the respective subset of data chunks using XOR logic or a lookup table. In some embodiments, for each of the multiple user data items of the user data 302, each of the multiple integrity data items of the integrity data 304 is determined using XOR logic or a lookup table.

[0054] In some embodiments, the method 500 is implemented based on a dynamic XOR policy to generate dynamic XOR parity data 304 for storage in the system block 306B (i.e., the second memory block 306B) while user data 302 is being written to the SLC block 306A or the TLC / QLC block during a TLC / QLC direct program algorithm. The dynamic XOR parity data 304 is calculated at superpage granularity (e.g., for the first memory block 306A), stored in ASIC memory (e.g., buffer 224 or 228), and periodically flushed to a non-volatile storage medium (system block 306B) during low-power state transitions (including power loss notifications (PLNs)). In some cases, the SRAM buffer 224 has a limited size, and the host memory buffer (HMB) 228 is used to store the dynamic XOR parity data 304. The firmware uses direct addressing to match the user data 302 stored in the first memory block 306A with the corresponding parity data 304 stored in the system block 306B. This ensures that the parity data 304 is protected from power loss. When the first memory block 306A is closed, the FW performs a full or partial block read (depending on the NAND technology) to ensure data integrity before invalidating the XOR parity data 304 stored in the system block 306B. When there is a safe power cycle or low power state transition, the parity data 304 is dumped to the system block 306B and becomes valid. Upon resume, if an error correcting code (ECC) error is detected in the open block, the integrity data 304 is used to recover the user data 302 and manage bad block error handling, which is identical to traditional XOR policy implementation.

[0055] In some embodiments, the low power state transition is enabled in response to a PLN received by the controller 202 of the memory system 200. The PLN directs the system module 100 to disable power and instructs the controller 202 to take the necessary actions and store a snapshot or current state of the memory system 200, which includes multiple memory channels 204. The snapshot and current state are loaded to help the memory system 200 quickly resume operation after a low power state.

[0056] In some embodiments, an internal copyback (ICB) function is supported by the NAND-based SSD 112. The SSD 112 copies all user data 302 from one first memory block 306A (source) to another block destination. When using ICB, there is no built-in intelligence in the first memory block 306A to distinguish between valid and invalid data; the entire block data is copied to the destination block. As the total NVB (number of valid blocks) in the QLC decreases, the overhead of maintaining the QLC XOR becomes high. As a result, the FW algorithm does not implement QLC XOR. In architectures without adaptive XOR parity, SLC parity is ported to the QLC during internal copyback. This data would not be ported if the internal copyback function were not used. As a result, the effectiveness of the TLC / QLC blocks is reduced due to the presence of XOR parity data. This degradation may cause QLC-to-QLC or TLC-to-TLC garbage collection (defragmentation) to be triggered earlier (to free up space in the TLC / QLC area), resulting in performance degradation for end users. The adaptive XOR parity-based method 500 is important for TLC / QLC NAND-based SSDs 112, ensuring that additional blocks are not needed, improving the memory operation speed of the NAND-based SSDs 112. The spare SLC blocks storing parity (e.g., second memory block 306B) are wear-leveled along with the remaining SLC data or system map blocks.

[0057] The method 500 is extendable to different types of memory systems 200, including but not limited to SSDs 112 in data centers, SSDs 112 in client devices, and automotive SSD segments. In some embodiments, the memory system 200 has XOR protection until the memory block 306 is opened. Post-closure relies on NAND reliability metrics. SLC has high margins. This feature is implemented with minimal impact on the value segment. In some cases, post-closure failure is triggered as a read failure based on retention or disturb mechanisms.

[0058] In some embodiments, application of method 500 is detected by sniffing the NAND interface bus and applying command sequence analysis.

[0059] FIG. 6 is a flow diagram of an example data write process 600 for writing user data 302 in a first memory block 306A of a memory system 200 (e.g., SSD 112), according to some embodiments. The first memory block 306A is also referred to as an SLC block, and the second memory block 306B is also referred to as a system block. In some embodiments, the data write process 600 is initiated (operation 602), for example, in response to a data write request. The controller 202 of the memory system 200 determines whether the first memory block 306A is closed for storing user data 302 (operation 604). In some embodiments, the user data 302 fills the first memory block 306A. The controller 202 determines whether the user data 302 fills the first memory block 306A (operation 604). Alternatively, in some embodiments, user data 302 does not fill first memory block 306A, but is stored in first memory block 306A to partially fill first memory block 306A. When first memory block 306A is closed, user data 302 is no longer stored in first memory block 306A.

[0060] In response to determining that the first memory block 306A is not closed, more user data 302 needs to be retrieved from the host device 220 (FIG. 2). While retrieving more user data 302 to store in the first memory block 306A, the controller 202 generates a subset of integrity data 304 (e.g., XOR-based parity data) corresponding to the retrieved user data 302 (operation 606) and temporarily stores the subset of integrity data 304 in the SRAM buffer 224. In the process of generating the integrity data 304, the controller 202 determines whether the integrity data 304 stored in the SRAM buffer 224 fills a predefined first integrity data set 404 (e.g., a die page including four memory pages) to be jointly copied from the SRAM buffer 224 to the HMB 228 (operation 608). In response to determining that the integrity data 304 stored in the SRAM buffer 224 fills the first integrity data set 404, the controller 202 further determines whether the HMB 228 is also being used to store the integrity data 304 for the second memory block 306B (operation 610). In response to determining that the HMB 228 is also being used to store the integrity data 304 for the second memory block 306B, the integrity data 304 is moved to the HMB 228 (operation 612) and, e.g., added to the integrity data 304 already stored in the HMB 228 until it is determined that the integrity data 304 stored in the HMB 228 jointly fills a predefined second integrity data set 404 (e.g., a superpage including eight memory pages) that is copied from the HMB 228 to the second memory block 306B (operation 614). Each second integrity data set 404 stored in the HMB 228 is written to the second memory block 306B (operation 616). In some embodiments, the HMB 228 is not used to store the integrity data for the second memory block 306B, and the integrity data 304 stored in the SRAM buffer 224 bypasses the HMB 228 and is written to the second memory block 306B (operation 616).The user data 302 is temporarily stored in the SRAM buffer 224 of the first memory block 306A (operation 618) and is written incrementally to the first memory block 306A.

[0061] In response to determining that the first memory block 306A is not closed (e.g., there is no more user data 302 to be stored in the first memory block 306A), the controller 202 reads the user data 302 back from the first memory block 306A (operation 620) and determines whether a readback error exists (operation 622). In response to determining that there is no readback error, the integrity data 304 corresponding to the user data 302 in the first memory block 306A is invalidated in the second memory block 306B (operation 624). Conversely, in response to determining that there is a readback error, the integrity data 304 corresponding to the user data 302 in the first memory block 306A is identified in the second memory block 306B (operation 626) and applied to the first memory block 306A to correct the readback error. In some embodiments, if a readback error is detected in the user data 302 in the first memory block 306A, the user data 302 is copied from the first memory block 306A to the third memory block 306C and corrected in the third memory block 306C. The user data 302 in the first memory block 306A and the corresponding integrity data 304 in the second memory block 306B are invalidated. Alternatively, in some embodiments, the user data 302 in the third memory block 306C (FIG. 4) is read back and a readback error is detected in the user data 302 in the third memory block 306C. The user data 302 is copied from the third memory block 306C to the first memory block 306A and corrected in the first memory block 306A. The user data 302 and the corresponding integrity data 304 in the third memory block 306C are invalidated. After the user data 302 in the first memory block 306A is invalidated or corrected, the write operation is completed (operation 628).

[0062] FIG. 7 is a flow diagram of another example of a data storage method 700, according to some embodiments. The method 700 is performed in an electronic device having a memory system 200 (Operation 702). The memory system 200 includes a first memory block 306A and a second memory block 306B. Each memory block 306 includes one or more individual memory dies 206 (e.g., two different dies 206-0 and 206-1 of the first memory block 306A in FIG. 4). The electronic device stores user data 302 including a plurality of user data items in the first memory block 306A (Operation 704). Each of the plurality of user data items of the user data 302 is configured to be verified based on a respective one of a plurality of integrity data items. The electronic device stores integrity data 304 including a plurality of integrity data items in a second memory block 306B (Operation 706), where each memory die of the second memory block 306B is different from one or more individual dies of the first memory block 306A. Each memory die of the first memory block 306A is different from one or more individual dies of the second memory block 306B. The first memory block 306A and the second memory block 306B comprise entirely different memory dies. The electronic device invalidates the integrity data 304 in the second memory block 306B (operation 708) and reads the user data 302 from the first memory block 306A independently of the integrity data 304 (operation 710).

[0063] In some embodiments, before invalidating the integrity data 304 in the second memory block 306B, the electronic device reads back the user data 302 from the first memory block 306A (operation 712) and determines that the user data 302 is valid based on the integrity data 304 (operation 714). The integrity data 304 in the second memory block 306B is invalidated in response to determining that the user data 302 is valid based on the integrity data 304. The integrity data 304 in the second memory block 306B is discarded (operation 716). In other words, the user data 302 is stored in the first memory block 306A without the integrity data 304 and is thereafter read without checking data validity based on the integrity data 304.

[0064] In some embodiments, before storing the user data 302 in the first memory block 306A, the electronic device stores the user data 302 in a third memory block 306C that is different from the first and second memory blocks (operation 718). The electronic device reads back the user data 302 from the third memory block 306C (operation 720) and determines that the user data 302 read back from the third memory block 306C is invalid based on the integrity data 304 stored in the second memory block 306B (operation 722). Further, in some embodiments, in response to determining that the subset of user data 302 stored in the third memory block 306C is invalid, the electronic device copies the user data 302 from the third memory block 306C to the first memory block 306A (operation 724), corrects the user data 302 in the first memory block 306A based on the integrity data 304 (operation 726), and erases the user data 302 in the third memory block 306C (operation 728).

[0065] In some embodiments, the memory system 200 includes an SSD 112 of an electronic device, and each memory die 206 includes multiple memory planes 208. Each memory plane 208 includes multiple memory pages 210, and each memory page 210 includes multiple memory cells. Furthermore, in some embodiments, the user data 302 includes multiple user data sets 402, with each user data set 402 configured to occupy one or more distinct first memory pages. The user data 302 is stored in the first memory block 306A by retrieving each of the multiple user data sets 402 in a buffer and then sequentially storing each user data set as a whole (e.g., jointly in response to a memory command) in one or more distinct memory pages 210 of the first memory block 306A. Additionally, in some embodiments, the integrity data 304 includes multiple integrity data sets 404, with each integrity data set 404 configured to occupy one or more distinct second memory pages. Specifically, after obtaining each of the plurality of integrity data sets 404 in the buffer, each integrity data set 404 is stored as a whole (e.g., jointly in response to a memory command) in one or more separate second memory pages 210 of the second memory block 306B. The plurality of integrity data sets 404 are stored contiguously in the second memory block 306B. The buffer is optionally the SRAM buffer 224 or the HMB 228. The one or more separate first or second memory pages 210 include a reconfigurable number of memory pages 210 that are jointly read from and written to.

[0066] Furthermore, in some embodiments, the memory system 200 includes a plurality of memory blocks 306, and the second memory block 306B is the last memory block of the plurality of memory blocks 306.

[0067] In some embodiments, the first memory block 306A includes a plurality of first cells of a first cell type (e.g., SLC). The memory system 200 further includes a fourth memory block 306D, which includes a plurality of second cells of a second cell type (e.g., QLC). The first cell type is separate and distinct from the second cell type. The electronic device reads the user data 302 from the first memory block 306A by copying the user data 302 from the first memory block 306A to the fourth memory block 306D without the integrity data 304 (operation 730).

[0068] In some embodiments, for each of the plurality of user data items in user data 302, each of the plurality of integrity data items in integrity data 304 is determined by XOR logic. In some embodiments, for each of the plurality of user data items in user data 302, each of the plurality of integrity data items in integrity data 304 is determined by a lookup table.

[0069] In some embodiments, the electronic device divides the user data 302 into multiple data chunks. Each data chunk has a data chunk size. The electronic device determines each of the subsets of the integrity data 304 based on the subset of each data chunk. Each subset of data chunks includes a predetermined number of data chunks. In one example, XOR parity is obtained at different levels (e.g., plane levels) based on the size of the subset of each data chunk.

[0070] In some embodiments, the electronic device encodes each of the plurality of user data items of the user data 302 with a low-density parity check (LDPC) engine to generate a respective LDPC code. Each of the plurality of integrity data items of the integrity data 304 corresponding to each user data 302 includes an LDPC code. In some embodiments, the electronic device encodes each of the plurality of user data items of the user data 302 with an XOR parity scheme. In some embodiments, the electronic device encodes each of the plurality of user data items of the user data 302 with both an LDPC engine and an XOR parity scheme. In some embodiments, the electronic device encodes a data chunk including a set of user data items of the user data 302 with one or both of an LDPC engine and an XOR parity scheme.

[0071] In some embodiments, the memory system includes a redundant array of independent disks (RAID) further including a first drive and a second drive. The first memory block includes at least a portion of the first drive in the RAID. The electronic device determines integrity data 304 including a set of RAID parity data items based on a subset of user data 302 stored on the first drive of the RAID and a set of user data stored on a second drive of the RAID.

[0072] It should be understood that the particular order in which the operations in Figures 5-7 are described is merely exemplary and is not intended to indicate that the described order is the only order in which the operations can be performed. Those skilled in the art will recognize various methods for storing user data 302 in memory system 200 (e.g., SSD 112). Additionally, it should be noted that other process details described above with reference to Figures 1-4 equally apply to methods 500, 600, and 700 described above with reference to Figures 5, 6, and 7. For the sake of brevity, these details will not be repeated here.

[0073] The memory is also used to store instructions and data associated with methods 500, 600, and 700 and includes high-speed random-access memory such as DRAM, SRAM, DDR RAM, or other random-access solid-state memory devices, and optionally includes non-volatile memory such as one or more magnetic disk storage devices, one or more optical disk storage devices, one or more flash memory devices, or one or more other non-volatile solid-state storage devices. The memory optionally includes one or more storage devices located remotely from the one or more processing units. The memory, or alternatively, the non-volatile memory within the memory, comprises a non-transitory computer-readable storage medium. In some embodiments, the memory, or the non-transitory computer-readable storage medium of the memory, stores programs, modules, and data structures, or a subset or superset, for implementing methods 500, 600, and 700.

[0074] Each of the above-identified elements may be stored in one or more of the memory devices described above and corresponds to a set of instructions for performing the functions described above. The above-identified modules or programs (i.e., sets of instructions) need not be implemented as separate software programs, procedures, modules, or data structures; various subsets of these modules may be combined or rearranged in various embodiments. In some embodiments, memory optionally stores a subset of the above-identified modules and data structures. Additionally, memory optionally stores additional modules and data structures not described above.

[0075] The terms used in describing the various described implementations herein are for the purpose of describing particular implementations only and are not intended to be limiting. As used in describing the various described implementations and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. The term "and / or," as used herein, refers to and encompasses any and all possible combinations of one or more of the associated listed items. It is further understood that, as used in this specification, the terms "includes," "comprises," and / or "comprising" specify the presence of claimed features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. Additionally, while the terms "first," "second," etc. may be used herein to describe various elements, it is understood that these elements are not limited to these terms. These terms are used only to distinguish one element from another.

[0076] As used herein, the term "if" is interpreted to mean "when" or "upon" or "response to determining" or "response to detecting" or "in response to a determination," depending on the context, as appropriate. Similarly, the phrase "upon determining" or "upon detecting a stated state or event" is interpreted to mean "upon determining" or "in response to determining" or "upon detecting a stated state or event" or "in response to detecting a stated state or event" or "in response to determining that a stated state or event is detected," depending on the context, as appropriate.

[0077] The foregoing description, for purposes of interpretation, has been set forth in terms of specific embodiments. However, the foregoing illustrative discussion is not intended to be exhaustive or to limit the scope of the claims to the precise form disclosed. Many modifications and variations are possible in light of the above teachings. The embodiments have been chosen and described to best illustrate the principles and practical application of the invention and to enable those skilled in the art to understand them.

[0078] In particular, any examples relating to specific numbers or settings are not intended to be exhaustive or to limit the scope of the claims to only the disclosed examples. Many modifications and variations are possible in light of the above teachings and the common sense of those skilled in the art. The embodiments have been chosen and described to best interpret the principles and practices of operation and to enable those skilled in the art to understand them.

[0079] Although the various figures depict a number of logical steps in a particular order, steps that are not order-dependent may be reordered, and other steps may be combined or separated. While some reorderings or other groupings have been specifically mentioned, other reorderings or groupings will be apparent to those skilled in the art, and the reorderings and groupings presented herein are not an exhaustive list of alternatives. It should also be recognized that the steps may be implemented in hardware, firmware, software, or any combination thereof.

Claims

1. A data storage method, comprising:

1. An electronic device having a memory system having a first memory block and a second memory block, each including one or more individual memory dies, storing user data in the first memory block, the user data including a plurality of user data items, each of the plurality of user data items configured to be verified based on a respective one of a plurality of integrity data items; storing integrity data in the second memory block, the integrity data including the plurality of integrity data items, wherein each memory die of the second memory block is different from the one or more individual memory dies of the first memory block; invalidating the integrity data in the second memory block; reading the user data from the first memory block independently of the integrity data; A method comprising:

2. before invalidating the integrity data in the second memory block; reading back the user data from the first memory block; determining, based on the integrity data, that the user data is valid, wherein, in response to determining that the user data is valid based on the integrity data, the integrity data in the second memory block is invalidated; discarding the integrity data in the second memory block; The method of claim 1 further comprising:

3. before storing the user data in the first memory block; storing the user data in a third memory block different from the first memory block and the second memory block; reading back the user data from the third memory block; determining, based on the integrity data stored in the second memory block, that the user data read from the third memory block is invalid; The method of claim 1 further comprising:

4. Storing the user data in the first memory block comprises, in response to determining that the subset of user data stored in the third memory block is invalid, copying the user data from the third memory block to the first memory block; correcting the user data in the first memory block based on the integrity data; erasing the user data in the third memory block; The method of claim 3 further comprising:

5. 10. The method of claim 1, wherein the memory system comprises a solid-state drive of the electronic device, each memory die comprising a plurality of memory planes, each memory plane comprising a plurality of memory pages, and each memory page comprising a plurality of memory cells.

6. The user data includes a plurality of user data sets, each of which is configured to occupy one or more individual first memory pages, and the step of storing the user data in the first memory block comprises:

6. The method of claim 5, further comprising the step of, after obtaining each of said user data sets in a buffer, storing each of said user data sets as a whole contiguously within said one or more individual first memory pages of said first memory block.

7. The integrity data includes a plurality of integrity data sets, each integrity data set configured to occupy one or more separate second memory pages, and the step of storing the integrity data in the second memory blocks includes:

6. The method of claim 5, further comprising, after obtaining each of the plurality of integrity data sets in a buffer, storing each of the integrity data sets as a whole contiguously within the one or more separate second memory pages of the second memory block.

8. 6. The method of claim 5, wherein the memory system includes a plurality of memory blocks, and the second memory block is the last memory block of the plurality of memory blocks.

9. the first memory block includes a plurality of first cells of a first cell type; the memory system further includes a fourth memory block, the fourth memory block including a plurality of second cells of a second cell type; the second cell type is different from the first cell type; The step of reading the user data from the first memory block includes: further comprising copying the user data from the first memory block to the fourth memory block without the integrity data.

9. The method according to any one of claims 1 to 8.

10. 9. The method of claim 1, further comprising determining, for each of the plurality of user data items, each of the plurality of integrity data items by one of XOR logic and a look-up table.

11. dividing the user data into a plurality of data chunks, each data chunk having a data chunk size; determining each of a subset of integrity data items based on a subset of each data chunk, the subset of each data chunk including a predetermined number of data chunks; 9. The method of claim 1, further comprising:

12. 12. The method of claim 11, further comprising: encoding each of the plurality of user data items with a low-density parity check (LDPC) engine to generate a respective LDPC code, wherein each of the plurality of integrity data items comprises the LDPC code.

13. the memory system includes a redundant array of inexpensive disks (RAID) including a first drive and a second drive, the first memory block includes at least a portion of the first drive in the RAID, and the one or more programs: and further comprising instructions for determining the integrity data including a set of RAID parity data items based on the subset of user data stored on the first drive of the RAID and a set of user data stored on the second drive of the RAID.

9. The method according to any one of claims 1 to 8.

14. 1. An electronic device comprising: one or more processors; a memory system having a first memory block and a second memory block, each including one or more individual memory dies; a memory storing one or more programs for execution by said one or more processors, said one or more programs including instructions for performing a method according to any one of claims 1 to 8; An electronic device comprising:

15. 9. A non-transitory computer-readable storage medium storing one or more programs for execution by one or more processors, the one or more programs including instructions for performing the method of any one of claims 1 to 8.