ZNS parity swap to DRAM

Abstract

The present disclosure generally relates to a method of operating a storage device. The storage device includes a controller including a first random access memory (RAM1), a second random access memory (RAM2), and a storage unit divided into a plurality of partitions. A first command to write data to a first partition is received, first XOR data is generated in the RAM1, and the data of the first command is written to the first partition. When a second command to write data to a second partition is received, the generated first XOR data is copied from the RAM1 to the RAM2, and second XOR data for the second partition is copied from the RAM2 to the RAM1. The second XOR data is updated with the second command, and the data of the second command is written to the second partition. The updated second XOR data is copied from the RAM1 to the RAM2.

Description

[0001] Cross Reference to Related Applications

[0002] This patent application claims priority to U.S. Application No. 16 / 884,569, filed May 27, 2020, which is incorporated by reference herein in its entirety. BACKGROUND TECHNICAL FIELD

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

[0005] Description of the Related Art

[0006] Storage devices, such as SSDs, can be used in computers in applications that require relatively low latency and high capacity storage. For example, SSDs can exhibit lower latency than hard disk drives (HDDs), especially for random reads and writes. Generally, a controller of an SSD receives commands to read or write data from a host device to a memory device. The data is read and written to one or more erase blocks in the memory device. Each of these erase blocks is associated with a logical block address, such that the SSD and / or the host device knows where the data is stored. One or more erase blocks can be grouped together by their respective logical block addresses to form a plurality of zones.

[0007] Generally, one die in each zone is dedicated to storing parity data (such as XOR data) for that zone. As the storage device receives a command to write data to a particular zone, that data associated with the command is written to the memory device, and parity data is simultaneously generated for that data to protect the data. The parity data is then stored to random access memory (RAM), such as SRAM or DRAM, within the storage device. However, because RAM is expensive, the storage device generally includes a very limited amount of RAM. Because parity data is generated for each write command received, the parity data takes up a lot of valuable RAM space, which can reduce the amount of RAM space available for other data, or can require a larger amount of RAM to be included in the storage device. As a result, the overall cost of the storage device can increase, or the capabilities of the storage device can be limited.

[0008] Therefore, there is a need for a new method of efficiently operating a storage device. SUMMARY

[0009] The present disclosure generally relates to methods of operating a storage device. The storage device includes a controller including a first random access memory (RAM1), a second random access memory (RAM2), and a storage unit divided into a plurality of zones. A first command to write data to a first zone is received, first XOR data is generated in RAM1, and data of the first command is written to the first zone. When a second command to write data to a second zone is received, the generated first XOR data is copied from RAM1 to RAM2, and second XOR data for the second zone is copied from RAM2 to RAM1. The second XOR data is updated with the second command, and data of the second command is written to the second zone. The updated second XOR data is copied from RAM1 to RAM2.

[0010] In one embodiment, a storage device includes a non-volatile storage unit. A capacity of the non-volatile storage unit is divided into a plurality of zones. The non-volatile storage unit includes a plurality of dies, each of the plurality of dies including a plurality of erase blocks. The storage device further includes a first volatile memory unit, a controller coupled to the non-volatile storage unit and the first volatile memory unit, and the controller including a second volatile memory unit. The controller is configured to receive a command to write data to one or more zones, generate first parity data for a first zone in the second volatile memory unit, and copy the first parity data for the first zone from the second volatile memory unit to the first volatile memory unit. The controller is further configured to copy second parity data for a second zone from the first volatile memory unit to the second volatile memory unit, update the second parity data for the second zone in the second volatile memory unit, and update the first parity data for the first zone in the second volatile memory unit.

[0011] In another embodiment, a storage device includes a non-volatile storage unit. A capacity of the non-volatile storage unit is divided into a plurality of zones. The non-volatile storage unit includes a plurality of dies, each of the plurality of dies including a plurality of erase blocks. The storage device further includes a first volatile memory unit, a controller coupled to the non-volatile storage unit and the first volatile memory unit, and the controller including a second volatile memory unit. The controller is configured to receive a first command to write data into a first zone in the non-volatile storage unit, generate first parity data for the data associated with the first command, and concurrently write the data associated with the first command into the first zone, where the first parity data is stored in the second volatile memory unit. The controller is further configured to receive a second command to write data into a second zone in the non-volatile storage unit, copy second parity data associated with the second zone from the first volatile memory unit to the second volatile memory unit, update the second parity data with the data associated with the second command, and concurrently write the data associated with the second command into the second zone.

[0012] In another embodiment, a storage device includes a non-volatile storage unit. A capacity of the non-volatile storage unit is divided into a plurality of zones. The non-volatile storage unit includes a plurality of dies, each of the plurality of dies including a plurality of erase blocks. The storage device further includes a DRAM unit, a controller coupled to the non-volatile storage unit and the DRAM unit, and the controller including an SRAM unit. The controller is configured to receive a first command to write data into a first zone in the non-volatile storage unit, update first parity data in a first location in the SRAM unit with the data associated with the first command, and concurrently write the data associated with the first command into the first zone. The controller is further configured to receive a second command to write data into a second zone in the non-volatile storage unit, copy the updated first parity data from the SRAM unit to the DRAM unit, and concurrently copy second parity data associated with the second zone from the DRAM unit to a second location in the SRAM unit. The controller is further configured to update the second parity data with the data associated with the second command, and concurrently write the data associated with the second command into the second zone. The controller is further configured to receive a third command to write data into a third zone in the non-volatile storage unit, erase the updated first parity data from the first location in the SRAM unit, generate third parity data in the first location in the SRAM unit, and concurrently write the data associated with the third command into the first zone. BRIEF DESCRIPTION OF DRAWINGS

[0013] 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.

[0014] Figure 1 is a schematic block diagram illustrating a storage system according to one embodiment.

[0015] Figure 2 is a block diagram illustrating a method of operating a storage device to execute a read or write command according to one embodiment.

[0016] Figure 3A illustrates a partitioned namespace used in a storage device according to one embodiment.

[0017] Figure 3B illustrates a state diagram for a partitioned namespace of a storage device according to one embodiment. Figure 3A

[0018] Figures 4A-4F illustrates a schematic block diagram of generating and / or updating parity data or XOR data in SRAM, DRAM, or SRAM and DRAM according to various embodiments.

[0019] Figures 5A-5B illustrates a schematic diagram of updating in-flight data over time in a storage device according to various 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 is to 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, it is contemplated that features and elements from the disclosure can be implemented in any combination other than the specific embodiments illustrated and described. Furthermore, although 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 a limitation 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" shall not be construed as being a surrender by the inventor of any of the application subject matter disclosed herein and shall not constitute admissions that the application subject matter disclosed herein is part of the common general knowledge of those skilled in the art in any jurisdiction.

[0022] The present disclosure generally relates to a method of operating a storage device. The storage device includes a controller including a first random access memory (RAM1), a second random access memory (RAM2), and a storage unit divided into a plurality of partitions. A first command to write data to a first partition is received, first XOR data is generated in the RAM1, and data of the first command is written to the first partition. When a second command to write data to a second partition is received, the generated first XOR data is copied from the RAM1 to the RAM2, and second XOR data for the second partition is copied from the RAM2 to the RAM1. The second XOR data is updated with the second command, and data of the second command is written to the second partition. The updated second XOR data is copied from the RAM1 to the RAM2.

