Block state parity data in memory

Abstract

The invention relates to block state parity data in memory. Apparatuses, systems, and methods for block state parity data are described. An example method includes storing block state data associated with at least one block of non-volatile memory within a controller, the block state data indicating a state of the at least one block of memory. The example method further includes storing parity data corresponding to the block state data. The example method further includes comparing the stored block state data to the parity data prior to writing the block state data to the non-volatile memory.

Description

Technical Field

[0001] Embodiments of the present disclosure relate generally to semiconductor memories and methods, and more particularly, to devices, systems, and methods related to block status parity data. Background Art

[0002] Memory devices are typically provided as internal semiconductor integrated circuits in computers or other electronic systems. There are many different types of memory, including volatile and non-volatile memory. Volatile memory may require power to maintain its data (e.g., host data, error data, etc.), and includes random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and synchronous dynamic random access memory (SDRAM), among others. Non-volatile memory may provide persistent data by retaining stored data when not powered, and may include NAND flash memory, NOR flash memory, and resistance variable memory, such as phase change random access memory (PCRAM), resistive random access memory (RRAM), and magnetoresistive random access memory (MRAM), such as spin torque transfer random access memory (STT RAM), among others.

[0003] The memory device may be coupled to a host (e.g., a host computing device) to store data, commands, and / or instructions for use by the host in operation of a computer or electronic system. For example, during operation of a computing or other electronic system, data, commands, and / or instructions may be transferred between the host and the memory device(s). Summary of the invention

[0004] One aspect of the present disclosure discloses a method for providing parity data associated with block status data, comprising: storing the block status data associated with at least one block of a non-volatile memory in a controller, the block status data indicating a status of the at least one block of the memory; storing the parity data corresponding to the block status data; and comparing the stored block status data with the parity data before writing the block status data to the non-volatile memory.

[0005] Another aspect of the present disclosure discloses a device for providing parity data associated with block status data, comprising: a non-volatile memory comprising a plurality of blocks of memory; and a controller coupled to the non-volatile memory and configured to: store the block status data associated with at least one of the plurality of blocks of the non-volatile memory in a register in the controller, the block status data indicating a state of the at least one block of memory; store the parity data corresponding to the block status data in the controller; compare the stored block status data associated with at least one block of the non-volatile memory with the parity data before writing the block status data to the non-volatile memory; and determine that the at least one block of the non-volatile memory is valid or reload the stored block status data in response to the comparison of the stored block status data with the parity data.

[0006] Another aspect of the present disclosure discloses a device for providing parity data associated with block status data, comprising: a non-volatile memory; and a controller coupled to the memory and configured to cause the device to: store the block status data associated with at least one block of the non-volatile memory in a register in the controller, the block status data indicating a state of the at least one block of memory; store the parity data corresponding to the block status data in the controller; compare the stored block status data in the register with the parity data; receive and store block status data associated with another block of memory in the non-volatile memory; compare the stored block status data in the register with the parity data in the controller in response to receiving an update; and write the stored block status data to the non-volatile memory in response to the block status data matching the parity data. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 An example computing environment including a memory subsystem according to some embodiments of the present disclosure is described.

[0008] Figure 2 is an example memory system including block status parity data according to some embodiments of the present disclosure.

[0009] Figure 3 is a flow chart of an example method including block status parity data according to some embodiments of the present disclosure.

[0010] Figure 4 is a block diagram of an example computer system in which embodiments of the present disclosure may operate. DETAILED DESCRIPTION

[0011] An apparatus, system, and method for block status parity check data in a memory are described. The memory device may be a non-volatile memory device. An example of a non-volatile memory device is a flash memory system. Figure 1 Other examples of non-volatile memory devices are described. A memory device may include physical blocks (eg, sets of data) of memory cells. A memory device may be coupled to a controller within a memory subsystem.

[0012] The memory subsystem may be a memory system, a memory device, a memory module, or a combination thereof. Figure 1 Examples of storage devices and memory modules are described. In general, a host system may utilize a memory subsystem that includes one or more memory components (hereinafter also referred to as a "memory device"). The host system may provide data to be stored at the memory subsystem and may request data to be retrieved from the memory subsystem.

