Managing address access information

Abstract

This disclosure relates to managing address access information. An apparatus can receive a command for an address of a memory array. Based on or in response to the command, the apparatus can read a first set of tag bits from the memory array. The first set of tag bits can indicate access information for a set of addresses including the address. The apparatus can determine a second set of tag bits based on the command and the address. The second set of tag bits can indicate updated access information for the address. The apparatus can generate a codeword based on the first set of tag bits and the second set of tag bits, and can store the codeword in the memory array.

Description

[0001] CROSS-REFERENCE

[0002] This patent application claims priority to U.S. Patent Application No. 17 / 586,534 to Song et al., filed January 27, 2022, entitled “MANAGING ADDRESS ACCESS INFORMATION,” and U.S. Provisional Patent Application No. 63 / 210,897 to Song et al., filed June 15, 2021, entitled “MANAGING ADDRESS ACCESS INFORMATION,” each of which is assigned to the assignee hereof and each of which is hereby expressly incorporated by reference in its entirety. TECHNICAL FIELD

[0003] The technical field relates to managing address access information. BACKGROUND

[0004] Memory devices are widely used in various electronic devices such as computers, user devices, wireless communication devices, cameras, digital displays, and the like. Information is stored by programming memory cells within a memory device into various states. For example, a binary memory cell can be programmed into one of two supported states, often represented by a logic 1 or a logic 0. In some examples, an individual memory cell can support more than two states, any of which can be stored. To access stored information, a component can read or sense at least one stored state in a memory device. To store information, a component can write or program a state in a memory device.

[0005] There are a variety of types of memory devices and memory cells, including magnetic hard disks, random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase change memory (PCM), self- selective memory, sulfide memory technology, and the like. Memory cells can be volatile or non-volatile. Non-volatile memory, such as FeRAM, can maintain their stored logic state for extended periods of time even in the absence of an external power source. Volatile memory devices, such as DRAM, can lose their stored state when disconnected from an external power source. SUMMARY

[0006] A method is described. The method can include receiving a command for an address of a memory array, reading a first set of flag bits from the memory array based at least in part on the command, the first set of flag bits indicating access information for a set of addresses including the address, determining a second set of flag bits based at least in part on the command and the address, the second set of flag bits indicating updated access information for the address, generating a codeword based at least in part on the first set of flag bits and the second set of flag bits, and storing the codeword in the memory array.

[0007] An apparatus is described. The apparatus can include an amplifier component configured to sense a first set of flag bits from a memory array based at least in part on a command for an address of the memory array, the first set of flag bits indicating access information for a set of addresses including the address, a decoder configured to determine a second set of flag bits based at least in part on the command and the address, the second set of flag bits indicating updated access information for the address, an error correction code (ECC) engine configured to generate a codeword based at least in part on the first set of flag bits and the second set of flag bits, and a latch component configured to latch the codeword for storage at the memory array.

[0008] An apparatus is described. The apparatus can include a memory array, and a controller coupled with the memory array, the controller configured to cause the apparatus to receive a command for an address of the memory array, read a first set of flag bits from the memory array based at least in part on the command, the first set of flag bits indicating access information for a set of addresses including the address, determine a second set of flag bits based at least in part on the command and the address, the second set of flag bits indicating updated access information for the address, generate a codeword based at least in part on the first set of flag bits and the second set of flag bits, and store the codeword in the memory array. BRIEF DESCRIPTION OF DRAWINGS

[0009] Figure 1 An example of a system that supports managing address access information is described in accordance with examples as disclosed herein.

[0010] Figure 2 An example of a system that supports managing address access information is described in accordance with examples as disclosed herein.

[0011] Figure 3 An example of an apparatus that supports managing address access information is described in accordance with examples as disclosed herein.

[0012] Figure 4 An example of a process flow that supports managing address access information is described in accordance with examples as disclosed herein.

[0013] Figure 5 An example of a timing diagram that supports managing address access information according to examples as disclosed herein is illustrated.

[0014] Figure 6 An example of a process flow that supports managing address access information according to examples as disclosed herein is illustrated.

[0015] Figure 7 An example of a timing diagram that supports managing address access information according to examples as disclosed herein is illustrated.

[0016] Figure 8 A block diagram of an apparatus that supports managing address access information according to examples as disclosed herein is shown.

[0017] Figure 9 A flow diagram illustrating one or more methods that support managing address access information according to examples as disclosed herein is shown. DETAILED DESCRIPTION

[0018] Some devices, such as memory devices, can manage memory using metadata that provides information about the state of memory cells in the memory. For example, a device can use dirty bits that indicate whether an address (e.g., a column address, a row address) has been accessed (e.g., written, read). The dirty bits can be a subset of tag bits, which can refer to bits that provide state information for the memory. To improve the reliability of the dirty bits, a device can protect the dirty bits using an error correction code (ECC). For example, a device can encode and decode the dirty bits using an ECC engine that is also used for data bits. But the location and size of the ECC engine (e.g., a certain amount of logic gates) can negatively impact the efficiency and latency of the ECC operations for the dirty bits, among other drawbacks.

[0019] According to the techniques described herein, a device can improve the efficiency of ECC operations for tag bits (e.g., tag bits that include dirty bits), among other advantages, by performing ECC operations on at least some of the tag bits (e.g., dirty bits) using a separate ECC engine (relative to the ECC engine used for data bits). The size of the ECC engine for the tag bits (which can be referred to as a tag ECC engine) can be smaller than the size of the ECC engine for the data bits (which can be referred to as a data ECC engine), which can improve the speed of operation of the tag ECC engine relative to the data ECC engine. Additionally or alternatively, the tag ECC engine can be disposed near a memory array that stores the dirty bits, which can reduce latency associated with performing ECC operations on the dirty bits relative to other techniques or configurations.

[0020] The features of the present disclosure are initially described in the context of a system as described with reference to Figure 1 and 2 The features of the present disclosure are initially described in the context of a system as described with reference to Figures 3 to 7Features of the disclosure are described in the context of apparatuses, process flows, and timing diagrams described. Features of the disclosure are further illustrated by and described with reference to apparatus diagrams and flowcharts related to managing address access information as described with reference to Figure 8 and 9 Apparatus diagrams and flowcharts described in relation to managing address access information further illustrate and describe these and other features of the disclosure.

[0021] Figure 1 An example of a system 100 that supports managing address access information in accordance with examples as disclosed herein is illustrated. The system 100 can include a host device 105, a memory device 110, and a plurality of channels 115 coupling the host device 105 and the memory device 110. The system 100 can include one or more memory devices 110, but aspects of the one or more memory devices 110 can be described in the context of a single memory device, such as the memory device 110.

[0022] The system 100 can include portions of an electronic device such as a computing device, a mobile computing device, a wireless device, a graphics processing device, a vehicle, or other system. For example, the system 100 can illustrate aspects of a computer, a laptop computer, a tablet computer, a smartphone, a cellular phone, a wearable device, an internet-connected device, a vehicle controller, etc. The memory device 110 can be a component of the system that can be used to store data for one or more other components of the system 100.

[0023] At least portions of the system 100 can be an example of the host device 105. The host device 105 can be an example of a processor or other circuitry within a device that uses memory to perform processes, such as within a computing device, a mobile computing device, a wireless device, a graphics processing device, a computer, a laptop computer, a tablet computer, a smartphone, a cellular phone, a wearable device, an internet-connected device, a vehicle controller, a system on a chip (SoC), or some other fixed or portable electronic device, among other examples. In some examples, the host device 105 can refer to hardware, firmware, software, or a combination thereof that implements the functionality of the external memory controller 120. In some examples, the external memory controller 120 can be referred to as a host or host device 105.

[0024] Memory device 110 can be an independent device or component operable to provide physical memory addresses / space that can be used or referenced by system 100. In some examples, memory device 110 can be configured to work with one or more different types of host devices. Signaling between host device 105 and memory device 110 can be operable to support one or more of: modulation schemes for modulating signals, various pin configurations for transmitting signals, various form factors for physical packaging of host device 105 and memory device 110, clock signaling and synchronization between host device 105 and memory device 110, timing conventions, or other factors.

[0025] Memory device 110 can be used to store data for components of host device 105. In some examples, memory device 110 can act as a slave or dependent device of host device 105 (e.g., responding to and executing commands provided by host device 105 through external memory controller 120). Such commands can include one or more of write commands for write operations, read commands for read operations, refresh commands for refresh operations, or other commands.

[0026] Host device 105 can include one or more of external memory controller 120, processor 125, basic input / output system (BIOS) component 130, or other components such as one or more peripheral components or one or more input / output controllers. Components of host device 105 can be coupled with each other using bus 135.

[0027] Processor 125 can be used to provide control or other functionality for at least portions of system 100 or at least portions of host device 105. Processor 125 can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or a combination of these components. In such examples, processor 125 can be an example of a central processing unit (CPU), a graphics processing unit (GPU), a general purpose GPU (GPGPU), or a SoC, among other examples. In some examples, external memory controller 120 can be implemented by processor 125 or be a part of the processor.

[0028] BIOS component 130 can be a software component that includes a BIOS operated as firmware that can initialize and run various hardware components of system 100 or host device 105. BIOS component 130 can also manage data flow between processor 125 and various components of system 100 or host device 105. BIOS component 130 can include a program or software stored in one or more of read-only memory (ROM), flash memory, or other nonvolatile storage.

