Post error correction code register for caching metadata
By storing metadata in volatile memory and writing it back to non-volatile memory when necessary, the power consumption problem caused by frequent access and error correction code operations is solved, enabling more efficient memory system operation.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- MICRON TECHNOLOGY INC
- Filing Date
- 2022-08-16
- Publication Date
- 2026-06-23
AI Technical Summary
Existing technologies result in excessive power consumption and inefficiency when frequently accessing and performing error correction code operations, especially in hybrid systems using non-volatile and volatile memory.
By storing metadata in registers after performing error correction code operations, the frequency of access to the local array is reduced, and data is written back to the local array only when necessary, thus reducing power consumption and the number of operations.
It effectively reduces power consumption and the number of operations, improves system efficiency, and reduces the need for frequent access to non-volatile memory and error correction code operations.
Smart Images

Figure CN115910176B_ABST
Abstract
Description
[0001] Cross-referencing
[0002] This patent application claims priority to U.S. Patent Application No. 17 / 648,404, filed January 19, 2022, entitled “Post Error Correction Code Registers for Cached Metadata”, and U.S. Provisional Patent Application No. 63 / 234,015, filed August 17, 2021, entitled “Post Error Correction Code Registers for Cached Metadata”, each of which is assigned to the assignee and each of which is expressly incorporated herein by reference in its entirety. Technical Field
[0003] The technical field relates to post-error correction code (ECC) registers for caching metadata. Background Technology
[0004] Memory devices are widely used to store information in various electronic devices such as computers, user devices, wireless communication devices, cameras, and digital displays. Information is stored by programming memory cells within the memory device into various states. For example, a binary memory cell can be programmed to support one of two states, often represented by logic 1 or logic 0. In some instances, a single memory cell can support more than two states, any of which can be stored. To access the stored information, a component can read or sense at least one stored state in the memory device. To store information, a component can write states into the memory device or program states.
[0005] Various types of memory devices and memory cells exist, 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), auto-select memory, and chalcogenide memory technology. Memory cells can be volatile or non-volatile. Non-volatile memory, such as FeRAM, can maintain its stored logic state for a long time, even without external power. Volatile memory devices, such as DRAM, may lose their stored state when disconnected from external power. Summary of the Invention
[0006] Describe a device. The device may include: a non-volatile memory; a volatile memory; and an interface controller coupled to the non-volatile memory and the volatile memory, the interface controller being operable such that the device: reads metadata from a memory array contained in the interface controller, the metadata including information for operating the volatile memory as a cache for the non-volatile memory; performs an error correction code (ECC) operation on the metadata based at least in part on reading the metadata from the memory array; writes the metadata to a register coupled to the memory array based at least in part on performing the ECC operation; and writes the metadata from the register to the memory array.
[0007] Describe a method. The method may include: reading metadata from a memory array contained in an interface controller coupled to volatile memory and non-volatile memory, the metadata including information for operating the volatile memory as a cache for the non-volatile memory; performing an error correction code (ECC) operation on the metadata based at least in part on reading the metadata from the memory array; writing the metadata to a register coupled to the memory array based at least in part on performing the ECC operation; and writing the metadata from the register to the memory array.
[0008] Describe an apparatus. The apparatus may include: a non-volatile memory; volatile memory configured to operate as a cache for the non-volatile memory; and an interface controller coupled to the non-volatile memory and the volatile memory, the interface controller including: a static random access memory (SRAM) array configured to store metadata for enabling the volatile memory to operate as the cache; error correction code (ECC) logic coupled to the SRAM array and configured to perform ECC operations on the metadata from the SRAM array; and a register for storage of the volatile memory, coupled to the ECC logic and configured to store metadata from the ECC logic, wherein the interface controller is configured to update the metadata in the register and transmit the metadata from the register to the SRAM array. Attached Figure Description
[0009] Figure 1 This describes an instance of a system that supports a post-ECC register for caching metadata, based on examples disclosed herein.
[0010] Figure 2This document describes an instance of a memory subsystem that supports a post-ECC register for caching metadata, based on the examples disclosed herein.
[0011] Figure 3 This describes an instance of an interface controller that supports the post-ECC register for caching metadata, based on examples disclosed herein.
[0012] Figure 4 This describes an example of a process for handling post-ECC registers for cached metadata, based on examples disclosed herein.
[0013] Figure 5 A block diagram illustrating a device that supports a post-ECC register for caching metadata, based on examples disclosed herein.
[0014] Figure 6 The flowchart illustrates one or more methods for supporting post-ECC registers for caching metadata, based on examples disclosed herein. Detailed Implementation
[0015] For example, an electronic device may include non-volatile memory (e.g., main memory for storing information during other operations) and volatile memory (e.g., secondary memory) that can be used as a cache for the non-volatile memory. This configuration allows the device to benefit from the advantages of non-volatile memory (e.g., non-volatile permanent storage, high storage capacity, low power consumption) while maintaining compatibility with the host device and other aspects through the volatile memory. To support this type of configuration, the device may include an interface controller that interfaces the volatile and non-volatile memory with the host device.
[0016] The interface controller may include a local array (e.g., a local memory array) that stores metadata for managing volatile memory as a cache. Upon receiving a command, the interface controller can read the metadata associated with the command from the local array and perform an error correction code (ECC) operation on the metadata to detect any errors. If any errors are detected in the metadata, the interface controller can correct the errors and store the metadata back into the local array for future access. Thus, the interface controller can access the metadata in the local array and perform ECC operations command-by-command. However, accessing the metadata in the local array and performing ECC operations command-by-command can lead to frequent accesses to the local array and multiple (if not many) ECC operations, which can consume excessive power and has other disadvantages.
[0017] According to the techniques described herein, an apparatus or a component of an apparatus (e.g., an interface controller) can reduce power consumption and achieve other advantages by storing metadata from the local array in a register after performing an ECC operation on the metadata. For example, the interface controller can read metadata from the local array based on or in response to a first command (e.g., a start command for a row of volatile memory) and can store the metadata in a register (after performing an ECC operation) so that the metadata can be updated based on or in response to subsequent commands on the row without accessing the local array. The interface controller can store the metadata in the register for a period of time, e.g., until a second command (e.g., a precharge command for the row) is received, at which point the interface controller can write the metadata from the register (e.g., after ECC encoding) to the local array. Therefore, the interface controller can avoid multiple accesses to the local array (and multiple ECC operations) for the same metadata, which reduces power consumption and has other advantages.
[0018] Firstly, in reference Figure 1 and 2 The features of this disclosure are described in the context of the system and memory subsystem described herein. (See references...) Figure 3 The described interface controller and as in the reference Figure 4 The features of this disclosure are described in the context of the described processing flow. Further references are as follows: Figure 5 and 6 The device diagrams and flowcharts described herein illustrate and describe these and other features of the present disclosure, which relate to the post-ECC registers used for caching metadata.
[0019] Figure 1 This describes an example of a system 100 that supports a post-ECC register for caching metadata, as disclosed herein. System 100 may be contained in an electronic device, such as a computer or telephone. System 100 may include a host device 105 and a memory subsystem 110. Host device 105 may be a processor or system-on-a-chip (SoC) that interfaces with interface controller 115, as well as other components of the electronic device containing system 100. Memory subsystem 110 may store electronic information (e.g., digital information, data) for host device 105 and provide access to said electronic information. Memory subsystem 110 may include interface controller 115, volatile memory 120, and non-volatile memory 125. In some instances, interface controller 115, volatile memory 120, and non-volatile memory 125 may be contained in the same physical package, such as package 130. However, interface controller 115, volatile memory 120, and non-volatile memory 125 may be disposed on different corresponding dies (e.g., silicon dies).
[0020] Devices in system 100 can be coupled via various wires (e.g., traces, printed circuit board (PCB) wiring, redistribution layer (RDL) wiring) that enable the transmission of information (e.g., commands, addresses, data) between devices. These wires can form channels, data buses, command buses, address buses, etc.
[0021] Memory subsystem 110 may be configured to provide the benefits of non-volatile memory 125 while maintaining compatibility with host device 105 that supports protocols for different types of memory, such as volatile memory 120, and other instances. For example, non-volatile memory 125 may provide benefits (e.g., relative to volatile memory 120), such as non-volatility, higher capacity, or lower power consumption. However, host device 105 may be configured incompatible with or inefficiently coupled to various aspects of non-volatile memory 125. For instance, host device 105 may support voltages, access latency, protocols, page sizes, etc., that are incompatible with non-volatile memory 125. To compensate for incompatibility between host device 105 and non-volatile memory 125, memory subsystem 110 may be configured to include volatile memory 120, which is compatible with host device 105 and acts as a cache for non-volatile memory 125. Therefore, host device 105 can use the protocols supported by volatile memory 120 while also benefiting from the advantages of non-volatile memory 125.
[0022] In some instances, system 100 may be contained in, or coupled to, a computing device, electronic device, mobile computing device, or wireless device. The device may be a portable electronic device. For example, the device may be a computer, laptop computer, tablet computer, smartphone, cellular phone, wearable device, Internet-connected device, etc. In some instances, the device may be configured for bidirectional wireless communication via a base station or access point. In some instances, the device associated with system 100 is capable of machine-type communication (MTC), machine-to-machine (M2M) communication, or device-to-device (D2D) communication. In some instances, the device associated with system 100 may be referred to as a user equipment (UE), station (STA), mobile terminal, etc.
[0023] Host device 105 may be configured to interface with memory subsystem 110 using a first protocol (e.g., Low Power Double Data Rate (LPDDR)) supported by interface controller 115. Therefore, in some instances, host device 105 may interface directly with interface controller 115 and indirectly with non-volatile memory 125 and volatile memory 120. In alternative instances, host device 105 may interface directly with non-volatile memory 125 and volatile memory 120. Host device 105 may also interface with other components of the electronic device comprising system 100. Host device 105 may 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 another programmable logic device, discrete gate or transistor logic, discrete hardware components, or combinations thereof. In some instances, host device 105 may be referred to as a host.
[0024] Interface controller 115 can be configured to (e.g., based on or in response to one or more commands or requests issued by host device 105) interface with volatile memory 120 and non-volatile memory 125 on behalf of host device 105. For example, interface controller 115 can facilitate the retrieval and storage of data in volatile memory 120 and non-volatile memory 125 on behalf of host device 105. Therefore, interface controller 115 can facilitate data transfer between various sub-components, such as data transfer between at least some of host device 105, volatile memory 120, or non-volatile memory 125. Interface controller 115 can interface with host device 105 and volatile memory 120 using a first protocol, and can interface with non-volatile memory 125 using a second protocol supported by non-volatile memory 125.
[0025] Non-volatile memory 125 may be configured to store digital information (e.g., data) for use in electronic devices including system 100. Therefore, non-volatile memory 125 may include an array of memory cells and a local memory controller configured to operate the array of memory cells. In some instances, the memory cells may be or include FeRAM cells (e.g., non-volatile memory 125 may be FeRAM). Non-volatile memory 125 may be configured to interface with interface controller 115 using a second protocol different from the first protocol used between interface controller 115 and host device 105. In some instances, non-volatile memory 125 may have a longer latency for access operations compared to volatile memory 120. For example, retrieving data from non-volatile memory 125 may take longer than retrieving data from volatile memory 120. Similarly, writing data to non-volatile memory 125 may take longer than writing data to volatile memory 120. In some instances, non-volatile memory 125 may have a smaller page size than volatile memory 120, as described herein.
[0026] Volatile memory 120 may be configured to serve as a cache for one or more components, such as non-volatile memory 125. For example, volatile memory 120 may store information (e.g., data) for electronic devices containing system 100. Therefore, volatile memory 120 may include an array of memory cells and a local memory controller configured to operate the array of memory cells. In some instances, the memory cells may be or include DRAM cells (e.g., the volatile memory may be DRAM). Non-volatile memory 125 may be configured to interface with interface controller 115 using a first protocol used between interface controller 115 and host device 105.
[0027] In some instances, volatile memory 120 may have shorter latency for access operations compared to non-volatile memory 125. For example, retrieving data from volatile memory 120 may take less time than retrieving data from non-volatile memory 125. Similarly, writing data to volatile memory 120 may take less time than writing data to non-volatile memory 125. In some instances, volatile memory 120 may have a larger page size compared to non-volatile memory 125. For example, the page size of volatile memory 120 may be 2 kilobytes (2kB) and the page size of non-volatile memory 125 may be 64 bytes (64B) or 128 bytes (128B).
[0028] While non-volatile memory 125 may be a higher-density memory compared to volatile memory 120, in some instances, accessing non-volatile memory 125 may take longer than accessing volatile memory 120 (e.g., due to different architectures and protocols, and other reasons). Therefore, using volatile memory 120 as a cache can reduce latency in system 100. As an example, by retrieving data from volatile memory 120 instead of from non-volatile memory 125, access requests for data from host device 105 can be satisfied relatively quickly. To facilitate the operation of volatile memory 120 as a cache, interface controller 115 may include multiple buffers 135. Buffers 135 may be disposed on the same die as interface controller 115 and may be configured to temporarily store data for transfer between volatile memory 120, non-volatile memory 125, or host device 105 (or any combination thereof) during one or more access operations (e.g., store and retrieve operations).
[0029] Access operations may also be referred to as access procedures or access routines, and may involve one or more sub-operations performed by one or more components in the memory subsystem 110. Examples of access operations may include storage operations in which data provided by the host device 105 is stored (e.g., written to) volatile memory 120 or non-volatile memory 125 (or both), and retrieval operations in which data requested by the host device 105 is obtained (e.g., read) from volatile memory 120 or non-volatile memory 125 and returned to the host device 105.
[0030] To store data in memory subsystem 110, host device 105 may issue a write command (also known as a write request, store command, or store request) to interface controller 115. The write command may contain a memory address or be accompanied by a memory address targeting a location (e.g., a set of cells) in non-volatile memory 125. In some instances, the set of memory cells may also be referred to as part of the memory. Host device 105 may also provide data to be written. Interface controller 115 may temporarily store the data in buffer 135-a. After storing the data in buffer 135-a, interface controller 115 may transfer the data from buffer 135-a to volatile memory 120 or non-volatile memory 125, or both. In write-through mode, interface controller 115 may transfer the data to both volatile memory 120 and non-volatile memory 125. In write-back mode, interface controller 115 may transfer the data only to volatile memory 120 (wherein the data is transferred to non-volatile memory 125 during a later eviction process).
[0031] In either mode, the interface controller 115 can identify appropriate locations (e.g., a set of volatile memory cells) within the volatile memory 120 for storing data associated with a write command. To do this, the interface controller 115 can implement set-associative mapping, where addresses of the non-volatile memory 125 are mapped to multiple addresses of the volatile memory 120. For example, the interface controller 115 can implement an n-way associative mapping that allows data from (or for) addresses of the non-volatile memory 125 (e.g., locations, sets of non-volatile memory cells) to be stored at one of n addresses (e.g., locations, sets of volatile memory cells, cache blocks) of the volatile memory 120, where the n addresses may be collectively referred to as a set. Therefore, the interface controller 115 can manage the volatile memory 120 as a cache of the non-volatile memory 125 by referencing a set of n addresses of the volatile memory 120 associated with a target address. Although described with reference to associative mapping, the interface controller 115 may manage the volatile memory 120 as a cache by implementing one or more other types of mapping (e.g., direct mapping or associative mapping, and other instances).
[0032] After determining which set of n addresses is associated with the target non-volatile address, the interface controller 115 can store the data at one of the n addresses in that set. Therefore, by retrieving data from the lower-latency volatile memory 120 instead of the higher-latency non-volatile memory 125, subsequent (e.g., later) read commands for the data from the host device 105 can be efficiently satisfied. Thus, write commands from the host device 105 can be satisfied fully (e.g., in write-back mode) or partially (e.g., in write-through mode) by storing the data in the volatile memory 120. To track the data stored in the volatile memory 120, the interface controller 115 can use tag addresses indicating which data is stored at different addresses in the volatile memory 120.
[0033] To retrieve data from memory subsystem 110, host device 105 sends a read command (also called a read request, retrieval command, or retrieval request) to interface controller 115. The read command can target an address in non-volatile memory 125. Upon receiving the read command, interface controller 115 can examine the requested data in volatile memory 120. For example, interface controller 115 can check whether the requested data is stored at one of n addresses associated with the target non-volatile memory address. If the data is stored at one of the n addresses, interface controller 115 can transfer the data from volatile memory 120 to buffer 135-a, making it available for transmission to host device 105. Generally, the term "hit" can be used to refer to a scenario where volatile memory 120 stores data targeted by host device 105.
[0034] If the volatile memory 120 does not store the requested data, the interface controller 115 may transfer the requested data from the non-volatile memory 125 to the buffer 135-a so that it can be transmitted to the host device 105. Generally, the term "miss" can be used to refer to a scenario where the volatile memory 120 does not store the data targeted by the host device 105. In a miss scenario, after transferring the requested data to the buffer 135-a, the interface controller 115 may transfer the requested data from the buffer 135-a to the volatile memory 120 so that subsequent read requests for the data can be satisfied through the volatile memory 120 instead of the non-volatile memory 125. For example, the interface controller 115 may store the data at one of n addresses in a set associated with the target non-volatile memory address. If other data is already stored at the n addresses, the interface controller 115 may transfer the other data to the buffer 135-b so that it can be transmitted to the non-volatile memory 125 for storage. This process can be called "evicting", and the data transferred from volatile memory 120 to buffer 135-b can be called "victimized data".
[0035] In some cases, interface controller 115 may transfer a subset of compromised data from buffer 135-b to non-volatile memory 125. For example, interface controller 115 may transfer one or more subsets of compromised data that have changed since the data was initially stored in non-volatile memory 125. Data that is inconsistent between volatile memory 120 and non-volatile memory 125 (e.g., due to an update in one memory but not in another) may be referred to as “modified” or “dirty” data in some cases. In some instances (e.g., when the interface controller is operating in a mode such as write-back mode), dirty data may be data that exists in volatile memory 120 but not in non-volatile memory 125.
[0036] Therefore, if volatile memory 120 is full, interface controller 115 may execute an eviction procedure to save data from volatile memory 120 to non-volatile memory 125 (e.g., to make room for new data in volatile memory 120). In some instances, interface controller 115 may execute a "filling" procedure in which data from non-volatile memory 125 is saved to volatile memory 120. Interface controller 115 may execute a filling procedure in the event of a miss (e.g., filling volatile memory 120 with relevant data). For example, in the event of a read miss (which occurs if a read command from host device 105 targets data stored in non-volatile memory 125 instead of volatile memory 120), interface controller 115 may retrieve (from non-volatile memory 125) the data requested by the read command and, in addition to returning the data to the host device, store the data in volatile memory 120 (e.g., so that the data can be quickly retrieved in the future).
[0037] Therefore, the memory subsystem 110 may satisfy (or “fulfill”) the request using volatile memory 120 or non-volatile memory 125, depending on the hit or miss status of the request (e.g., a read command, a write command) from the host device 105. For example, in the case of a read miss, non-volatile memory 125 may satisfy the read command from the host device 105, meaning that the data returned from the host device 105 may originate from non-volatile memory 125. And, in the case of a read hit, volatile memory 120 may satisfy the read command from the host device 105, meaning that the data returned from the host device 105 may originate from volatile memory 120. In some instances, the hit-to-miss ratio (“hit-miss ratio”) may be relatively high (e.g., the hit percentage (or “hit rate”) may be approximately 85%, while the miss percentage (or “miss rate”) may be approximately 15%).
[0038] System 100 may include any number of non-transitory computer-readable media that support the quality of service information as described herein. For example, host device 105, interface controller 115, volatile memory 120, or non-volatile memory 125 may include or otherwise access one or more non-transitory computer-readable media storing instructions (e.g., firmware) for performing the functions attributed herein to host device 105, interface controller 115, volatile memory 120, or non-volatile memory 125. For example, such instructions, if executed by host device 105 (e.g., by a host device controller), by interface controller 115, by volatile memory 120 (e.g., by a local controller), or by non-volatile memory 125 (e.g., by a local controller), may cause host device 105, interface controller 115, volatile memory 120, or non-volatile memory 125 to perform the associated functions as described herein.
[0039] In some instances, the interface controller 115 may include a local array that stores metadata for enabling the volatile memory 120 to operate as a cache for the non-volatile memory 125. For example, the local array may store tag information (e.g., tag addresses) indicating which data is stored in the volatile memory 120, dirty information (also known as dirty bits or dirty flags) indicating whether data stored in the volatile memory 120 is also stored in the non-volatile memory 125, validity information indicating whether data stored in the volatile memory 120 is valid, and other types of metadata.
[0040] To improve the reliability of metadata stored in the local array, the interface controller 115 may implement ECC protection, which may involve ECC encoding the metadata before storing it in the local array and ECC decoding the metadata before using metadata management cache operations. For example, if a command is received from the host device 105, the interface controller may read the metadata associated with the command from the local array, perform ECC decoding on the metadata, correct any detected errors in the metadata, perform ECC encoding on the metadata, and store the metadata back in the local array. Such techniques ensure that only corrected metadata is stored in the local array. However, such techniques can lead to frequent access to the local array (e.g., because the local array may be accessed multiple times for commands associated with the same metadata) and multiple ECC operations, which may adversely affect the performance of the interface controller 115.
[0041] According to the techniques described herein, interface controller 115 can reduce access to the local array by storing metadata for a row in a register between the start and precharge commands for that row. While the metadata is stored in the register, interface controller 115 can update the metadata, which reduces access to the local array and the number of ECC operations performed by interface controller 115. Accessing the local array consumes more power than accessing registers; and performing ECC operations can also consume significant amounts of power. Therefore, the techniques described herein enable interface controller 115 to reduce power consumption related to metadata management.
[0042] Figure 2 This document describes an instance of a memory subsystem 200 that supports post-ECC registers for caching metadata, based on the examples disclosed herein. Memory subsystem 200 may be used as a reference. Figure 1 An example of the described memory subsystem 110. Therefore, the memory subsystem 200 can be compared with, as referenced... Figure 1 The host device interaction is described. The memory subsystem 200 may include an interface controller 202, volatile memory 204, and non-volatile memory 206, which may be as described in reference... Figure 1 Examples of the described interface controller 115, volatile memory 120, and non-volatile memory 125. Therefore, the interface controller 202 may represent, as referenced... Figure 1 The described host device interfaces with volatile memory 204 and non-volatile memory 206. For example, the interface controller 202 may use volatile memory 204 as a cache for non-volatile memory 206. Using volatile memory 204 as a cache allows the subsystem to provide the benefits of non-volatile memory 206 (e.g., non-volatile, high-density storage) while maintaining compatibility with host devices that support protocols different from those of non-volatile memory 206.
[0043] exist Figure 2 In this diagram, dashed lines between components represent data flows or data transmission paths, while solid lines between components represent command flows or command transmission paths. In some cases, the memory subsystem 200 is one of several similar or identical subsystems that may be included in an electronic device. In some instances, each subsystem may be referred to as a slice and may be associated with a corresponding channel of the host device.
[0044] Non-volatile memory 206 can be configured to be used as main memory for a host device (e.g., memory for long-term data storage). In some cases, non-volatile memory 206 may comprise one or more arrays of FeRAM cells. Each FeRAM cell may include a select element and a ferroelectric capacitor and can be accessed by applying appropriate voltage to one or more access lines, such as word lines, board lines, and digital lines. In some instances, a subset of FeRAM cells coupled to a enabled word line may be sensed, for example, in parallel or simultaneously, without having to sense all FeRAM cells coupled to the enabled word line. Therefore, the page size of the FeRAM array may be different from (e.g., smaller than) the DRAM page size. In the context of a memory device, a page may refer to a row of memory cells (e.g., a group of memory cells with a common row address), and the page size may refer to the number of memory cells or column addresses in a row, or the number of column addresses accessed during an access operation. Alternatively, the page size may refer to the size of data handled by various interfaces, or the amount of data that a row can store. In some cases, different memory device types may have different page sizes. For example, a DRAM page size (e.g., 2kB) can be a superset of a non-volatile memory (e.g., FeRAM) page size (e.g., 64B).
[0045] The smaller page size of FeRAM arrays offers various efficiency benefits because a single FeRAM cell may require more power to read or write compared to a single DRAM cell. For example, the smaller page size used for FeRAM arrays facilitates efficient energy use because a smaller number of FeRAM cells can be initiated for minute changes in the associated information. In some instances, depending on the nature of the data and commands used for FeRAM operations, the page size of the FeRAM cell array can, for example, change dynamically (e.g., during operation of the FeRAM cell array).
[0046] While individual FeRAM cells may require more power to read or write compared to individual DRAM cells, FeRAM cells can maintain their stored logic states for extended periods in the absence of an external power supply because the ferroelectric material in the FeRAM cell can maintain a non-zero polarization in the absence of an electric field. Therefore, including an FeRAM array in non-volatile memory 206 provides power and efficiency benefits relative to volatile memory cells (e.g., DRAM cells in volatile memory 204) because it reduces or eliminates the need for refresh operations.
[0047] Volatile memory 204 can be configured to serve as a cache for non-volatile memory 206. In some cases, volatile memory 204 may comprise one or more arrays of DRAM cells. Each DRAM cell may include a capacitor containing dielectric material to store charge representing a programmable state. The memory cells of volatile memory 204 may be logically grouped or arranged into one or more memory banks (as referred to herein as "banks"). For example, volatile memory 204 may comprise sixteen banks. The memory cells of a bank may be arranged in a grid or an array of intersecting columns and rows, and each memory cell may be accessed or refreshed by applying an appropriate voltage to the digital lines (e.g., column lines) and word lines (e.g., row lines) for the memory cell. A row of a bank may be referred to as a page, and the page size may refer to the number of columns or the number of memory cells in a row (and therefore, the amount of data that a row can store). As mentioned, the page size of volatile memory 204 may be different from (e.g., larger than) the page size of non-volatile memory 206.
[0048] Interface controller 202 may include various circuitry for interfacing (e.g., communicating) with other devices such as host devices, volatile memory 204, and non-volatile memory 206. For example, interface controller 202 may include a data (DA) bus interface 208, a command and address (C / A) bus interface 210, a data bus interface 212, a C / A bus interface 214, a data bus interface 216, and a C / A bus interface 264. The data bus interfaces may support the use of one or more communication protocols to transmit information. For example, data bus interface 208, C / A bus interface 210, data bus interface 216, and C / A bus interface 264 may support information transmitted using a first protocol (e.g., LPDDR signaling), while data bus interface 212 and C / A bus interface 214 may support information transmitted using a second protocol. Therefore, the various bus interfaces coupled to interface controller 202 may support different data volumes or data rates.
[0049] Data bus interface 208 may be coupled to data bus 260, transaction bus 222, and buffer circuitry system 224. Data bus interface 208 may be configured to transmit and receive data via data bus 260 and to transmit and receive control information (e.g., acknowledgment / negative acknowledgment) or metadata via transaction bus 222. Data bus interface 208 may also be configured to transfer data between data bus 260 and buffer circuitry system 224. Data bus 260 and transaction bus 222 may be coupled to interface controller 202 and host device, thereby establishing a conductive path between interface controller 202 and host device. In some instances, the pin of transaction bus 222 may be referred to as a Data Mask Inversion (DMI) pin. Although shown as having one data bus 260 and one transaction bus 222, any number of data buses 260 and any number of transaction buses 222 may be coupled to one or more data bus interfaces 208.
[0050] C / A bus interface 210 can be coupled to C / A bus 226 and decoder 228. C / A bus interface 210 can be configured to transmit and receive commands and addresses via C / A bus 226. Commands and addresses received via C / A bus 226 can be associated with data received or transmitted via data bus 260. C / A bus interface 210 can also be configured to transmit commands and addresses to decoder 228, such that decoder 228 can decode the commands and forward the decoded commands and associated addresses to command circuitry system 230.
[0051] Data bus interface 212 can be coupled to data bus 232 and memory interface circuitry 234. Data bus interface 212 can be configured to transmit and receive data via data bus 232, which can be coupled to non-volatile memory 206. Data bus interface 212 can also be configured to transfer data between data bus 232 and memory interface circuitry 234. C / A bus interface 214 can be coupled to C / A bus 236 and memory interface circuitry 234. C / A bus interface 214 can be configured to receive commands and addresses from memory interface circuitry 234 and forward the commands and addresses to non-volatile memory 206 via C / A bus 236 (e.g., to a local controller of non-volatile memory 206). Commands and addresses transmitted via C / A bus 236 can be associated with data received or transmitted via data bus 232. The data bus 232 and the C / A bus 236 can be coupled to the interface controller 202 and the non-volatile memory 206, thereby establishing a conductive path between the interface controller 202 and the non-volatile memory 206.
[0052] Data bus interface 216 may be coupled to data bus 238 (e.g., data bus 238-a, data bus 238-b) and memory interface circuitry 240. Data bus interface 216 may be configured to transmit and receive data via data bus 238, which may be coupled to volatile memory 204. Data bus interface 216 may also be configured to transfer data between data bus 238 and memory interface circuitry 240. C / A bus interface 264 may be coupled to C / A bus 242 and memory interface circuitry 240. C / A bus interface 264 may be configured to receive commands and addresses from memory interface circuitry 240 and forward commands and addresses to volatile memory 204 (e.g., to a local controller of volatile memory 204) via C / A bus 242. Commands and addresses transmitted via C / A bus 242 may be associated with data received or transmitted via data bus 238. The data bus 238 and the C / A bus 242 can be coupled to the interface controller 202 and the volatile memory 204, thereby establishing a conductive path between the interface controller 202 and the volatile memory 204.
[0053] In addition to the bus and bus interface for communicating with the coupled device, the interface controller 202 may also include circuitry for using non-volatile memory 206 as main memory and volatile memory 204 as cache. For example, the interface controller 202 may include command circuitry 230, buffer circuitry 224, cache management circuitry 244, one or more engines 246, and one or more schedulers 248.
[0054] Command circuitry system 230 may be coupled to buffer circuitry system 224, decoder 228, cache management circuitry system 244, scheduler 248, and other components. Command circuitry system 230 may also be referred to as a controller and may be configured to manage commands for volatile memory and commands for non-volatile memory. Command circuitry system 230 may be configured to receive command and address information from decoder 228 and store the command and address information in queue 250. Command circuitry system 230 may include logic 262 that processes command information (e.g., from a host device) and metadata from other components (e.g., cache management circuitry system 244, buffer circuitry system 224) and uses the information to generate one or more commands for scheduler 248. Command circuitry system 230 may also be configured to transmit address information (e.g., address bits) to cache management circuitry system 244. In some instances, logic 262 may be circuitry configured to function as a finite state machine (FSM).
[0055] Buffer circuitry system 224 may be coupled to data bus interface 208, command circuitry system 230, memory interface circuitry system 234, and memory interface circuitry system 234. Buffer circuitry system 224 may include a collection of one or more buffer circuits for at least some (if not every) banks of volatile memory 204. Buffer circuitry system 224 may also include components for accessing the buffer circuitry (e.g., a memory controller). In one example, volatile memory 204 may include sixteen banks, and buffer circuitry system 224 may include sixteen collections of buffer circuitry. Each collection of buffer circuitry may be configured to store data from or for a corresponding bank of volatile memory 204. As an example, the collection of buffer circuitry for bank 0 (BK0) may be configured to store data from or for a first bank of volatile memory 204, and the buffer circuitry for bank 15 (BK15) may be configured to store data from or for a sixteenth bank of volatile memory 204.
[0056] Each set of buffer circuits in buffer circuit system 224 may include a pair of buffers. The pair of buffers may include: one buffer (e.g., an Open Page Data (OPD) buffer) configured to store data targeted by an access command (e.g., a write command or read command) from the host device; and another buffer (e.g., a Victim Page Data (VPD) buffer) configured to store data for an eviction process triggered by the access command. For example, the set of buffer circuits for BK0 may include buffers 218 and 220, which may be instances of buffers 135-a and 135-b, respectively. Buffer 218 may be configured to store BK0 data targeted by an access command from the host device. Furthermore, buffer 220 may be configured to store data transferred from BK0 as part of a eviction process triggered by an access command. Each buffer in the set of buffer circuits may be configured to have a size (e.g., storage capacity) corresponding to the page size of volatile memory 204. For example, if the page size of volatile memory 204 is 2kB, then the size of each buffer can be 2kB. Therefore, in some instances, the size of the buffer can be equal to the page size of volatile memory 204.
[0057] Cache management circuitry system 244 may be coupled to command circuitry system 230, engine 246, scheduler 248, and other components. Cache management circuitry system 244 may include sets of cache management circuitry for one or more banks of volatile memory (e.g., each bank). As an example, cache management circuitry system 244 may include sixteen sets of cache management circuitry for BK0 through BK15. Each set of cache management circuitry may include two memory arrays configured to store metadata for volatile memory 204. As an example, the set of cache management circuitry for BK0 may include memory array 252 (e.g., a cache DRAM (CDRAM) tag array (CDT-TA)) and memory array 254 (e.g., a CDRAM active (CDT-V) array), configured to store metadata for BK0. In some instances, memory arrays for multiple banks (e.g., two banks) may be combined and referred to as groups or blocks. Memory arrays may also be referred to as arrays, local arrays, or buffers, among other suitable terms. In some cases, memory arrays may be or contain volatile memory cells, such as static RAM (SRAM) cells. However, memory arrays are not limited to SRAM.
[0058] Metadata (or "access information") may include tag information, validity information, or dirty information (or any combination thereof) associated with volatile memory 204, and other instances. Tag information (e.g., tag addresses) may indicate which data is stored at an address in volatile memory 204. For example, tag information for an address in volatile memory 204 may indicate a non-volatile memory address associated with data stored at that address in volatile memory 204. As mentioned, validity information may indicate whether the data stored in volatile memory 204 is actual data (e.g., data with an expected order or form) or placeholder data (e.g., random or dummy data without an expected or significant order). Furthermore, dirty information may indicate whether the data stored in volatile memory 204 differs from the corresponding data stored in non-volatile memory 206. For example, dirty information may indicate whether the data stored in volatile memory 204 has been updated relative to the data stored in non-volatile memory 206.
[0059] Memory array 252 may be an instance of a local array and may contain memory cells storing metadata (e.g., tag information, validity information, dirty information) of one or more associated stores of volatile memory 204. Memory array 252 may also be referred to as a tag memory array or tag memory. The metadata in memory array 252 may be stored row-wise (e.g., there may be corresponding metadata for each row associated with a volatile memory store). Interface controller 202 can examine requested data in volatile memory 204 by referring to the metadata in memory array 252. For example, interface controller 202 may receive a read command from a host device for data associated with an address in non-volatile memory 206. Interface controller 202 may use a subset of address bits to refer to the metadata in memory array 252. For example, using set-associative mapping, interface controller 202 may use a first subset of address bits to determine which set of n addresses is associated with the data, and may use a second subset of address bits to determine whether any of the n addresses in the set stores the data.
[0060] In addition to storing tag information, memory array 252 may also store validity information indicating whether data in volatile memory 204 is actual data (also called valid data) or random data (also called invalid data). For example, volatile memory 204 may initially store random data and continue to do so until data is written to the volatile memory cells from a host device or non-volatile memory 206. To track which data is valid, memory array 252 may be configured to set a bit of the set of volatile memory cells (e.g., rows) when actual data is stored. This bit may be called a validity bit or validity flag. Like tag information, validity information stored in memory array 252 may be stored row-wise. Thus, in some instances, each validity bit may indicate the validity of data stored in the associated row. In some instances, memory array 252 may store dirty information indicating whether a set of volatile memory cells (e.g., rows) stores any dirty data. Similar to validity information, dirty information stored in memory array 252 may be stored row-wise.
[0061] Memory array 254 may also be an instance of a local array. Memory array 254 may also be referred to as a data memory array or data memory. Memory array 254 may be similar to memory array 252 and may also include memory cells that store metadata for one or more banks of volatile memory 204 associated with memory array 252. For example, memory array 254 may store validity information and dirt information for one or more banks of volatile memory 204. However, the metadata stored in memory array 254 may be stored by sub-blocks rather than by rows. For example, validity information stored in memory cells of memory array 254 may indicate the validity of data for a subset of volatile memory cells in a row of volatile memory 204.
[0062] Therefore, in some instances, metadata in memory array 252 may be stored row-wise (e.g., for 2kB of data) and sub-block-wise (e.g., for 64B of data). For illustration, validity information in memory array 254 may indicate the validity of each subset (e.g., 32B or 64B) of data stored in rows of volatile memory 204. Similarly, dirty information stored in memory array 254 may indicate which subsets of volatile memory cells in rows of volatile memory 204 store dirty data. Storing metadata (e.g., tag information, validity information, dirty information) row-wise in memory array 252 allows interface controller 202 to determine whether data in volatile memory 204 has a hit or a miss. Storing metadata (e.g., validity information, dirty information) in sub-blocks in memory array 254 allows interface controller 202 to determine which subsets of the data to return to the host device (e.g., during a read process) and which subsets of the data to retain in non-volatile memory 206 (e.g., during an eviction process).
[0063] Each cache management circuitry may also include a corresponding pair of registers, which are coupled to command circuitry system 230, engine 246, memory interface circuitry system 234, memory interface circuitry system 240, and the memory array for the cache management circuitry, as well as other components. For example, the cache management circuitry may include a first register (e.g., register 256, which may be an Open Page Tag (OPT) register) configured to receive metadata (e.g., tag information, validity information, or dirty information, other information, or one or more bits of any combination) from memory array 252 or scheduler 248-b, or both. The cache management circuitry may also include a second register (e.g., register 258, which may be a Victim Page Tag (VPT) register) configured to receive metadata (e.g., validity information, or dirty information, or both) from memory array 254 and scheduler 248-a, or both. Information in registers 256 and 258 can be passed to command circuitry system 230 and engine 246 to enable decisions to be made by these components. For example, the command circuitry system 230 may issue a command to read non-volatile memory 206 or volatile memory 204 based on or in response to metadata in register 256 and / or register 258 or both.
[0064] Engine 246-a may be coupled to registers 256 and 258 and scheduler 248. Engine 246-a may be configured to receive metadata from various components and issue commands to scheduler 248 based on or in response to said metadata. For example, if interface controller 202 is in a first mode, such as write-through mode, engine 246-a may issue commands to scheduler 248-b, and in response, scheduler 248-b initiates or facilitates data transfer from buffer 218 to both volatile memory 204 and non-volatile memory 206. Alternatively, if interface controller 202 is in a second mode, such as write-back mode, engine 246-a may issue commands to scheduler 248-b, and in response, scheduler 248-b initiates or facilitates data transfer from buffer 218 to volatile memory 204. In the case of a write-back operation, the data stored in volatile memory 204 may eventually be transferred to non-volatile memory 206 during a subsequent (e.g., later) eviction process.
[0065] Engine 246-b may be coupled to register 258 and scheduler 248-a. Engine 246-b may be configured to receive metadata from register 258 and issue commands to scheduler 248-a based on or in response to said metadata. For example, engine 246-b may issue commands to scheduler 248-a to initiate or facilitate the transfer of dirty data from buffer 220 to non-volatile memory 206 (e.g., as part of a retrieval process). If buffer 220 holds a dataset (e.g., victim data) transferred from volatile memory 204, engine 246-b may indicate which one or more subsets (e.g., which 64Bs) of the dataset in buffer 220 should be transferred to non-volatile memory 206.
[0066] Scheduler 248-a may be coupled to various components of interface controller 202 and may facilitate access to non-volatile memory 206 by issuing commands to memory interface circuitry 234. Commands issued by scheduler 248-a may be based on commands from command circuitry 230, engine 246-a, engine 246-b, or a combination of these components. Similarly, scheduler 248-b may be coupled to various components of interface controller 202 and may facilitate access to volatile memory 204 by issuing commands to memory interface circuitry 240. Commands issued by scheduler 248-b may be based on or in response to commands from command circuitry 230 or engine 246-a, or both.
[0067] The memory interface circuitry 234 can communicate with the non-volatile memory 206 via one or more of the data bus interface 212 and the C / A bus interface 214. For example, the memory interface circuitry 234 can prompt the C / A bus interface 214 to forward commands issued by the memory interface circuitry 234 to the local controller in the non-volatile memory 206 via the C / A bus 236. Furthermore, the memory interface circuitry 234 can send data to or receive data from the non-volatile memory 206 via the data bus 232. In some instances, commands issued by the memory interface circuitry 234 may be supported by the non-volatile memory 206 but not by the volatile memory 204 (e.g., commands issued by the memory interface circuitry 234 may differ from commands issued by the memory interface circuitry 240).
[0068] The memory interface circuitry 240 can communicate with the volatile memory 204 via one or more of the data bus interface 216 and the C / A bus interface 264. For example, the memory interface circuitry 240 can prompt the C / A bus interface 264 to forward commands issued by the memory interface circuitry 240 to the local controller of the volatile memory 204 via the C / A bus 242. Furthermore, the memory interface circuitry 240 can send or receive data to or from the volatile memory 204 via one or more data buses 238. In some instances, commands issued by the memory interface circuitry 240 may be supported by the volatile memory 204 but not by the non-volatile memory 206 (e.g., commands issued by the memory interface circuitry 240 may differ from commands issued by the memory interface circuitry 234).
[0069] In summary, the components of interface controller 202 can use non-volatile memory 206 as main memory and volatile memory 204 as cache. Such operations can be prompted by one or more access commands (e.g., read commands and write commands) received from the host device.
[0070] In some instances, interface controller 202 may receive write commands from a host device. The write command may be received via C / A bus 226 and transmitted to command circuitry 230 via one or more of C / A bus interface 210 and decoder 228. The write command may include or be accompanied by address bits targeting a memory address of non-volatile memory 206. Data to be written may be received via data bus 260 and transmitted to buffer 218 via data bus interface 208. In write-through mode, interface controller 202 may transmit data to both non-volatile memory 206 and volatile memory 204. In write-back mode, in some instances, interface controller 202 may transmit data only to volatile memory 204.
[0071] In either mode, the interface controller 202 may first check whether the volatile memory 204 has space for storing data (e.g., available memory cells). To do this, the command circuitry system 230 may refer to metadata in the appropriate memory array 252 to determine whether one or more of the n addresses associated with the non-volatile memory address are empty (e.g., storing random or invalid data) or whether one or more of the n addresses associated with the non-volatile memory address are full (e.g., storing valid data). For example, the command circuitry system 230 may determine whether one or more of the n addresses are available for writing (or not available for writing) based on tag information and validity information stored in the memory array 252. The addresses of the volatile memory 204 may be associated with a set of volatile memory cells, which may be referred to as a line, cache line, cache block, or row.
[0072] If one of the n associated addresses is available for writing, the interface controller 202 can transfer data from buffer 218 to volatile memory 204 for storage at said address (e.g., in a set of associated volatile memory cells). However, if none of the n associated addresses are available, the interface controller 202 can initiate an eviction process to free up space in volatile memory 204 for data. The eviction process may involve transferring compromised data from one of the n associated addresses to buffer 220. Dirty information for the compromised data can be transferred from memory array 254 to register 258 for identification of a dirty subset of the compromised data. After the compromised data is stored in buffer 220, new data can be transferred from buffer 218 to volatile memory 204, and compromised data can be transferred from buffer 220 to non-volatile memory 206. In some cases, a dirty subset of the old data can be transferred to non-volatile memory 206 and a clean subset (e.g., an unmodified subset) can be discarded. Engine 246-b can identify a dirty subset based on or in response to dirty information transferred from memory array 254 to register 258 during the eviction process.
[0073] In another example, interface controller 202 may receive commands, such as read commands, from a host device. Read commands may be received via C / A bus 226 and transmitted to command circuitry 230 via one or more of C / A bus interface 210 and decoder 228. Read commands may include address bits targeting a memory address of non-volatile memory 206. Before attempting to access the target memory address of non-volatile memory 206, interface controller 202 may check whether volatile memory 204 stores data. To do this, command circuitry 230 may refer to metadata in memory array 252 (e.g., using a set of non-volatile memory address bits) to determine whether one or more of n addresses associated with the non-volatile memory address store the requested data. If the requested data is stored in volatile memory 204, interface controller 202 may transmit the requested data to buffer 218 for transmission to the host device via data bus 260.
[0074] If the requested data is not stored in volatile memory 204 (e.g., the requested data may be stored in non-volatile memory 206 or another location), interface controller 202 may retrieve the data from non-volatile memory 206 and transfer the data to buffer 218 for transmission to the host device via data bus 260. Alternatively, interface controller 202 may transfer the requested data from buffer 218 to volatile memory 204 for lower latency access during subsequent retrieval operations. However, before transferring the requested data, interface controller 202 may first determine whether one or more of the n associated addresses are available to store the requested data (e.g., whether one or more of the n associated addresses are empty or full). Interface controller 202 may determine the availability of the n associated addresses by communicating with the relevant cache management circuitry. If the associated addresses are available, interface controller 202 may transfer the data in buffer 218 to volatile memory 204 without performing an eviction process. Otherwise, the interface controller 202 may transfer the data from the buffer 218 to the volatile memory 204 after the recovery process.
[0075] The memory subsystem 200 can be implemented in one or more configurations, including a single-chip version and a multi-chip version. The multi-chip version may include one or more components of the memory subsystem 200, including interface controller 202, volatile memory 204, and non-volatile memory 206 (and other components or combinations thereof), on a separate chip from the chip containing one or more other components of the memory subsystem 200. For example, in a multi-chip version, the corresponding separate chip may include each of interface controller 202, volatile memory 204, and non-volatile memory 206. In contrast, the single-chip version may include interface controller 202, volatile memory 204, and non-volatile memory 206 on a single chip.
[0076] In some instances, memory array 252 (or memory array 254) may include or be coupled to one or more registers. For example, memory array 252 may include or be coupled to a register for each bank of volatile memory 204, and memory array 254 may also include or be coupled to a register for each bank of volatile memory 204. As described herein, interface controller 202 may use registers to store metadata from the array, allowing the metadata to be updated without multiple array accesses (and without performing multiple ECC operations), which improves the power efficiency of interface controller 202.
[0077] Figure 3 This describes an instance of an interface controller 300 that supports post-ECC registers for caching metadata, as disclosed in this document. The interface controller 300 may be as described in the references... Figure 1 The interface controller 115 described or as referenced Figure 2 An example of the described interface controller 202. Interface controller 300 may include a local array 305, which may be as described in the reference... Figure 2 Examples of memory array 252 or memory array 254 described herein. As described herein, interface controller 300 may use registers to store metadata from local array 305, which may improve the power consumption of interface controller 300. Although shown as having a single local array, interface controller 300 may contain any number of local arrays, which may be instances of memory array 252, memory array 254, or both.
[0078] Local array 305 may contain multiple (e.g., k, where k is an integer) groups (e.g., blocks) of memory cells, each of which may store metadata for one or more banks of volatile memory. For example, group 0 may store metadata for banks 0 and 1, group 1 may store metadata for banks 2 and 3, and so on. Each group may contain entries for a set of addresses for volatile memory. Therefore, there may be N entries for N sets of addresses. There may be n (e.g., 16) paths in the set, and each path may correspond to a row address of volatile memory. In some instances, each path in the set may be identified by a path index.
[0079] In an example where local array 305 is memory array 252, local array 305 may store tag information (e.g., tag address bits), validity information, and dirty information by row or according to other possible granularity levels. Thus, tag information for a path may indicate data in a row of volatile memory, validity information for a path may indicate the validity status of a row, and dirty information for a path may indicate the dirty status of the row. Local array 305 may also include ECC bits for metadata in the local array. In some instances, local array 305 may also include replacement policy information for evicting data from volatile memory. The enlarged upper view of group k illustrates a simplified entry for an example where local array 305 is memory array 252.
[0080] In an instance where local array 305 is memory array 254, local array 305 may store validity information by sub-block or according to other possible granularity levels. For example, validity information for a path may include validity information for 64-byte sub-blocks of data within a row. Local array 305 may also include ECC bits for metadata in local array 305. The lower enlarged view of group k illustrates a simplified entry for an instance where local array 305 is memory array 254.
[0081] Therefore, local array 305 can store metadata for enabling volatile memory to operate as a cache, as well as ECC bits for the metadata. In one instance, local array 305 can be operated by controller 310, which may be an instance of a finite state machine. Controller 310 can issue control signals to local array 305 to cause local array 305 to perform aspects of the techniques described herein, such as reading and writing metadata and ECC bits. In some instances, local array 305 may be or may contain a static random access (SRAM) array. However, local array 305 is not limited to SRAM and may be or may contain different types of arrays, such as DRAM, and other memory technologies.
[0082] Local array 305 may be coupled to comparison logic 315, which may be configured to compare tag information stored in local array 305 with tag information from an incoming command, and in doing so, determine whether there is a hit or a miss for the command. If a hit occurs, comparison logic 315 may output a hit indication along with the tag information associated with the hit. Comparison logic 315 may also be configured to transmit metadata information (e.g., tag information) from local array 305 to ECC logic 320. In one instance, comparison logic 315 may include one or more comparators (e.g., the comparison logic may include N comparators to compare tag information of N paths in a set or include any other number of comparators), and other options.
[0083] ECC logic 320 may be coupled to local array 305 (e.g., via comparator logic 315) and register 340. ECC logic 320 may be configured to perform ECC operations on metadata, such as ECC encoding and ECC decoding.
[0084] ECC logic 320 may include encoding logic 325, decoding logic 330, and correction logic 335. Encoding logic 325 may be configured to perform ECC encoding on metadata (e.g., by applying error correction codes to the metadata). Encoding logic 325 may output a codeword (referred to as a metadata codeword) containing metadata and parity bits (also called ECC bits) generated by ECC encoding. Decoding logic 330 may be configured to perform ECC decoding on the metadata codeword to detect errors in the metadata codeword. For example, decoding logic 330 may use the metadata codeword and error correction codes to generate correction sub-bits indicating the location of errors in the metadata codeword. Correction logic 335 may be coupled to decoding logic 330 and may be configured to correct errors in the metadata codeword detected by decoding logic 330. ECC logic 320 may be configured to communicate indications of metadata errors to other components of the interface controller, such as command circuitry 230 or scheduler 248.
[0085] Register 340 can be configured to receive and store corrected metadata from ECC logic 320. In some instances, one register 340 may exist for each bank of volatile memory (e.g., the number of registers 340 may be equal to the number of banks in volatile memory), and each register 340 may be configured to store metadata for the individual bank associated with that register 340. For example, if there are y banks in volatile memory, there may be y registers 340, and each register 340 may store metadata for the bank corresponding to that register. It is possible to prevent volatile memory from opening more than a single row in a given bank at any given time; therefore, having register 340 for each bank of volatile memory allows interface controller 300 to efficiently manage the metadata of the banks in parallel. Register 340 may be controlled by control circuitry 345, which may issue control signals to registers and supporting circuitry (e.g., access circuitry) to implement aspects of the techniques described herein. In some other instances, each bank of the volatile memory may have a different set of n registers 340 (e.g., the number of registers 340 may differ from the number of banks in the volatile memory), and each register 340 may be configured to store metadata of one or more banks associated with that register 340. For example, if there are y banks in the volatile memory, there may be z registers 340, and each register 340 may store metadata corresponding to one or more banks.
[0086] If the metadata is stored in register 340, the interface controller 300 can update the metadata based on or in response to commands from the host device. Therefore, compared to other techniques that access the local array 305 to update metadata information, the interface controller 300 can save power by accessing register 340 to update metadata information. Additionally, updating the metadata in register 340 allows the interface controller 300 to avoid performing multiple rounds of ECC operations on the metadata, which reduces power consumption compared to other techniques that perform multiple rounds of ECC operations. If register 340 stores corrected metadata, register 340 can transmit the corrected metadata to other components of the interface controller, such as command circuitry 230 or scheduler 248.
[0087] Therefore, the interface controller 300 can use registers 340 to store and update metadata, which reduces power consumption at the interface controller compared to other technologies. Although shown as having a single local array 305 and a single set of registers 340, the interface controller 300 may include multiple local arrays (e.g., memory array 252 and memory array 254) and a set of registers 340 for each local array 305.
[0088] Figure 4This describes an example of a processing flow 400 for the post-ECC register of cached metadata, based on examples disclosed herein. Processing flow 400 can be found in the reference... Figure 1 The described memory subsystem 110 or interface controller 115, reference Figure 2 The described memory subsystem 200 or interface controller 202 or reference Figure 3 The interface controller 300 described is implemented. However, other types of devices or components (or combinations thereof) may implement the processing flow 400. The processing flow 400 may describe the operation of a device that uses registers to store and manage metadata of volatile memory operating as a cache for non-volatile memory.
[0089] For ease of reference, the reference apparatus describes processing flow 400. For example, aspects of processing flow 400 may be implemented by means of volatile memory and non-volatile memory. Alternatively, aspects of processing flow 400 may be implemented as instructions stored in memory (e.g., firmware stored in volatile memory 120 or non-volatile memory 125, or both). For example, instructions, when executed by a controller, may cause the controller to perform the operation of processing flow 400.
[0090] At 405, a command, such as an ACT command, can be received from the host device. For example, the interface controller 300 can receive an ACT command for a row of a bank of volatile memory. A row can be a collection of memory cells sharing a common word line. The ACT command prompts the interface controller 300 to initiate (e.g., enable) the row. In some instances, the ACT command issued by the host device can be used to enable the row taking into account the host media characteristics of memory protocols such as LPDDR5. In such instances, the host device may not be aware of the bank-row structure of volatile and non-volatile memory. Therefore, the interface controller 300 can map the ACT command from the host device to the bank-row structure of volatile memory, non-volatile memory, or both.
[0091] At 410, metadata can be read from the local array. For example, interface controller 300 can read metadata associated with a startup command from local array 305, which may be an instance of memory array 252 or memory array 254. Interface controller 300 can also read parity bits of the metadata from local array 305. At 415, ECC decoding can be performed on the metadata (or more specifically, ECC decoding can be performed on a metadata codeword containing the metadata and its parity bits). Interface controller 300 can pass the metadata from local array 305 to ECC logic 320, such that decoding logic 330 can perform ECC decoding on the metadata.
[0092] At point 420, it can be determined whether an error exists in the metadata. For example, interface controller 300 can determine whether an error exists in the metadata based on or in response to ECC decoding. If an error is determined to exist in the metadata at point 420, processing flow 400 can continue to point 435. If no error is determined to exist in the metadata at point 420, processing flow 400 can continue to point 425.
[0093] At 425, an error indication may be sent. For example, interface controller 300 may (e.g., via ECC logic) send an error indication to one or more other components of interface controller 300, such as a controller (e.g., command circuit system 230), scheduler 248, or both. Sending the error indication prevents other components from using uncorrected metadata (which is sent to other components between 410 and 415) for cache management. At 430, error correction may occur. For example, interface controller 300 may (e.g., via correction logic 335) correct one or more correctable errors in the metadata. If the error in the metadata is uncorrectable, interface controller 300 may send an indication of the uncorrectable error to one or more other components of interface controller 300.
[0094] At 435, metadata can be written to a register. For example, interface controller 300 can write metadata to register 340 corresponding to the memory bank indicated by the start command. The metadata written to the register can be received by the register from ECC logic 320 (possibly after error correction if an error is detected at 420). At 440, metadata can be sent to one or more components of interface controller 300. For example, interface controller 300 can send the metadata written to register to command circuit system 230, scheduler 248, or both. Interface controller 300 can send metadata from registers such that other components can use a corrected version of the metadata after reading metadata from local array 305 to replace the metadata sent from comparison logic 315 (e.g., for latency purposes). Other components can replace previously sent metadata with corrected metadata based on or in response to an error indication sent at 425.
[0095] At 445, commands for rows of the memory bank can be received. For example, interface controller 300 can receive read or write commands for rows of the memory bank. At 450, metadata in registers can be updated. For example, interface controller 300 can update metadata in registers based on or in response to commands received at 445. By updating metadata in registers, interface controller 300 can save power that would otherwise be consumed when accessing local array 305 and performing additional ECC operations on metadata.
[0096] At 455, commands such as a precharge (PRE) command can be received. For example, interface controller 300 can receive a precharge command for a row of volatile memory. The precharge command can prompt interface controller 300 to undo the startup (e.g., shutdown) of a row. In some instances, a precharge command issued by the host device can be used to shut down a row taking into account the host media characteristics of memory protocols such as LPDDR5. In such instances, the host device may not be aware of the bank-row structure of volatile and non-volatile memory. Therefore, interface controller 300 can map the precharge command from the host device to the bank-row structure of volatile memory, non-volatile memory, or both.
[0097] At 460, ECC encoding can be performed. For example, interface controller 300 can (e.g., via encoding logic 325) apply error correction codes to the metadata to produce a metadata codeword containing the metadata and parity bits for the metadata. Interface controller 300 can pass the metadata from a register to ECC logic 320 based on or in response to a precharge command. At 465, the metadata (or more specifically, the metadata codeword) can be written to local array 305.
[0098] Although described with reference to a single local array 305, processing flow 400 may include additional operations similar to and in parallel with operations 405 to 465 occurring for a second local array 305 (e.g., at least partially overlapping in time). Alternative instances of the foregoing may be implemented, in which some operations may be performed in a different order than described, in parallel, or not at all. In some cases, operations may include additional features not mentioned herein, or additional operations may be added. Furthermore, certain operations may be performed multiple times, or certain combinations of repeatable or cyclical operations may be performed.
[0099] Figure 5 A block diagram 500 illustrates a device 520 for supporting a post-ECC register for caching metadata, based on an example disclosed herein. Device 520 may be as described in the references... Figures 1 to 4 Examples of various aspects of the described apparatus. Apparatus 520 or its various components may be examples of components used to perform the various aspects of the post-error correction code register for cached metadata as described herein. For example, apparatus 520 may include array access circuitry 525, ECC logic 530, register access circuitry 535, receive circuitry 540, transmit circuitry 545, or any combination thereof. Each of these components may communicate with each other directly or indirectly (e.g., via one or more buses).
[0100] Array access circuitry 525 may be configured or otherwise support means for reading metadata from a memory array contained in an interface controller coupled to volatile and non-volatile memory, the metadata containing information for enabling the volatile memory to operate as a cache for the non-volatile memory. ECC logic 530 may be configured or otherwise support means for performing ECC operations on metadata, at least in part based on reading metadata from the memory array. Register access circuitry 535 may be configured or otherwise support means for writing metadata to registers coupled to the memory array, at least in part based on performing ECC operations. In some instances, array access circuitry 525 may be configured or otherwise support means for writing metadata from registers to the memory array.
[0101] In some instances, the receiving circuitry 540 may be configured or otherwise supported to include means for receiving a start command for a row of memory in volatile memory, wherein metadata is read from the memory array at least in part based on the start command. In some instances, the receiving circuitry 540 may be configured or otherwise supported to include means for receiving a precharge command for a row of memory in volatile memory, wherein metadata is written to the memory array at least in part based on the precharge command.
[0102] In some instances, the receiving circuitry 540 may be configured or otherwise supported to include means for receiving read or write commands for a row after a start command has been received. In some instances, the register access circuitry 535 may be configured or otherwise supported to include means for updating metadata in a register, at least in part, based on a read or write command.
[0103] In some instances, the receiving circuitry system 540 may be configured or otherwise support components for determining, at least in part, a storage bank associated with metadata of a memory array based on a startup command, wherein metadata is written to registers at least in part based on registers configured for the storage bank.
[0104] In some instances, array access circuitry 525 may be configured or otherwise support components for reading parity bits from the memory array, wherein ECC operations are performed at least in part based on the parity bits used for the metadata. In some instances, ECC logic 530 may be configured or otherwise support components for decoding (as part of the ECC operation) a codeword containing parity bits and metadata. In some instances, ECC logic 530 may be configured or otherwise support components for detecting errors in the metadata at least in part based on decoding the codeword.
[0105] In some instances, the ECC logic 530 may be configured or otherwise support components for detecting errors in metadata based at least in part on ECC operation. In some instances, the ECC logic 530 may be configured or otherwise support components for correcting errors detected in metadata based at least in part on the detected errors, wherein the metadata is written to a register after the errors are corrected.
[0106] In some instances, the transmit circuitry system 545 may be configured or otherwise support components for sending error indications to a controller included in an interface controller (the controller being used to manage commands for volatile memory and commands for non-volatile memory). In some instances, the transmit circuitry system 545 may be configured or otherwise support components for sending corrected metadata to the controller after sending an error indication.
[0107] In some instances, metadata is associated with a first bank of the memory array, and array access circuitry 525 may be configured or otherwise supported for means of reading second metadata from the memory array, the second metadata being associated with a second bank of the memory array. In some instances, metadata is associated with a first bank of the memory array, and register access circuitry 535 may be configured or otherwise supported for means of writing the second metadata to a second register coupled to the memory array, at least in part based on performing a second ECC operation on the second metadata.
[0108] Figure 6 The illustration shows a flowchart of method 600 for supporting a post-ECC register for caching metadata, based on examples disclosed herein. Operation of method 600 can be implemented by means or components thereof as described herein. For example, it can be implemented by means of, as referenced herein... Figures 1 to 5 The described apparatus performs the operations of method 600. In some instances, the apparatus may execute a set of instructions to control the functional elements of the apparatus to perform the described functions. Alternatively, the apparatus may use dedicated hardware to perform aspects of the described functions.
[0109] At 605, the method may include reading metadata from a memory array contained in an interface controller coupled to volatile and non-volatile memory, the metadata containing information for enabling the volatile memory to operate as a cache for the non-volatile memory. The operation of 605 may be performed according to examples as disclosed herein. In some instances, aspects of the operation of 605 may be provided by reference to [reference needed]. Figure 5 The described array access circuitry system 525 is executed.
[0110] At 610, the method may include performing an ECC operation on the metadata, at least in part, based on reading the metadata from the memory array. The operation at 610 may be performed according to examples disclosed herein. In some instances, aspects of the operation at 610 may be derived from references... Figure 5 The described ECC logic 530 is executed.
[0111] At 615, the method may include writing metadata to a register coupled to the memory array, at least in part based on performing an ECC operation. The operation at 615 may be performed according to examples disclosed herein. In some instances, aspects of the operation at 615 may be derived from references... Figure 5 The described register access circuitry is executed by system 535.
[0112] At 620, the method may include writing metadata from a register to a memory array. The operation at 620 may be performed according to examples disclosed herein. In some instances, aspects of the operation at 620 may be as described in references... Figure 5 The described array access circuitry system 525 is executed.
[0113] In some instances, the device described herein may perform one or more methods, such as method 600. The device may include features, circuitry, logic, components, or instructions (e.g., a non-transitory computer-readable medium storing instructions executable by a processor) for reading metadata (which includes information for enabling the volatile memory to operate as a cache for the non-volatile memory) from a memory array contained in an interface controller coupled to volatile and non-volatile memory, at least in part based on reading the metadata from the memory array, and at least in part based on performing the ECC operation to write the metadata to a register coupled to the memory array and from the register to the memory array.
[0114] Some examples of the method 600 and apparatus described herein may further include operations, features, circuitry, logic, components, or instructions for receiving a start command for a line of memory in volatile memory, wherein metadata may be read from the memory array at least in part based on the start command.
[0115] Some examples of the method 600 and apparatus described herein may further include operations, features, circuitry, logic, components, or instructions for receiving precharge commands for rows of memory banks in volatile memory, wherein metadata may be written to the memory array at least in part based on the precharge commands.
[0116] Some instances of the method 600 and device described herein may further include operations, features, circuitry, logic, components, or instructions for receiving a read command or write command for a row after receiving a start command and updating metadata in a register at least in part based on the read command or write command.
[0117] Some instances of the method 600 and apparatus described herein may further include operations, characteristics, circuitry, logic, components, or instructions for determining, at least in part, a memory bank that can be associated with metadata based on a startup command, wherein metadata may be written to registers at least in part based on registers configured for the memory bank.
[0118] Some instances of the method 600 and apparatus described herein may further include operations, features, circuitry, logic, components, or instructions for reading parity bits for metadata from a memory array, wherein ECC operations may be performed at least in part based on the parity bits for metadata.
[0119] Some instances of the method 600 and apparatus described herein may further include operations, features, circuitry, logic, components, or instructions for decoding a codeword containing parity bits and metadata as part of ECC operation and for detecting errors in the metadata based at least in part on the decoding of the codeword.
[0120] Some instances of the method 600 and device described herein may further include operations, features, circuitry, logic, components, or instructions for detecting errors in metadata at least in part based on ECC operation and for correcting errors detected in metadata at least in part based on the detected errors, wherein the metadata may be written to a register after the errors are corrected.
[0121] Some examples of the method 600 and apparatus described herein may further include sending an error indication to a controller included in an interface controller (the controller is used to manage commands for volatile memory and commands for non-volatile memory) and, after sending the error indication, sending corrected metadata to the controller's operation, features, circuitry, logic, components, or instructions.
[0122] In some instances of the method 600 and apparatus described herein, metadata may be associated with a first storage bank of a memory array, and the method, apparatus, and non-transitory computer-readable medium may further include operations, features, circuitry, logic, components, or instructions for reading second metadata (which is associated with a second storage bank of the memory array) from the memory array and writing the second metadata into a second register that may be coupled to the memory array, at least in part based on performing a second ECC operation on the second metadata.
[0123] It should be noted that the methods described herein describe possible implementations, and the operations and steps may be rearranged or otherwise modified, and other implementations are possible. Furthermore, two or more parts from the methods described may be combined.
[0124] Describe a device. The device may include: a non-volatile memory; a volatile memory; and an interface controller coupled to the non-volatile memory and the volatile memory, the interface controller being operable such that the device: reads metadata from a memory array contained in the interface controller, the metadata containing information for operating the volatile memory as a cache for the non-volatile memory; performs an ECC operation on the metadata at least in part based on reading the metadata from the memory array; writes the metadata to a register coupled to the memory array at least in part based on performing the ECC operation; and writes the metadata from the register to the memory array.
[0125] In some instances, the device may include receiving an activation command for a row of memory in the volatile memory, wherein the metadata may be read from the memory array at least in part based on the activation command. In some instances, the device may include receiving a precharge command for the row of memory in the volatile memory, wherein the metadata may be written to the memory array at least in part based on the precharge command.
[0126] In some instances, the device may include receiving a read command or a write command for the row after receiving the activation command, and updating the metadata in the register at least in part based on the read command or the write command. In some instances, the device may include determining the memory bank of the memory array that can be associated with the metadata based at least in part on the activation command, wherein the metadata may be written to the register at least in part based on the register configured for the memory bank.
[0127] In some instances, the device may include reading parity bits for the metadata from the memory array, wherein the ECC operation may be performed at least in part based on the parity bits for the metadata. In some instances of the device, the interface controller may be operable such that the device, as part of the ECC operation, decodes a codeword containing the parity bits and the metadata, and detects errors in the metadata at least in part based on the decoding of the codeword.
[0128] In some instances, the device may include detecting errors in the metadata at least in part based on the ECC operation, and correcting the detected errors in the metadata at least in part based on the detection of the errors, wherein the metadata may be written to the register after the errors are corrected. In some instances, the device may include sending an indication of the error to a controller included in the interface controller, the controller being configured to manage commands for the volatile memory and commands for the non-volatile memory, and sending the corrected metadata to the controller after sending the indication of the error.
[0129] In some instances, the device may include reading second metadata from the memory array, the second metadata being associated with a second bank of the memory array, and writing the second metadata to a second register that may be coupled to the memory array, at least in part based on performing a second ECC operation on the second metadata.
[0130] Describing another device. The device may include: a non-volatile memory; volatile memory configured to operate as a cache for the non-volatile memory; and an interface controller coupled to the non-volatile memory and the volatile memory, the interface controller comprising: an SRAM array configured to store metadata for enabling the volatile memory to operate as the cache; ECC logic coupled to the SRAM array and configured to perform ECC operations on the metadata from the SRAM array; and a register serving as a storage bank for the volatile memory, coupled to the ECC logic and configured to store metadata from the ECC logic, wherein the interface controller is configured to update the metadata in the register and transmit the metadata from the register to the SRAM array.
[0131] In some instances of the device, the interface controller includes a register set logically coupled to the ECC, wherein the register set contains the registers, and each register in the register set may be associated with a corresponding bank of the volatile memory. In some instances, the device may include a controller coupled to the registers and configured to control the operation of the registers.
[0132] In some instances of the device, the interface controller may be configured to communicate the metadata from the SRAM array to the ECC logic, and the interface controller may be configured to communicate the metadata from the ECC logic to the register. In some instances of the device, the interface controller may be configured to communicate the metadata from the SRAM array to the ECC logic based at least in part on an activation command for a row of the memory bank, and the interface controller may be configured to communicate the metadata from the register to the SRAM array based at least in part on a precharge command for the row of the memory bank.
[0133] The information and signals described herein can be represented using any of a variety of different techniques and skills. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the foregoing description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, optical fields or optical particles, or any combination thereof. Some diagrams may illustrate signaling as a single signal; however, those skilled in the art will understand that a signal can represent a bus of signals, where the bus can have various bit widths.
[0134] A protocol can define one or more communication procedures and one or more communication parameters supported for use by a device or component. For example, a protocol can define various operations, timing and frequency for those operations, the meaning of various commands or signals or both, one or more addressing schemes for one or more memories, the type of communication reserved for pins, the size of data processed at various components of an interface, the data rate supported by various components of an interface, or the bandwidth supported by various components of an interface, and other parameters and metrics, or any combination thereof. The use of shared protocols enables interaction between devices because each device can operate in a way that another device expects, recognizes, and understands. For example, two devices supporting the same protocol can interact according to the policies, procedures, and parameters defined by the protocol, while two devices supporting different protocols may be incompatible.
[0135] To illustrate, two devices supporting different protocols may be incompatible because the protocols define different addressing schemes (e.g., different numbers of address bits). As another illustration, two devices supporting different protocols can be incompatible because the protocols define different transmission procedures for responding to a single command (e.g., the batch length or number of bytes allowed in response to the command may be different). Simply translating a command into an action should not be interpreted as the use of two different protocols. In fact, protocols can be considered different if the corresponding procedures or parameters defined by the two protocols change. For example, if a device supports different addressing schemes or different transmission procedures for responding to commands, the device may be said to support two different protocols.
[0136] The terms "electronic connectivity," "conductive contact," "connection," and "coupling" refer to a relationship between components that supports the flow of electrons between them. Components are considered to be in electronic communication with each other (or in conductive contact, connected, or coupled) if any conductive path exists between them that allows a signal to flow between them at any given time. At any given time, based on or in response to the operation of a device containing the connected components, the conductive path between components that are in electronic communication with each other (or in conductive contact, connected, or coupled) can be an open circuit or a closed circuit. The conductive path between connected components can be a direct conductive path between the components, or an indirect conductive path between connected components that may include intermediate components such as switches, transistors, or other components. In some instances, one or more intermediate components, such as switches or transistors, may be used to interrupt the signal flow between connected components for a period of time.
[0137] The term "coupling" refers to the condition that shifts from an open-circuit relationship between components to a closed-circuit relationship. In an open-circuit relationship, signals cannot currently travel between components via a conductive path, while in a closed-circuit relationship, signals can travel between components via a conductive path. When a component, such as a controller, couples other components together, it initiates a change that allows signals to flow between other components via conductive paths that were previously not permitted.
[0138] The term "isolation" refers to the relationship between components where signals cannot currently flow between them. Components are isolated from each other if there is an open circuit between them. For example, components separated by a switch positioned between two components are isolated from each other when the switch is open. When a controller separates two components, it prevents signals from flowing between the components using previously permitted conductive paths.
[0139] The devices discussed herein, including memory arrays, can be formed on semiconductor substrates such as silicon, germanium, silicon-germanium alloys, gallium arsenide, and gallium nitride. In some instances, the substrate is a semiconductor wafer. In other instances, the substrate can be a silicon-on-insulator (SOI) substrate, such as silicon-on-glass (SOG) or silicon-on-sapphire (SOP), or an epitaxial layer of semiconductor material on another substrate. The conductivity of the substrate or subregions of the substrate can be controlled by doping with various chemicals including, but not limited to, phosphorus, boron, or arsenic. Doping can be performed during the initial formation or growth of the substrate, either by ion implantation or by any other doping method.
[0140] The switching components or transistors discussed herein may represent field-effect transistors (FETs) and include a three-terminal device comprising a source, a drain, and a gate. The terminals may be connected to other electronic components via a conductive material (e.g., a metal). The source and drain may be conductive and may include heavily doped, for example, degenerate, semiconductor regions. The source and drain may be separated by lightly doped semiconductor regions or channels. If the channel is n-type (i.e., the majority carriers are electrons), the FET may be called an n-type FET. If the channel is p-type (i.e., the majority carriers are holes), the FET may be called a p-type FET. The channel may be capped by an insulating gate oxide. The conductivity of the channel can be controlled by applying a voltage to the gate. For example, applying a positive or negative voltage to an n-type FET or a p-type FET, respectively, can cause the channel to become conductive. When a voltage greater than or equal to the transistor's threshold voltage is applied to the transistor's gate, the transistor may be "turned on" or "started up." When a voltage less than the transistor's threshold voltage is applied to the transistor's gate, the transistor may be "turned off" or "de-started up."
[0141] The description herein, illustrated with reference to the accompanying drawings, describes exemplary configurations and does not represent all implementable or claim-scoped instances. The term "exemplary" as used herein means "serving as an example, illustration, or description," not "preferred to" or "superior to" other instances. The detailed description includes specific details to provide an understanding of the described techniques. However, these techniques may be practiced without these specific details. In some cases, well-known structures and apparatuses are shown in block diagram form to avoid obscuring the concepts of the described instances.
[0142] In the accompanying drawings, similar components or features may have the same reference numerals. Additionally, various components of the same type can be distinguished by a dash following the reference numeral and a second numeral used to differentiate them among similar components. If only the first reference numeral is used in the specification, the description applies to any of the similar components having the same first reference numeral, regardless of the second reference numeral.
[0143] The information and signals described herein can be represented using any of a variety of different techniques and skills. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the foregoing description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or light particles, or any combination thereof.
[0144] As used herein, the term "generally" means that the modified feature (e.g., a verb or adjective modified by the term "generally") need not be absolute but must be close enough to obtain the advantage of the feature. As used herein, the term "in parallel" means that the described actions or phenomena occur during a period of time that are at least partially overlapping in time, can be substantially simultaneous, or are offset in time. As used herein, unless otherwise described or referred to, a "set" of objects may refer to one or more of the objects.
[0145] The various illustrative blocks and modules described in connection with the disclosure herein may be implemented or executed using a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic, discrete hardware component, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration).
[0146] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored as one or more instructions or code on or transmitted via a computer-readable medium. Other examples and implementations are within the scope of this disclosure and the appended claims. For example, due to the nature of software, the functions described above may be implemented using software executed by a processor, hardware, firmware, hardwired, or any combination thereof. Features implementing the functions may also be physically located in various locations, including distributed implementations such that portions of the functions are implemented in different physical locations. Moreover, as used herein, the word “or” used in the list of items included in the claims (e.g., a list of items beginning with phrases such as “at least one of” or “one or more of”) indicates an inclusive list, such that a list of at least one of, for example, 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). Moreover, as used herein, the phrase “based on” should not be construed as referring to a closed set of conditions. For example, without departing from the scope of this disclosure, an exemplary step described as “based on condition A” may be based on both condition A and condition B. In other words, as used herein, the phrase “based on” should also be interpreted as the phrase “at least partially based on”.
[0147] Computer-readable media includes both non-transitory computer-readable storage media and communication media, with communication media encompassing any media that facilitates the transfer of a computer program from one place to another. Non-transitory storage media can be any available media accessible by a general-purpose or special-purpose computer. By way of example, and not limitation, non-transitory computer-readable media may include RAM, ROM, electrically erasable programmable read-only memory (EEPROM), compressed optical disc (CD) ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage devices, or any other non-transitory media that can be used to carry or store desired program code components in the form of instructions or data structures and is accessible by a general-purpose or special-purpose computer or a general-purpose or special-purpose processor. Furthermore, any connection may be appropriately referred to as computer-readable media. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then such 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 media. As used herein, disks and optical discs include CDs, laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs reproduce data optically using lasers. Combinations of these are also included within the scope of computer-readable media.
[0148] The description provided herein enables those skilled in the art to make or use this disclosure. Those skilled in the art will appreciate the various modifications that can be made to this disclosure, and that the general principles defined herein can be applied to other variations without departing from the scope of this disclosure. Therefore, this disclosure is not limited to the examples and designs described herein, but is given the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. An apparatus comprising: Non-volatile memory; Volatile memory; as well as An interface controller, coupled to the non-volatile memory and the volatile memory, is operable to cause the device to: Receive an activation command for a row of a storage bank in the volatile memory; Metadata is read from the volatile memory array contained in the interface controller, at least in part, based on the activation command. The metadata includes information for operating the volatile memory as a cache for the non-volatile memory. At least in part, error correction code (ECC) operations are performed on the metadata based on reading the metadata from the volatile memory array; The metadata is written to a register coupled to the volatile memory array, at least in part based on the execution of the ECC operation; Receive a precharge command for the row of the memory bank in the volatile memory; as well as The metadata is written from the register to the volatile memory array, at least in part, based on the precharge command.
2. The device of claim 1, wherein the interface controller is operable to cause the device to: After receiving the activation command, receive a read command or write command for the row; and The metadata in the register is updated at least in part based on the read command or the write command.
3. The device of claim 1, wherein the interface controller is operable to cause the device to: The memory bank associated with the metadata of the volatile memory array is determined at least in part based on the activation command, wherein the metadata is written to the register at least in part based on the register being configured for the memory bank.
4. The device of claim 1, wherein the interface controller is operable to cause the device to: The parity bit for the metadata is read from the volatile memory array, wherein the ECC operation is performed at least in part based on the parity bit for the metadata.
5. The device of claim 4, wherein the interface controller is operable to cause the device to: As part of the ECC operation, the codeword including the parity bit and the metadata is decoded; and Errors in the metadata are detected, at least in part, based on decoding the codewords.
6. The device of claim 1, wherein the interface controller is operable to cause the device to: Errors in the metadata are detected at least in part based on the ECC operation; and The error detected in the metadata is corrected at least in part based on the detection of the error, wherein the metadata is written to the register after the error is corrected.
7. The device of claim 6, wherein the interface controller is operable to cause the device to: The error indication is sent to a controller included in the interface controller, the controller being configured to manage commands for the volatile memory and commands for the non-volatile memory; and After the indication of the error is sent, the corrected metadata is sent to the controller.
8. The device of claim 1, wherein the metadata is associated with a first bank of the volatile memory array, and wherein the interface controller is operable to cause the device to: Read second metadata from the volatile memory array, the second metadata being associated with a second bank of the volatile memory array; and The second metadata is written to a second register coupled to the volatile memory array, at least in part based on performing a second ECC operation on the second metadata.
9. The device of claim 1, wherein the register is included in the interface controller.
10. A method comprising: Receive activation commands for rows of storage banks in volatile memory; Metadata is read from a volatile memory array contained in an interface controller coupled to the volatile memory and the non-volatile memory, at least in part based on the activation command. The metadata includes information for enabling the volatile memory to operate as a cache for the non-volatile memory. At least in part, error correction code (ECC) operations are performed on the metadata based on reading the metadata from the volatile memory array; The metadata is written to a register coupled to the volatile memory array, at least in part based on the execution of the ECC operation; Receive a precharge command for the row of the memory bank in the volatile memory; as well as The metadata is written from the register to the volatile memory array, at least in part, based on the precharge command.
11. The method of claim 10, further comprising: After receiving the activation command, receive a read command or write command for the row; as well as The metadata in the register is updated at least in part based on the read command or the write command.
12. The method of claim 10, further comprising: The memory bank associated with the metadata of the volatile memory array is determined at least in part based on the activation command, wherein the metadata is written to the register at least in part based on the register being configured for the memory bank.
13. The method of claim 10, further comprising: The parity bit for the metadata is read from the volatile memory array, wherein the ECC operation is performed at least in part based on the parity bit for the metadata.
14. The method of claim 13, further comprising: As part of the ECC operation, the codeword including the parity bit and the metadata is decoded; as well as Errors in the metadata are detected, at least in part, based on decoding the codewords.
15. The method of claim 10, further comprising: Errors in the metadata are detected at least in part based on the ECC operation; as well as The error detected in the metadata is corrected at least in part based on the detection of the error, wherein the metadata is written to the register after the error is corrected.
16. The method of claim 15, further comprising: The error indication is sent to a controller included in the interface controller, which manages commands for the volatile memory and commands for the non-volatile memory; as well as After the indication of the error is sent, the corrected metadata is sent to the controller.
17. The method of claim 10, wherein the metadata is associated with a first bank of the volatile memory array, the method further comprising: Second metadata is read from the volatile memory array, the second metadata being associated with a second storage bank of the volatile memory array; as well as The second metadata is written to a second register coupled to the volatile memory array, at least in part based on performing a second ECC operation on the second metadata.
18. An apparatus comprising: Non-volatile memory; A volatile memory configured to operate as a cache for the non-volatile memory; as well as An interface controller, coupled to the non-volatile memory and the volatile memory, the interface controller comprising: A static random access memory (SRAM) array configured to store metadata for enabling the volatile memory to operate as the cache; Error correction code (ECC) logic, coupled to the SRAM array and configured to perform ECC operations on the metadata from the SRAM array; and A register, which is a bank of the volatile memory, coupled to the ECC logic and configured to store metadata from the ECC logic, wherein the interface controller is configured to update the metadata in the register and transmit the metadata from the register to the SRAM array, wherein the interface controller is configured to transmit the metadata from the SRAM array to the ECC logic at least in part based on an activation command for a row of the bank, and wherein the interface controller is configured to transmit the metadata from the register to the SRAM array at least in part based on a precharge command for the row of the bank.
19. The device of claim 18, wherein the interface controller includes a register set logically coupled to the ECC, wherein the register set contains the registers, and each register in the register set is associated with a corresponding bank of the volatile memory.
20. The apparatus of claim 18, further comprising: A controller, which is coupled to the register and configured to control the operation of the register.
21. The device of claim 18, wherein the interface controller is configured to communicate the metadata from the SRAM array to the ECC logic, and wherein the interface controller is configured to communicate the metadata from the ECC logic to the register.