[0013] A memory operation (e.g., read, write, or other memory operation) may be initiated to read data from a memory device of the memory subsystem and / or write data to store data in a memory device of the memory subsystem. A controller of the memory subsystem may store block status data indicating a block status, such as whether each of a plurality of blocks in the memory device is a bad block (e.g., the block is invalid, cannot properly store data, stores invalid data, etc.) or a good block (e.g., the block is valid, stores correct data, still operates properly, etc.). The controller may store an indication of whether one of the plurality of blocks is bad in a register of a latch. The block status data within the register of the controller may be written (e.g., copied) to the memory device so that the memory device also stores data about whether each block is a good block (properly stores data) or a bad block (cannot properly store data). In some examples, an event may cause the latch to store incorrect data and indicate that a good block is a bad block or a bad block is a good block. Such an event may be referred to as a latch reversal event.

[0014] A latch flip event may cause a controller to identify a block of memory as a bad block or invalid block and prevent access to the block of memory, but the block of memory within the non-volatile memory is still "good" or valid. A latch flip event may be caused by a neutron strike. As used herein, the term "neutron strike" refers to the interaction between one or more neutrons and components of a memory device. The components may include, but are not limited to, a memory cell array, latches, and logic circuitry. Errors may include, but are not limited to, changing a memory address stored in a latch or flipping a data bit. A processor coupled on or to the memory device may include an error correction code (ECC) circuitry to correct errors. However, if the number of errors exceeds the ability of the ECC circuitry to correct the errors, the memory device may operate improperly.

[0015] Aspects of the present disclosure address the above and other deficiencies by providing parity data associated with block state data in a register to detect when the block state data in the register is unintentionally changed due to a latch flip event (e.g., due to a neutron strike to the register, for example). The parity data may be used to protect the block state data. The parity data may be stored within a controller, in a location separate from the register within the controller, and / or in several other memory locations. In order to check the validity of the block state data (e.g., an indication of the validity of a block of memory), a parity value may be determined for the block state data and compared to the parity data. In the event that the two values ​​do not match, the block state data may be determined to be erroneous and the previously stored block state data may be reloaded. In the event that the two values ​​match, it may be determined that the block state data is still valid and the block state data may be used (e.g., the block state data is loaded to a memory device to indicate which blocks are used or not used in the memory), and / or a read or write operation may be sent based on the block state data in the register to avoid using a bad block.

[0016] Figure 1 An example computing system 100 is illustrated that includes a memory subsystem 110 according to some embodiments of the present disclosure. The memory subsystem 110 may include media such as one or more non-volatile memory devices (e.g., memory device 130). In other embodiments, the memory subsystem 110 may include volatile memory devices and / or a combination of volatile and non-volatile memory devices.

[0017] The memory subsystem 110 may be a storage device, a memory module, or a hybrid of a storage device and a memory module. Examples of storage devices include solid-state drives (SSDs), flash drives, universal serial bus (USB) flash drives, embedded multimedia controller (eMMC) drives, universal flash storage (UFS) drives, secure digital (SD) cards, and hard disk drives (HDDs). Examples of memory modules include dual in-line memory modules (DIMMs), small outline DIMMs (SO-DIMMs), and various types of non-volatile dual in-line memory modules (NVDIMMs).

[0018] Computing system 100 may be a computing device such as a desktop computer, a laptop computer, a server, a network server, a mobile device, a vehicle (e.g., an airplane, a drone, a train, a car, or other transportation), an Internet of Things (IoT)-enabled device, an embedded computer (e.g., a computer included in a vehicle, industrial equipment, or a networked business device), or such a computing device that includes a memory and a processing device.