[0029] Memory device 110 can include a device memory controller 155 and one or more memory dies 160 (e.g., memory chips) to support a desired or specified capacity for data storage. Each memory die 160 (e.g., memory die 160-a, memory die 160-b, memory die 160-N) can include a local memory controller 165 (e.g., local memory controller 165-a, local memory controller 165-b, local memory controller 165-N), and a memory array 170 (e.g., memory array 170-a, memory array 170-b, memory array 170-N). Memory array 170 can be a collection of memory cells (e.g., one or more grids, one or more banks, one or more tiles, one or more sections), where each memory cell can be used to store at least one data bit. A memory device 110 that includes two or more memory dies 160 can be referred to as a multi-die memory or a multi-die package, or a multi-chip memory or a multi-chip package.

[0030] Device memory controller 155 can include circuitry, logic, or components that can be used to control operations of memory device 110. Device memory controller 155 can include hardware, firmware, or instructions that enable memory device 110 to perform various operations, and can be used to receive, transmit, or execute commands, data, or control information related to components of memory device 110. Device memory controller 155 can be used to communicate with one or more of external memory controller 120, one or more memory dies 160, or processor 125. In some examples, device memory controller 155 can control operations of memory device 110 described herein in conjunction with local memory controllers 165 of memory dies 160.

[0031] In some examples, memory device 110 can receive data or commands, or both, from host device 105. For example, memory device 110 can receive a write command instructing memory device 110 to store data for host device 105 or a read command instructing memory device 110 to provide data stored in memory dies 160 to host device 105.

[0032] The local memory controller 165 (e.g., local to the memory die 160) can include circuitry, logic, or components that can be used to control operations of the memory die 160. In some examples, the local memory controller 165 can be used to communicate (e.g., receive or transmit data or commands, or both) with the device memory controller 155. In some examples, the memory device 110 can not include the device memory controller 155, and the local memory controller 165 or the external memory controller 120 can perform various functions described herein. Thus, the local memory controller 165 can be used to communicate with the device memory controller 155, with other local memory controllers 165, or directly with the external memory controller 120 or the processor 125, or a combination thereof. Examples of components that can be included in the device memory controller 155 or the local memory controller 165, or both, can include a receiver to receive signals (e.g., from the external memory controller 120), a transmitter to transmit signals (e.g., to the external memory controller 120), a decoder to decode or demodulate received signals, an encoder to encode or modulate signals to be transmitted, or various other circuitry or controllers operable to support the described operations of the device memory controller 155 or the local memory controller 165, or both.

[0033] The external memory controller 120 can be used to enable one or more of transferring information, data, or commands between components of the system 100 or the host device 105 (e.g., the processor 125) and the memory device 110. The external memory controller 120 can translate or interpret communications exchanged between components of the host device 105 and the memory device 110. In some examples, the external memory controller 120 or other components of the system 100 or the host device 105 or functions thereof described herein can be implemented by the processor 125. For example, the external memory controller 120 can be hardware, firmware, or software or some combination thereof implemented by the processor 125 or other components of the system 100 or the host device 105. Although the external memory controller 120 is depicted as being external to the memory device 110, in some examples, the external memory controller 120 or functions thereof described herein can be implemented by one or more components of the memory device 110 (e.g., the device memory controller 155, the local memory controller 165), or vice versa.

[0034] The components of the host device 105 can exchange information with the memory device 110 using one or more channels 115. The channels 115 can be used to support communications between the external memory controller 120 and the memory device 110. Each channel 115 can be an example of a transmission medium that carries information between the host device 105 and the memory device. Each channel 115 can include one or more signal paths or transmission media (e.g., conductors) between terminals associated with the components of the system 100. A signal path can be an example of an electrically conductive path that can be used to carry a signal. For example, a channel 115 can include a first terminal that includes one or more pins or pads at the host device 105 and one or more pins or pads at the memory device 110. A pin can be an example of an electrically conductive input or output point of a device of the system 100, and a pin can be used to function as part of a channel.

[0035] The channels 115 (and associated signal paths and terminals) can be dedicated to transferring one or more types of information. For example, the channels 115 can include one or more command and address (CA) channels 186, one or more clock signal (CK) channels 188, one or more data (DQ) channels 190, one or more other channels 192, or a combination thereof. In some examples, signaling can be transferred on the channels 115 using single data rate (SDR) signaling or double data rate (DDR) signaling. In SDR signaling, one modulation symbol (e.g., a signal level) of a signal can be registered for each clock cycle (e.g., on a rising or falling edge of a clock signal). In DDR signaling, two modulation symbols (e.g., signal levels) of a signal can be registered for each clock cycle (e.g., on both a rising edge and a falling edge of a clock signal).

[0036] In some examples, the CA channels 186 can be used to transfer commands between the host device 105 and the memory device 110, including control information (e.g., address information) associated with the commands. For example, a command carried by the CA channels 186 can include a read command with an address of data that is desired. In some examples, the CA channels 186 can include any number of signal paths (e.g., eight or nine signal paths) used to decode one or more of address or command data. In some examples, the data channels 190 can be used to transfer one or more of data or control information between the host device 105 and the memory device 110. For example, the data channels 190 can transfer information to be written to the memory device 110 (e.g., bidirectional) or information read from the memory device 110.

[0037] The channel 115 can include any number of signal paths, including a single signal path. In some examples, the channel 115 can include multiple individual signal paths. For example, the channel can be x4 (e.g., including four signal paths), x8 (e.g., including eight signal paths), x16 (including sixteen signal paths), etc. In some examples, one or more other channels 192 can include one or more error detection code (EDC) channels. The EDC channels can be used to transmit error detection signals, such as checksums, to improve system reliability. The EDC channels can include any number of signal paths.

[0038] Information stored in the memory device 110 can become corrupted over time, resulting in one or more errors in the data, independent of refresh operations. To improve the reliability of the memory device 110, the memory device 110 can implement an error correction scheme to detect, identify, and correct such errors. For example, prior to storing a set of data bits, the memory device 110 can generate a codeword that can be used by the memory device 110 to detect errors in the codeword, the codeword being comprised of the data bits and corresponding parity bits, using an error correction code. The parity bits can be generated by applying the error correction code to the set of data bits, which can involve inputting the set of data bits into a logic circuit comprised of, for example, a series of XOR logic gates. The memory device 110 can store the set of data bits and the parity bits (collectively referred to as a “codeword”) in memory such that one or more errors in the codeword can be detected (and possibly corrected) during a read operation. For example, the memory device 110 can detect an error in the codeword based on or in response to syndrome bits generated (e.g., during a decoding process) from bits of the codeword stored in memory.

[0039] In some examples, ECC techniques can be used to protect metadata bits, which can be bits that provide information about the memory array. For example, ECC techniques can be used to protect dirty bits, which can indicate the access status of a column (or row) in the memory array. If the memory device 110 operates the memory array as a cache (e.g., for a main memory such as non-volatile memory), the memory device 110 can use the dirty bits to perform an eviction process in which data from the memory array is moved from the cache to the main memory. Other uses of dirty bits are also contemplated and within the scope of the present disclosure. For example, the host device 105 can determine which memory cells to access based on (e.g., as a function of) the access status of those memory cells. The dirty bits can be a subset of tag bits, which can refer to bits that provide state information of the memory array. Other subsets of tag bits can include validity bits, which can indicate the validity status of data stored at an address, and tag address bits, which can indicate cache address information.

[0040] Rather than using a single ECC engine for data bits and dirty bits, which can be inefficient or slow and other drawbacks, the memory device 110 can use separate ECC engines for data bits and dirty bits. For example, the memory device 110 can use a data ECC engine for data bits and a flag ECC engine for dirty bits. The flag ECC engine can be smaller and closer to the memory array relative to the data ECC engine, which can be larger and further away from the memory array storing the data bits and dirty bits, which can improve latency and efficiency. Although described with reference to dirty bits, the techniques described herein can be applied to other types of bits, such as other types of metadata bits.

[0041] In some examples, the techniques described herein can be implemented by a multi-memory device including non-volatile memory (e.g., FeRAM) and volatile memory (DRAM). The device can operate the non-volatile memory as a main memory for storing information and can operate the volatile memory as a cache for the non-volatile memory. Such a configuration can allow the device to benefit from the advantages of non-volatile memory (e.g., non-volatility, permanent storage, high storage capacity, low power consumption) while maintaining compatibility with host devices and other aspects through the volatile memory. The device can manage the operation of the volatile memory using metadata such as dirty bits. To improve the efficiency of ECC operations for the metadata, the device can implement aspects of the techniques described herein.

[0042] Although described with reference to DRAM, the techniques described herein can be implemented for any type of memory and are not limited to the memory technologies described herein.

[0043] The system 100 can include any number of non-transitory computer- readable media that support managing address access information. For example, the host device 105, the external memory controller 120, the memory device 110, or the device memory controller 155 can include or otherwise have access to one or more non-transitory computer-readable media that store instructions (e.g., firmware) for performing the functions attributed herein to the host device 105, the external memory controller 120, the memory device 110, or the device memory controller 155. For example, if executed by the host device 105 (e.g., by the processor 125), by the external memory controller 120, by the memory device 110 (e.g., by the device memory controller 155 or the local memory controller 165), such instructions can cause the host device 105, the external memory controller 120, the memory device 110, or the device memory controller 155 to perform the associated functions as described herein.

[0044] Figure 2Examples of a system 200 that supports managing address access information in accordance with examples as disclosed herein are described. The system 200 can include a host device 205 and a memory sub-system 210. The host device 205 can be a processor or a system on a chip (SoC) that interfaces with an interface controller 215 and other components of an electronic device that includes the system 200. The memory sub-system 210 can store and provide access to electronic information (e.g., digital information, data) for the host device 205. The memory sub-system 210 can include the interface controller 215, a volatile memory 220, and a non-volatile memory 225. In some examples, the interface controller 215, the volatile memory 220, and the non-volatile memory 225 can be included in the same physical package, such as a package 230. However, the interface controller 215, the volatile memory 220, and the non-volatile memory 225 can be disposed on different respective dies (e.g., silicon dies).

