Opportunity data movement

Abstract

This application relates to opportunistic data movement. A memory device can include a non-volatile memory and a volatile memory used as a cache for the non-volatile memory. The memory device can receive a write command from a host device. The write command can be associated with a row of a bank in the volatile memory. The memory device can write data associated with the write command to a buffer associated with the bank and coupled with the volatile memory. And based on the write command and prior to receiving a precharge command for the row of the bank from the host device, the memory device can transfer the data from the buffer to the volatile memory.

Description

[0001] Cross-references

[0002] This patent application claims priority to U.S. Provisional Patent Application No. 63 / 140,101, filed January 21, 2021, entitled “Opportunistic Data Movement”, by Malik et al., which is assigned to the assignee and is expressly incorporated herein by reference in its entirety. Technical Field

[0003] This technical field relates to opportunistic data movement. Background Technology

[0004] Memory devices are widely used to store information in various electronic devices such as computers, 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 and can store either one. 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), 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. For example, non-volatile FeRAM can maintain its stored logic state for a long time even without external power. Volatile DRAM devices, on the other hand, may lose their stored state when disconnected from external power. Summary of the Invention

[0006] Describe an apparatus. The apparatus may include: a non-volatile memory; volatile memory configured to serve 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 is configured to cause the apparatus to: receive from a host device a write command associated with a row of a memory bank in the volatile memory; write data associated with the write command to a buffer associated with the memory bank and coupled to the volatile memory; transfer data from the buffer to the volatile memory at least in part based on the write command and before receiving a precharge command for a row of the memory bank from the host device; and write data to a row of the memory bank in the volatile memory after the data has been transferred to the volatile memory and at least in part based on the write command.

[0007] Describe a device. The device may include: a non-volatile memory; a volatile memory configured to serve 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 is configured to cause the device to: receive a write command for data from a row of a memory bank in the volatile memory; write data from the row of the memory bank to a buffer coupled to the volatile memory and the non-volatile memory, at least in part based on the write command; transfer data from the buffer to the non-volatile memory, at least in part based on the write command and before receiving a precharge command for the row of the memory bank from a host device; and write data to the non-volatile memory after transferring the data to the non-volatile memory and at least in part based on the write command.

[0008] Describe a method. The method may be performed by a memory device and may include: receiving from a host device a write command associated with a row of a bank in volatile memory, the volatile memory being used as a cache for non-volatile memory; writing data associated with the write command to a buffer associated with and coupled to the volatile memory; transferring the data from the buffer to the volatile memory at least in part based on the write command and before receiving a precharge command for the row of the bank from the host device.

[0009] Describe a method. The method can be performed by a memory device and may include: receiving a write command for data from a row of a bank in volatile memory, the volatile memory serving as a cache for non-volatile memory; writing data from the row of the bank to a buffer coupled to the volatile memory and the non-volatile memory, at least in part based on the write command; and transferring the data from the buffer to the non-volatile memory, at least in part based on the write command and before receiving a precharge command for the row of the bank from a host device. Attached Figure Description

[0010] Figure 1This describes an example of a system that supports the movement of opportunity data, based on examples disclosed herein.

[0011] Figure 2 This describes an example of a storage subsystem that supports opportunistic data movement, based on examples disclosed herein.

[0012] Figure 3 Examples of devices that support opportunity data movement, as disclosed herein.

[0013] Figure 4 This document describes an example of a process flow that supports the movement of opportunity data, as illustrated in the examples disclosed herein.

[0014] Figure 5 This document describes an example of a process flow that supports the movement of opportunity data, as illustrated in the examples disclosed herein.

[0015] Figure 6 A block diagram illustrating a memory device that supports opportunistic data movement based on examples disclosed herein.

[0016] Figure 7 and 8 The flowchart illustrates one or more methods for supporting opportunity data movement based on examples disclosed herein. Detailed Implementation

[0017] For example, an electronic device may include non-volatile memory (e.g., primary memory for storing information and other operations) and volatile memory serving 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 and persistent storage, high storage capacity, low power consumption) while maintaining compatibility with the host device via the volatile memory. If such a device receives one or more write commands for data associated with a row of memory in the volatile memory, the device may temporarily store the data for the row in a buffer. Upon receiving a command for the row (e.g., a precharge command), the device may transfer the data for the row from the buffer to the volatile memory for storage. However, waiting for a command such as a precharge command before transferring data to the volatile memory can delay the closing of the row, which in turn can delay the satisfaction of one or more subsequent access commands to the memory, and other disadvantages. Similar or other problems may arise if the device uses a second buffer to evict data from the volatile memory to the non-volatile memory.

[0018] According to the techniques described herein, a device can reduce the latency between receiving a command for a row (e.g., a precharge command) and closing a row by opportunistically transferring dirty data from, for example, a buffer to volatile memory before receiving a command such as a precharge command. Therefore, the device can reduce the latency associated with accessing a row of memory relative to other techniques. According to the techniques described herein, the technique can be used to evict data from, for example, a second buffer to non-volatile memory. For example, the device can transfer data from a second buffer to non-volatile memory before receiving a command associated with the data (e.g., a precharge command).

[0019] First, as referenced 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 apparatus and as referenced Figure 4 and 5 The features of this disclosure are described in the context of the described processing flow. References refer to, for example, [references to, and other sources]. Figures 6 to 8 The device diagrams and flowcharts describing the opportunity data movement are used to further illustrate and describe these and other features of this disclosure.

[0020] Figure 1 This describes an example of a system 100 that supports opportunistic data movement according to examples disclosed herein. The memory system 100 may be contained in an electronic device, such as a computer or telephone. The memory system 100 may include a host device 105 and a memory subsystem 110. The host device 105 may be a processor or system-on-a-chip (SoC) that interfaces with an interface controller 115 and other components of the electronic device containing the memory system 100. The memory subsystem 110 may store electronic information (e.g., digital information, data) for the host device 105 and provide access to said electronic information. The memory subsystem 110 may include an interface controller 115, volatile memory 120, and non-volatile memory 125. In some instances, the interface controller 115, volatile memory 120, and non-volatile memory 125 may be contained in the same physical package, such as package 130. However, the interface controller 115, volatile memory 120, and non-volatile memory 125 may be disposed on different corresponding dies (e.g., silicon dies).

[0021] Devices in memory system 100 can be coupled by various wires (e.g., traces, printed circuit board (PCB) routes, redistribution layer (RDL) routes) 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.

[0022] 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 incompatible with or inefficiently configured with various aspects of non-volatile memory 125. For example, host device 105 may support voltage, access latency, protocols, page sizes, etc., that are incompatible with non-volatile memory 125. To compensate for the incompatibility between host device 105 and non-volatile memory 125, memory subsystem 110 may be configured with volatile memory 120 that is compatible with host device 105 and acts as a cache for non-volatile memory 125. Therefore, host device 105 can use protocols supported by volatile memory 120 while also benefiting from the advantages of non-volatile memory 125.

[0023] In some instances, the memory system 100 may be included 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 the memory system 100 may be capable of machine-type communication (MTC), machine-to-machine (M2M) communication, or device-to-device (D2D) communication. In some instances, the device associated with the memory system 100 may be referred to as a user equipment (UE), station (STA), mobile terminal, etc.

[0024] Host device 105 may be configured to interface with memory subsystem 110 using a first protocol (e.g., low-power dual 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 that includes memory 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 of these types of components. In some instances, host device 105 may be referred to as a host.

[0025] Interface controller 115 can be configured to interface with volatile memory 120 and non-volatile memory 125 on behalf of host device 105 (e.g., based on one or more commands or requests issued by 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.

[0026] Non-volatile memory 125 may be configured to store digital information (e.g., data) for electronic devices including memory system 100. Therefore, non-volatile memory 125 may include one or more memory cell arrays and a local memory controller configured to operate the memory cell arrays. 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.

[0027] Volatile memory 120 may be configured to serve as a cache for one or more components (e.g., non-volatile memory 125). For example, volatile memory 120 may store information (e.g., data) for an electronic device containing memory system 100. Therefore, volatile memory 120 may include one or more memory cell arrays and a local memory controller configured to operate the memory cell arrays. 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.

[0028] 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 than 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).

[0029] While non-volatile memory 125 may be a higher-density memory than volatile memory 120, 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 memory 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).

[0030] Access operations, also referred to as access procedures or access routines, may involve one or more sub-operations performed by one or more components of the memory subsystem 110. Examples of access operations may include: a storage operation 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 a retrieval operation 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.

[0031] To store data in memory subsystem 110, host device 105 can initiate a storage operation (or “stored procedure”) by transmitting a storage command (also referred to as a storage request, write command, or write request) to interface controller 115. The storage command can target a set of non-volatile memory cells in non-volatile memory 125. In some instances, the set of memory cells may also be referred to as a portion of memory. Host device 105 can also provide data to be written to the set of non-volatile memory cells to interface controller 115. Interface controller 115 can temporarily store the data in buffer 135-a. After storing the data in buffer 135-a, interface controller 115 can 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 can transfer data to both volatile memory 120 and non-volatile memory 125. In write-back mode, the interface controller 115 may transfer data only to the volatile memory 120 (wherein data is transferred to the non-volatile memory 125 during a later eviction process).

[0032] In any mode, interface controller 115 may identify an appropriate set of one or more volatile memory cells in volatile memory 120 for storing data associated with a store command. To this end, interface controller 115 may implement set association mapping, wherein each set (e.g., a block) of one or more non-volatile memory cells in non-volatile memory 125 may be mapped to multiple sets of volatile memory cells in volatile memory 120. For example, interface controller 115 may implement an n-way association mapping, which allows data from a set of non-volatile memory cells to be stored in one of n sets of volatile memory cells in volatile memory 120. Therefore, interface controller 115 can manage volatile memory 120 as a cache of non-volatile memory 125 by referring to n sets of volatile memory cells associated with a target set of non-volatile memory cells. As used herein, unless otherwise described or mentioned, a “set” of objects may refer to one or more objects. Although described with reference to set association mapping, interface controller 115 can manage volatile memory 120 as a cache by implementing one or more other types of mapping (e.g., direct mapping or association mapping, and other instances).