[0019] The computing system 100 may include a host system 120 coupled to one or more memory subsystems 110. In some embodiments, the host system 120 is coupled to memory subsystems 110 of different types. Figure 1 An example of a host system 120 coupled to one memory subsystem 110 is illustrated. As used herein, "coupled to" or "coupled with" generally refers to a connection between components, which can be an indirect communication connection or a direct communication connection (e.g., without intervening components), whether wired or wireless, including connections such as electrical connections, optical connections, magnetic connections, and the like.

[0020] The host system 120 may include a processor chipset and a software stack executed by the processor chipset. The processor chipset may include one or more cores, one or more caches, a memory controller (e.g., an SSD controller), and a storage protocol controller (e.g., a PCIe controller, a SATA controller). The host system 120 uses the memory subsystem 110, for example, to write data to the memory subsystem 110 and read data from the memory subsystem 110.

[0021] The host system 120 may be coupled to the memory subsystem 110 via a physical host interface. Examples of the physical host interface include, but are not limited to, a Serial Advanced Technology Attachment (SATA) interface, a Peripheral Component Interconnect Express (PCIe) interface, a Universal Serial Bus (USB) interface, a Fibre Channel, a Serial Attached SCSI (SAS), a Small Computer System Interface (SCSI), a Double Data Rate (DDR) memory bus, a Dual In-line Memory Module (DIMM) interface (e.g., a DIMM slot interface supporting Double Data Rate (DDR)), an Open NAND Flash Interface (ONFI), Double Data Rate (DDR), Low Power Double Data Rate (LPDDR), or any other interface. The physical host interface may be used to transfer data between the host system 120 and the memory subsystem 110. When the memory subsystem 110 is coupled to the host system 120 through a PCIe interface, the host system 120 may further utilize an NVM Express (NVMe) interface to access components (e.g., the memory device 130). The physical host interface may provide an interface for passing control, address, data, and other signals between the memory subsystem 110 and the host system 120 . Figure 1 Memory subsystem 110 is illustrated. In general, host system 120 can access multiple memory subsystems via the same communication connection, multiple separate communication connections, and / or a combination of communication connections.

[0022] The memory device 130 may include any combination of different types of non-volatile memory devices and / or volatile memory devices. Volatile memory devices may be, but are not limited to, random access memory (RAM), such as dynamic random access memory (DRAM) and synchronous dynamic random access memory (SDRAM). Non-volatile memory devices (e.g., memory device 130) may be, but are not limited to, NAND-type flash memory and write-in-place memory. NAND-type flash memory includes, for example, two-dimensional NAND (2D NAND) and three-dimensional NAND (3D NAND).

[0023] Each of the memory devices 130 may include one or more arrays of memory cells. One type of memory cell, such as a single level cell (SLC), may store one bit per cell. Other types of memory cells, such as multi-level cells (MLC), three-level cells (TLC), four-level cells (QLC), and five-level cells (PLC), may store multiple bits per cell. In some embodiments, each of the memory devices 130 may include one or more arrays of memory cells, such as SLC, MLC, TLC, QLC, PLC, or any combination thereof. In some embodiments, a particular memory device may include an SLC portion, an MLC portion, a TLC portion, a QLC portion, or a PLC portion of a memory cell. The memory cells of the memory device 130 may be grouped into pages, which may refer to a logical unit of a memory device used to store data. For some types of memory, such as NAND, pages may be grouped to form blocks.

[0024] Although a non-volatile memory component such as a NAND-type memory (e.g., 2D NAND, 3D NAND) is described, the memory device 130 may be based on any other type of non-volatile memory or storage device, such as read-only memory (ROM), phase-change memory (PCM), self-select memory, other chalcogenide-based memories, ferroelectric transistor random access memory (FeTRAM), ferroelectric random access memory (FeRAM), magnetic random access memory (MRAM), spin transfer torque (STT)-MRAM, conductive bridging RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), non-OR (NOR) flash memory, and electrically erasable programmable read-only memory (EEPROM).

[0025] The memory subsystem controller 115 (or simply controller 115) can communicate with the memory device 130 to perform operations such as reading data, writing data, or erasing data and other such operations at the memory device 130. The memory subsystem controller 115 may include hardware, such as one or more integrated circuits and / or discrete components, buffer memory, or a combination thereof. The hardware may include digital circuitry with dedicated (i.e., hard-coded) logic to perform the operations described herein. The memory subsystem controller 115 may be a microcontroller, dedicated logic circuitry (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), or other suitable processor.