[0045] The memory sub-system 210 can be configured to provide the benefits of the non-volatile memory 225 while maintaining compatibility with the host device 205 that supports protocols for different types of memory, such as the volatile memory 220, among other examples. For example, the non-volatile memory 225 can provide advantages (e.g., relative to the volatile memory 220), such as non-volatility, higher capacity, or lower power consumption. However, the host device 205 can be incompatible or inefficiently configured with various aspects of the non-volatile memory 225. For example, the host device 205 can support voltages, access latencies, protocols, page sizes, etc. that are incompatible with the non-volatile memory 225. To compensate for the incompatibilities between the host device 205 and the non-volatile memory 225, the memory sub-system 210 can be configured with the volatile memory 220, which can be compatible with the host device 205 and act as a cache for the non-volatile memory 225. Thus, the host device 205 can use protocols supported by the volatile memory 220 while benefiting from the advantages of the non-volatile memory 225.

[0046] The host device 205 can be configured to interface with the memory sub-system 210 using a first protocol supported by the interface controller 215 (e.g., low power double data rate (LPDDR)). Thus, in some examples, the host device 205 can interface directly with the interface controller 215 and indirectly with the non-volatile memory 225 and the volatile memory 220. In alternative examples, the host device 205 can interface directly with the non-volatile memory 225 and the volatile memory 220. The host device 205 can also interface with other components of an electronic device that includes the system 200. The host device 205 can be or include a SoC, a general purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or it can be a combination of these types of components.

[0047] The interface controller 215 can be configured to interface with the volatile memory 220 and the non-volatile memory 225 on behalf of the host device 205 (e.g., based on or in response to one or more commands or requests issued by the host device 205). For example, the interface controller 215 can facilitate retrieval and storage of data in the volatile memory 220 and the non-volatile memory 225 on behalf of the host device 205. Thus, the interface controller 215 can facilitate data transfer between various subcomponents, such as between the host device 205, at least some of the volatile memory 220, or the non-volatile memory 225. The interface controller 215 can interface with the host device 205 and the volatile memory 220 using a first protocol, and can interface with the non-volatile memory 225 using a second protocol supported by the non-volatile memory 225.

[0048] The non-volatile memory 225 can be configured to store digital information (e.g., data) for an electronic device including the system 200. Accordingly, the non-volatile memory 225 can include one or more arrays of memory cells and a local memory controller configured to operate the arrays of memory cells. In some examples, the memory cells can be or include FeRAM cells (e.g., the non-volatile memory 225 can be FeRAM). The non-volatile memory 225 can be configured to interface with the interface controller 215 using a second protocol that is different than a first protocol used between the interface controller 215 and the host device 205. In some examples, the non-volatile memory 225 can have a longer access operation latency than the volatile memory 220. For example, retrieving data from the non-volatile memory 225 can take longer than retrieving data from the volatile memory 220. Similarly, writing data to the non-volatile memory 225 can take longer than writing data to the volatile memory 220. In some examples, the non-volatile memory 225 can have a smaller page size than the volatile memory 220, as described herein.

[0049] The volatile memory 220 can be configured to operate as a cache for one or more components of, for example, the non-volatile memory 225. For example, the volatile memory 220 can store information (e.g., data) for an electronic device including the system 200. Accordingly, the volatile memory 220 can include one or more arrays of memory cells and a local memory controller configured to operate the arrays of memory cells. In some examples, the memory cells can be or include DRAM cells (e.g., the volatile memory can be DRAM). The non-volatile memory 225 can be configured to interface with the interface controller 215 using a first protocol used between the interface controller 215 and the host device 205.

[0050] In some examples, the volatile memory 220 can have a shorter access operation latency than the non-volatile memory 225. For example, retrieving data from the volatile memory 220 can take less time than retrieving data from the non-volatile memory 225. Similarly, writing data to the volatile memory 220 can take less time than writing data to the non-volatile memory 225. In some examples, the volatile memory 220 can have a larger page size than the non-volatile memory 225. For example, the volatile memory 220 can have a page size of 2 kilobytes (2 kB) and the non-volatile memory 225 can have a page size of 64 bytes (64 B) or 128 bytes (128 B).

[0051] While the non-volatile memory 225 can be a higher density memory as compared to the volatile memory 220, accessing the non-volatile memory 225 can take longer as compared to accessing the volatile memory 220 (e.g., due to different architectures and protocols, among other reasons). Thus, operating the volatile memory 220 as a cache can reduce latency in the system 200. As an example, by retrieving data from the volatile memory 220 rather than from the non-volatile memory 225, an access request for data from the host device 205 can be satisfied relatively quickly. To facilitate operation of the volatile memory 220 as a cache, the interface controller 215 can include a plurality of buffers 235. The buffers 235 can be disposed on the same die as the interface controller 215 and can be configured to temporarily store data for transfer between the volatile memory 220, the non-volatile memory 225, or the host device 205 (or any combination thereof) during one or more access operations (e.g., store and retrieve operations).

[0052] To store data in the memory sub-system 210, the host device 205 can initiate a write operation by transmitting a write command (also referred to as a store request, a store command, or a write request) to the interface controller 215. The write command can target a set of non-volatile memory cells in the non-volatile memory 225. The host device 205 can also provide data to be written to the set of non-volatile memory cells to the interface controller 215. The interface controller 215 can temporarily store the data in the buffer 235-a. After storing the data in the buffer 235-a, the interface controller 215 can transfer the data from the buffer 235-a to the volatile memory 220 or the non-volatile memory 225, or both. In write-through mode, the interface controller 215 can transfer the data to both the volatile memory 220 and the non-volatile memory 225. In write-back mode, the interface controller 215 can transfer the data only to the volatile memory 220 (where the data is transferred to the non-volatile memory 225 during a later eviction process).

[0053] In either mode, the interface controller 215 can identify an appropriate set of one or more volatile memory units in the volatile memory 220 for storing data associated with a write command. To do so, the interface controller 215 can implement a set-associative mapping in which each set of one or more non-volatile memory units in the non-volatile memory 225 can be mapped to a plurality of sets (e.g., rows) of volatile memory units in the volatile memory 220. For example, the interface controller 215 can implement an n-way associative mapping that allows data from a set of non-volatile memory units to be stored in one of n sets of volatile memory units in the volatile memory 220. Accordingly, the interface controller 215 can manage the volatile memory 220 as a cache for the non-volatile memory 225 by referencing the n sets of volatile memory units associated with a target set of non-volatile memory units. While described with reference to a set-associative mapping, the interface controller 215 can manage the volatile memory 220 as a cache by implementing one or more other types of mappings (e.g., direct mappings or associative mappings, among other examples).

[0054] After determining which n sets of volatile memory units are associated with a target set of non-volatile memory units, the interface controller 215 can store data in one or more of the n sets of volatile memory units. Accordingly, subsequent (e.g., following) read commands for data from the host device 205 can be efficiently satisfied by retrieving the data from the lower latency volatile memory 220 instead of the higher latency non-volatile memory 225. The interface controller 215 can determine which of the n sets of volatile memory 220 to store data based on or in response to one or more parameters associated with the data stored in the n sets of volatile memory 220 (e.g., a validity, age, or modification status of the data). Accordingly, a write command by the host device 205 can be satisfied completely (e.g., in write-back mode) or partially (e.g., in write-through mode) by storing the data in the volatile memory 220. To track data stored in the volatile memory 220, the interface controller 215 can store a tag address for one or more sets of volatile memory units (e.g., for each set of volatile memory units) that indicates non-volatile memory units with data stored in a given set of volatile memory units.

[0055] To retrieve data from the memory sub-system 210, the host device 205 can initiate a read operation by transmitting a read command (also referred to as a retrieval request, retrieval command, or read request) to the interface controller 215. The read command can target a set of one or more non-volatile memory cells in the non-volatile memory 225. Upon receiving the read command, the interface controller 215 can check for the requested data in the volatile memory 220. For example, the interface controller 215 can check for the requested data in the n-sets of volatile memory cells that are associated with the target set of non-volatile memory cells. If one of the n-sets of volatile memory cells stores the requested data (e.g., stores data for the target set of non-volatile memory cells), the interface controller 215 can transfer the data from the volatile memory 220 to the buffer 235-a (e.g., in response to determining whether one of the n-sets of volatile memory cells stores the requested data, or one of the n-sets of volatile memory cells stores the requested data, as described with reference to Figure 4 and 5 ). The data can be transmitted to the host device 205.

[0056] Generally, the term “hit” can be used to refer to a situation in which the volatile memory 220 stores data that is targeted by the host device 205. If one or more of the n-sets of volatile memory cells does not store the requested data (e.g., the n-sets of volatile memory cells store data for a set of non-volatile memory cells other than the target set of non-volatile memory cells), the interface controller 215 can transfer the requested data from the non-volatile memory 225 to the buffer 235-a (e.g., in response to determining whether one or more of the n-sets of volatile memory cells does not store the requested data, or one or more of the n-sets of volatile memory cells does not store the requested data, as described with reference to Figure 4 and 5 ). The data can be transmitted to the host device 205. Generally, the term “miss” can be used to refer to a situation in which the volatile memory 220 does not store data that is targeted by the host device 205.