[0023] Figure 1 is a schematic block diagram illustrating a storage system 100 in accordance with one or more techniques of the present disclosure, in which a storage device 106 can be used as a storage device for a host device 104. For example, the host device 104 can utilize storage units 110 included in the storage device 106, such as non-volatile memory (NVM), to store and retrieve data. For example, the storage units 110 can be any type of non-volatile memory, such as MRAM, NAND, NOR, or HDD. In the following description, the storage units 110 are referred to as non-volatile memory (NVM) 110 for simplicity and illustrative purposes. The host device 104 includes a host DRAM 138. In some examples, the storage system 100 can include multiple storage devices, such as the storage device 106, which can operate as a storage array. For example, the storage system 100 can include multiple storage devices 106 configured to collectively operate as a redundant array of inexpensive / independent disks (RAID) for the host device 104.

[0024] Storage system 100 includes host device 104, which can store data to and / or retrieve data from one or more storage devices, such as storage device 106. Figure 1 As shown, host device 104 can communicate with 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, etc.

[0025] Storage device 106 includes a controller 108, an NVM 110, a power supply 111, a first random access memory (RAM) or volatile memory 112, such as dynamic random access memory (DRAM), and an interface 114. The controller 108 may include a parity check engine or XOR engine 124 and a second RAM or volatile memory 118, such as static random access memory (SRAM). In the following description, for simplicity and illustrative purposes, the first RAM or volatile memory 112 is referred to as DRAM, and the second RAM or volatile memory 118 is referred to as SRAM. In some examples, for clarity, storage device 106 may include... Figure 1 Additional components not shown. For example, storage device 106 may include a printed circuit board (PCB) to which components of storage device 106 are mechanically attached, and the PCB includes conductive traces for electrically interconnecting components of storage device 106, etc. In some examples, the physical dimensions and connector configuration of storage device 106 may conform to one or more standard form factors. Some exemplary standard form factors include, but are not limited to, 2.5” data storage devices (e.g., HDDs or SSDs), 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, storage device 106 may be directly coupled (e.g., directly soldered) to the motherboard of host device 104.