[0026] The memory subsystem controller 115 may include a processing device, which may include one or more processors (e.g., processor 117), configured to execute instructions stored in a local memory 119. In the illustrated example, the local memory 119 of the memory subsystem controller 115 includes an embedded memory configured to store instructions for executing various processes, operations, logic flows, and routines that control the operation of the memory subsystem 110, including handling communications between the memory subsystem 110 and the host system 120.

[0027] In some embodiments, local memory 119 may include memory registers that store memory pointers, fetched data, etc. Local memory 119 may also include read-only memory (ROM) for storing microcode. Figure 1 The example memory subsystem 110 in FIG. 1 has been described as including a memory subsystem controller 115, but in another embodiment of the present disclosure, the memory subsystem 110 does not include a memory subsystem controller 115, but may rely on external control (e.g., provided by an external host, or provided by a processor or controller separate from the memory subsystem).

[0028] In general, the memory subsystem controller 115 may receive commands or operations from the host system 120 and may convert the commands or operations into instructions or appropriate commands to achieve the desired access to the memory device 130. The memory subsystem controller 115 may be responsible for other operations associated with the memory device 130, such as wear leveling operations, garbage collection operations, error detection and error correction code (ECC) operations, encryption operations, cache operations, and address translation between logical addresses (e.g., logical block addresses (LBAs), namespaces) and physical addresses (e.g., physical block addresses, physical media locations, etc.). The memory subsystem controller 115 may further include a host interface circuit system to communicate with the host system 120 via a physical host interface. The host interface circuit system may convert commands received from the host system into command instructions to access the memory device 130, and convert responses associated with the memory device 130 into information for the host system 120.

[0029] The memory subsystem 110 may also include additional circuitry or components not illustrated. In some embodiments, the memory subsystem 110 may include a cache or buffer (e.g., DRAM) and address circuitry (e.g., row decoders and column decoders) that may receive addresses from the memory subsystem controller 115 and decode the addresses to access the memory device 130.

[0030] In some embodiments, memory device 130 includes a local media controller that operates in conjunction with memory subsystem controller 115 to perform operations on one or more memory cells of memory device 130. An external controller (e.g., memory subsystem controller 115) can manage memory device 130 externally (e.g., perform media management operations on memory device 130). In some embodiments, memory device 130 is a managed memory device, which is a raw memory device combined with a local controller (e.g., a local media controller) for media management within the same memory device package. An example of a managed memory device is a managed NAND (MNAND) device.

[0031] In some embodiments, memory subsystem controller 115 includes at least a portion of registers 113. For example, memory subsystem controller 115 may include processor 117 (processing device) configured to execute instructions stored in local memory 119 for using registers 113 to perform the operations described herein.

[0032] The memory subsystem controller 115 includes a register 113 that may be configured to partially or fully store block status data associated with at least one block within the non-volatile memory device 130. The data within the memory device 130 may be stored within multiple physical blocks of memory cells (e.g., a set of data). The controller 115 may store block status data associated with at least one block of memory cells in the non-volatile memory device 130. The status data may indicate the validity of at least one block of memory. For example, the block status data may indicate whether the data within at least one block of memory is valid or invalid, and / or whether the block is able to save data without introducing errors (e.g., a "good" block may store data properly while a "bad" block is prone to errors). The register 113 may store block status data indicating which blocks of memory cells in the non-volatile memory device 130 are valid or invalid. For example, the register 113 may include one or more latches configured to store an indication of whether a block among multiple blocks of memory is a "good" block or a "bad" block. For example, the latch may store "1" for a good block and "0" for a bad block, etc. The block status data in register 113 may be copied to non-volatile memory device 130 (at specific time intervals) Figure 2 ). Although not shown in the accompanying drawings in order not to obscure the drawings Figure 1 1, but registers 113 may include various circuitry to facilitate data storage. For example, registers 113 may include dedicated circuitry in the form of an ASIC, FPGA, state machine, and / or other logic circuitry that may allow registers 113 to store block state data.