[0057] In a miss case, after passing the requested data to buffer 235-a, interface controller 215 can pass the requested data from buffer 235-a to volatile memory 220, so that subsequent read requests for the data can be satisfied by volatile memory 220 instead of non-volatile memory 225. For example, interface controller 215 can store the data in one of the n sets of volatile memory cells associated with the target set of non-volatile memory cells. But the n sets of volatile memory cells can already be storing data for other sets of non-volatile memory cells. Thus, to preserve this other data, interface controller 215 can pass the other data to buffer 235-b, so that the data can be passed to non-volatile memory 225 for storage. This process can be referred to as "eviction," and the data passed from volatile memory 220 to buffer 235-b can be referred to as "victim" data.

[0058] In some cases, interface controller 215 can pass a subset of the victim data from buffer 235-b to non-volatile memory 225. For example, interface controller 215 can pass one or more subsets of the victim data that have changed since the data was originally stored in non-volatile memory 225. Data that is not consistent between volatile memory 220 and non-volatile memory 225 (e.g., due to updates in one memory but not the other) can be referred to in some cases as "modified" or "dirty" data. In some examples (e.g., if the interface controller is operating in a mode such as write-back mode), dirty data can be data that exists in volatile memory 220 but not in non-volatile memory 225.

[0059] Thus, if volatile memory 220 is full, interface controller 215 can perform an eviction procedure to save data from volatile memory 220 to non-volatile memory 225 (e.g., to make room for new data in volatile memory 220). In some examples, interface controller 215 can perform a "fill" procedure, in which data from non-volatile memory 225 is saved to volatile memory 220. Interface controller 215 can perform a fill procedure in the case of a miss (e.g., to fill up volatile memory 220 with relevant data). For example, in the case of a read miss that occurs when a read command from host device 205 is targeted at data stored in non-volatile memory 225, instead of volatile memory 220, interface controller 215 can retrieve the data requested by the read command (from non-volatile memory 225), and in addition to returning the data to the host device, store the data in volatile memory 220 (e.g., so that the data can be quickly retrieved in the future).

[0060] Accordingly, depending on a hit or miss status of a request (e.g., a read command, a write command) from the host device 205, the memory sub-system 210 satisfies (or “fulfills”) the request using either the volatile memory 220 or the non-volatile memory 225. For example, in the case of a read miss, the non-volatile memory 225 can satisfy a read command from the host device 205, meaning that data returned from the host device 205 can originate from the non-volatile memory 225. And in the case of a read hit, the volatile memory 220 can satisfy a read command from the host device 205, meaning that data returned from the host device 205 can originate from the volatile memory 220. In some examples, a ratio of hits to misses (“hit-miss ratio”) can be relatively high (e.g., a percentage of hits (or “hit rate”) can be approximately 85%, while a percentage of misses (or “miss rate”) can be approximately 15%).

[0061] The memory sub-system 210 can implement the techniques described herein to manage flag bits for the volatile memory 220, the non-volatile memory 225, or both. For example, the memory sub-system 210 can perform ECC operations on data bits using a data ECC engine, and can perform ECC operations on flag bits using a flag ECC engine.

[0062] Figure 3 An example of a device 300 that supports managing address access information according to examples as disclosed herein is described. The device 300 can be an example of the system 100 or the memory device 110 as described with reference to Figure 1 The device 300 can be an example of the system 200 or the memory sub-system 210 as described with reference to Figure 2 The device 300 can include a memory array 305 and an ECC engine 310, which can be an example of a flag ECC engine. The device 300 can use the ECC engine 310 to update flag bits, such as dirty bits, in the memory array 305.

[0063] The memory array 305 can include memory cells arranged in columns and rows, where the memory cells in a row are in different columns. For example, the memory array 305 can include memory cells that store data bits, parity bits, and marker bits such as dirty bits. To illustrate, the memory array can include memory cells that store data bits D0-D13, memory cells that store parity bits for the data bits (denoted as DE0-DE4), memory cells that store dirty bits T0-T3, and memory cells that store parity bits for the marker bits (denoted as TE0-TE2). The memory array 305 can include four columns (CO-C3), each column including four memory cells. For example, column CO can include memory cells that store D0-D3, column CI can include memory cells that store D4-D7, column C2 can include memory cells that store D8-D11, and column C3 can include memory cells that store D12-D15. The memory cells in a column can be in a row. Further, the memory array 305 can have multiple rows associated with the columns. Thus, in one example, the memory array 305 can include memory cells in one row and four columns.

[0064] The configuration of the memory array 305 is for purposes of illustration and is not limiting. Other configurations of the memory array 305 are contemplated and are within the scope of the present disclosure.

[0065] Memory cells can be distinguished from other memory cells by their column address and row address. Thus, each memory cell can be accessed based on (e.g., according to, using) the corresponding address for the memory cell. The device 300 can track which addresses have been accessed (e.g., written, read) by maintaining a set of dirty bits. For example, the device 300 can store dirty bits TO-T3 in the memory array, where TO is a dirty bit for column CO, Tl is a dirty bit for column CI, T2 is a dirty bit for column C2, and T3 is a dirty bit for column C3. A first value (e.g., a logical 0) for a dirty bit can indicate that the corresponding column has not been accessed, while a second value (e.g., a logical 1) for a dirty bit can indicate that the corresponding column has been accessed. Although described with reference to columns, the techniques described herein can additionally or alternatively be implemented for rows of the memory array 305.

[0066] The device 300 can access the memory array 305 using the amplifier components 315, which can be input / output (I / O) amplifiers or other circuitry capable of reading and writing to memory cells of the memory array 305. The amplifier components 315 can be coupled with the memory cells of the memory array 305 via one or more traces (also referred to as conductive lines), such as local data lines. The device 300 can determine which memory cells to access based on (e.g., as a function of) column and row addresses. Data bits from (or for) the memory array 305 can be transferred over a data bus 330, which can be a bidirectional data bus.

[0067] The device 300 can include one or more decoders that decode address information for the memory array 305. For example, the device 300 can include a decoder 320 that can decode address information (e.g., a column address) from a host device and generate a flag bit corresponding to the decoded column address. For example, if the decoder 320 receives address information for column CO (which can be indicated by a command from a host device), the decoder 320 can generate a flag bit set to a logical 1 for column CO. The flag bits generated by the decoder 320 can be referred to as generated flag bits and the flag bits stored by the memory array 305 can be referred to as stored flag bits.

[0068] If the device 300 receives a memory operation command to access one column in the memory array 305, the device 300 can update the stored flag bits in the memory array 305. To update the stored flag bits in the memory array 305, the device 300 can read the stored flag bits using the amplifier components 315 and transfer the stored flag bits to the ECC engine 310. For example, the device 300 can read the stored flag bits TO to T3 using corresponding amplifier components 315 (e.g., amplifier components 5, 10, 15, and 20), which can transfer the stored flag bits TO to T3 to the ECC engine 310. In some examples (e.g., if the device 300 is in an error correction mode), the device 300 can also read the parity bits TE0 to TE2 using the amplifier components 315 (e.g., using amplifier components 25, 26, and 27) and transfer the parity bits TE0 to TE2 to the ECC engine 310.

[0069] Continuing the foregoing example, the device 300 can transfer the generated flag bits from the decoder 320 to the latch 325. The generated flag bits can be based on (e.g., correspond to) the column address indicated by the memory operation command. The latch 325 can be a component capable of latching (e.g., saving) bits of information, such as the generated flag bits and the updated flag bits. The latch 325 can transfer the generated flag bits received from the decoder 320 to the ECC engine 310 for combination with the stored flag bits.

[0070] Thus, the ECC engine 310 can receive and combine the stored flag bits and the generated flag bits. Combining the stored flag bits and the generated flag bits (rather than merely storing the generated flag bits) can allow the device 300 to keep the stored flag bits protected by ECC (as overwriting the stored flag bits with the generated flag bits can disrupt the ECC protection of the associated parity bits). Combining the stored flag bits and the generated flag bits (rather than generating a new codeword based on the generated flag bits alone) can allow the device to preserve the stored flag bits that are not updated by the generated flag bits.

[0071] Although described with reference to the ECC engine 310, other components of the device 300 can combine the stored flag bits with the generated flag bits. For example, a set of multiplexers coupled with the ECC engine 310 and the latch 325 can combine the stored flag bits with the generated flag bits. In some examples, combining the stored flag bits with the generated flag bits can involve one or more logical OR operations. Thus, combining the stored flag bits and the generated flag bits can generate the same quantity of flag bits as the stored flag bits, but generate different values for at least some of the stored flag bits. The quantity of stored flag bits and the quantity of generated flag bits can be the same or different.

[0072] Before combining the stored flag bits with the generated flag bits, the ECC engine 310 can optionally perform an ECC decoding operation on the stored flag bits. For example, the ECC engine 310 can decode the codeword made up of the stored flag bits and the parity bits TE0-TE2 to generate a set of syndrome bits for the codeword. The ECC engine 310 can then use the syndrome bits to detect and correct any errors within the codeword. Thus, the reliability of the stored flag bits can be improved by performing ECC decoding, error detection, and error correction.

[0073] Before combining the stored flag bits with the generated flag bits, a mode of the device 300 can determine (e.g., control) whether the ECC engine 310 performs ECC decoding on the codeword. For example, if the device 300 is in a low-power mode or a low-latency mode, the ECC engine 310 can not perform ECC decoding. As another example, if the device 300 is in a high-power mode or a latency-tolerant mode, the ECC engine 310 can perform ECC decoding.