[0026] The interface 114 of the 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, PCIe, Non-Volatile Memory Standard (NVMe), OpenCAPI, GenZ, Cache Coherent Interface Accelerator (CCIX), Compute Express Link (CXL), Open Channel SSD (OCSSD), etc. Electrical connections of the interface 114 (e.g., the data bus, the 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 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 storage device 106 includes the NVM 110, which can include a plurality of memory devices. The NVM 110 can be configured to store and / or retrieve data. For example, a memory device of the NVM 110 can receive data and a message instructing the memory device to store the data from the controller 108. Similarly, a memory device of the NVM 110 can receive a message instructing the memory device to retrieve data from the controller 108. In some examples, each of the memory devices can be referred to as a die. In some examples, a single physical chip can include multiple dies (i.e., multiple memory devices). In some examples, each of the memory devices can be configured to store a relatively large amount of data (e.g., 128 MB, 256 MB, 412 MB, 1 GB, 2 GB, 3 GB, 8 GB, 16 GB, 22 GB, 54 GB, 128 GB, 256 GB, 412 GB, 1 TB, etc.).

[0028] In some examples, each memory device 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, a hard disk drive (HDD), and any other type of non-volatile memory device.

[0029] ​The NVM 110 can include a plurality of flash memory devices. The 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 a NAND flash memory device, the flash memory device can be divided into a plurality of blocks, which can be divided into a plurality of pages. Each block of the plurality of blocks within a particular memory device can include a plurality of NAND cells. Rows of NAND 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 NAND flash memory device can be a 2D or 3D device and can be a single level cell (SLC), a multi-level cell (MLC), a triple level cell (TLC), a quad level cell (QLC), or other higher iteration number of level cells. The controller 108 can write data to and read data from the NAND flash memory device at a page level and erase data from the NAND flash memory device at a block level.

[0030] A portion of the NVM 110 can be formatted as logical blocks such that a capacity of the NVM 110 is divided into a plurality of zones. Each of the zones includes a plurality of physical or erase blocks of the NVM 110 and each of the erase blocks is associated with a plurality of logical blocks. Each of the logical blocks is associated with a unique LBA or sector. Each of the zones can have a size that is aligned with a capacity of one or more erase blocks of the NVM 110. When the controller 108 receives a command from, such as, the host device 104, the controller 108 can read data from and write data to a plurality of logical blocks associated with a plurality of erase blocks of the NVM 110.

[0031] The storage device 106 includes a power source 111, which can provide power to one or more components of the storage device 106. When operating in a standard mode, the power source 111 can power the one or more components using power provided by an external device, such as the host device 104. For example, the power source 111 can power the one or more components using power received from the host device 104 via the interface 114. 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.

[0032] The storage device 106 also includes a volatile memory that can be used by the controller 108 to store information. The volatile memory can include one or more volatile memory devices. In some examples, the controller 108 can use the volatile memory as a cache. For example, the controller 108 can store cached information in the volatile memory until the cached information is written to the NVM 110. Examples of the volatile memory 112 include, but are not limited to, RAM, DRAM 112, SRAM 118, and Synchronous Dynamic RAM (SDRAM (e.g., DDR1, DDR2, DDR3, DDR3L, LPDDR3, DDR4, LPDDR4, DDR5, LPDDR5, etc.)). As shown, the volatile memory can consume power received from the power source 111. Figure 1

[0033] Various types of volatile memory can be used for different access attributes. For example, DRAM 112 can be arranged for longer burst accesses to improve bandwidth (BW) of the same access bus. Alternatively, DRAM 112 can be used for smaller accesses so that random small accesses can have better latency. The controller 108 includes additional optional SRAM and / or embedded MRAM 126. The embedded MRAM 126 is another alternative memory that can be used in another implementation. Similarly, access to the MRAM 126 can be optimized for different design purposes, but the number of embedded MRAM 126 in the SSD controller 108 can be cost sensitive. Thus, how much and which data goes into advanced non-volatile memory and advanced volatile memory will be subject to system tradeoffs. ​

[0034] The storage device 106 includes a controller 108, which can manage one or more operations of the storage device 106. For example, the controller 108 can manage reading data from and / or writing data to the NVM 110 via a toggle mode (TM) bus 128. The controller 108 can include an XOR engine 124. Data can be stored in the DRAM 112, the SRAM 118, or both the DRAM 112 and the SRAM 118. In some embodiments, when the 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.

[0035] The controller 108 can include an XOR engine 124 having logic and / or features to generate XOR parity information. The XOR engine 124 is a type of parity engine and is referred to as an XOR engine for exemplary purposes. However, the XOR engine 124 can include other embodiments of parity engines. XOR parity information can be used to improve the reliability of the storage device 106, such as enabling it to perform data recovery for data that fails to write to or read from the NVM round trip, or to perform data recovery in the event of a power loss. Reliability can be provided by using XOR parity information that is generated or calculated based on data stored to the storage device 106. Data can be written to the NVM 110 through the XOR engine 124. The XOR engine 124 can generate a parity stream to be written to the SRAM 118. The SRAM 118 and the DRAM 112 can each contain a plurality of regions to which data can be written. Data can be transferred from SRAM regions 122a-122n in the SRAM 118 to DRAM regions 116a-116n in the DRAM 112, and vice versa.

[0036] The SRAM device 118 and the DRAM device 112 each individually comprise one or more dies. Each of the one or more dies comprises one or more banks of memory. The bank of memory is comprised of rows and pages. The SRAM 118 in the controller 108 can be logically or physically divided into different SRAM zones or regions 122a-122n for use by the controller 108. Similarly, the DRAM 112 can be logically or physically divided into different DRAM zones or regions 116a-116n for use by the controller 108. The MRAM within the controller 108 can be logically or physically divided into different MRAM zones or regions (not shown). The external attachment to the MRAM is typically vendor specific in structure and access, which is not described here.

[0037] Figure 2 is a block diagram illustrating a method 200 of operating a memory device to execute a read or write command according to one embodiment. The method 200 can be used with the memory system 100 having a host device 104 and a memory device 106 comprising a controller 108. The method 200 can be used with a device having a host device and a memory device comprising a command processor.

[0038] The method 200 begins at operation 250, where the host device writes a command as an entry into a submission queue. At operation 250, the host device can write one or more commands into the submission queue. The command can be a read command or a write command. The host device can comprise one or more submission queues. The host device can write the one or more commands into the submission queue in any order (i.e., a submission order) regardless of the order in which the one or more commands were written in a sequential order (i.e., a sequential processing order).

[0039] In operation 252, the host device writes one or more updated submission queue tail pointers and rings a doorbell or sends an interrupt signal to notify or signal the memory device of the new command ready for execution. If there is more than one submission queue, the host can write the updated submission queue tail pointers and send a doorbell or interrupt signal for each of the submission queues in the submission queue. In operation 254, in response to receiving the doorbell or interrupt signal, the controller of the memory device fetches the command from the one or more submission queues and the controller receives or DMA reads the command.

[0040] In operation 256, the controller processes the command and writes or transfers data associated with the command to the host device memory. The controller can process more than one command at a time. The controller can process the one or more commands in submission order or in order. Processing a write command can include identifying a zone for writing data associated with the command, writing the data to one or more logical block addresses (LBAs) of the zone, and advancing a write pointer of the zone to identify a next available LBA within the zone.

[0041] In operation 258, once the command has been fully processed, the controller writes a completion entry corresponding to the executed command to the completion queue of the host device and moves or updates the CQ head pointer to point to the newly written completion entry.

[0042] In operation 260, the controller generates and sends an interrupt signal or doorbell to the host device. The interrupt signal indicates that the command has been executed and that data associated with the command is available in the memory device. The interrupt signal further informs the host device that the completion queue is ready to be read or processed.

[0043] In operation 262, the host device processes the completion entry. In operation 264, the host device writes the updated CQ head pointer to the storage device and rings the doorbell or sends an interrupt signal to the storage device to free the completion entry.

[0044] Figure 3A A zone namespace (ZNS) 302 view used in a storage device 300 is shown, in accordance with one embodiment. The storage device 300 can present the ZNS 302 view to a host device. Figure 3B A state diagram 350 of the ZNS 302 of the storage device 300 is shown, in accordance with one embodiment. The storage device 300 can be a storage device 106 of the storage system 100 of Figure 1 The storage device 300 can have one or more ZNS 302, and each ZNS 302 can have a different size. In addition to the one or more zone namespaces 302, the storage device 300 can further include one or more regular namespaces. Moreover, the ZNS 302 can be zone block commands (ZBC) for SAS and / or zone device ATA command set (ZAC) for SATA. Host-side zone activity can be more directly related to media activity in the zone drive due to the relationship between possible logical and physical activity.

[0045] In the storage device 300, the ZNS 302 is a quantity of NVM that can be formatted into logical blocks such that the capacity is divided into a plurality of zones 306a-306n (collectively, zones 306). The NVM can be Figure 1The zones 306 each include a number of physical blocks or erase blocks (not shown) of memory cells or NVM 304, and each of the erase blocks is associated with a number of logical blocks (not shown). Each of the zones 306 can have a size that is aligned with the capacity of one or more erase blocks of the NVM or NAND device. When the controller 308 receives a command from, such as, a host device (not shown) or a submission queue of a host device, the controller 308 can read data from and write data to a number of logical blocks associated with a number of erase blocks (EBs) of the ZNS 302. Each of the logical blocks is associated with a unique LBA or sector.

[0046] In one embodiment, the NVM 304 is a NAND device. The NAND device includes one or more dies. Each of the one or more dies includes one or more planes. Each of the one or more planes includes one or more erase blocks. Each of the one or more erase blocks includes one or more word lines (e.g., 256 word lines). Each of the one or more word lines can be addressed in one or more pages. For example, an MLC NAND die can use an upper page and a lower page to reach two bits in each cell of the entire word line (e.g., 16 kB per page). Further, each page can be accessed at a granularity equal to or less than a full page. A controller can frequently access NAND at a user data granularity LBA size of 512 bytes. Thus, as referenced in the description below, a NAND location is equal to a granularity of 512 bytes. Thus, the LBA size is 512 bytes and the page size of two pages of MLC NAND is 16 KiB, which results in 32 LBAs per word line. However, the NAND location size is not intended to be limiting and is used as an example only.

[0047] As data is written to the erase blocks, one or more logical blocks are correspondingly updated within the zones 306 to track the location of the data within the NVM 304. Data can be written to one zone 306 at a time until the zone 306 is full, or to multiple zones 306 such that multiple zones 306 can be partially full. Similarly, as data is written to a particular zone 306, the data can be written to multiple erase blocks in order of NAND locations or one block at a time per word line until moving to an adjacent block (i.e., writing to a first erase block until the first erase block is full before moving to a second erase block), or can be written to multiple erase blocks in order of NAND locations or multiple blocks at a time in a parallel manner to partially fill each block (i.e., writing to a first NAND location of each erase block before writing to a second NAND location of each erase block). This sequential programming of each NAND location is a typical non-limiting requirement of many NAND EBs.

[0048] When the controller 308 selects the erase block in which to store data for each partition, the controller 308 will be able to select the erase block at the time of the partition open, or it can select the erase block when the need to fill the first NAND location or word line of that particular erase block is reached. This can be more differentiated when using the above described method of completely filling an erase block before starting the next one. The controller 308 can use the time difference to select a more desirable erase block on a just-in-time basis. The decision of which erase block to allocate and assign to each partition and its contiguous LBAs can be happening at all times within the controller 308 for zero or more parallel partitions.

[0049] Each of the partitions 306 is associated with a zone start logical block address (ZSLBA) or zone start sector. The ZSLBA is the first available LBA in the partition 306. For example, the first partition 306a is associated with a ZSLBA, the second partition 306b is associated with a ZSLBA, the third partition 306c is associated with a ZSLBA, the fourth partition 306d is associated with a ZSLBA, and the nth partition 306n (i.e., the last partition) is associated with a ZSLBA. Each partition 306 is identified by its ZSLBA and is configured to receive sequential writes (i.e., data is written to the NVM 110 in the order in which write commands are received). a b c d n Each partition 306 is identified by its ZSLBA and is configured to receive sequential writes (i.e., data is written to the NVM 110 in the order in which write commands are received).

[0050] When data is written to a partition 306, the write pointer 310 is advanced or updated to point to or indicate the next available block in the partition 306 for writing data, in order to track the next write start point (i.e., the completion point of a previous write equals the start point of a subsequent write). Thus, the write pointer 310 indicates where a subsequent write to the partition 306 will start. The subsequent write command is a "partition append" command, where the data associated with the subsequent write command is appended to the partition 306 at the location indicated by the write pointer 310 as the next start point. An ordered list of LBAs within the partition 306 can be stored for write ordering. Each partition 306 can have its own write pointer 310. Thus, when a write command is received, the partition is identified by its ZSLBA and the write pointer 310 determines the location within the identified partition where the write of data starts.

[0051] Figure 3B The following is shown for a single partition 306, but the same applies to each of the partitions 306. Figure 3A ​​​​ZNS 302. In the state diagram 350, each zone can be in a different state, such as empty, open, full, or offline. When a zone is empty, the zone has no data (i.e., none of the erase blocks in the zone currently store data), and the write pointer is at the ZSLBA (i.e., WP = 0). An empty zone will switch to an open and active zone once a write is scheduled to the zone or a zone open command is issued by the host. Zone management (ZM) commands can be used to move a zone between the zone open and zone closed states (both active states). If a zone is active, the zone includes open blocks that can be written to, and the host can be provided a description of the recommended time in the active state. The controller 308 includes the ZM. Zone metadata can be stored in the ZM and / or the controller 308.

[0052] The term“write” includes programming user data on 0 or more NAND locations in an erase block and / or partially filled NAND locations in an erase block when user data has not filled all available NAND locations. The term“write” can further include moving a zone to full due to internal drive processing needs (open block data retention issues due to error bits accumulating faster on open erase blocks), the storage device 300 closing or filling zones due to resource limitations (like too many open zones to track or defect states found), or the host device closing zones due to issues such as no more data to send to the drive, the computer shutting down, error processing on the host, limited host resources for tracking, and the like.

[0053] An active zone can be open or closed. An open zone is an empty or partially filled zone that is ready to write and has currently allocated resources. Data received from the host device with a write command or zone append command can be programmed to open erase blocks that are not currently filled with previous data. A closed zone is an empty or partially filled zone that is not currently receiving writes continuously from the host. Moving a zone from open to closed allows the controller 308 to reallocate resources to other tasks. These tasks can include, but are not limited to, other open zones, other regular non-zone areas, or other controller needs.

[0054] In the open and closed zones, the write pointer points to a location in the zone between the ZSLBA and the end of the last LBA of the zone (i.e., WP > 0). The active zone can switch between the open and closed states according to a designation by the ZM or when a write is scheduled to the zone. In addition, the ZM can reset the active zone to clear or erase the data stored in the zone so that the zone switches back to the empty zone. Once the active zone is full, the zone switches to the full state. A full zone is a zone that is completely filled with data and has no more available sectors or LBAs for writing data (i.e., WP = zone capacity (ZCAP)). In the full zone, the write pointer points to the end of the writeable capacity of the zone. Read commands for the data stored in the full zone can still be executed.

[0055] The zones can have any total capacity, such as 256 MiB or 512 MiB. However, a small portion of each zone can not be accessible for writing data, but can still be read, such as the portion of each zone that stores XOR data and one or more excluded erase blocks. For example, if the total capacity of the zone 306 is 512 MiB, then the ZCAP can be 470 MiB, which is the capacity available for writing data, and 42 MiB is not available for writing data. The writeable capacity of a zone (ZCAP) is equal to or less than the total zone storage capacity. The storage device 300 can determine the ZCAP of each zone at zone reset. For example, the controller 308 or the ZM can determine the ZCAP of each zone. The storage device 300 can determine the ZCAP of a zone when the zone is reset.

[0056] The ZM can reset a full zone, scheduling erasure of the data stored in the zone so that the zone switches back to the empty zone. When a full zone is reset, although the zone can be marked as an empty zone available for writing, the data of the zone can not be immediately cleared. However, the reset zone must be erased before switching to the open and active zones. The zone can be erased at any time between the ZM reset and the ZM open. When a zone is reset, the storage device 300 can determine the new ZCAP of the reset zone and update the writeable ZCAP attribute in the zone metadata. An offline zone is a zone that cannot have data written to it. The offline zone can be in the full state, the empty state, or in the partially full state without being in the active state.

[0057] As resetting a partition clears or schedules erasure of all data stored in the partition, the need for garbage collection of individual erase blocks is eliminated, improving the overall garbage collection process of the storage device 300. The storage device 300 can mark one or more erase blocks for erasure. When a new partition is to be formed and the storage device 300 anticipates ZM open, then the one or more erase blocks marked for erasure can be erased. The storage device 300 can further decide and create the physical backing of the partition upon erasing the erase block. Thus, once a new partition is open and an erase block is selected to form the partition, the erase block will be erased. Further, each time a partition is reset, a new order of LBAs and write pointers 310 of the partition 306 can be selected so that the partition 306 can tolerate out-of-order receipt of commands. The write pointers 310 can optionally be closed so that commands can be written to any starting LBA indicated by the command.

[0058] Referring back to Figure 3A When a host sends a write command to write data to the partition 306, the controller 308 pulls in the write command and identifies the write command as a write to the newly open partition 306. The controller 308 selects a set of EBs to store data associated with the write command to the newly open partition 306, and the newly open partition 306 switches to the active partition 306. The write command can be a command to write new data or a command to move valid data to another partition for garbage collection purposes. The controller 308 is configured to DMA read new commands from a submission queue populated by the host device.

[0059] In the empty partition 306 that just switched to the active partition 306, because the write pointer 310 indicates the first available logical block associated with the ZS LBA as the first available logical block, data is assigned to the partition 306 and a set of associated sequential LBAs of the partition 306 starting at the ZS LBA. The data can be written to one or more erase blocks or NAND locations allocated for the physical location of the partition 306. After the data associated with the write command is written to the partition 306, the write pointer 310 is updated to point to the next LBA available for host writes (i.e., the completion point of the first write). The write data from the host write command is sequentially programmed into the next available NAND location in the erase block selected for the physical backing of the partition.

[0060] In some embodiments, the NAND location can equal a word line. In such embodiments, the controller can optionally gather several write commands in another memory location, such as DRAM or SRAM, before programming an entire word line made up of multiple write commands. A write command longer than a word line would be able to program a complete word line and fill the complete word line with some data, and the excess data beyond the word line would be used to fill the next word line. For the purposes of this specification, the write data size is equal to 512 bytes of NAND location; however, this is not intended to be limiting.

[0061] For example, the controller 308 can receive a first write command, or first zone append command, to the third zone 306c. The host identifies, in order, which logical block of the zone 306 to use to write data associated with the first command. The data associated with the first command is then written to the first or next available LBA in the third zone 306c as indicated by the write pointer 310, and the write pointer 310 is advanced or updated to point to the next available LBA available for host writes (i.e., WP > 0). If the controller 308 receives a second write command, or second zone append command, to the third zone 306c, the data associated with the second write command is written to the next available LBA in the third zone 306c identified by the write pointer 310. Once the data associated with the second command is written to the third zone 306c, the write pointer 310 is again advanced or updated to point to the next available LBA available for host writes. Resetting the third zone 306c moves the write pointer 310 back to the Z c SLBA (i.e., WP = 0), and the third zone 306c switches to an empty zone.

[0062] Figures 4A-4F A schematic block diagram illustrating generation and / or updating of parity data or XOR data in a second RAM or volatile memory, a first RAM or volatile memory, or both the first RAM or volatile memory and the second RAM or volatile memory, is shown in accordance with various embodiments. Figure 1 The system 100 of FIG. 1 will be described in accordance with Figures 4A-4F For the purposes of the following description, the non-volatile memory unit 110 will be referred to as NVM, the first RAM or volatile memory 112 (i.e., first RAM 1) will be referred to as DRAM, and the second RAM or volatile memory 118 (i.e., second RAM 2) will be referred to as SRAM, for simplicity and exemplary purposes.

[0063] The phrase "XOR or parity data" is used throughout as an example of in-flight data and is not intended to be limiting as other forms of in-flight data can be relevant. In other words, the XOR or parity data discussed in the following examples is in-flight data and can include unwritten host data. Unwritten user data or host data can include smaller lengths or smaller amounts of data (e.g., less than the size of one or more word lines) that are stored in a parking location or buffer until the aggregate size of the data reaches a minimum size (e.g., the size of one or more word lines), at which point the unwritten user data is written to the NVM 110.

[0064] XOR data or parity data that is considered in-flight data is considered a parity buffer and can protect against data loss due to data corruption, error bit transmission, power loss, and other reasons for data loss. For example, XOR data or parity data can be generated or updated in SRAM and temporarily stored in SRAM and / or DRAM before being copied to the NVM 402. Further, for example, in the event of a power failure, a capacitor (not shown) located within the storage device 106, such as Figure 1 , can store a sufficient amount of energy to program data from the DRAM (such as Figure 1 DRAM 112) to the NVM 402 to help prevent data loss.

[0065] In Figures 4A-4F , the parity data or XOR data is represented by "Wxx", where "x" represents the write ID of the associated command. The XOR data can be stored in the SRAM regions 122a-122n or the DRAM regions 116a-116n, or both the SRAM regions 122a-122n and the DRAM regions 116a-116n. The SRAM regions 122a-122n and the DRAM regions 116a-116n can be any suitable size, such as 512 bytes. In the following description, the non-volatile storage unit 110 can be referred to as NVM for simplicity.

[0066] The storage device 106 receives one or more commands from the host device 104 and the one or more commands pass through the controller 108 and the XOR engine 124 within the controller 108 before being written to the NVM 110. As the write data associated with the one or more commands pass through the XOR engine 124, the XOR engine 124 continuously generates or updates the XOR data or parity data associated with the write data of each of the commands and writes the write data associated with each of the commands to a partition in the NVM 110.

[0067] XOR data or parity data will generally be written to SRAM 118 in order from XOR engine 124. The SRAM region or DRAM region can be any suitable size, such as 512 bytes. XOR engine 124 can write directly to DRAM 112, but writing to DRAM 112 is generally slower than writing to SRAM 118, and writing directly to DRAM 112 can cause a performance bottleneck, slowing the entire write process. When a new command is received, controller 108 or XOR engine 124 can erase the data in the SRAM region 122a-122n containing the oldest data. The parity data on SRAM 118 can be copied or re-written to DRAM 112. Data can be written to DRAM regions 116a-116n in order or randomly. In other words, if XOR data or parity data associated with a first partition is stored in a first DRAM region 116a, new XOR data or parity data for the first partition can be re-written in the first DRAM region 116a, or the new XOR data or parity data can be written to a new DRAM region, such as fifth DRAM region 116e.

[0068] In Figure 4A , when a first command to write data to a first partition is received, first parity data WOO or XOR data associated with the first partition, such as first partition 306a of Figure 3A , is written to a first SRAM region 122a. At the same time, user data associated with the first command is written to the first partition. After the first parity data WOO is processed and stored in the first SRAM region 122a, the first parity data WOO is copied or re-written to DRAM 112 in any available DRAM region, such as first DRAM region 116a. While the first parity data WOO is being written to the first DRAM region 116a, when a second command to write data to a second partition is received, second parity data WOl or XOR data associated with the second partition, such as second partition 306b of Figure 3A , is generated in a second SRAM region 112b. At the same time, user data associated with the second command is written to the second partition. After the XOR data or parity data is successfully generated, the data can be copied or re-written to DRAM 112.

[0069] In Figure 4BIn the middle, second parity data W01 or XOR data associated with the second partition is stored in the second SRAM region 122b. The second parity data W01 or XOR data is then copied to an available DRAM region 116a-116n, such as the second DRAM region 116b. Third parity data W02 or XOR data associated with the third partition is generated in the third SRAM region 122c. After the second parity data W01 has been successfully written to the second DRAM region 116b, the third parity data W02 is copied to the third DRAM region 116c. The previous first XOR data W00 is stored in the first SRAM region 122a after being copied to the first DRAM region 116a and has been erased by the controller 108 or XOR engine 124 due to receiving a new write command. The location of the new parity data or XOR data W03 associated with the third command to write to the third partition is generated in the erased first SRAM region 122a.

[0070] In the middle, second parity data W01 or XOR data associated with the second partition is stored in the second SRAM region 122b. The second parity data W01 or XOR data is then copied to an available DRAM region 116a-116n, such as the second DRAM region 116b. Third parity data W02 or XOR data associated with the third partition is generated in the third SRAM region 122c. After the second parity data W01 has been successfully written to the second DRAM region 116b, the third parity data W02 is copied to the third DRAM region 116c. The previous first XOR data W00 is stored in the first SRAM region 122a after being copied to the first DRAM region 116a and has been erased by the controller 108 or XOR engine 124 due to receiving a new write command. The location of the new parity data or XOR data W03 associated with the third command to write to the third partition is generated in the erased first SRAM region 122a. Figure 4C In the middle, second parity data W01 or XOR data associated with the second partition is stored in the second SRAM region 122b. The second parity data W01 or XOR data is then copied to an available DRAM region 116a-116n, such as the second DRAM region 116b. Third parity data W02 or XOR data associated with the third partition is generated in the third SRAM region 122c. After the second parity data W01 has been successfully written to the second DRAM region 116b, the third parity data W02 is copied to the third DRAM region 116c. The previous first XOR data W00 is stored in the first SRAM region 122a after being copied to the first DRAM region 116a and has been erased by the controller 108 or XOR engine 124 due to receiving a new write command. The location of the new parity data or XOR data W03 associated with the third command to write to the third partition is generated in the erased first SRAM region 122a.

[0071] In the middle, second parity data W01 or XOR data associated with the second partition is stored in the second SRAM region 122b. The second parity data W01 or XOR data is then copied to an available DRAM region 116a-116n, such as the second DRAM region 116b. Third parity data W02 or XOR data associated with the third partition is generated in the third SRAM region 122c. After the second parity data W01 has been successfully written to the second DRAM region 116b, the third parity data W02 is copied to the third DRAM region 116c. The previous first XOR data W00 is stored in the first SRAM region 122a after being copied to the first DRAM region 116a and has been erased by the controller 108 or XOR engine 124 due to receiving a new write command. The location of the new parity data or XOR data W03 associated with the third command to write to the third partition is generated in the erased first SRAM region 122a. Figure 4C In the middle, second parity data W01 or XOR data associated with the second partition is stored in the second SRAM region 122b. The second parity data W01 or XOR data is then copied to an available DRAM region 116a-116n, such as the second DRAM region 116b. Third parity data W02 or XOR data associated with the third partition is generated in the third SRAM region 122c. After the second parity data W01 has been successfully written to the second DRAM region 116b, the third parity data W02 is copied to the third DRAM region 116c. The previous first XOR data W00 is stored in the first SRAM region 122a after being copied to the first DRAM region 116a and has been erased by the controller 108 or XOR engine 124 due to receiving a new write command. The location of the new parity data or XOR data W03 associated with the third command to write to the third partition is generated in the erased first SRAM region 122a. Figure 4D In the middle, second parity data W01 or XOR data associated with the second partition is stored in the second SRAM region 122b. The second parity data W01 or XOR data is then copied to an available DRAM region 116a-116n, such as the second DRAM region 116b. Third parity data W02 or XOR data associated with the third partition is generated in the third SRAM region 122c. After the second parity data W01 has been successfully written to the second DRAM region 116b, the third parity data W02 is copied to the third DRAM region 116c. The previous first XOR data W00 is stored in the first SRAM region 122a after being copied to the first DRAM region 116a and has been erased by the controller 108 or XOR engine 124 due to receiving a new write command. The location of the new parity data or XOR data W03 associated with the third command to write to the third partition is generated in the erased first SRAM region 122a.

[0072] If the data has not yet been erased, the existing parity data in SRAM 118 can be updated. New parity data or XOR data for partitioning can be updated in the SRAM areas 122a-122n that currently store the parity data for that partition, without having to pull parity data from DRAM 112. Figure 4E In this process, the updated first parity data W00′ is written to or copied to DRAM 112 in an available DRAM region (such as the fifth DRAM region 116e). The updated first parity data W00′ can also be written to a new DRAM region, such as the fifth DRAM region 116e. Figure 4E As shown, the updated first parity data W00′ can also be written to or copied to a DRAM region currently storing outdated first parity data, such as the first DRAM region 116a storing outdated first parity data W00. Furthermore, the fourth parity data or XOR data W04 in the third SRAM region 122c associated with the fourth partition is written to the sixth SRAM region 116f. Since the third parity data W03 has not yet been erased from the first SRAM region 122a, when a command to write data to the third partition is received, the third parity data W03 is updated to W03′.

[0073] If the data has not yet been erased from SRAM 118, the existing parity data in SRAM 118 can be updated multiple times. Figure 4F When a command to write data to the first partition is received, the first updated W00′ is updated again in the second SRAM region 122b of SRAM 118 to the newly updated first parity data W00′. Since the updated first parity data W00′ has not yet been erased from SRAM 118, it can be updated again in its current SRAM region 122b. Furthermore, writes from SRAM 118 to DRAM 112 can replace existing related parity data that may be outdated stored in DRAM regions 116a-116n. For example, the third updated parity data W03′ in the first SRAM region 122a of SRAM 118 can replace the old or outdated third parity data W03 in the fourth DRAM region 116d of DRAM 112. Once a partition is filled with user data, the corresponding parity data or XOR data stored in SRAM or DRAM can be written to the designated XOR die in the associated partition.

[0074] Figures 5A-5B Schematic diagrams 500 and 550 respectively illustrate the updating of in-flight data (such as parity data or XOR data) in a storage device over time according to various implementation schemes.Figures 5A-5B The storage device can be Figure 1 Storage device 106. As in the example above, parity data will be used as an example of in-flight data. The times used below are representative and can occur over seconds or minutes. Write commands for the first partition are shown as horizontal stripes, and write commands for the second partition are shown as vertical stripes. For example, first write command 502 is for the first partition, and second write command 510 is for the second partition.

[0075] exist Figure 5A In schematic diagram 500, the controller includes three available controller RAM or buffer areas 504a, 504b, and 504c for storing host write commands, and one available parity RAM or buffer area 506 for storing parity data. The controller buffer areas 504a, 504b, and 504c, and the parity buffer area 506 can be... Figure 1 Any SRAM regions 122a-122n. Controller buffer regions 504a, 504b, and 504c store data not yet written to the NVM. The storage device also includes two available RAM regions 508a and 508b for parity data storage, each region corresponding to a partition, such that the first RAM region 508a corresponds to the first partition, and the second RAM region 508b corresponds to the second partition. The number of regions listed above for each component is not intended to be limiting, but rather to provide examples of possible implementations.

[0076] At time 1, the controller receives a first host write command 502 to write data to the first partition. The data from the first host write command 502 is temporarily stored in the first controller region 504a. The data from the first host write command 502 is then written to the NVM (such as...). Figure 1 Before or during the NVM 110, XOR engines (such as...) Figure 1 The XOR engine 124) in the parity buffer area 506 (such as Figure 1 The first parity data for the first host write command 502 for the first partition is generated in the SRAM region 122a).