[0033] The memory subsystem controller 115 may further include parity data. The parity data may be located in a memory within the controller and / or within a block of memory in the non-volatile memory device 130. The parity data may track block status data of a block of memory cells in the non-volatile memory device 130. The parity data may track which blocks of memory cells in the non-volatile memory device 130 are invalid. For example, the parity data may be stored within the memory subsystem controller 115, in a location within the memory subsystem controller 115 separate from the register 113, or within the non-volatile memory 130. The block status data within the register 113 may be compared with the parity data. For example, a parity value may be determined for the block status data and compared with the parity data. In some examples, the comparison of the block status data with the parity data may occur each time the block status data is to be transferred from the register 113 to the non-volatile memory device 130 or each time data is stored within the register 113. In the event that the parity value of the block status data and the comparison of the parity data determine a match, the block status data can be determined to be valid or accurate and the block status data can be used to determine which blocks to write memory to and / or which blocks to read memory from. Likewise, in the event that the comparison determines a match, the block status data can be copied to the non-volatile memory device 130 so that the non-volatile memory device 130 can also use the block status data to read and / or write data. Although described as being separate from registers 113, in some embodiments, the parity data can be stored partially or entirely within registers 113.

[0034] Figure 2 2 is an example memory system 231 including block status parity data according to some embodiments of the present disclosure. The example memory system 231 may include a memory subsystem controller 215. The memory subsystem controller 215 may store data associated with a non-volatile memory device (e.g., Figure 1 1 and 2. The controller 215 may be used to store the block status data associated with a first portion 230-1 of a block of memory cells and a second portion 230-2 of a block of memory cells in the non-volatile memory device 130 illustrated in FIG. 2. Although only two portions of a block of memory cells are illustrated, embodiments are not limited thereto and an unlimited number of blocks of memory may be within the non-volatile memory device, the status data of which may be partially or fully stored within the controller 215. The status data may indicate the validity of each block of memory cells. For example, the block status data may indicate whether a block is a good data block or a bad data block, such as whether the block is able to properly store data without generating errors or has ceased to function properly.

[0035] The controller 215 may store block status data associated with at least one block of the memory 230-1 and 230-2 in the non-volatile memory device in the register 213 (e.g., similar to Figure 1 230-2). The block status data may indicate whether the block is a good block or a bad block in at least one block of the memory of the first 230-1 or second 230-2 portion of memory. The register 213 may include one or more latches configured to indicate whether each block of memory is a good block or a bad block of the memory 230-1 and 230-2. The controller 215 may also store parity data in at least one block of the memory of the portion of memory 230-1 and 230-2. The parity data may also indicate the validity of the block status data.

[0036] Prior to writing the block status data to the non-volatile memory device, the controller 215 may compare the parity value of the block status data within the register 213 with the parity data. The comparison of the block status data with the parity data may occur whenever the block status data is to be transferred from the register 213 to the non-volatile memory device 230-1, 230-2, whenever data is to be stored within the register 213, and / or whenever data is to be read and / or written to the non-volatile memory device 230-1, 230-2. The block status data may be written to the non-volatile memory device 230-1, 230-2 in response to the block status data matching the parity data. If there is a difference between the block status data in the register 213 and the parity data (e.g., does not match the parity data), the block status data is not written to the non-volatile memory device. Instead, the block status data may be determined to be erroneous and the previously stored block status data may be reloaded. In this manner, block state data may be verified and errors that have been input into the block state data, for example, by a latch flip event, such as a neutron strike, may be removed. A latch flip event may be defined as an event that causes a latch to be accidentally enabled. For example, a latch may flip data within a cell of at least one block of memory 230-1, 230-2. The latch flip event may cause the controller 215 to identify at least one block of memory 230-1 and 230-2 within its registers as a bad block and prevent access to at least one block of memory 230-1 and 230-2 within non-volatile memory, even if at least one block of memory 230-1 and 230-2 within non-volatile memory is still a good block.

[0037] The difference between the block state data and the parity data in register 213 may be an indicator that a latch flip event has occurred. In one example, the latch flip event may be caused by a silicon particle colliding with a neutron within a cell of at least one block of memories 230-1 and 230-2 (e.g., referred to as a neutron strike). The silicon particle may attract charge and change data within at least one block of memories 230-1 and 230-2. In another example, the latch flip event may be caused by an alpha particle colliding with a neutron within a cell of at least one block of memories 230-1 and 230-2. However, the embodiment is not limited thereto, and any event that causes a neutron collision with a cell of at least one block of memories 230-1 and 230-2 may cause a latch flip event.

[0038] Before writing the address to the non-volatile memory, the controller 215 may compare the block status data with the parity data to determine whether the block status data is still valid. If the block status data of at least one block of memories 230-1 and 230-2 within the register does not match the parity data, then this is an indication that at least one block of memories 230-1 and 230-2 is indeed invalid. The controller 215 may then transfer the previously stored block status data (e.g., stored within the OTP memory) to the register 213 and then transfer the block status data to the non-volatile memory devices 230-1, 230-2. However, if the block status data of at least one block of memories 230-1 and 230-2 within the register matches the parity data, then this is an indication that the block status data is valid and can be transferred to the portion of memories 230-1, 230-2 without updating.

[0039] Figure 3 is a flow chart of an example method 360 corresponding to block status parity data according to some embodiments of the present disclosure. The method 360 may be performed by processing logic, which may include hardware (e.g., a processing device, a circuit system, a dedicated logic, a programmable logic, a microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. In some embodiments, the method 360 is respectively performed by Figure 1 and 2 The memory subsystem controllers 115 and 215 of the present invention are executed. Although shown in a particular order or sequence, the order of the processes may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood to be examples only, and the illustrated processes may be performed in a different order, and some processes may be performed in parallel. In addition, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process flows are possible.

[0040] At operation 362, method 360 includes connecting to a non-volatile memory (eg, Figures 1 to 2The memory subsystem controller may store block status data associated with at least one block of non-volatile memory 130, 230-1, 230-2 described in the foregoing description within the memory subsystem controller, the block status data indicating a state of at least one block of memory. The state of at least one block may include whether it is a good block or a bad block. The memory subsystem controller may store block status data associated with at least one block of memory in a non-volatile memory device in a register (e.g., in a register, respectively). Figures 1 to 2 The block status data may indicate a state of at least one block of the memory.

[0041] At operation 364, method 360 includes storing parity data corresponding to the block status data. The parity data may be stored in a controller and / or a memory device. The parity data may track block status data for blocks of memory cells in a nonvolatile memory device. The parity data may track which blocks of memory cells in a nonvolatile memory device are good blocks or bad blocks. The parity data may be stored within a memory subsystem controller, in a location within the memory subsystem controller separate from the registers.

[0042] At operation 366, method 360 includes comparing the stored block status data to the parity data before writing the block status data to the non-volatile memory. The comparison of the block status data to the parity data may occur each time the block status data is to be transferred from the register to the non-volatile memory device or each time data is stored in the register. In the event that the two values ​​do not match, the block status data may be determined to be erroneous and the previously stored block status data may be reloaded, such as by retrieving the previously stored block status data from the OTP memory. In the event that the two values ​​match, it may be determined that the block status data is still valid and the block status data may be used (e.g., the block status data may be loaded to the memory device to indicate which blocks are used or not used in the memory), and / or a read or write operation may be sent based on the block status data in the register to avoid using a bad block.

[0043] Figure 4 An example machine illustrating a computer system 400 in which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed. In some embodiments, the computer system 400 may correspond to a host system (e.g., Figure 1 1) a host system 120 that includes, is coupled to, or utilizes a memory subsystem (e.g., Figure 1In some embodiments, the machine may be connected (e.g., using a network) to other machines in a LAN, an intranet, an extranet, and / or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or a client machine in a cloud computing infrastructure or environment.

[0044] The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a network appliance, a server, a network router, a switch or a bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Furthermore, while a single machine is described, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0045] The example computer system 400 includes a processing device 402, a main memory 404 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) (e.g., synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM)), etc.), a static memory 406 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage system 418, which communicate with each other via a bus 430.