[0074] After combining the stored flag bits with the generated flag bits, the ECC engine 310 can perform an ECC encoding operation on the combined flag bits. For example, the ECC engine can apply an ECC code (e.g., a Hamming matrix) to the combined flag bits to generate a set of parity bits for the combined flag bits. The combined flag bits and the parity bits for the combined flag bits can collectively form a codeword, which represents updated flag information for the memory array 305. After generating the new codeword for the flag information, the ECC engine 310 can transfer the codeword to the latch 325 for saving. The latch 325 can latch (e.g., store) the codeword until the prompting device 300 writes the codeword to the memory array 305. If the prompting device 300 writes the codeword to the memory array 305, the codeword can be transferred from the latch 325 to the amplifier component 315, which can write the codeword to the memory array. For example, the amplifier component 315 can write the flag bits of the codeword to the memory cells storing the flag bits TO to T3, and can write the parity bits of the codeword to the memory cells storing the parity bits TE0 to TE2.

[0075] Accordingly, the device 300 can efficiently manage access information, such as flag information, for the memory array 305.

[0076] Figure 4 An example of a process flow 400 that supports managing address access information in accordance with examples as disclosed herein is described. The process flow 400 can be implemented by the system 100, the memory device 110, the system 200, the memory sub-system 210, or the device 300 as described with reference to Figures 1 to 3 However, other types of devices or components can implement the process flow 400. The process flow 400 can illustrate the operation of a device that manages flag bits (e.g., dirty bits) of a memory array using a flag ECC engine. In some examples, the process flow 400 can be an example of a read-modify-write process.

[0077] For ease of reference, the process flow 400 is described with reference to a device. For example, aspects of the process flow 400 can be implemented by a device that includes volatile memory, non-volatile memory, or both, among other configurations. Additionally or alternatively, aspects of the process flow 400 can be implemented as instructions stored in memory (e.g., firmware stored in a device). For example, if executed by a controller, the instructions can cause the controller to perform the operations of the process flow 400.

[0078] At 405, a command, such as a memory operation command, can be received. For example, the device 300 can receive a memory operation command from a host device. The memory operation command can indicate an address (e.g., column address, row address) of the array 305. The memory operation command can also be referred to as an access command. Examples of memory operation commands include read commands and write commands.

[0079] At 410, the stored flag bits can be read. For example, the device 300 can read the stored flag bits from the memory array 305 using the amplifier assembly 315. The flag bits can indicate access information for one or more addresses of the memory array 305. The device 300 can read the stored flag bits based on or in response to the memory operation command received at 405. For example, the device 300 can read the stored flag bits for the column, row, or both indicated by the memory operation command. In some examples (e.g., if ECC decoding is enabled for the flag bits), the device 300 can also read the parity bits for the stored flag bits.

[0080] At 415, the stored flag bits can be transferred (e.g., passed). For example, the device 300 can transfer the stored flag bits from the amplifier assembly 315 to the ECC engine 310. In some examples (e.g., if ECC decoding is enabled for the flag bits), the device 300 can also transfer the parity bits for the stored flag bits to the ECC engine 310.

[0081] At 420, a determination can be made as to whether ECC decoding is enabled for the flag bits. In some examples, the determination at 420 can occur before 410. The device 300 can determine whether ECC decoding is enabled for the flag bits based on (e.g., in response to) a mode of the device 300. If at 420, the device 300 determines that ECC decoding is enabled for the flag bits, the device 300 can proceed to 425 and perform ECC decoding on a codeword made up of the stored flag bits and the parity bits for the stored flag bits. The device 300 can also detect and correct any errors in the codeword. If at 420, the device 300 determines that ECC decoding is disabled for the flag bits, the device can proceed to 430.

[0082] At 430, one or more flag bits can be generated. For example, the device 300 can generate one or more flag bits based on (e.g., corresponding to) the address indicated by the memory operation command (e.g., via the decoder 320). The generated flag bits can indicate updated access information for one or more memory addresses of the memory array 305. In some examples, generating the flag bits can include selecting values for the flag bits. For example, the decoder 320 can select values for the flag bits associated with the column (or row) indicated by the command received at 405. To illustrate, if the command indicates column C2, the decoder 320 can select a value of logic 1 for flag bit T2.

[0083] At 435, the generated flag bits can be transferred. For example, the device 300 can transfer the generated flag bits from the decoder 320 to the latch 325, and then from the latch 325 to the ECC engine 310.

[0084] At 440, the stored flag bits and the generated flag bits can be combined. For example, the ECC engine 310 can combine the stored flag bits and the generated flag bits. In some examples, combining the stored flag bits and the generated flag bits can involve using the generated flag bits to modify the stored flag bits.

[0085] At 445, ECC encoding can be performed. For example, the device 300 can perform ECC encoding on the combined flag bits to generate a codeword consisting of the combined flag bits and parity bits for the combined flag bits. The combined flag bits can also be referred to as updated flag bits or other suitable terminology, and the generated codeword can be referred to as a new flag codeword.

[0086] At 450, the new flag codeword can be transferred. For example, the device 300 can transfer the new flag codeword from the ECC engine 310 to the latch 325. At 455, the latch 325 can latch the new flag codeword. At 460, a command, such as a precharge command, can be received. For example, the device 300 can receive the precharge command from a host device. The precharge command can indicate that the device 300 is to turn off (e.g., deactivate) a row activated for the memory operation command.

[0087] At 465, the new flag codeword can be stored in memory. For example, the device 300 can transfer the new flag codeword from the latch 325 to the amplifier component 315, which can write the new flag codeword to the memory array 305. The device can store the new flag codeword in memory based on (e.g., in response to) the precharge command received at 360.

[0088] Accordingly, ECC-protected tag information for memory array 305 can be updated. Alternative examples of the foregoing can be implemented in which some operations are performed in a different order than described, in parallel, or not at all. In some cases, operations can include additional features not mentioned herein, or additional operations can be added. Also, certain operations can be performed multiple times, or certain combinations of operations can be repeated or looped.

[0089] Figure 5 An example of a timing diagram 500 that supports managing address access information according to examples as disclosed herein is illustrated. Timing diagram 500 can illustrate commands received (e.g., from a host device) over command bus 505, data transferred over data bus 510, and commands transferred over internal command bus 515. The timing diagram can also illustrate tag information operations 520, which can refer to operations involving tag bits, such as stored tag bits and generated tag bits.

[0090] At time tO, a command, such as a write command 525, can be received over external command bus 505. Write command 525 can be received by device 300. The write command can be for a data set (e.g., data 530) and can indicate a memory address (e.g., an address for memory array 305) or be associated with a memory address. At time t2, after a write latency 527 has expired, the data set (e.g., data 530) can be received over one of data buses 510.

[0091] At time t3, a command, such as a precharge command 533, can be received over external command bus 505. Precharge command 533 can be received by device 300. At t4, the data set (e.g., data 530) can be internally transferred to amplifier component 315 for writing to memory array 305. Also at or near time t4, a tag bit 540 can be generated. For example, decoder 320 can generate tag bit 540 based on (e.g., in response to, in accordance with) write command 525 and the address indicated by write command 525. In some examples, tag bit 540 can be generated based on (e.g., in response to) a column address provided by write command 525. Tag bit 540 can be transferred to ECC engine 310 for combination.

[0092] At time t5, a write command 535 for a data set (e.g., data 530) can be internally communicated. The write command 535 can cause the data set to be written to the memory array 305 (e.g., at the memory address indicated by the write command 525). Also, at or near time t4, a read command 545 can be internally communicated. The read command 545 can be for the stored marker bit (e.g., stored marker bit 550) associated with the address indicated by the write command 525. The read command 545 can cause the stored marker bit 550 (and optionally, a parity bit for the stored marker bit) to be read from the memory array 305. The stored marker bit 550 can be communicated to the ECC engine 310 for combination.

[0093] At time t6, the generated marker bit 540 and the stored marker bit 550 can be combined. For example, the ECC engine 310 can combine the generated marker bit 540 and the stored marker bit 550 to generate a combined marker bit 555. At time t7, a new marker codeword 560 can be generated based on (e.g., using) the combined marker bit 555. At time t8, a write command 565 for the new marker codeword 560 can be internally communicated. The write command 565 can cause the new marker codeword 560 to be written to the memory array 305. In some examples, the write command 565 is based on (e.g., in response to) the precharge command 533.

[0094] Thus, the ECC-protected marker information can be updated. Although described with reference to marker bits, the operations of timing diagram 500 can be implemented for other types of bits that include dirty bits. Alternative examples of the foregoing can be implemented in which some operations are performed in a different order than described, in parallel, or not at all. In some cases, the operations can include additional features not mentioned herein, or additional operations can be added. Also, certain operations can be performed multiple times, or certain combinations of operations can be repeated or looped. For example, at least some of the operations depicted in timing diagram 500 can be performed for additional write commands received prior to the precharge command 533. In this case, if the precharge command 533 is issued, the final marker information for the memory array 305 can be processed. Figure 5

[0095] Figure 6 An example of a process flow 600 that supports managing address access information in accordance with examples as disclosed herein is illustrated. The process flow 600 can be implemented by the system 100, the memory device 110, the system 200, the memory sub-system 210, or the device 300 as described with reference to Figures 1 to 3 However, other types of devices or components can implement the process flow 600. The process flow 600 can illustrate the operation of a device that manages marker bits (e.g., dirty bits) for a memory array using a marker ECC engine. In some examples, the process flow 600 can be an example of a read process for marker bits.​

[0096] For ease of reference, the process flow 600 is described with reference to a device. For example, aspects of the process flow 600 can be implemented by a device including volatile memory, non-volatile memory, or both, among other configurations. Additionally or alternatively, aspects of the process flow 600 can be implemented as instructions stored in memory (e.g., firmware stored in a device). For example, if executed by a controller, the instructions can cause the controller to perform the operations of the process flow 600.