[0077] At time 2, the controller receives a second host write command 510 to write data to the second partition. The data from the second host write command 510 is temporarily stored in the second controller region 50ba. Before or during the writing of the data from the second host write command 510 to the NVM, the XOR engine 124 generates second parity data for the second host write command 510 to the second partition in the parity buffer region 506. The first parity data previously in the parity buffer region 506 is copied from the controller buffer to the RAM region 508a. The RAM region 508a may be... Figure 1 The first DRAM region 116a.

[0078] At time 3, the controller receives a third host write command 518 to write data to the first partition. The data from the third host write command 505 is temporarily stored in the third controller region 504c. Before or during the writing of the data from the third host write command 518 to the NVM, the XOR engine 124 generates third parity data for the third host write command 518 for the first partition in the parity buffer region 506. At time 2, the first parity data written to RAM region 508a is copied to the parity buffer region 506. The parity buffer region 506 includes the first parity data for the first host write command 502 for the first partition and the third parity data for the third host write command 518 for the first partition. At time 3, the second parity data previously in the parity buffer region 506 for the second host write command 510 for the second partition is copied from the controller buffer to RAM region 508b.

[0079] exist Figure 5B In schematic diagram 550, the controller includes three available controller RAM or buffer areas 534a, 534b, and 534c for host write commands, and one available parity RAM or buffer area 536 for parity data. The controller buffer areas 534a, 534b, and 534c, and the parity buffer area 536 can be... Figure 1 Any SRAM regions 122a-122n. Controller buffer regions 534a, 534b, and 534c store data not yet written to the NVM. The storage device also includes two available RAM regions 538a and 538b for parity data storage, each region corresponding to a partition, such that the first RAM region 538a corresponds to the first partition, and the second RAM region 538b corresponds to the second partition. The number of regions listed above for each component is not intended to be limiting, but rather to provide examples of possible implementations.