[0033] After determining which n sets of volatile memory cells are associated with the target set of non-volatile memory cells, the interface controller 115 can store data in one or more of the n sets of volatile memory cells. Therefore, by retrieving data from the lower-latency volatile memory 120 instead of the higher-latency non-volatile memory 125, subsequent retrieval commands for data from the host device 105 can be efficiently satisfied. The interface controller 115 can determine which of the n sets of volatile memory 120 to store data based on one or more parameters (e.g., data validity, timeliness, or modification status) associated with the data stored in the n sets of volatile memory 120. Therefore, storage 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 data in volatile memory 120. In order to track data stored in volatile memory 120, interface controller 115 may store tag addresses for one or more sets of volatile memory cells (e.g., for each set of volatile memory cells), the tag addresses indicating non-volatile memory cells with data stored in a given set of volatile memory cells.

[0034] To retrieve data from memory subsystem 110, host device 105 can initiate a retrieval operation (also called a retrieval process) by transmitting a retrieval command (also referred to as a retrieval request, read command, or read request) to interface controller 115. The retrieval command can target one or more sets of non-volatile memory cells in non-volatile memory 125. After receiving the retrieval command, interface controller 115 can examine the requested data in volatile memory 120. For example, interface controller 115 can examine the requested data in n sets of volatile memory cells associated with the target set of non-volatile memory cells. If the requested data is stored in one of the n sets of volatile memory cells (e.g., data is stored for the target set of non-volatile memory cells), then interface controller 115 can transfer the data from volatile memory 120 to buffer 135-a (e.g., in response to determining that the requested data is stored in one of the n sets of volatile memory cells, such as...). Figure 4 and 5 (as described in the document), enabling it to be transmitted to host device 105.

[0035] Generally, the term "hit" can be used to refer to a situation where volatile memory 120 stores data targeted by host device 105 (e.g., in a read scenario) or data associated with a non-volatile memory address targeted by host device (e.g., in a write scenario). Generally, the term "miss" can be used to refer to a situation where volatile memory 120 does not store data targeted by host device 105 (e.g., in a read scenario) or data associated with a non-volatile memory address targeted by host device (e.g., in a write scenario).

[0036] Continuing with the previous example, if the set of n volatile memory cells does not store the requested data (e.g., the set of n volatile memory cells stores data for a set of non-volatile memory cells other than the target set of non-volatile memory cells), then the interface controller 115 may transfer the requested data from the non-volatile memory 125 to the buffer 135-a (e.g., in response to determining that the set of n volatile memory cells does not store the requested data, as referenced...). Figure 4 and 5 (as described), so that it can be transmitted to host device 105.

[0037] In a read miss scenario, after passing the requested data to buffer 135-a, interface controller 115 may pass the requested data from buffer 135-a to volatile memory 120, so that subsequent read requests for the data can be satisfied through volatile memory 120 instead of non-volatile memory 125. For example, interface controller 115 may store the data in one of n sets of volatile memory cells associated with a target set of non-volatile memory cells. However, the n sets of volatile memory cells may already contain data for other sets of non-volatile memory cells. Therefore, to preserve such other data, interface controller 115 may pass the other data to buffer 135-b so that the data can be passed to non-volatile memory 125 for storage. This process may be called "eviction," and the data passed from volatile memory 120 to buffer 135-b may be called "victim" data.

[0038] 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. In some cases, data associated with the same memory address but inconsistent between one memory and another (e.g., due to an update in one memory while not updated in the other) may be referred to as "modified" or "dirty" data. In some instances (e.g., if the interface controller is operating in a mode such as write-back mode), then dirty data may be data that exists in one memory but not in another. In some instances, data may be dirty if the data in volatile memory 120 is inconsistent with the corresponding data in non-volatile memory 125, or if the corresponding data does not exist in non-volatile memory 125. As another example, the data may be dirty data if the data in buffer 218 is inconsistent with the corresponding data in volatile memory 120, or if the corresponding data does not exist in volatile memory 120. The corresponding data may refer to data associated with the same memory address as another piece of data (e.g., a volatile memory address, a non-volatile memory address).

[0039] Therefore, buffer 135 can be used to temporarily store data for communication between host device 105, volatile memory 120, and non-volatile memory 125. As an example, data for a line of memory to be written to volatile memory 120 can be accumulated in buffer 135-a. The data accumulated in buffer 135-a, along with associated write commands, can be received from host device 105 in 32-B or 64-B chunks (or at other granularities). After receiving a previous activation command for a line, interface controller 115 can activate or "open" the line to prepare it for access procedures. However, interface controller 115 may not begin moving data (e.g., valid dirty data) from buffer 135-a to volatile memory 120 until a subsequent precharge command for the line is received. If volatile memory 120 follows a closed-page policy where one row in the memory bank must be closed before another row can be opened, then waiting for a precharge command before moving data to volatile memory 120 can effectively "block" further access to the memory bank until all relevant data has been stored in the row and the row has been closed. Therefore, volatile memory 120 may violate the access timing expected by host device 105, or increase the latency associated with service access commands from host device 105, and other problems.

[0040] According to the techniques described herein, before receiving a precharge command for a row, the interface controller 115 may opportunistically or strategically move data for the row in volatile memory 120 from buffer 135-a to volatile memory 120, thereby reducing the latency between receiving the precharge command and closing the row. This type of technique can be referred to as opportunistic write-back.

[0041] During the eviction process for a row of volatile memory 120, data to be stored in non-volatile memory 125 (e.g., damaged data from the row) may be accumulated in buffer 135-b. The damaged data accumulated in buffer 135-b, along with an associated write command, may be received from volatile memory 120. After receiving a precharge command for a row of memory, buffer 135-b may move the dirty damaged data from buffer 135-b to non-volatile memory 125 for storage. If buffer 135-b is the only eviction buffer dedicated to memory of volatile memory 120, subsequent eviction processes for memory may be suspended until buffer 135-b finishes moving the dirty damaged data to non-volatile memory 125. Therefore, access to memory of volatile memory 120 is effectively prevented until all dirty damaged data has been moved to non-volatile memory 125 (and buffer 135-b is available for the next eviction process).

[0042] According to the techniques described herein, interface controller 115 may opportunistically or strategically move dirty victim data from buffer 135-b to non-volatile memory 125. Specifically, data originating from rows in volatile memory 120 may be moved from buffer 135-b to non-volatile memory 125 before interface controller 115 receives a precharge command for a row. This type of technique is referred to as opportunistic eviction and allows buffer 135-b to be emptied earlier than other techniques. Therefore, the accessibility of volatile memory 120 can be improved, depending on the efficiency of the eviction procedure. Although described with reference to a scenario where a single buffer is used per bank of volatile memory, opportunistic eviction techniques can provide similar benefits in scenarios where a dynamic eviction buffer pool is used for volatile memory 120.

[0043] Although described separately, in some instances, buffers 135-a and 135-b can be combined. That is, the functionality of buffers 135-a and 135-b can be provided by a single buffer.

[0044] Figure 2 This describes an example of a memory subsystem 200 that supports opportunistic data movement, as disclosed herein. The memory subsystem 200 may be 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 respectively 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.

[0045] exist Figure 2In 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.

[0046] Non-volatile memory 206 can be configured to serve as the main memory of 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 voltages 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 an active word line may be sensed, for example, in parallel or simultaneously, without necessarily sensing all FeRAM cells coupled to the active 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 memory cells in a row (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).

[0047] The smaller page size of FeRAM arrays can offer various efficiency benefits because a single FeRAM cell may require more power to read or write compared to a single DRAM cell. For example, a smaller page size for FeRAM arrays can facilitate efficient energy use because a smaller number of FeRAM cells can be activated with minimal associated changes in 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).

[0048] While a single FeRAM cell may require more power to read or write compared to a single DRAM cell, it can maintain its stored logic state for an extended period in the absence of an external power supply because the ferroelectric material within 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.

[0049] 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 can 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 memory cells in the row (and therefore, the amount of data that the 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.

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

[0051] Data bus interface 208 may be coupled to data bus 260, transaction bus 222, and buffer circuitry 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 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, there may be any number of data buses 260 and any number of transaction buses 222 coupled to one or more data bus interfaces 208.

[0052] 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, so that decoder 228 can decode commands and forward the decoded commands and associated addresses to command circuitry system 230.

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

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

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

[0056] 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 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 stores information 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 pass 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).

[0057] Buffer circuitry system 224 may be coupled to data bus interface 208, command circuitry system 230, memory interface circuitry system 240, 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 (or both). As an example, the set of buffer circuits for memory bank 0 (BK0) can be configured to store data from a first memory bank of volatile memory 204 or to store data for the first memory bank (or both), and the buffer circuits for memory bank 15 (BK15) can be configured to store data from a sixteenth memory bank of volatile memory 204 or to store data for the sixteenth memory bank (or both).

[0058] 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 a host device; and another buffer (e.g., a Victim Page Data (VPD) buffer) configured to store data for use in an eviction process triggered by an 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 a host device. And buffer 220 may be configured to store data transferred from BK0 as part of an eviction process triggered by an access command. Each buffer in the set of buffer circuits may be configured with 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.

[0059] 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 a set of cache management circuits for one or more banks of volatile memory (e.g., each bank of memory). As an example, cache management circuitry system 244 may include sixteen sets of cache management circuits for BK0 through BK15. Each set of cache management circuits may include two memory arrays configured to store storage information for volatile memory 204. As an example, the set of cache management circuits for BK0 may include memory array 252 (e.g., a cache DRAM tag array (CDT-TA)) and memory array 254 (e.g., a cache DRAM valid (CDT-V) array) configured to store storage information for BK0. In some instances, the memory array may also be referred to as an array or buffer. In some cases, the memory array may be or contain volatile memory cells, such as static RAM (SRAM) cells.