[0097] At 605, a command, such as a read command, can be received. For example, the device 300 can receive a read command for the marker information from a host device. At 610, a command, such as a read command, can be received. For example, the device 300 can receive a read command for the data. At 615, a marker codeword can be read. For example, the device 300 can read the marker information from the memory array 305 based on (e.g., in response to) the read command received at 605. The device 300 can read the stored marker bits, the parity bits for the stored marker bits, or both. At 620, ECC decoding can be performed for the marker information. For example, the device 300 can perform ECC decoding on a marker codeword made up of the marker bits and the parity bits for the marker bits. The device 300 can also detect and correct any errors in the marker codeword. At 625, the data can be read. For example, the device 300 can read the data from the memory array 305. The device 300 can read the data based on (e.g., in response to) the read command received at 615. At 630, ECC decoding can be performed for the data. For example, the device 300 can perform ECC decoding on the data and the parity bits for the data. The device 300 can also detect and correct any errors in the data codeword.

[0098] At 635, the marker information can be transferred to the host device. For example, the device 300 can transfer the marker codeword or a portion of the marker codeword (e.g., the marker bits) to the host device. The device 300 can transfer the marker information based on (e.g., in response to) the read command received at 605. The device 300 can transfer the marker information through one or more pins of a data bus. At 640, the data can be transferred to the host device. For example, the device 300 can transfer the data to the host device. The device 300 can transfer the data based on (e.g., in response to) the read command received at 610. The device 300 can transfer the data through the data bus or a different data bus. In some examples, the device 300 can transfer the marker information and the data simultaneously (e.g., at partially or fully overlapping times).

[0099] Although described with reference to tag bits, operations of process flow 600 can be implemented for other types of bits that include dirty bits. Alternative examples of the foregoing can be implemented in which some operations are performed in a different order than described, in parallel, or not at all. In some cases, operations can include additional features not mentioned herein, or additional operations can be added. Also, certain operations can be performed multiple times, or certain combinations of operations can be repeated or looped.

[0100] Figure 7 An example of a timing diagram 700 that supports managing address access information according to examples as disclosed herein is illustrated. Timing diagram 700 can illustrate commands received (e.g., from a host device) over command bus 705, data transferred over data bus 710, and tag information transferred over one or more metadata pins 715. In some examples, metadata pins 715 are data mask (DM) pins. Metadata pins 715 can be included in data bus 710 or a different data bus.

[0101] At time tO, a command, such as a tag read command 720, can be received over command bus 705. Tag read command 720 can be received by device 300. Tag read command 720 can be for tag information stored in memory array 305 and can indicate a memory address (e.g., an address for memory array 305) or be associated with a memory address. At time tl, a command, such as a data read command 725, can be received over command bus 705. Data read command 725 can be received by device 300. Data read command 725 can be for a data set and can indicate a memory address or be associated with a memory address. In some examples, tag read command 720 and data read command 725 can be combined into a single command.

[0102] At time t3, at least a portion of tag information (e.g., tag bits 740) can be transferred over metadata pins 715 after a read latency (RL) 730 has expired (which can be relative to time t2). Tag bits 740 can be transferred based on (e.g., in response to) tag read command 720. Also at or near time t3, a data set (e.g., data 735) can be received over data bus 710. Data set 735 can be transferred based on (e.g., in response to) data read command 725. Thus, tag bits 740 and data set 735 can be transferred in parallel (e.g., at partially or fully overlapping times).

[0103] Although described with reference to flag bits, the operations of timing diagram 700 can be implemented for other types of bits including dirty bits. Alternative examples of the foregoing can be implemented where some operations are performed in a different order than described, in parallel, or not at all. In some cases, operations can include additional features not mentioned herein, or additional operations can be added. Additionally, certain operations can be performed multiple times, or certain combinations of operations can be repeated or looped.

[0104] Figure 8 A block diagram 800 showing an apparatus 820 that supports managing address access information in accordance with examples as disclosed herein is shown. The apparatus 820 can be an example of aspects of a system, subsystem, or apparatus as described with reference to Figures 1 to 7 The apparatus 820, or various components thereof, can be an example of means for performing various aspects of managing address access information as described herein. For example, the apparatus 820 can include a receiver 825, sensing circuitry 830, a decoder 835, an ECC engine 840, a latching circuitry 845, a driver 850, or any combination thereof. Each of these components can communicate, directly or indirectly, with one another (e.g., via one or more buses).

[0105] The receiver 825 can be or include a data bus, a data bus interface, a buffer, logic, circuitry, a processor, a controller, or other components capable of performing the functions described herein. The sensing circuitry 830 can be or include an amplifier component (e.g., an amplifier such as a sense amplifier), a sensing component, I / O circuitry, or other components capable of performing the functions described herein. The decoder 835 can be or include logic circuitry, a processor, a controller, or other components capable of performing the functions described herein. The ECC engine 840 can be or include logic circuitry, a processor, a controller, or other components capable of performing the functions described herein. The latching circuitry 845 can be or include a latch, logic circuitry, or other components capable of performing the functions described herein. The driver 850 can be or include a transmitter, a voltage generator, or other components capable of performing the functions described herein.

[0106] The receiver 825 can be configured as, or otherwise support, a means for receiving a command for a memory array address. The sense circuitry 830 can be configured as, or otherwise support, a means for reading, based at least in part on the command, a first set of flag bits from the memory array that indicate access information for a set of addresses including the address. The decoder 835 can be configured as, or otherwise support, a means for determining, based at least in part on the command and the address, a second set of flag bits that indicate updated access information for the address. The ECC engine 840 can be configured as, or otherwise support, a means for generating a codeword based at least in part on the first set of flag bits and the second set of flag bits. In some examples, the sense circuitry 830 can be configured as, or otherwise support, a means for storing the codeword in the memory array.

[0107] In some examples, the ECC engine 840 can be configured as, or otherwise support, a means for combining the first set of flag bits with the second set of flag bits to update the first set of flag bits prior to generating the codeword.

[0108] In some examples, to support generating the codeword and other operations, the ECC engine 840 can be configured as, or otherwise support, a means for performing ECC encoding on the updated first set of flag bits, where the codeword includes the updated first set of flag bits and a set of parity bits based at least in part on the updated first set of flag bits.

[0109] In some examples, to determine the second set of flag bits and other operations, the decoder 835 can be configured as, or otherwise support, a means for selecting, based at least in part on the command, values for flag bits corresponding to the address, where the second set of flag bits includes the flag bits. In some examples, the receiver 825 can be configured as, or otherwise support, a means for receiving a precharge command after the write command, where the codeword is stored in the memory array based at least in part on receiving the precharge command. In some examples, the latch circuitry 845 can be configured as, or otherwise support, a means for latching the codeword in a set of latch components prior to storing the codeword in the memory array.

[0110] In some examples, the latch circuitry 845 can be configured as, or otherwise support, a means for transferring the codeword from the set of latch components to a set of amplifier components coupled with the memory array. In some examples, the sense circuitry 830 can be configured as, or otherwise support, a means for storing the codeword in the memory array using the set of amplifier components based at least in part on transferring the codeword.

[0111] In some examples, the ECC engine 840 can be configured as or otherwise support a means for performing ECC decoding on the first set of marker bits and a set of parity bits for the first set of marker bits, where a codeword is generated based at least in part on performing the ECC decoding. In some examples, the codeword is written to a set of memory cells.

[0112] In some examples, the sensing circuitry 830 can be configured as or otherwise support a means for transferring the first set of marker bits to the ECC engine. In some examples, the latching circuitry 845 can be configured as or otherwise support a means for transferring the second set of marker bits to the ECC engine. In some examples, the ECC engine 840 can be configured as or otherwise support a means for combining the first set of marker bits with the second set of marker bits based at least in part on transferring the first and second sets of marker bits to the ECC engine.

[0113] In some examples, the receiver 825 can be configured as or otherwise support a means for receiving a read command for a codeword from a host device. In some examples, the driver 850 can be configured as or otherwise support a means for transferring a portion of the codeword to the host device based at least in part on the read command for the codeword, the portion of the codeword indicating access information for the set of addresses.

[0114] In some examples, the receiver 825 can be configured as or otherwise support a means for receiving a read command for data associated with a codeword from a host device. In some examples, the driver 850 can be configured as or otherwise support a means for transferring the data to the host device based at least in part on the read command for the data, where the transfer of the data and the transfer of the portion of the codeword at least partially overlap in time. In some examples, the command is a write command or a read command. In some examples, the address is a column address or a row address.

[0115] Figure 9 A flow diagram illustrating a method 900 that supports managing address access information in accordance with examples as disclosed herein is shown. The operations of method 900 can be implemented by a device or its components as described herein. For example, the operations of method 900 can be performed by a device as described with reference to FIGS. 1-8B, 9, and 10A-10B, according to examples. In some examples, a device can execute a set of instructions to control the functional elements of the device to perform the described functions. Additionally or alternatively, the device can perform aspects of the described functions using special-purpose hardware. Figures 1 to 8

[0116] At 905, the method can include receiving a command for an address of a memory array. The operations of 905 can be performed according to the examples as disclosed herein. In some examples, operations of 905 can be performed by a device as described with reference to FIGS. 1-8B, 9, and 10A-10B, according to examples. Figure 8 ​Aspects of the described receiver 825 perform operations of 905.

[0117] At 910, the method can include reading a first set of marker bits (e.g., stored marker bits) from a memory array based at least in part on a command, the first set of marker bits indicating access information for a set of addresses including the address. Operations of 910 can be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of 910 can be performed by a read circuit as Figure 8 Aspects of the described sensing circuitry 830 perform.