[0080] At time 1, the controller receives a first host write command 532 to write data to the first partition. The data for the first host write command 532 is temporarily stored in the first controller buffer area 534a. Before or during the writing of the data for the first host write command 532 for the first partition to the NVM, the XOR engine 124 generates first parity data for the first host write command 532 for the first partition in the parity buffer area 536.

[0081] At time 2, the controller receives a second host write command 540 to write data to the second partition. The data for the second host write command 532 is temporarily stored in the second controller buffer area 534b. Because the third controller buffer area 534c is not stored or populated with data, the XOR engine 124 has not yet generated the second parity data for the second host write command 540 at time 2, as the next received host write command may need to write data to the first partition. Therefore, by retaining the first parity data in the parity buffer area 536, if the next received host write command needs to write data to the first partition, the storage device will be able to generate the parity data for the first partition in the parity buffer area 536 without pulling parity data from the RAM area 538a.

[0082] At time 3, the controller receives a third-host write command 548 to write data to the first partition. The data for the third-host write command 532 is temporarily stored in the first controller buffer area 534c. Before or during the writing of the data for the first partition by the third-host write command 548 to the NVM, the XOR engine 124 generates third parity data for the first partition's third-host write command 532 in the parity buffer area 536. The parity buffer area 536 includes both the first parity data for the first partition's first-host write command 532 and the third parity data for the first partition's third-host write command 548.