[0060] Storage information (or "metadata") may include content information, validity information, dirty information (or any combination thereof), and other instances associated with volatile memory 204. Content information (which may also be referred to as tagging information or address information) indicates which data is stored in a set of volatile memory cells. For example, the content information (e.g., tag address) of a row in volatile memory 204 may indicate which set of one or more non-volatile memory cells currently contains the data stored in that row. As mentioned, validity information may indicate whether the data stored in the set of volatile memory cells 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 important order). Furthermore, dirty information may indicate whether data in one memory is dirty relative to corresponding data in another memory. For example, dirty information for volatile memory 204 may indicate whether data stored in a set of one or more volatile memory cells of volatile memory 204 is dirty (e.g., updated, different from the corresponding data) relative to corresponding data stored in a set of one or more non-volatile memory cells of non-volatile memory 206. As another example, dirty information for buffer 218 may indicate whether data stored in buffer 218 is dirty (e.g., updated, different from the corresponding data) relative to corresponding data stored in volatile memory 204.

[0061] In some instances, the memory subsystem 200 may also maintain dirty information for the data in buffer 218. The dirty information for buffer 218 may indicate the dirty state of the data in buffer 218 relative to the corresponding data in the memory associated with buffer 218.

[0062] Memory array 252 may include memory cells that store storage information (e.g., tag information, validity information, dirty information) of associated memory banks (e.g., BK0) of volatile memory 204. Storage information may be stored on a row-by-row basis (e.g., each row of an associated non-volatile memory bank may have corresponding storage information). Interface controller 202 can examine requested data in volatile memory 204 by referring to the storage information in memory array 252. For example, interface controller 202 may receive a retrieval command from a host device for data in a set of non-volatile memory cells in non-volatile memory 206. Interface controller 202 may refer to the storage information in memory array 252 using a set of one or more address bits (e.g., a set of row address bits) targeted by the access request. For example, using set association mapping, interface controller 202 may refer to content information in memory array 252 to determine which set of volatile memory cells (if it exists) stores the requested data.

[0063] In addition to storing content information for the volatile memory cells, memory array 252 may also store validity information indicating whether data in the set of volatile memory cells is actual data (also called valid data) or random data (also called invalid data). For example, volatile memory cells in 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 for each set of volatile memory cells (e.g., a row) when actual data is stored in the set of volatile memory cells. This bit may be called a validity bit or validity flag. Like content information, validity information stored in memory array 252 may be stored on a row-by-row basis. Thus, in some instances, each validity bit may indicate the validity of data stored in the associated row.

[0064] 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, the dirty information stored in memory array 252 may be stored on a row-by-row basis.

[0065] Memory array 254 may be similar to memory array 252 and may also include memory cells that store storage information for banks (e.g., BK0) of volatile memory 204 associated with memory array 252. For example, memory array 254 may store validity information and dirt information for banks of volatile memory 204. However, the storage information stored in memory array 254 may be stored on a sub-block basis rather than on a row-by-row basis. 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.

[0066] As an example, validity information in memory array 254 can indicate the validity of each subset (e.g., 32B or 64B) of data stored in rows BK0 of volatile memory 204. Similarly, dirty information stored in memory cells of memory array 254 can indicate which subset of volatile memory cells in rows of volatile memory 204 stores dirty data. For example, dirty information in memory array 254 can indicate the dirty state of each subset (e.g., 32B or 64B) of data stored in rows BK0 of volatile memory 204. Storing storage information (e.g., tagging information, validity information) on a row-by-row basis in memory array 252 allows interface controller 202 to determine whether data in volatile memory 204 has a hit or a miss. Storing storage information (e.g., validity information, dirty information) in memory array 254 on a sub-block basis allows interface controller 202 to determine which subsets of data are returned to the host device (e.g., during a retrieval process) and which subsets of data are retained in non-volatile memory 206 (e.g., during an eviction process).

[0067] 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 Mark (OPT) register) configured to receive storage information (e.g., one or more bits of tag information, validity information, or dirty information) 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 Mark (VPT) register) configured to receive storage information (e.g., validity information, dirty information) from memory array 254 and scheduler 248-a, or both. The information in registers 256 and 258 may be passed to command circuitry system 230 and engine 246 to enable decisions to be made by these components. For example, the command circuit system 230 may issue a command to read non-volatile memory 206 or volatile memory 204 based on stored information in register 256, register 258 or both.

[0068] Engine 246-a can be coupled to registers 256 and 258 and scheduler 248. Engine 246-a can be configured to receive stored information from various components and issue commands to scheduler 248 based on the stored information. For example, if interface controller 202 is in a first mode, such as write-through mode, then engine 246-a can 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, then engine 246-a can issue commands to scheduler 248-b, and in response, scheduler 248-b can initiate or facilitate data transfer from buffer 218 to volatile memory 204. In the case of a write-back operation, the data stored in volatile memory 204 can eventually be transferred to non-volatile memory 206 during a subsequent eviction process.

[0069] Engine 246-b may be coupled to register 258 and scheduler 248-a. Engine 246-b may be configured to receive stored information from register 258 and issue commands to scheduler 248-a based on the stored information. 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 an eviction process). If buffer 220 holds a set of data transferred from volatile memory 204 (e.g., victim data), then engine 246-b may indicate which one or more subsets (e.g., which 64Bs) of the set of data in buffer 220 should be transferred to non-volatile memory 206.

[0070] Scheduler 248-a can be coupled to various components of interface controller 202 and can facilitate access to non-volatile memory 206 by issuing commands to memory interface circuitry 234. Commands issued by scheduler 248-a can be based on commands from command circuitry 230, engine 246-a, engine 246-b, or a combination of these components. Similarly, scheduler 248-b can be coupled to various components of interface controller 202 and can facilitate access to volatile memory 204 by issuing commands to memory interface circuitry 240. Commands issued by scheduler 248-b can be based on commands from command circuitry 230 or engine 246-a, or both.

[0071] 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 a local controller in the non-volatile memory 206 via the C / A bus 236. Furthermore, the memory interface circuitry 234 can transmit 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 instead of 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).

[0072] 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 transmit data to or receive data 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 instead of 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).

[0073] 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 / retrieve commands / requests and write / store commands / requests) received from the host device.

[0074] In some instances, interface controller 202 may receive a store command from a host device. The store command may be received via C / A bus 226 and passed to command circuitry 230 via one or more of C / A bus interface 210 and decoder 228. The store command may include or be accompanied by address bits targeting a memory address of non-volatile memory 206. Data to be stored may be received via data bus 260 and passed to buffer 218 via data bus interface 208. In write-through mode, interface controller 202 may pass data to both non-volatile memory 206 and volatile memory 204. In write-back mode, interface controller 202 may pass data only to volatile memory 204.

[0075] In either mode, the interface controller 202 may first check whether the volatile memory 204 has memory cells available for storing data. To do this, the command circuitry 230 may refer to the memory array 252 (e.g., using a set of memory address bits) to determine whether one or more of the n volatile memory cell sets (e.g., rows) associated with the memory address are empty (e.g., storing random or invalid data). For example, the command circuitry 230 may determine whether one or more of the n volatile memory cell sets (e.g., rows) are available based on tagging information and validity information stored in the memory array 252. In some cases, the volatile memory cell sets in the volatile memory 204 may be referred to as lines, cache lines, or rows.

[0076] If one of the n associated sets of volatile memory cells is available to store information, then the interface controller 202 may transfer data from buffer 218 to volatile memory 204 for storage in the set of volatile memory cells. However, if the associated set of volatile memory cells is not empty, then the interface controller 202 may initiate an eviction process to free up space for data in volatile memory 204. The eviction process may involve transferring compromised data from one of the n associated sets of volatile memory cells to buffer 220. Dirty information for the compromised data may 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 may be transferred from buffer 218 to volatile memory 204, and compromised data may be transferred from buffer 220 to non-volatile memory 206. In some cases, a dirty subset of the old data is transferred to non-volatile memory 206 and a clean subset (e.g., an unmodified subset) is discarded. The dirty subset can be identified by engine 246-b based on the dirty information passed from memory array 254 to register 258 during the eviction process.

[0077] In another example, interface controller 202 may receive a retrieval command from a host device. The retrieval command can be received via C / A bus 226 and passed to command circuitry 230 via one or more of C / A bus interface 210 and decoder 228. The retrieval command may contain 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 memory array 252 (e.g., using a set of memory address bits) to determine whether one or more of n sets (e.g., rows) of volatile memory cells associated with the memory address store the requested data. If the requested data is stored in volatile memory 204, then interface controller 202 may pass the requested data to buffer 218 for transmission to the host device via data bus 260.

[0078] If the requested data is not stored in volatile memory 204, then interface controller 202 may retrieve the data from non-volatile memory 206 and pass the data to buffer 218 for transmission to the host device via data bus 260. Alternatively, interface controller 202 may pass the requested data from buffer 218 to volatile memory 204, allowing for low-latency data access during subsequent retrieval operations. However, before passing the requested data, interface controller 202 may first determine whether one or more of the n associated sets of volatile memory cells are available to store the requested data. Interface controller 202 may determine the availability of the n associated sets of volatile memory cells by communicating with the associated cache management circuitry. If the associated sets of volatile memory cells are available, then interface controller 202 may pass the data from buffer 218 to volatile memory 204 without performing an eviction process. Otherwise, interface controller 202 may pass the data from buffer 218 to volatile memory 204 after performing an eviction process.

[0079] The memory subsystem 200 can be implemented in one or more configurations, including single-chip and multi-chip versions. 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 contain 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.

[0080] In some instances, register 256 may be configured to enable engine 246-a to monitor (e.g., continuously monitor) dirty information for associated buffer 218. Dirty information reflects the dirty state of data stored in buffer 218 relative to data in the memory associated with buffer 218. Data in buffer 218 may be considered dirty if it differs from corresponding data in the associated memory, or if the memory does not contain corresponding data. In some instances, register 256 may be configured to enable engine 246-a to monitor (e.g., continuously monitor) validity information for associated buffer 218. Validity information reflects the validity state of data stored in buffer 218 relative to rows in the memory associated with the buffer. Data in buffer 218 may be considered valid if it is associated with an open row in the associated memory; however, data in buffer 218 may be considered invalid if it is random data or data from a row different from the open row.