[0046] The processing device 402 represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, or the like. More specifically, the processing device may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor that implements other instruction sets or a processor that implements a combination of instruction sets. The processing device 402 may also be one or more special-purpose processing devices, such as an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), a network processor, or the like. The processing device 402 is configured to execute instructions 426 for performing the operations and stages discussed herein. The computer system 400 may further include a network interface device 408 for communicating over a network 420.

[0047] The data storage system 418 may include a machine-readable storage medium 424 (also referred to as a computer-readable medium) having stored thereon one or more sets of instructions 426 or software embodying any one or more of the methodologies or functionality described herein. The instructions 426 may also reside, completely or at least partially, within the main memory 404 and / or within the processing device 402 during execution by the computer system 400, with the main memory 404 and the processing device 402 also constituting machine-readable storage media. The machine-readable storage medium 424, the data storage system 418, and / or the main memory 404 may correspond to Figure 1 Memory subsystem 110.

[0048] In one embodiment, instructions 426 include instructions to implement functionality using data stored in registers 413. Although machine-readable storage medium 424 is shown as a single medium in the example embodiment, the term "machine-readable storage medium" should be considered to include a single medium or multiple media storing one or more sets of instructions. The term "machine-readable storage medium" should also be considered to include any medium capable of storing or encoding a set of instructions for execution by a machine and causing the machine to perform any one or more methodologies of the present disclosure. Therefore, the term "machine-readable storage medium" should be considered to include, but not limited to, solid-state memory, optical media, and magnetic media.