[0083] At time 4, the controller receives a fourth host write command 556 to write data to the second partition. Since controller buffers 534a, 534b, and 534c are currently storing data, the parity data (first parity data and third parity data) for the first partition in parity buffer 536 is copied to RAM region 538a. Throughout times 1 to 3, previous write commands (such as first host write command 532) in the first controller buffer 534a have been successfully written to the NVM, and the data in the first controller buffer 534a can be overwritten by data from new host write commands (such as fourth host write command 556). The data of fourth host write command 556 is written to the first controller buffer 534a. Before or during the writing of the data of fourth host write command 556 for the second partition to the NVM, XOR engine 124 generates both the second parity data for second host write data 540 for the second partition and the fourth parity data for fourth host write command 556 for the second partition in parity buffer 536.

[0084] In comparison, Figure 5B The diagram 550 shows the ratio of the number of times data is transferred or copied to the parity buffer area to the number of times data is transferred or copied from the parity buffer area to the RAM area. Figure 5A The number of times the diagram 500 is less. Because transferring data to and from the parity buffer to the RAM area takes time, therefore... Figure 5B The schematic diagram 550 can be compared to Figure 5A The diagram illustrates a faster and more efficient way to operate.

[0085] To prevent data loss on the drive, parity data is created using an XOR engine. This parity data is then written from the XOR engine to SRAM. Parity data can also be written to DRAM, pulled from DRAM into SRAM for updates, or updated within SRAM via new write commands from the XOR engine related to the same parity data. This improves the efficiency of updating parity information, allowing for higher data transfer rates. Since SRAM is faster but more expensive, and DRAM is slower but cheaper, the use of both DRAM and SRAM is better optimized, reducing any DRAM access penalties. Furthermore, because parity data already generated for a partition can be pulled from DRAM into SRAM for updates, it is not necessary to generate entirely new parity or XOR data each time, reducing the amount of time spent backing up or protecting user data.