[0081] In some instances, register 258 may be configured to enable engine 246-b to monitor (e.g., continuously monitor) dirty information for associated buffer 220. Dirty information may reflect the dirty state of data stored in buffer 220 relative to corresponding data in non-volatile memory 206. If the data in buffer 220 differs from the corresponding data in non-volatile memory 206, or if non-volatile memory 206 does not have the corresponding data, then the data may be considered dirty. In some instances, register 258 may be configured to enable engine 246-b to monitor (e.g., continuously monitor) validity information for associated buffer 220. Validity information may reflect the validity state of data stored in buffer 220. If the data in buffer 220 is associated with a line undergoing the current eviction procedure, then the data may be considered valid; however, if the data in buffer 220 is random data or data from a line other than the line undergoing the eviction procedure, then the data may be considered invalid.

[0082] It should be understood that volatile memory 204 and non-volatile memory 206 can support various strategies for accessing memory cells. For example, volatile memory 204 and non-volatile memory 206 can adhere to an activation strategy that requires volatile memory 204 and non-volatile memory 206 to open (or "activate") a row before reading data from or writing data to it. Additionally, volatile memory 204 and non-volatile memory 206 can adhere to a page-closing strategy that requires a row in a bank of memory 204 or non-volatile memory 206 to be closed (or "deactivated") before another row in the same bank is activated.

[0083] As mentioned, buffer 218 can be used to accumulate data (e.g., data to be written to the row) or data from the row for a row in the associated memory of volatile memory 204. For example, in a write scenario, buffer 218 can accumulate data from the host device that is to be written to a row in the associated memory of volatile memory 204. Interface controller 202 can then transfer the data from buffer 218 to volatile memory 204. It should be understood that, depending on the validity and dirty state of the data, some or all of the data in buffer 218 may be transferred to volatile memory 204. For example, interface controller 202 can transfer valid dirty data for a row from buffer 218 to the associated memory of volatile memory 204. As described herein, interface controller 202 can implement opportunistic write-back by transferring valid dirty data from buffer 218 to volatile memory 204 before receiving a precharge command for a row from the host device. Since the interface controller 202 transfers data to the volatile memory 204 in small blocks of information (e.g., 64B) at a time (e.g., due to the cache line size of the volatile memory 204), starting the write-back process earlier allows the interface controller 202 to complete the write-back process earlier (compared to other techniques).

[0084] In some instances (e.g., in the event of a read miss or write miss), interface controller 202 may evict data from rows in volatile memory 204 before writing new data to the row. Buffer 218 may be used to accumulate corrupted data evicted from the associated memory in volatile memory 204. After receiving a precharge command for a row from the host device, interface controller 202 may begin transferring data from buffer 218 to volatile memory 204. It should be understood that, depending on the validity and dirty state of the data, some or all of the data in buffer 218 may be transferred to volatile memory 204. For example, interface controller 202 may transfer valid dirty data for a row from buffer 218 to the associated memory in volatile memory 204. As described herein, interface controller 202 may implement opportunistic write-back by transferring valid dirty data from buffer 218 to volatile memory 204 before receiving a precharge command for a row from the host device. Since data is transmitted to volatile memory 204 in small blocks (e.g., 32B) at a time, starting the eviction process earlier allows interface controller 202 to complete the eviction process earlier (compared to other techniques).

[0085] Figure 3 This describes an example of a device 300 that supports opportunity data movement, as disclosed herein. Device 300 may be or include, as referenced... Figure 1 The memory subsystem 110 described or as referenced Figure 2The described aspects of the memory subsystem 200. Alternatively, the device can be any type of device comprising multiple memories. The device 300 can execute opportunistic write-back and opportunistic eviction procedures, which can improve the operation of the device 300 relative to other types of write-back and eviction procedures.

[0086] Although illustrated with limited connections for ease of illustration, additional connections between the various components of device 300 are contemplated. For example, buffers 365 and 370 may be coupled to volatile memory 305 and non-volatile memory 310, allowing data to be transferred between buffers 365 and 370 and the memory. Furthermore, additional components may be included and encompassed. For example, volatile memory 305 may contain multiple (e.g., x) banks, and each bank may have a write-back engine 330, a victim engine 335, an eviction engine 340, an open page register 355, a victim page register 360, an open page buffer 365, and a victim page buffer 370 (a total of x components for each listed component, where x is the number of banks in volatile memory 305). However, for ease of illustration, the techniques disclosed herein are described with reference to individual examples of each listed component. Although described individually, buffers 365 and 370 may be combined in some instances. In other words, in some instances, the functionality of buffers 365 and 370 can be provided by a single buffer.

[0087] The device 300 can implement opportunistic write-back procedures, as described herein, by operating the open page buffer 365, the open page register 355, the write-back (WB) engine 330, the volatile memory (VM) scheduler 325, and the volatile memory interface circuitry system 350, as well as other components. Return to Reference Figure 2 Open page buffer 365 may be an instance of buffer 218, open page register 355 may be an instance of register 256, write-back engine 330 may be an instance of engine 246-a, volatile memory scheduler 325 may be an instance of scheduler 248-b, and volatile memory interface circuit system 350 may be an instance of memory interface circuit system 240.

[0088] Open page register 355 can be configured to reflect (e.g., continuously reflect) the validity and dirty states of data in open page buffer 365. For example, open page register 355 may include multiple trigger circuits that output flags indicating the validity and dirty states of data for each 64B (or other granularity) of data in open page buffer 365. The flags output by the trigger circuits can be updated in real time as the validity and dirty states of data in open page buffer 365 change. Therefore, open page register 355 can be configured to provide (e.g., continuously provide) (or make dirty and validity information available or passable) to write-back engine 330. As mentioned, the data in open page buffer 365 may contain data for open rows of memory in volatile memory 305. In some instances, open page buffer 365 may also contain data from the previous open row of memory.

[0089] When data for an open row in volatile memory 305 is stored in the open page buffer 365, the data can be considered valid data; however, data for a previously open (but now closed) row in volatile memory can be considered invalid. When data for a row in volatile memory 305 is stored in the open page buffer 365, if the data differs from the corresponding data in volatile memory 305 (or if the corresponding data does not exist in volatile memory 305), then the data can be considered dirty data.

[0090] The write-back engine 330 can monitor validity and dirty information within the open page register 355 and (e.g., based on validity and dirty information) transmit a write-back request along with associated storage information to the volatile memory scheduler 325. The write-back request may indicate dirty data to be transferred from the open page buffer 365 to the volatile memory 305, along with the associated volatile memory address, ensuring the data is stored in the correct location. The associated storage information may include one or more dirty flags, the total amount of dirty data in the open page buffer 365, or both. The write-back request may also be referred to as a write-back command and can be considered an access command from the perspective of the volatile memory scheduler.

[0091] The volatile memory scheduler 325 can accumulate access commands (referred to as VM access commands) for the volatile memory and determine the order and timing of their issuance. The volatile memory scheduler 325 can receive and arbitrate between VM access commands originating from the host device and access commands generated internally (e.g., from other components of the interface controller 302). For example, the volatile memory scheduler 325 can arbitrate between access commands used to satisfy write-back requests from the write-back engine and access commands used to satisfy host device requests. Host device requests can be received from the command circuitry 315, which can sequence VM access commands and NVM access commands. In addition to arbitrating access commands, the volatile memory scheduler 325 can also control the direction of the data bus between the interface controller 302 and the volatile memory 305. The direction of the data bus or the data bus “mode” can refer to the in-bound or out-bound data flow from the perspective of the interface controller 302.

[0092] In the case of arbitration between VM access commands, the volatile memory scheduler 325 can consider the data bus direction as a factor. For example, if the data bus is operating in the write direction (e.g., configured for data transfer), the volatile memory scheduler can issue a write command; if the data bus is operating in the read direction (e.g., configured for receiving), the volatile memory scheduler can issue a read command. The volatile memory scheduler 325 can use a turnaround strategy to determine when to switch the data bus direction. The turnaround strategy can be based on various factors, such as the number of queued write commands for the volatile memory 305, the number of queued read commands for the volatile memory 305, the priority of the access commands, the readiness of the memory bank for activating the command, or a combination of these metrics. Since the issuance of access commands is based on the data bus direction, the factors of the turnaround strategy can be considered as factors for issuing access commands.

[0093] After receiving a write-back request from the write-back engine, the volatile memory scheduler 325 may add one or more access commands to one or more queues to satisfy the write-back request. For example, based on the write-back request, the volatile memory scheduler 325 may add a write command for an open row of volatile memory 305 to the write command queue. The volatile memory scheduler 325 may also maintain a read command queue. As mentioned, the volatile memory scheduler 325 may determine the direction of the data bus based on the number of write commands in the write queue and the number of read commands in the read queue. Therefore, the issuance of write commands for the write-back procedure may be based on the number of write commands in the write queue and the number of read commands in the read queue. If the data bus is operating in the write direction, the volatile memory scheduler 325 may issue a write command for a row of volatile memory. The order in which write commands are issued relative to other queued write commands may be based on the order of receipt, the relative priority of the write commands, or both, and other metrics. According to the opportunistic write-back technique described herein, the volatile memory scheduler 325 can issue a write command for the write-back procedure before the interface controller 302 receives a precharge command for opening a row.

[0094] Access commands issued by the volatile memory scheduler 325 can be received by the volatile memory interface circuitry system 350 and forwarded to the volatile memory 305. The volatile memory interface circuitry system 350 can be responsible for the timing of the forwarding of access commands to the volatile memory 305 (e.g., ensuring that access commands are issued to the volatile memory 305 at appropriate timing). Therefore, the interface controller 302 can implement opportunistic write-back procedures.

[0095] The device 300 can implement an opportunistic eviction procedure, as described herein, by operating the victim page buffer 370, the victim page register 360, the victim engine 335, the eviction engine 340, the non-volatile memory (NVM) scheduler 320, the non-volatile memory interface circuitry system 345, and other components. (Return to Reference) Figure 2 Victim page buffer 370 may be an instance of buffer 220, victim page register 360 may be an instance of register 256, victim engine 335 and eviction engine 340 may be instances of engine 246-b which is functionally split into two components, nonvolatile memory scheduler 320 may be an instance of scheduler 248-a, and volatile memory interface circuit system 350 may be an instance of memory interface circuit system 234.