[0049] Some portions of the foregoing detailed description have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is herein and generally conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulation of physical quantities. Typically, but not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, combined, compared, and otherwise manipulated. It has proven convenient at times, primarily for common usage reasons, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0050] It should be remembered, however, that all of these and similar terms are associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. The present disclosure may be directed to the actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other such information storage systems.

[0051] The present disclosure also relates to an apparatus for performing the operations described herein. This apparatus may be specially constructed for the intended purpose, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. This computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk, including floppy disks, optical disks, CD-ROMs and magneto-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus.

[0052] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various general purpose systems may be used with programs according to the teachings herein, or it may prove convenient to build more specialized equipment to perform the methods. The structures of a variety of these systems will appear as described in the following description. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages ​​may be used to implement the teachings of the present disclosure as described herein.

[0053] The present disclosure may be provided as a computer program product or software that may include a machine-readable medium having instructions stored thereon, which instructions may be used to program a computer system (or other electronic device) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer). In some embodiments, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., computer) readable storage medium, such as a read-only memory ("ROM"), a random access memory ("RAM"), a magnetic disk storage medium, an optical storage medium, a flash memory component, etc.

[0054] In the foregoing description, embodiments of the present disclosure have been described with reference to specific example embodiments thereof. It will be apparent that various modifications may be made to the present disclosure without departing from the broader spirit and scope of the embodiments of the present disclosure as set forth in the appended claims. Accordingly, the description and drawings should be regarded in an illustrative rather than a restrictive sense.

Claims

1. A method for providing parity data associated with block status data, comprising: storing the block status data associated with at least one block of non-volatile memory (130, 230) within the controller (115, 215), the block status data indicating a status of the at least one block of memory (130, 230); storing the parity data corresponding to the block status data; and Prior to writing the block status data to the non-volatile memory (130, 230), the stored block status data is compared to the parity data. 2 . The method of claim 1 , further comprising writing the block status data to the nonvolatile memory in response to the block status data matching the parity data. 3 . The method of claim 1 , further comprising not writing the block status data to the nonvolatile memory in response to the block status data not matching the parity data. 4 . The method of claim 1 , further comprising retrieving previously stored previous block state data from an additional memory device.