[0086] In one embodiment, the storage device includes a non-volatile memory cell. The capacity of the non-volatile memory cell is divided into multiple partitions. The non-volatile memory cell includes multiple dies, each of the multiple dies including multiple erase blocks. The storage device further includes a first volatile memory cell, a controller coupled to the non-volatile memory cell and the first volatile memory cell, and a controller including a second volatile memory cell. The controller is configured to: receive a command to write data to one or more partitions, generate first parity data for the first partition in the second volatile memory cell, and copy the first parity data for the first partition from the second volatile memory cell to the first volatile memory cell. The controller is also configured to: copy second parity data for the second partition from the first volatile memory cell to the second volatile memory cell, update the second parity data for the second partition in the second volatile memory cell, and update the first parity data for the first partition in the second volatile memory cell.

[0087] The controller is configured to erase first parity data and second parity data from a second volatile memory. When the controller buffer of the second volatile memory cell is full, the first parity data for the first partition is copied from the second volatile memory cell to the first volatile memory cell, the controller buffer temporarily storing data to be written to the non-volatile memory cell. The controller is further configured to write data associated with a first command to the first partition, while simultaneously generating first parity data for the first partition. The controller is further configured to write data associated with a second command to the second partition, while simultaneously updating the second parity data for the second partition. The non-volatile memory cell is a NAND memory cell. The controller includes an XOR engine. The XOR engine is configured to: generate the first parity data for the first partition in the second volatile memory cell, update the second parity data for the second partition in the second volatile memory cell, and update the first parity data for the first partition in the second volatile memory cell.

[0088] In another embodiment, the storage device includes a non-volatile memory cell. The capacity of the non-volatile memory cell is divided into multiple partitions. The non-volatile memory cell includes multiple dies, each of the multiple dies including multiple erase blocks. The storage device further includes a first volatile memory cell, a controller coupled to the non-volatile memory cell and the first volatile memory cell, and a controller including a second volatile memory cell. The controller is configured to: receive a first command to write data to the first partition in the non-volatile memory cell, generate first parity data for the data associated with the first command, and simultaneously write the data associated with the first command to the first partition, wherein the first parity data is stored in the second volatile memory cell. The controller is also configured to: receive a second command to write data to the second partition in the non-volatile memory cell, copy second parity data associated with the second partition from the first volatile memory cell to the second volatile memory cell, update the second parity data with the data associated with the second command, and simultaneously write the data associated with the second command to the second partition.

[0089] The controller is further configured to copy first parity data from the second volatile memory cell to the first volatile memory cell once the controller buffer of the second volatile memory cell is full, the controller buffer temporarily storing data to be written to the non-volatile memory cell. The controller further includes an XOR engine. The XOR engine is configured to generate first parity data and update second parity data. The first volatile memory cell is a DRAM cell, and the second volatile memory cell is an SRAM cell. The first non-volatile cell is a NAND memory cell. The controller is further configured to copy second parity data from the second volatile memory cell to the first volatile memory cell once the second parity data is generated. The controller is further configured to: receive a third command to write data to a first partition in the non-volatile memory cell, update the first parity data in the second volatile memory cell with data associated with the second command, and simultaneously write the data associated with the second command to the second partition. The controller is also configured to copy the first parity data from the second volatile memory unit to the first volatile memory unit once the first parity data is updated.

[0090] In another embodiment, the storage device includes non-volatile memory cells. The capacity of the non-volatile memory cells is divided into multiple partitions. The non-volatile memory cells include multiple dies, each of the multiple dies including multiple erase blocks. The storage device further includes DRAM cells, a controller coupled to the non-volatile memory cells and the DRAM cells, and a controller including SRAM cells. The controller is configured to: receive a first command to write data to a first partition in the non-volatile memory cells, update first parity data at a first location in the SRAM cells with data associated with the first command, and simultaneously write the data associated with the first command to the first partition. The controller is also configured to: receive a second command to write data to a second partition in the non-volatile memory cells, copy the updated first parity data from the SRAM cells to the DRAM cells, and simultaneously copy second parity data associated with the second partition from the DRAM cells to a second location in the SRAM cells. The controller is also configured to update the second parity data with data associated with the second command, and simultaneously write the data associated with the second command to the second partition. The controller is also configured to: receive a third command to write data to a third partition in a non-volatile memory cell, erase the updated first parity data from a first location in an SRAM cell, generate third parity data in a first location in an SRAM cell, and simultaneously write the data associated with the third command to the first partition.