[0096] Victim page register 360 can be configured to reflect (e.g., continuously reflect) the validity and dirty status of data in victim page buffer 370. For example, victim page register 360 may include multiple trigger circuits that output indicators of the validity and dirty status of each 64B (or other granularity) of data in victim page buffer 370. Flags output by the trigger circuits can be updated in real time as the validity and dirty status of data in victim page buffer 370 changes. Therefore, victim page register 360 can be configured to provide (e.g., continuously provide) (or make dirty and validity information available or passable) to victim engine 335 and eviction engine 340. As mentioned, the data in victim page buffer 370 may contain data from a victim row of memory in volatile memory 305. In some instances, victim page buffer 370 may also contain data from a previous victim row of memory.

[0097] If the data of the current victim row from volatile memory 305 is stored in the victim page buffer 370, the data can be considered valid data; however, the data of the previous victim row from volatile memory 305 can be considered invalid. If the data of the current victim row from volatile memory 305 is stored in the victim page buffer 370, and the data is different from the corresponding data in non-volatile memory 310 (or if the corresponding data does not exist in non-volatile memory 310), then the data can be considered dirty data.

[0098] Victim engine 335 can monitor validity and dirt information within victim page register 360 and (e.g., based on validity and dirt information) transmit victim requests and associated storage information to volatile memory scheduler 325. A victim request may indicate data transferred from volatile memory 305 to victim page buffer 370 as part of an eviction process, along with the associated non-volatile memory address, so that the data can be stored in the correct location in non-volatile memory 310. A victim request may also be referred to as a victim command and can be considered an access command from the perspective of volatile memory scheduler 325. Volatile memory scheduler 325 may add access commands associated with a victim request (e.g., one or more read commands for a victim row in volatile memory 305) to appropriate queues and arbitrate between access commands and other access commands as described herein.

[0099] The eviction engine 340 can monitor validity and dirty information within the victim page register 360 and (e.g., based on validity and dirty information) transmit an eviction request along with associated storage information to the non-volatile memory scheduler 320. The eviction request may indicate the dirty victim data to be transferred from the victim page buffer 370 to the non-volatile memory 310, along with the associated non-volatile memory address, ensuring the dirty victim data is stored in the correct location. The associated storage information may include one or more dirty flags, the total amount of dirty data in the victim page buffer 370, or both. The eviction request may also be referred to as an eviction command and can be considered an access command from the perspective of the non-volatile memory scheduler 320.

[0100] The non-volatile memory scheduler 320 can accumulate access commands for non-volatile memory (referred to as NVM access commands) and determine the order and timing of their issuance. The non-volatile memory scheduler 320 can receive and arbitrate between NVM access commands originating from the host device and access commands generated internally (e.g., from other components of the interface controller 302). For example, the non-volatile memory scheduler 320 can arbitrate between access commands used to satisfy eviction requests from the eviction engine 340 and access commands used to satisfy host device requests. Host device requests can be received from the command circuitry 315, which can sequence VM access commands and NVM access commands. In addition to arbitrating NVM access commands, the non-volatile memory scheduler 320 can control the direction of the data bus between the interface controller 302 and the non-volatile memory 310.

[0101] In the case of arbitration between NVM access commands, the non-volatile memory scheduler 320 can consider the data bus direction as a factor. For example, if the data bus is operating in the write direction, the non-volatile memory scheduler 320 can issue a write command, and if the data bus is operating in the read direction, the non-volatile memory scheduler 320 can issue a read command. The non-volatile memory scheduler 320 can use a turnaround strategy to determine when to switch the direction of the data bus. The turnaround strategy can be based on various factors, such as the number of queued write commands for the non-volatile memory 310, the number of queued read commands for the non-volatile memory 310, the priority of the access commands, the readiness of the memory bank for activating the command, or a combination of these metrics.

[0102] Upon receiving an eviction request from eviction engine 340, nonvolatile memory scheduler 320 may add one or more access commands to one or more queues to satisfy the eviction request. For example, based on the eviction request, nonvolatile memory scheduler 320 may add a write command for a row of nonvolatile memory 310 associated with data in victim page buffer 370 to a write command queue. Nonvolatile memory scheduler 320 may also maintain a read command queue. As mentioned, nonvolatile memory scheduler 320 may determine the direction of the data bus based on the number of write commands in the write queue and the number of read commands in the read queue. Therefore, the issuance of write commands for the eviction procedure may be based on the number of write commands in the write queue and the number of read commands in the read queue. If the data bus is operating in the write direction, then nonvolatile memory scheduler 320 may issue a write command for a row of nonvolatile memory 310. The order in which write commands are issued relative to other queued write commands may be based on the order of receipt, the relative priority of the write commands, or both, and other metrics. According to the opportunistic eviction technique described herein, the nonvolatile memory scheduler 320 can issue a write command for the eviction process before the interface controller 302 receives a precharge command for the victim line of volatile memory 305.

[0103] Access commands issued by the non-volatile memory scheduler 320 can be received by the non-volatile memory interface circuitry system 345 and forwarded to the non-volatile memory 310. The non-volatile memory interface circuitry system 345 can be responsible for the timing of the forwarding of access commands to the non-volatile memory 310 (e.g., ensuring that access commands are issued to the non-volatile memory 310 at appropriate timing).

[0104] Therefore, the interface controller 302 can implement an opportunity eviction procedure.

[0105] Figure 4 This describes an example of a process flow 400 that supports opportunity data movement, as disclosed in the examples herein. Process flow 400 may be derived from, as referenced... Figure 1 The described memory subsystem 110 or interface controller 115, as referenced Figure 2 The described memory subsystem 200 or interface controller 202, as referenced Figure 3 The described device 300 or interface controller 302 or another type of device is implemented. Process flow 400 may illustrate the operation of the device during the opportunity to write back the program.

[0106] For ease of reference, process flow 400 is described in the reference apparatus. For example, aspects of process flow 400 may be implemented by means including volatile memory, which serves as a cache for non-volatile memory. Alternatively, aspects of process flow 400 may be implemented as instructions stored in memory (e.g., firmware stored in volatile memory 120 or non-volatile memory 125). For example, when executed by a controller, the instructions may cause the controller to perform the operations of process flow 400.

[0107] At 405, an activation command may be received, for example, from a host device. For instance, interface controller 302 may receive an activation command for row x of memory bank n. The activation command may instruct row x to be activated (e.g., powered on, opened). In response to the activation command, interface controller 302 may open row x of memory bank n. At 410, a write command may be received from a host device. For instance, interface controller 302 may receive a write command for row x of memory bank n. The write command may be associated with data received from the host device.

[0108] At 415, in response to a write command, the data associated with the write command can be stored, for example, in a buffer. For instance, interface controller 302 can write data to a buffer associated with memory bank n (e.g., open page buffer 365). At 420, dirty information for the buffer can be monitored. For instance, write-back engine 330 can monitor the dirty flag of the buffer maintained by open page register 355. At 425, data can be determined to be dirty. For instance, write-back engine 330 can determine data to be dirty based on a dirty flag associated with the data (e.g., a dirty bit).

[0109] At 430, data can be transferred from, for example, a buffer to, for example, volatile memory, and associated write commands can be transferred to, for example, volatile memory. For example, interface controller 302 can transfer data from a buffer to volatile memory 305, and interface controller 302 can transfer associated write commands for the data to volatile memory 305. Write commands can be issued from volatile memory scheduler 325 (e.g., in response to a write-back request from a write-back engine) and can be forwarded to volatile memory 305 via volatile memory interface circuitry 350. Volatile memory scheduler 325 can issue write commands based on the number of write commands queued for volatile memory 305, the number of read commands queued for volatile memory 305, the priority of the write commands, the availability of memory banks for activating the commands, or a combination of these metrics. After receiving data and associated write commands, volatile memory 305 can write data to row x of memory bank n. Before receiving a precharge command for a row, the interface controller 302 may continue to opportunistically move dirty data from the buffer to volatile memory.

[0110] At 435, a command, such as a precharge command, may be received from the host device. For example, interface controller 302 may receive a precharge command for row x of memory bank n. At 440, any remaining dirty data in the buffer may be transferred to volatile memory for storage in row x of memory bank n. The remaining dirty data may be transferred based on the precharge command. After receiving the remaining dirty data, volatile memory 305 may write the remaining dirty data to row x of memory bank n and close row x. Volatile memory 305 may close row x after receiving the remaining data based on the precharge command received by the volatile memory.

[0111] Therefore, write-back opportunities may be implemented. 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 below, 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.

[0112] Figure 5 This describes an example of process flow 500 that supports opportunity data movement, as disclosed in the examples herein. Process flow 500 may be derived from, as referenced... Figure 1 The described memory subsystem 110 or interface controller 115, as referenced Figure 2 The described memory subsystem 200 or interface controller 202, as referenced Figure 3The described device 300 or interface controller 302 or another type of device is implemented. Process flow 500 can illustrate the operation of the device during an opportunity expulsion procedure. In some instances, aspects of process flow 500 may occur in parallel with or partially overlap with aspects of process flow 400 in time. For example, aspects of process flow 500 may be executed as part of an expulsion procedure initiated in response to an activation command received in process flow 400.

[0113] For ease of reference, the reference apparatus describes process flow 500. For example, aspects of process flow 500 may be implemented by means including volatile memory, which serves as a cache for non-volatile memory. Alternatively, aspects of process flow 500 may be implemented as instructions stored in memory (e.g., firmware stored in volatile memory 120 or non-volatile memory 125). For example, when executed by a controller, the instructions may cause the controller to perform the operations of process flow 500.