5. The method of claim 1, further comprising writing data to the at least one block in response to the block status data and the parity data associated with the at least one block matching.

6. An apparatus for providing parity data associated with block status data, comprising: a non-volatile memory (130, 230) comprising a plurality of blocks of memory (130, 230); and A controller (115, 215) coupled to the non-volatile memory (130, 230) and configured to: storing the block status data associated with at least one of the plurality of blocks of the non-volatile memory (130, 230) in a register (113, 213, 413) in the controller (115, 215), the block status data indicating a status of the at least one block of memory; storing the parity data corresponding to the block status data in the controller (115, 215); comparing the stored block status data associated with at least one block of the non-volatile memory (130, 230) with the parity data before writing the block status data to the non-volatile memory (130, 230); and The at least one block of the nonvolatile memory (130, 230) is determined to be valid or the stored block status data is reloaded in response to a comparison of the stored block status data with the parity data.

7. The apparatus of claim 6, wherein the controller is configured to: receiving an update that the at least one block of memory is invalidated; storing block status data associated with at least one block of the non-volatile memory in the register (113, 213, 413) in the controller; and The stored block state data associated with at least one block of the non-volatile memory and the parity data associated with at least one block of the non-volatile memory are compared.

8. The apparatus of any one of claims 6-7, wherein the controller is configured to write the at least one block of memory to the non-volatile memory in response to the block status data matching the parity data.

9. The apparatus of any one of claims 6-7, wherein the controller is configured to prevent writing of the at least one block of memory to the non-volatile memory in response to the block status data not matching the parity data.

10. The apparatus of any one of claims 6-7, wherein the controller is configured to determine that a latch flip event has occurred in response to an indication that a difference exists between the block status data and the parity data.

11. An apparatus for providing parity data associated with block status data, comprising: Non-volatile memory (130, 230); and A controller (115, 215) coupled to the memory (130, 230) and configured to cause the device to: storing the block status data associated with at least one block of the non-volatile memory (130, 230) in a register (113, 213, 413) in the controller (115, 215), the block status data indicating a status of the at least one block of the memory (130, 230); storing the parity data corresponding to the block status data in the controller (115, 215); comparing the stored block status data in the register (113, 213, 413) with the parity data; receiving and storing block status data associated with another block of memory (130, 230) in the non-volatile memory (130, 230); comparing the stored block status data within the register (113, 213, 413) with the parity data within the controller (115, 215) in response to receiving an update; and The stored block status data is written to the non-volatile memory (130, 230) in response to the block status data matching the parity data.

12. The apparatus of claim 11, wherein: The controller is configured to prevent access to any block of memory determined to be a bad block; and The controller is configured to restore access to any block of memory in response to a match between the block status data and the parity data and the block status data indicating that the any block of memory is a good block.

13. The apparatus of any one of claims 11 to 12, wherein the controller is configured to: receiving an update that the at least one block of memory is invalid; storing block status data associated with the at least one block of the non-volatile memory in the register in the controller; storing parity data associated with the at least one block of memory within the controller; comparing the stored block status data in the register with the parity data; and The stored block state data is reloaded in response to the block state data not matching the parity data.

14. The apparatus of any one of claims 11 to 12, wherein the controller is configured to: storing block status data associated with the at least one block of the non-volatile memory in the register in the controller; storing parity data associated with the at least one block of memory within the controller; comparing the stored block state data associated with the at least one block and the parity data associated with at least one block; comparing the stored block status data within the register with the parity data within the controller; and The stored block status data is written to the non-volatile memory in response to the block status data matching the parity data.

15. The apparatus of any of claims 11-12, wherein the controller is configured to: receive an update that the at least one block of memory is invalid; storing block status data associated with the at least one block of the non-volatile memory in the register in the controller; storing parity data associated with the at least one block of memory within the controller; comparing the stored block status data in the register with the parity data; and The stored block status data is written to the non-volatile memory in response to the block status data matching the parity data.

Images