[0118] At 915, the method can include determining a second set of marker bits (e.g., generated marker bits) based at least in part on (e.g., in response to, in accordance with) the command and the address, the second set of marker bits indicating updated access information for the address. Operations of 915 can be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of 915 can be performed by a decoder as Figure 8 Aspects of the described decoder 835 perform operations of 915.

[0119] At 920, the method can include generating a codeword based at least in part on (e.g., using) the first set of marker bits and the second set of marker bits. Operations of 920 can be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of 920 can be performed by an ECC engine as Figure 8 Aspects of the described ECC engine 840 perform.

[0120] At 925, the method can include storing the codeword in the memory array. Operations of 925 can be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of 925 can be performed by sensing circuitry as Figure 8 Aspects of the described sensing circuitry 830 perform.

[0121] In some examples, an apparatus as described herein can perform one or more methods such as method 900. The apparatus can include features, circuitry, logic, means, or instructions (e.g., a non-transitory computer-readable medium storing instructions executable by a processor) for receiving a command for an address of a memory array; reading a first set of marker bits from the memory array based at least in part on the command, the first set of marker bits indicating access information for a set of addresses including the address; determining a second set of marker bits based at least in part on the command and the address, the second set of marker bits indicating updated access information for the address; generating a codeword based at least in part on the first set of marker bits and the second set of marker bits; and storing the codeword in the memory array.

[0122] Some examples of the method 900 and the apparatus described herein can further include operations, features, circuitry, logic that performs, means for, or instructions for combining the first set of marker bits with the second set of marker bits to update the first set of marker bits prior to generating the codeword. In some examples of the method 900 and the apparatus described herein, generating the codeword can include operations, features, circuitry, logic, means for, or instructions for performing ECC encoding on the updated first set of marker bits, where the codeword includes the updated first set of marker bits and a set of parity bits based at least in part on the updated first set of marker bits.

[0123] In some examples of the method 900 and the apparatus described herein, determining the second set of marker bits can include operations, features, circuitry, logic, means for, or instructions for selecting a value of a marker bit corresponding to the address based at least in part on the command, where the second set of marker bits includes the marker bit.

[0124] Some examples of the method 900 and the apparatus described herein can further include operations, features, circuitry, logic, means for, or instructions for receiving a precharge command after the write command, where the codeword can be stored in the memory array based at least in part on receiving the precharge command. Some examples of the method 900 and the apparatus described herein can further include operations, features, circuitry, logic, means for, or instructions for latching the codeword in a set of latching components prior to storing the codeword in the memory array.

[0125] Some examples of the method 900 and the apparatus described herein can further include operations, features, circuitry, logic, means for, or instructions for transferring the codeword from the set of latching components to a set of amplifier components coupled with the memory array; and storing the codeword in the memory array using the set of amplifier components based at least in part on transferring the codeword.

[0126] Some examples of the method 900 and the apparatus described herein can further include operations, features, circuitry, logic, means for, or instructions for performing ECC decoding on the first set of marker bits and a set of parity bits for the first set of marker bits, where the codeword can be generated based at least in part on performing the ECC decoding. Some examples of the method 900 and the apparatus described herein can further include operations, features, circuitry, logic, means for, or instructions for writing the codeword to a set of memory cells.

[0127] Some examples of the method 900 and the apparatus described herein can further include operations, features, circuitry, logic, means, or instructions for transmitting a first set of marker bits to the ECC engine, transmitting a second set of marker bits to the ECC engine, and combining the first set of marker bits with the second set of marker bits based at least in part on transmitting the first and second sets of marker bits to the ECC engine.

[0128] Some examples of the method 900 and the apparatus described herein can further include operations, features, circuitry, logic, means, or instructions for receiving a read command for a codeword from a host device, and transmitting a portion of the codeword to the host device based at least in part on the read command for the codeword, the portion of the codeword indicating access information for the set of addresses.

[0129] Some examples of the method 900 and the apparatus described herein can further include operations, features, circuitry, logic, means, or instructions for receiving a read command for data associated with a codeword from a host device, and transmitting the data to the host device based at least in part on the read command for the data, wherein the transmission of the data and the transmission of the portion of the codeword at least partially overlap in time. In some examples of the method 900 and the apparatus described herein, the command can be a write command or a read command, and the address can be a column address or a row address.

[0130] It should be noted that the methods described herein describe possible implementations, and that the operations and the steps can be rearranged or otherwise modified and that other implementations are possible. Furthermore, portions from two or more of the methods can be combined.

[0131] Another apparatus is described. The apparatus can include an amplifier component configured to sense a first set of marker bits from a memory array based at least in part on a command for an address of the memory array, the first set of marker bits indicating access information for a set of addresses including the address, a decoder configured to determine a second set of marker bits based at least in part on the command and the address, the second set of marker bits indicating updated access information for the address, an ECC engine configured to generate a codeword based at least in part on the first set of marker bits and the second set of marker bits, and a latch component configured to latch the codeword for storage at the memory array.

[0132] In some examples of the apparatus, the ECC engine can be different from a second ECC engine configured to perform ECC operations on data bits stored in the memory array. In some examples of the apparatus, the ECC engine can be configured to combine the first set of marker bits with the second set of marker bits to update the first set of marker bits prior to generating the codeword.

[0133] In some examples, a device can include performing ECC encoding on the updated first set of flag bits, where the codeword includes the updated first set of flag bits and a set of parity bits based at least in part on the updated first set of flag bits. In some examples, a device can include selecting, based at least in part on the command, a value of a flag bit corresponding to the address, where the second set of flag bits includes the flag bit.

[0134] In some examples of a device, an amplifier component can be configured to store a codeword in a memory array based at least in part on a precharge command. In some examples of a device, an amplifier component can be configured to transfer a codeword to the amplifier component, and the amplifier component can be configured to store the transferred codeword in a memory array.

[0135] In some examples of a device, an ECC engine can be configured to perform ECC decoding on a first set of flag bits and a set of parity bits for the first set of flag bits, and can generate a codeword based at least in part on performing the ECC decoding. In some examples of a device, an amplifier component can be configured to transfer the first set of flag bits to the ECC engine, a decoder can be configured to transfer the second set of flag bits to the ECC engine, and the ECC engine can be configured to combine the first and second sets of flag bits.

[0136] Another device is described. The device can include a memory array; and a controller coupled with the memory array, the controller configured to cause the device to: receive a command for an address of a memory array; read a first set of flag bits from the memory array based at least in part on the command, the first set of flag bits indicating access information for a set of addresses including the address; determine a second set of flag bits based at least in part on the command and the address, the second set of flag bits indicating updated access information for the address; generate a codeword based at least in part on the first set of flag bits and the second set of flag bits; and store the codeword in the memory array.

[0137] In some examples, a device can include receiving a read command for a codeword from a host device, and transferring a portion of the codeword to the host device based at least in part on the read command for the codeword, the portion of the codeword indicating access information for the set of addresses. In some examples, a device can include receiving a read command for data associated with a codeword from a host device, and transferring the data to the host device based at least in part on the read command for the data, where the transfer of the data and the transfer of the portion of the codeword at least partially overlap in time.

[0138] Information and signals described herein can be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that can be referenced throughout the above description can be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof. Some drawings can illustrate signals as single signals; however, it will be understood by a person of ordinary skill in the art that the signals can represent a bus of signals, where the bus can have a variety of bit widths.

[0139] The terms“electronically communicate,”“electrically contact,”“connected,” and“coupled” can refer to a relationship between components in which a signal is supported to flow between the components. Components are considered to be in electronic communication with each other (or electrically contact each other, or connected to each other, or coupled to each other) if there is any conductive path between the components that can support a signal to flow between the components at any time. The conductive path between components that are in electronic communication with each other (or electrically contact each other, or connected to each other, or coupled to each other) can be an open circuit or a closed circuit at any given time, based on the operation of the device that includes the connected components. The conductive path between connected components can be a direct conductive path between the components, or the conductive path between connected components can be an indirect conductive path that can include intervening components such as switches, transistors, or other components. In some examples, the signal flow between connected components can be interrupted for a period of time, for example, using one or more intervening components such as switches or transistors.

[0140] The term“coupled” refers to the condition of moving from an open circuit relationship between components, in which a signal cannot currently pass between the components through a conductive path, to a closed circuit relationship between the components, in which a signal can pass between the components through a conductive path. When a component such as a controller couples other components together, the component initiates a change that allows a signal to flow between the other components through a conductive path that previously did not permit signal flow.

[0141] The term“isolated” refers to a relationship between components in which a signal cannot currently flow between the components. Components are isolated from each other if there is an open circuit between the components. For example, components that are isolated from each other by a switch positioned between the two components are isolated from each other when the switch is open. When a controller isolates two components, the controller implements a change that prevents a signal from flowing between the components using a conductive path that previously permitted signal flow.

[0142] The term“layer” or“level” as used herein refers to a layer or sheet of a geometric structure (e.g., with respect to a substrate). Each layer or level can have three dimensions (e.g., height, width, and depth) and can cover at least a portion of a surface. For example, a layer or level can be a three-dimensional structure in which two dimensions are greater than a third dimension, such as a thin film. A layer or level can include different elements, components, and / or materials. In some examples, one layer or level can be composed of two or more sub-layers or sub-levels.

[0143] As used herein, the term "substantially" means that the modified characteristic (e.g., verb or adjective modified by term substantially) is not absolute but is close enough to the absolute to derive the essential properties of the characteristic.

[0144] As used herein, the term "electrode" can refer to an electrical conductor and, in some examples, can serve as an electrical contact to a memory cell or other component of a memory array. An electrode can include a trace, wire, conductive line, conductive layer, etc. that provides an electrically conductive path between elements or components of a memory array.