[0114] At 505, a write command for data can be received from a row of volatile memory. For example, the controller of victim page buffer 370 can receive a write command for victim data from row x of memory bank n. At 510, in response to the write command, the victim data associated with the write command can be stored in a buffer associated with memory bank n. For example, interface controller 302 can write the victim data to a buffer associated with memory bank n (e.g., victim page buffer 370). At 515, dirty information for the buffer can be monitored. For example, eviction engine 340 can monitor the dirty flag of the buffer maintained by victim page register 360. At 520, the victim data can be determined to be dirty victim data. For example, eviction engine 340 can determine that the victim data is dirty victim data based on the dirty flag (e.g., dirty bit) associated with the victim data.

[0115] At point 525, dirty victim data can be transferred from the buffer to non-volatile memory, and associated write commands can be transferred to non-volatile memory. For example, interface controller 302 can transfer dirty victim data from victim page buffer 370 to non-volatile memory 310, and interface controller 302 can transfer associated write commands for dirty victim data to non-volatile memory 310. Write commands can be issued from non-volatile memory scheduler 320 (e.g., in response to an eviction request from eviction engine 340) and can be forwarded to non-volatile memory 310 via non-volatile memory interface circuitry 345. Non-volatile memory scheduler 320 can issue write commands based on the number of write commands queued for non-volatile memory 310, the number of read commands queued for non-volatile memory 310, the priority of the write commands, the availability of memory banks in non-volatile memory 310 for activating commands, or a combination of these metrics. After receiving data and the associated write command, the non-volatile memory 310 can write the corrupted data from row x of memory bank n into the non-volatile memory 310. Before receiving a precharge command for the row, the interface controller 302 can continue to opportunistically move dirty corrupted data from the buffer to the non-volatile memory.

[0116] At 530, a precharge command can be received from the host device. For example, interface controller 302 can receive a precharge command for row x of memory bank n. At 535, any remaining dirty data in the buffer can be transferred to non-volatile memory 310 for storage. The remaining dirty data can be transferred based on the precharge command. After receiving the remaining dirty data, non-volatile memory 310 can write the remaining dirty data to itself. After the remaining dirty data is transferred to non-volatile memory 310, the buffer can be used for a new eviction procedure. The new eviction procedure can come from the same memory bank (e.g., memory bank n, where a single buffer is used per memory bank) or from different memory banks (e.g., where a dynamic buffer pool is used).

[0117] Therefore, an opportunity eviction procedure can be implemented. Alternative instances of the foregoing can be implemented, in which some operations are performed in a different order than described, in parallel, or not at all. In some cases, operations may include additional features not mentioned below, 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.

[0118] Figure 6 A block diagram 600 illustrates a memory device 620 supporting opportunistic data movement according to an example disclosed herein. The memory device 620 may be as described in the references... Figures 1 to 5Examples of aspects of the described memory device. Memory device 620 or its various components may be examples of means for performing various aspects of opportunistic data movement as described herein. For example, memory device 620 may include receiving circuitry 625, a first buffer controller 630, a first transmission circuitry 635, a second buffer controller 640, a second transmission circuitry 645, a volatile memory controller 650, a first state circuitry 655, a first scheduling circuitry 660, a non-volatile memory controller 670, a second state circuitry 665, a second scheduling circuitry 675, or any combination thereof. Each of these components may communicate with each other directly or indirectly (e.g., via one or more buses).

[0119] The receiving circuit 625 may be or includes a data bus, data bus interface, logic, circuitry, processor, controller, or other components capable of performing the functions described herein. The first buffer controller 630 may be or includes logic, circuitry, processor, controller, or other components capable of performing the functions described herein. The first buffer controller 630 controls the operation of the open page buffer 365. The first transmission circuit 635 may be or includes a data bus, data bus interface, logic, circuitry, processor, controller, or other components capable of performing the functions described herein. The second buffer controller 640 may be or includes logic, circuitry, processor, controller, or other components capable of performing the functions described herein. The second buffer controller 640 controls the operation of the victim page buffer 370. The second transmission circuit 645 may be or includes a data bus, data bus interface, logic, circuitry, processor, controller, or other components capable of performing the functions described herein. The volatile memory controller 650 may be or includes logic, circuitry, processor, controller, or other components capable of performing the functions described herein.

[0120] The first state circuit 655 may be or include logic, circuitry, a processor, a controller, or other components capable of performing the functions described herein. The first state circuit 655 may be an instance of the write-back engine 330. The first scheduling circuit 660 may be or include logic, circuitry, a processor, a controller, or other components capable of performing the functions described herein. The first scheduling circuit 660 may be an instance of the volatile memory scheduler 325. The second state circuit 665 may be or include logic, circuitry, a processor, a controller, or other components capable of performing the functions described herein. The second state circuit 665 may be an instance of the evict engine 340. The non-volatile memory controller 670 may be or include logic, circuitry, a processor, a controller, or other components capable of performing the functions described herein. The second scheduling circuit 675 may be or include logic, circuitry, a processor, a controller, or other components capable of performing the functions described herein. The second scheduling circuit 675 may be an instance of the non-volatile memory scheduler 320.

[0121] The receiving circuit 625 may be configured or otherwise support means for receiving from a host device a write command associated with a row of memory in volatile memory, the volatile memory being configured to function as a cache for non-volatile memory. The first buffer controller 630 may be configured or otherwise support means for writing data associated with the write command to a buffer associated with and coupled to the volatile memory. The first transmission circuit 635 may be configured or otherwise support means for transferring data from the buffer to the volatile memory, at least in part based on the write command and before receiving a precharge command for a row of memory from the host device.

[0122] In some instances, the volatile memory controller 650 may be configured or otherwise support means for writing data to rows of a bank in the volatile memory, at least in part based on a write command, after the data has been transferred to the volatile memory.

[0123] In some instances, the first state circuit 655 may be configured or otherwise support means for determining that data contains dirty data that is different from the corresponding data in the row, wherein data is transferred from the buffer to volatile memory based at least in part on the fact that the data contains dirty data.

[0124] In some instances, the first state circuit 655 may be configured or otherwise support means for monitoring dirty information for a buffer, the dirty information being in a register associated with the buffer, wherein data is transmitted based at least in part on the dirty information indicating that the data contains dirty data.

[0125] In some instances, the first scheduling circuit 660 may be configured or otherwise support means for determining a first number of queued write commands for volatile memory and a second number of queued read commands for volatile memory, wherein data is transmitted based at least in part on the first number of queued write commands and the second number of queued read commands.

[0126] In some instances, the first buffer controller 630 may be configured or otherwise support means for writing second data for a row into the buffer, at least in part based on a second write command. In some instances, the first transfer circuit 635 may be configured or otherwise support means for transferring second data from the buffer to the volatile memory, at least in part based on the second write command and before receiving a precharge command for a row of the memory bank.

[0127] In some instances, the first buffer controller 630 may be configured or otherwise support means for writing second data for a row into the buffer, at least in part based on a second write command. In some instances, the receiving circuitry 625 may be configured or otherwise support means for receiving a precharge command for a row of memory from a host device. In some instances, the first transmission circuitry 635 may be configured or otherwise support means for transferring second data from the buffer to volatile memory, at least in part based on the second write command and the precharge command.

[0128] In some instances, the first buffer controller 630 may be configured or otherwise support means for determining, at least in part, that a row of the memory bank is storing second data based on a write command. In some instances, the second buffer controller 640 may be configured or otherwise support means for storing the second data in a second buffer coupled to both volatile and non-volatile memory, at least in part based on a determination. In some instances, the second transfer circuitry 645 may be configured or otherwise support means for transferring the second data to the non-volatile memory before receiving a precharge command for the memory bank.

[0129] The second buffer controller 640 may be configured or otherwise support means for receiving write commands for data from rows of memory in volatile memory, the volatile memory being configured to act as a cache for non-volatile memory. In some instances, the second buffer controller 640 may be configured or otherwise support means for writing data from rows of memory to buffers coupled to both volatile and non-volatile memory, at least in part based on write commands. The second transfer circuit 645 may be configured or otherwise support means for transferring data from the buffer to non-volatile memory, at least in part based on write commands and before receiving a precharge command for rows of memory from the host device.

[0130] In some instances, the nonvolatile memory controller 670 may be configured or otherwise support means for writing data to nonvolatile memory based at least in part on a write command and after data has been transferred to volatile memory.

[0131] In some instances, write commands are associated with an evictation procedure used to save data from rows of memory in volatile memory to non-volatile memory.

[0132] In some instances, the second state circuit 665 may be configured or otherwise support means for determining that data contains dirty data that is different from the corresponding data in the non-volatile memory, wherein the data is transferred from the buffer to the non-volatile memory based at least in part on the fact that the data contains dirty data.

[0133] In some instances, the second state circuit 665 may be configured or otherwise support means for monitoring dirty information for the buffer provided by a register associated with the buffer, wherein data is transmitted based at least in part on dirty information indicating that the data contains dirty data.

[0134] In some instances, the second scheduling circuit 675 may be configured or otherwise support means for determining a first number of queued write commands for non-volatile memory and a second number of queued read commands for non-volatile memory, wherein data is transmitted based at least in part on the first number of queued write commands and the second number of queued read commands.

[0135] In some instances, the second buffer controller 640 may be configured or otherwise support means for writing second data for a row into the buffer, at least in part based on a second write command. In some instances, the receiving circuitry 625 may be configured or otherwise support means for receiving a precharge command for a row of memory from a host device. In some instances, the second transmission circuitry 645 may be configured or otherwise support means for transferring second data from the buffer to non-volatile memory, at least in part based on both the second write command and the precharge command.

[0136] In some instances, the second buffer controller 640 may be configured or otherwise support means for writing second data for a row into the buffer, at least in part based on a second write command. In some instances, the second transfer circuitry 645 may be configured or otherwise support means for transferring second data from the buffer to non-volatile memory, at least in part based on the second write command and after receiving a precharge command for a row of the memory bank.

[0137] Figure 7 The flowchart illustrates a method 700 for supporting opportunistic data movement according to examples disclosed herein. Operation of method 700 may be implemented by a memory device or its components as described herein. For example, it may be implemented by a device as described in the references... Figures 1 to 6 The described memory device performs the operation of method 700. In some instances, the memory device may execute an instruction set to control the functional elements of the device to perform the described function. Alternatively, the memory device may use dedicated hardware to perform aspects of the described function.