[0091] The controller is configured to copy updated second parity data from the SRAM cell to the DRAM cell when erasing the updated first parity data and generating third parity data. The controller includes a parity engine configured to generate and update parity data for the controller. When the controller buffer of the SRAM cell is full, the updated first parity data is copied from the SRAM cell to the DRAM cell, the controller buffer temporarily storing data to be written to the non-volatile memory cell. The controller is further configured to copy the third parity data from the SRAM cell to the DRAM cell after generating the third parity data. The controller is further configured to: receive a fourth command to write data to a first partition in the non-volatile memory cell, copy the first parity data from the DRAM cell to the SRAM cell, and simultaneously copy the third parity data associated with the third partition from the SRAM cell to a second location in the DRAM cell. The controller also updates the first parity data with the data associated with the fourth command and simultaneously writes the data associated with the fourth command to the first partition.

[0092] While the foregoing describes embodiments of this disclosure, other and additional embodiments of this disclosure may be contemplated without departing from the basic scope of this disclosure, the scope of which is defined by the appended claims.

Claims

1. A storage device, the storage device comprising: A non-volatile memory cell, wherein the capacity of the non-volatile memory cell is divided into multiple partitions, and wherein the non-volatile memory cell includes multiple dies, each of the multiple dies including multiple erase blocks; First volatile memory unit; and A controller, coupled to the non-volatile memory unit and the first volatile memory unit, the controller including a second volatile memory unit, wherein the controller is configured to: Receive a command to write data to one or more of the plurality of partitions; First parity data for the first partition is generated in the second volatile memory unit; Upon receiving a first new command to write the first data to the second partition, the second parity data for the second partition is copied from the first volatile memory unit to the second volatile memory unit. The second parity data used for the second partition stream is updated to the updated second parity data in the second volatile memory unit; Upon receiving a second new command to write the second data to the first partition, the first parity data used for the first partition is updated to the updated first parity data in the second volatile memory unit. as well as In response to updating the first parity data, the updated first parity data is copied from the second volatile memory unit to the first volatile memory unit.

2. The storage device of claim 1, wherein the controller is further configured to erase the first parity data and the second parity data from the second volatile memory.

3. The storage device of claim 1, wherein when the controller buffer of the second volatile memory cell is filled, the updated first parity data for the first partition is copied from the second volatile memory cell to the first volatile memory cell, and the controller buffer temporarily stores data to be written to the non-volatile memory cell.

4. The storage device of claim 1, wherein the controller is further configured to write the first data to the first partition and simultaneously generate the first parity data for the first partition.

5. The storage device of claim 1, wherein the controller is further configured to write the second data to the second partition while updating the second parity data for the second partition; and In response to updating the second parity data, the updated second parity data is copied from the second volatile memory cell to the first volatile memory cell.

6. The storage device of claim 1, wherein the non-volatile storage cell is a NAND memory cell, and wherein the controller includes an XOR engine.

7. The storage device of claim 6, wherein the XOR engine is configured to: generate the first parity data for the first partition in the second volatile memory cell; Update the second parity data for the second partition in the second volatile memory cell; and The first parity data for the first partition is updated in the second volatile memory unit.

8. A storage device, the storage device comprising: A non-volatile memory cell, wherein the capacity of the non-volatile memory cell is divided into multiple partitions, and wherein the non-volatile memory cell includes multiple dies, each of the multiple dies including multiple erase blocks; First volatile memory unit; and A controller, coupled to the non-volatile memory unit and the first volatile memory unit, the controller including a second volatile memory unit, wherein the controller is configured to: Receive a first command to write first data to the first partition of the plurality of partitions in the non-volatile storage unit; Generate first parity data for the first data, and simultaneously write the first data to the first partition, wherein the first parity data is stored in the second volatile memory unit; Receive a second command to write the second data to the second partition in the non-volatile memory unit; Upon receiving the second command, the second parity data associated with the second partition is copied from the first volatile memory unit to the second volatile memory unit; Update the second parity data with the second data, and simultaneously write the second data to the second partition; as well as In response to updating the second parity data, the updated second parity data is copied from the second volatile memory cell to the first volatile memory cell.

9. The storage device of claim 8, wherein the controller is further configured to copy the first parity data from the second volatile memory cell to the first volatile memory cell once the controller buffer of the second volatile memory cell is filled, the controller buffer temporarily storing data to be written to the non-volatile memory cell.

10. The storage device of claim 8, wherein the controller further includes an XOR engine, and wherein the XOR engine is configured to generate the first parity data and update the second parity data.

11. The storage device of claim 8, wherein the first volatile memory cell is a DRAM cell.

12. The storage device of claim 8, wherein the second volatile memory cell is an SRAM cell.

13. The storage device of claim 8, wherein the non-volatile storage cell is a NAND memory cell.

14. The storage device of claim 8, wherein the controller is further configured to: Receive a third command to write third data into the first partition in the non-volatile memory unit; In the second volatile memory cell, the first parity data is updated with the third data, and simultaneously the third data is written to the first partition; and Once the first parity data is updated, the updated first parity data is copied from the second volatile memory unit to the first volatile memory unit.

15. A storage device, the storage device comprising: A non-volatile memory cell, wherein the capacity of the non-volatile memory cell is divided into multiple partitions, and wherein the non-volatile memory cell includes multiple dies, each of the multiple dies including multiple erase blocks; DRAM unit; and A controller, coupled to the non-volatile memory cell and the DRAM cell, the controller including an SRAM cell, wherein the controller is configured to: Receive a first command to write data to the first partition of the plurality of partitions in the non-volatile storage unit; The first parity data is updated at a first location in the SRAM cell with the data associated with the first command, and at the same time the data associated with the first command is written to the first partition; Receive a second command to write data to the second partition in the non-volatile storage unit; The updated first parity data is copied from the SRAM cell to the DRAM cell, and at the same time, the second parity data associated with the second partition is copied from the DRAM cell to the second location in the SRAM cell. The second parity data is updated with the data associated with the second command, and the data associated with the second command is simultaneously written to the second partition; Receive a third command to write data to the third partition in the non-volatile memory unit; Erase the updated first parity data from the first location in the SRAM cell; as well as Third parity data is generated in the first location of the SRAM cell, and the data associated with the third command is simultaneously written to the first partition.

16. The storage device of claim 15, wherein the controller is further configured to copy the updated second parity data from the SRAM cell to the DRAM cell when the updated first parity data is erased and the third parity data is generated.

17. The storage device of claim 15, wherein the controller includes a parity engine configured to generate and update parity data for the controller.

18. The storage device of claim 15, wherein when the controller buffer of the SRAM cell is filled, the updated first parity data is copied from the SRAM cell to the DRAM cell, and the controller buffer temporarily stores data to be written to the non-volatile memory cell.

19. The storage device of claim 15, wherein the controller is further configured to: copy the third parity data from the SRAM cell to the DRAM cell after generating the third parity data.

20. The storage device of claim 15, wherein the controller is further configured to: Receive a fourth command to write data to the first partition in the non-volatile storage unit; The first parity data is copied from the DRAM cell to the SRAM cell, and simultaneously the third parity data associated with the third partition is copied from the SRAM cell to a second location in the DRAM cell; and The first parity data is updated with the data associated with the fourth command, and the data associated with the fourth command is simultaneously written to the first partition.

Images