[0145] Devices discussed herein that include a memory array can be formed on a semiconductor substrate such as silicon, germanium, silicon-germanium alloys, gallium arsenide, gallium nitride, etc. In some examples, the substrate is a semiconductor wafer. In other examples, the substrate can be a silicon-on-insulator (SOI) substrate such as a silicon-on-glass (SOG) or a silicon-on-sapphire (SOP), or an epitaxial layer of semiconductor material on another substrate. The conductivity of the substrate or sub-regions of the substrate can be controlled by doping with various chemicals including, but not limited to, phosphorus, boron, or arsenic. Doping can be performed by ion implantation during initial formation or growth of the substrate, or by any other doping method.

[0146] A switching component or transistor discussed herein can represent a field effect transistor (FET) and includes a three-terminal device including a source, a drain, and a gate. The terminals can be connected to other electronic elements by conductive material such as metal. The source and drain can be conductive and can include heavy doping such as a degenerate semiconductor region. The source and drain can be separated by a lightly doped semiconductor region or channel. If the channel is n-type (i.e., majority of carriers are electrons), the FET can be referred to as an n-type FET. If the channel is p-type (i.e., majority of carriers are holes), the FET can be referred to as a p-type FET. The channel can be capped by an insulating gate oxide. The channel conductivity can be controlled by applying a voltage to the gate. For example, applying a positive or negative voltage to an n-type or p-type FET, respectively, can cause the channel to become conductive. A transistor can be "turned on" or "activated" when a voltage greater than or equal to the threshold voltage of the transistor is applied to the transistor gate. A transistor can be "turned off" or "deactivated" when a voltage less than the threshold voltage of the transistor is applied to the transistor gate.

[0147] The description set forth herein, in connection with the appended drawings, describes example configurations and does not represent all the examples that can be implemented or that are within the scope of the claims. The term "exemplary" used herein means "serving as an example, instance, or illustration," and not "preferred" over other examples. The detailed description includes specific details for the purpose of providing an understanding of the described techniques. These techniques, however, can be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the concepts of the described examples.

[0148] In the drawings, like reference numerals can be used to denote similar components throughout the several views. Additionally, various components of the same type can be distinguished from each other by following the convention of placing the primary reference number in a circle or box followed by a dash and a secondary reference number. If only the primary reference number is used, it is intended to represent any one of the similar components.

[0149] The functions described herein can be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Other examples and implementations are within the scope of the disclosure and appended claims. For example, due to the nature of software, functions described herein can be implemented using software executed by a processor, hardware, firmware, hardwiring, or combinations of any of these. Features implementing functions can also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations.

[0150] The various illustrative blocks and modules described in connection with the disclosure herein can be implemented or performed with a general-purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor can be a microprocessor, but in the alternative, the processor can be any processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration).

[0151] As used herein, including in the claims, “or” as used in a list of items (for example, a list of items prefaced by a phrase such as “at least one of’ or “one or more of’) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Also, as used herein, the phrase “based on” shall not be construed as a referral to a closed set of conditions. For example, an exemplary step that is described as “based on condition A” can be based on both condition A and condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on.”

[0152] Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium can be any available medium that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, non-transitory computer-readable media can comprise RAM, ROM, electrically erasable programmable read-only memory (EEPROM), compact disk (CD) ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to carry or store desired program elements in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, include CD, laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of computer-readable media.

[0153] The description herein is presented to enable a person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not to be limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method comprising: receiving a command for an address of a memory array; decoding, by a decoder, the address of the memory array based at least in part on the command; reading, based at least in part on the command, a first set of flag bits from the memory array, the first set of flag bits indicating access information for a set of addresses including the address; generating, by the decoder, a second set of flag bits based at least in part on the command and the decoded address, the generated second set of flag bits indicating updated access information for the decoded address; generating, by a first error correction code (ECC) engine, a codeword based at least in part on the first set of flag bits and the generated second set of flag bits, wherein the first ECC engine is different from a second ECC engine configured to perform ECC operations on data bits stored in the memory array; and storing the codeword in the memory array.

2. The method of claim 1, further comprising: combining, prior to generating the codeword, the first set of flag bits with the generated second set of flag bits to update the first set of flag bits.

3. The method of claim 2, wherein generating the codeword comprises: performing ECC encoding on the updated first set of flag bits, wherein the codeword comprises the updated first set of flag bits and a set of parity bits based at least in part on the updated first set of flag bits.

4. The method of claim 1, wherein generating the second set of flag bits comprises: selecting, based at least in part on the command, a value of a flag bit corresponding to the decoded address, wherein the generated second set of flag bits includes the flag bit.

5. The method of claim 1, further comprising: receiving a precharge command after the command, wherein the codeword is stored in the memory array based at least in part on receiving the precharge command.

6. The method of claim 1, further comprising: latching the codeword in a set of latching components prior to storing the codeword in the memory array.

7. The method of claim 6, further comprising: transferring the codeword from the set of latching components to a set of amplifier components coupled with the memory array; and storing the codeword in the memory array using the set of amplifier components based at least in part on transferring the codeword.

8. The method of claim 1, further comprising: performing ECC decoding on the first set of flag bits and a set of parity bits for the first set of flag bits, wherein the codeword is generated based at least in part on performing the ECC decoding.

9. The method of claim 1, wherein the first set of flag bits and parity bits for the first set of flag bits are read from a set of memory cells, and wherein storing the codeword comprises: writing the codeword to the set of memory cells.

10. The method of claim 1, further comprising: transferring the first set of flag bits to the first ECC engine; ​ transmitting the generated second set of flag bits to the first ECC engine; and combining the first set of flag bits with the generated second set of flag bits based at least in part on transmitting the first set of flag bits and the generated second set of flag bits to the first ECC engine.

11. The method of claim 1, further comprising: receiving a read command for the codeword from a host device; and transmitting a portion of the codeword to the host device based at least in part on the read command for the codeword, the portion of the codeword indicating access information for the set of addresses.

12. The method of claim 11, further comprising: receiving a read command for data associated with the codeword from the host device; and transmitting the data to the host device based at least in part on the read command for the data, wherein the transmission of the data and the transmission of the portion of the codeword at least partially overlap in time.

13. The method of claim 1, wherein the command is a write command or a read command, and wherein the address is a column address or a row address.

14. An apparatus comprising: an amplifier component configured to sense a first set of flag bits from a memory array based at least in part on a command for an address of the memory array, the first set of flag bits indicating access information for a set of addresses including the address; a decoder configured to decode the address of the memory array based at least in part on the command, and configured to generate a second set of flag bits based at least in part on the command and the decoded address, the generated second set of flag bits indicating updated access information for the decoded address; a first error correction code (ECC) engine configured to generate a codeword based at least in part on the first set of flag bits and the generated second set of flag bits, wherein the first ECC engine is different from a second ECC engine configured to perform ECC operations on data bits stored in the memory array; and a latch component configured to latch the codeword for storage at the memory array.

15. The apparatus of claim 14, wherein the first ECC engine is closer to the memory array than the second ECC engine.

16. The apparatus of claim 14, wherein the first ECC engine is configured to combine the first set of flag bits with the generated second set of flag bits to update the first set of flag bits prior to generating the codeword.

17. The apparatus of claim 14, wherein the first ECC engine is configured to generate the codeword by being configured to perform: ECC encoding on the updated first set of flag bits, wherein the codeword comprises the updated first set of flag bits and a set of parity bits based at least in part on the updated first set of flag bits.

18. The apparatus of claim 14, wherein the decoder is configured to generate the second set of flag bits by being configured to perform: selecting, based at least in part on the command, a value of a tag bit corresponding to the decoded address, wherein the generated second set of tag bits includes the tag bit.

19. The apparatus of claim 14, wherein the amplifier component is configured to store the codeword in the memory array based at least in part on a precharge command.

20. The apparatus of claim 14, wherein the amplifier component is configured to transfer the codeword to the amplifier component, and wherein the amplifier component is configured to store the transferred codeword in the memory array.

21. The apparatus of claim 14, wherein the first ECC engine is configured to perform ECC decoding on the first set of tag bits and a set of parity bits for the first set of tag bits, and wherein the codeword is generated based at least in part on performing the ECC decoding.

22. The apparatus of claim 14, wherein the amplifier component is configured to transfer the first set of tag bits to the first ECC engine, the decoder is configured to transfer the generated second set of tag bits to the first ECC engine, and the first ECC engine is configured to combine the first set of tag bits and the generated second set of tag bits.

23. An apparatus comprising: a memory array; and a controller coupled with the memory array, the controller configured to cause the apparatus to: receive a command for an address of the memory array; decode, by a decoder, the address of the memory array based at least in part on the command; read, from the memory array, a first set of tag bits based at least in part on the command, the first set of tag bits indicating access information for a set of addresses including the address; generate a second set of tag bits based at least in part on the command and the decoded address, the generated second set of tag bits indicating updated access information for the decoded address; generate, by a first error correction code (ECC) engine, a codeword based at least in part on the first set of tag bits and the generated second set of tag bits, wherein the first ECC engine is different from a second ECC engine configured to perform ECC operations on data bits stored in the memory array; and store the codeword in the memory array.

24. The apparatus of claim 23, wherein the controller is further operable to cause the apparatus to: receive, from a host device, a read command for the codeword; and transfer, to the host device, a portion of the codeword based at least in part on the read command for the codeword, the portion of the codeword indicating access information for the set of addresses.

25. The apparatus of claim 24, wherein the controller is further operable to cause the apparatus to: receive, from the host device, a read command for data associated with the codeword; and transfer, to the host device, the data based at least in part on the read command for the data, wherein the transfer of the data and the transfer of the portion of the codeword at least partially overlap in time.

Images