[0138] At 705, the method may include receiving from a host device a write command associated with a row of memory in volatile memory, the volatile memory being configured to serve as a cache for non-volatile memory. The operation at 705 may be performed according to examples disclosed herein. In some instances, it may be performed by, as referenced... Figure 6 The described receiving circuit 625 performs the operation of 705.

[0139] At 710, the method may include writing data associated with a write command to a buffer associated with the memory bank and coupled to volatile memory. The operation at 710 may be performed according to examples disclosed herein. In some instances, it may be performed by, as referenced... Figure 6 The first buffer controller 630 described performs the operation of 710.

[0140] At 715, the method may include transferring data from a buffer to volatile memory at least in part based on (e.g., in response to) a write command and before receiving a precharge command for a row of memory from the host device. The operation of 715 may be performed according to examples disclosed herein. In some instances, it may be performed by, as referenced... Figure 6 The first transmission circuit 635 described performs the operation of 715.

[0141] In some instances, the device as described herein may perform one or more methods, such as method 700. The device may include features, circuitry, logic, means, or instructions (e.g., a non-transitory computer-readable medium storing instructions executable by a processor) for: receiving from a host device a write command associated with a line of memory in volatile memory, the volatile memory being configured to function as a cache for non-volatile memory; writing data associated with the write command to a buffer associated with and coupled to the volatile memory; and transferring data from the buffer to the volatile memory at least in part based on (e.g., in response to) the write command and before receiving a precharge command for the line of memory from the host device.

[0142] Some examples of the method 700 and apparatus described herein may further include operations, features, circuit systems, logic, means, or instructions for writing data to a bank of memory in volatile memory, at least in part based on (e.g., in response to) a write command and after data has been transferred to volatile memory.

[0143] Some examples of the method 700 and apparatus described herein may further include operations, features, circuit systems, logic, devices, or instructions for determining that data contains dirty data that may differ from the corresponding data in a row, wherein data may be transferred from a buffer to volatile memory based at least in part on the fact that the data contains dirty data.

[0144] Some examples of the method 700 and apparatus described herein may further include operations, features, circuit systems, logic, means, or instructions for monitoring dirty information for a buffer, the dirty information being in a register associated with the buffer, wherein data may be transmitted at least in part based on the dirty information indicating that the data contains dirty data.

[0145] Some examples of the method 700 and apparatus described herein may further include operations, features, circuit systems, logic, means, or instructions for determining a first number of queued write commands for volatile memory and a second number of queued read commands for said volatile memory, wherein data may be transferred at least in part based on the first number of queued write commands and the second number of queued read commands.

[0146] Some examples of the method 700 and apparatus described herein may further include operations, features, circuitry, logic, means, or instructions for: writing second data for a row to a buffer at least in part based on a second write command; and transferring the second data from the buffer to volatile memory at least in part based on (e.g., in response to, due to) the second write command and before a precharge command for a row of the memory bank can be received.

[0147] Some examples of the method 700 and apparatus described herein may further include operations, features, circuit systems, logic, means, or instructions for: writing second data for a row to a buffer at least in part based on a second write command; receiving a precharge command for a row of memory from a host device; and transferring the second data from the buffer to volatile memory at least in part based on the second write command and the precharge command.

[0148] Some examples of the method 700 and apparatus described herein may further include operations, features, circuit systems, logic, means, or instructions for: determining, at least in part based on a write command, that a row of a memory bank is capable of storing second data; storing the second data in a second buffer coupled to a volatile memory and a non-volatile memory, at least in part based on the determination; and transferring the second data to the non-volatile memory before a precharge command for the memory bank can be received.

[0149] Figure 8 The flowchart illustrates a method 800 for supporting opportunistic data movement according to examples disclosed herein. Operation of method 800 may be implemented by a memory device or its components as described herein. For example, it may be implemented by a device as described in the references... Figures 1 to 6 The described memory device performs the operation of method 800. In some instances, the memory device may execute an instruction set to control the functional elements of the device to perform the described function. Alternatively, the memory device may use dedicated hardware to perform aspects of the described function.

[0150] At 805, the method may include receiving a write command for data from a row of a bank in volatile memory, said volatile memory being configured to act as a cache for non-volatile memory. The operation of 805 may be performed according to examples disclosed herein. In some instances, it may be performed by reference to... Figure 6 The second buffer controller 640 described performs the operation of 805.

[0151] At 810, the method may include writing data from rows of memory to a buffer coupled to both volatile and non-volatile memory, at least in part based on (e.g., in response to) a write command. The operation of 810 may be performed according to examples disclosed herein. In some instances, it may be performed by, as referenced... Figure 6 The second buffer controller 640 described performs the operation of 810.

[0152] At 815, the method may include transferring data from a buffer to non-volatile memory at least in part based on (e.g., in response to) a write command and before receiving a precharge command for a row of memory from the host device. The operation of 815 may be performed according to examples disclosed herein. In some instances, it may be performed by, as referenced... Figure 6 The second transmission circuit 645 described performs the operation of 815.

[0153] In some instances, the device as described herein may perform one or more methods, such as method 800. The device may include features, circuitry, logic, means, or instructions (e.g., a non-transitory computer-readable medium storing instructions executable by a processor) for: receiving a write command for data from a row of a bank in volatile memory, the volatile memory being configured to function as a cache for non-volatile memory; writing data from a row of the bank to a buffer coupled to the volatile memory and the non-volatile memory, at least in part based on the write command; and transferring data from the buffer to the non-volatile memory, at least in part based on the write command and before receiving a precharge command for a row of the bank from a host device.

[0154] Some examples of the methods 800 and devices described herein may further include operations, features, circuit systems, logic, means, or instructions for writing data to non-volatile memory, at least in part, based on a write command and after transferring data to volatile memory.

[0155] In some instances of the method 800 and apparatus described herein, a write command may be associated with an evicting procedure for saving data from a line of memory in volatile memory to non-volatile memory.

[0156] Some examples of the method 800 and apparatus described herein may further include operations, features, circuit systems, logic, devices, or instructions for determining that data contains dirty data that may differ from corresponding data in nonvolatile memory, wherein data may be transferred from a buffer to nonvolatile memory at least in part based on the data containing dirty data.

[0157] Some examples of the methods 800 and devices described herein may further include operations, features, circuit systems, logic, means, or instructions for monitoring dirty information for a buffer provided by a register associated with the buffer, wherein data may be transferred at least in part based on dirty information indicating that the data contains dirty data.

[0158] Some examples of the method 800 and apparatus described herein may further include operations, features, circuit systems, logic, means, or instructions for determining a first number of queued write commands for non-volatile memory and a second number of queued read commands for non-volatile memory, wherein data may be transferred at least in part based on the first number of queued write commands and the second number of queued read commands.

[0159] Some examples of the method 800 and apparatus described herein may further include operations, features, circuit systems, logic, means, or instructions for: writing second data for a row to a buffer at least in part based on a second write command; receiving a precharge command for a row of memory from a host device; and transferring the second data from the buffer to nonvolatile memory at least in part based on the second write command and the precharge command.

[0160] Some examples of the method 800 and apparatus described herein may further include operations, features, circuit systems, logic, means, or instructions for: writing second data for a row to a buffer at least in part based on a second write command; and transferring the second data from the buffer to a nonvolatile memory at least in part based on the second write command and after a precharge command for a row of the memory bank can be received.

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

[0162] Describe another device. The device may include: non-volatile memory; volatile memory configured to serve 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 being configured to cause the device to: receive from a host device a write command associated with a row of a memory bank in the volatile memory; write data associated with the write command to a buffer associated with the memory bank and coupled to the volatile memory; transfer data from the buffer to the volatile memory at least in part based on the write command and before receiving a precharge command for a row of the memory bank from the host device; and write data to a row of the memory bank in the volatile memory after the data has been transferred to the volatile memory and at least in part based on the write command.

[0163] In some instances of the device, the interface controller may be further used to enable the device to determine that the data contains dirty data that may be different from the corresponding data in the row, wherein the data may be transferred from the buffer to the volatile memory at least in part based on the fact that the data contains dirty data.

[0164] In some instances of the device, the interface controller may be further configured to enable the device to monitor dirty information for the buffer provided by registers associated with the buffer, wherein data may be transmitted based at least in part on dirty information indicating that the data contains dirty data.

[0165] In some instances of the device, the interface controller may further be configured to enable the device to determine a first number of queued write commands for volatile memory and a second number of queued read commands for volatile memory, wherein data may be transmitted based at least in part on the first number of queued write commands and the second number of queued read commands.

[0166] Describe another device. The device may include: a non-volatile memory; a volatile memory configured to serve 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 being configured to cause the device to: receive a write command for data from a row of a memory bank in the volatile memory; write data from the row of the memory bank to a buffer coupled to the volatile memory and the non-volatile memory, at least in part based on the write command; transfer data from the buffer to the non-volatile memory, at least in part based on the write command and before receiving a precharge command for the row of the memory bank; and write data to the non-volatile memory after transferring the data to the non-volatile memory and at least in part based on the write command.

[0167] In some instances of the device, the interface controller may be further configured to enable the device to determine that the data contains dirty data that may differ from the corresponding data in the non-volatile memory, wherein the data may be transferred from the buffer to the non-volatile memory at least in part based on the fact that the data contains dirty data.

[0168] In some instances of the device, the interface controller may be further configured to enable the device to monitor dirty information for the buffer provided by registers associated with the buffer, wherein data may be transmitted based at least in part on dirty information indicating that the data contains dirty data.

[0169] In some instances of the device, the interface controller may further be configured to enable the device to determine a first number of queued write commands for the non-volatile memory and a second number of queued read commands for the non-volatile memory, wherein data may be transmitted based at least in part on the first number of queued write commands and the second number of queued read commands.

[0170] 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 above description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or light particles, or any combination thereof. Some diagrams may illustrate a signal as a single signal; however, a signal may represent a bus of signals, where the bus may have various bit widths.

[0171] It should be noted that the methods described above describe possible implementations, and the operations and steps can be rearranged or otherwise modified, and other implementations are possible. Furthermore, two or more parts from the methods described may be combined.

[0172] When used to describe conditional actions or processes, the terms "if..., then...", "when...", "based on...", "at least in part based on...", and "in response to..." are interchangeable.

[0173] 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 a signal 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.

[0174] 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, the timing and frequency of 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 where pins are reserved, 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.

[0175] 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 passing procedures for responding to a single command (e.g., the burst length or number of bytes allowed in response to a command may be different). Simply translating a command into an action should not be interpreted as the use of two different protocols. In fact, if the corresponding procedures or parameters defined by the two protocols change, then the protocols can be considered different. For example, if a device supports different addressing schemes or different passing procedures for responding to commands, then the device can be said to support two different protocols.

[0176] The terms "electronic communication," "conductive contact," "connection," and "coupling" can refer to the relationship between components that supports the flow of signals between them. Components are considered to be in electronic communication with each other (or in conductive contact with each other, or connected to each other, or coupled to each other) if there are any conductive paths between them that support the flow of signals at any given time. At any given time, the conductive paths between components that are in electronic communication with each other (or in conductive contact with each other, or connected to each other, or coupled to each other) can be open or closed, depending on the operation of the device containing the connected components. The conductive paths between connected components can be direct conductive paths between components, or indirect conductive paths 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.

[0177] The term "coupling" refers to the condition that moves 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, the component initiates a change that allows signals to flow between the other components via conductive paths that were previously not permitted.

[0178] The term "isolation" refers to a 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 isolates two components, it prevents signals from flowing between the components using previously permitted conductive paths.

[0179] 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 by ion implantation or by any other doping method.

[0180] 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 (e.g., degenerate) semiconductor regions. The source and drain may be separated by lightly doped semiconductor regions or a channel. If the channel is n-type (i.e., the majority of charge carriers are electrons), then the FET may be called an n-type FET. If the channel is p-type (i.e., the majority of charge carriers are holes), then the FET may be called a p-type FET. The channel may be capped by an insulating gate oxide. The channel conductivity can be controlled by applying a voltage to the gate. For example, applying a positive or negative voltage to an n-type 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 "on" or "activated." When a voltage less than the transistor's threshold voltage is applied to the transistor's gate, the transistor may be "off" or "deactivated."

[0181] The description herein, illustrated with reference to the accompanying drawings, describes exemplary configurations and does not represent all instances that can be implemented or that are within the scope of the claims. The term "exemplary" as used herein means "serving as an example, illustration, or description" and is not "preferred" or "superior" to other instances. The detailed description includes specific details to provide an understanding of the described techniques. However, these techniques can be practiced without these specific details. In some cases, well-known structures and apparatuses are shown in block diagram form to avoid obscuring the concept of the described instances.

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

[0183] 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 above description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or light particles, or any combination thereof.

[0184] The various illustrative blocks and modules described in connection with the disclosure herein may be implemented or performed using a general-purpose processor, DSP, ASIC, FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor 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).

[0185] The functionality described herein can be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functionality can be stored as one or more instructions or code on or transmitted via a computer-readable medium. Other examples and embodiments are within the scope of this disclosure and the appended claims. For example, due to the nature of software, the functionality described above can be implemented using software executed by a processor, hardware, firmware, hardwired, or any combination thereof. Features implementing the functionality can also be physically located in various locations, including distributed implementations such that portions of the functionality are implemented in different physical locations. And, 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 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). Additionally, 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".

[0186] Computer-readable media includes both non-transitory computer storage media and communication media that include any media that facilitates the transfer of computer programs 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 can 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 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 is 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.

[0187] 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. A memory device comprising: a non-volatile memory; a volatile memory configured to serve as a cache for the non-volatile memory; and an interface controller coupled with the non-volatile memory and the volatile memory, the interface controller usable to cause the memory device to: receive a write command associated with a row of a bank in the volatile memory from a host device; write data associated with the write command to a buffer associated with the bank and coupled with the volatile memory; transfer the data from the buffer to the volatile memory by the interface controller based at least in part on the write command and prior to receiving by the interface controller from the host device a precharge command associated with the data for the row of the bank; and write the data to the row of the bank in the volatile memory after transferring the data to the volatile memory and based at least in part on the write command.

2. The memory device of claim 1, wherein the interface controller is further usable to cause the memory device to: determine that the data includes dirty data that is different from corresponding data in the row, wherein transferring the data from the buffer to the volatile memory is based at least in part on the data including dirty data.

3. The memory device of claim 1, wherein the interface controller is further usable to cause the memory device to: monitor dirty information for the buffer provided by a register associated with the buffer, wherein transferring the data is based at least in part on the dirty information indicating that the data includes dirty data.

4. The memory device of claim 1, wherein the interface controller is further usable to cause the memory device to: determine a first number of queued write commands for the volatile memory and a second number of queued read commands for the volatile memory, wherein transferring the data is based at least in part on the first number of queued write commands and the second number of queued read commands.

5. The memory device of claim 1, wherein the interface controller is further usable to cause the memory device to: write second data for the row to the buffer based at least in part on a second write command; and transfer the second data from the buffer to the volatile memory based at least in part on the second write command and prior to receiving the precharge command for the row of the bank.

6. The memory device of claim 1, wherein the interface controller is further usable to cause the memory device to: write second data for the row to the buffer based at least in part on a second write command; receive the precharge command for the row of the bank from the host device; and transfer the second data from the buffer to the volatile memory based at least in part on the second write command and the precharge command.

7. The memory device of claim 1, wherein the interface controller is further operable to cause the memory device to: determine, based at least in part on the write command, that the row of the bank is storing second data; based at least in part on the determination, store the second data in a second buffer coupled with the volatile memory and the non-volatile memory; and transfer the second data to the non-volatile memory prior to receiving the precharge command for the bank.

8. A memory device, comprising: a non-volatile memory; a volatile memory configured to function as a cache for the non-volatile memory; and an interface controller coupled with the non-volatile memory and the volatile memory, the interface controller operable to cause the memory device to: receive a write command for data from a row of a bank in the volatile memory; based at least in part on the write command, write the data from the row of the bank to a buffer coupled with the volatile memory and the non-volatile memory; based at least in part on the write command and prior to receiving a precharge command for the row of the bank from a host device, transfer the data from the buffer to the non-volatile memory; and after transferring the data to the non-volatile memory and based at least in part on the write command, write the data to the non-volatile memory.

9. The memory device of claim 8, wherein the write command is associated with an eviction procedure for saving the data from the row of the bank in the volatile memory to the non-volatile memory.

10. The memory device of claim 8, wherein the interface controller is further operable to cause the memory device to: determine that the data includes dirty data that is different from corresponding data in the non-volatile memory, wherein the data is transferred from the buffer to the non-volatile memory based at least in part on the data including dirty data.

11. The memory device of claim 8, wherein the interface controller is further operable to cause the memory device to: monitor dirty information for the buffer provided by a register associated with the buffer, wherein the data is transferred based at least in part on the dirty information indicating that the data includes dirty data.

12. The memory device of claim 8, wherein the interface controller is further operable to cause the memory device to: determine a first number of queued write commands for the non-volatile memory and a second number of queued read commands for the non-volatile memory, wherein the data is transferred based at least in part on the first number of queued write commands and the second number of queued read commands.

13. The memory device of claim 8, wherein the interface controller is further operable to cause the memory device to: writing second data for the row to the buffer based at least in part on a second write command; receiving the precharge command for the row of the bank from the host device; and transferring the second data from the buffer to the non-volatile memory based at least in part on the second write command and the precharge command.

14. The memory device of claim 8, wherein the interface controller is further usable to cause the memory device to: write second data for the row to the buffer based at least in part on a second write command; and transfer the second data from the buffer to the non-volatile memory based at least in part on the second write command and after receiving the precharge command for the row of the bank.

15. A method at a memory device, comprising: receiving a write command from a host device associated with a row of a bank in a volatile memory, the volatile memory used as a cache for a non-volatile memory; writing data associated with the write command to a buffer associated with the bank and coupled with the volatile memory; and transferring the data from the buffer to the volatile memory by the memory device based at least in part on the write command and prior to receiving, by the memory device from the host device, a precharge command for the row of the bank associated with the data.

16. The method of claim 15, further comprising: writing the data to the row of the bank in the volatile memory based at least in part on the write command and after transferring the data to the volatile memory.

17. The method of claim 15, further comprising: determining that the data includes dirty data different from corresponding data in the row, wherein the data is transferred from the buffer to the volatile memory based at least in part on the data including dirty data.

18. The method of claim 15, further comprising: monitoring dirty information for the buffer, the dirty information in a register associated with the buffer, wherein the data is transferred based at least in part on the dirty information indicating that the data includes dirty data.

19. The method of claim 15, further comprising: determining a first number of queued write commands for the volatile memory and a second number of queued read commands for the volatile memory, wherein the data is transferred based at least in part on the first number of queued write commands and the second number of queued read commands.

20. The method of claim 15, further comprising: writing second data for the row to the buffer based at least in part on a second write command; and transferring the second data from the buffer to the volatile memory based at least in part on the second write command and prior to receiving the precharge command for the row of the bank. ​ 21. A method at a memory device, comprising: receiving a write command for data from a row of a bank in volatile memory used as a cache for non-volatile memory; writing the data from the row of the bank to a buffer coupled with the volatile memory and the non-volatile memory based at least in part on the write command; and transferring the data from the buffer to the non-volatile memory based at least in part on the write command and prior to receiving a precharge command for the row of the bank from a host device.

22. The method of claim 21, further comprising: writing the data to the non-volatile memory based at least in part on the write command and after transferring the data to the volatile memory.

23. The method of claim 21, further comprising: determining that the data includes dirty data different from corresponding data in the non-volatile memory, wherein the data is transferred from the buffer to the non-volatile memory based at least in part on the data including dirty data.

24. The method of claim 21, further comprising: monitoring dirty information for the buffer provided by a register associated with the buffer, wherein the data is transferred based at least in part on the dirty information indicating that the data includes dirty data.

Images