Danger detection in multi-memory devices

Abstract

This application relates to hazard detection in multi-memory devices. A device can receive a first command indicative of a first bank address, a first row address, and a first column address. Based on the first bank address, the device can select a buffer for a hazard detection procedure that detects hazardous commands. As part of the hazard detection procedure, the device can compare the first row address and the first column address from the first command to a second row address and a second column address from a second command in the buffer. The device can determine whether the first command and the second command are hazardous commands based on comparing the first row address and the first column address from the first command to the second row address and the second column address from the second command.

Description

[0001] Cross-referencing

[0002] This patent application claims priority to U.S. Patent Application No. 17 / 584,104, filed January 25, 2022, entitled "HAZARD DETECTION IN A MULTI-MEMORY DEVICE," and U.S. Provisional Patent Application No. 63 / 234,042, filed August 17, 2021, entitled "HAZARD DETECTION IN A MULTI-MEMORY DEVICE," each of which is assigned to the assignee, and each of which is expressly incorporated herein by reference in its entirety. Technical Field

[0003] The technical field relates to hazard detection in multi-memory devices. Background Technology

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

[0005] Various types of memory devices and memory cells exist, including magnetic hard disks, random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase-change memory (PCM), auto-select memory, and chalcogenide memory technology. Memory cells can be volatile or non-volatile. Non-volatile memory, such as FeRAM, can maintain its stored logic state for a long time, even without external power. Volatile memory devices, such as DRAM, may lose their stored state when disconnected from external power. Summary of the Invention

[0006] An apparatus is described. The apparatus may include non-volatile memory; volatile memory; and an interface controller coupled to the non-volatile memory and the volatile memory, the interface controller being operable to cause the apparatus to: receive a first command indicating a first bank address, a first row address, and a first column address; select, at least partially based on the first bank address and from a set of buffers each associated with a corresponding bank of the volatile memory, a buffer for a hazard detection procedure that detects a hazard command subject to an execution sorting condition; as part of the hazard detection procedure and at least partially based on the selection of the buffer, compare the first row address and the first column address from the first command with a second row address and a second column address from a second command in the buffer; and determine, at least partially based on the comparison of the first row address and the first column address from the first command with the second row address and the second column address from the second command, whether the first command and the second command are hazard commands subject to an execution sorting condition.

[0007] A method is described. The method may include receiving a first command indicating a first bank address, a first row address, and a first column address; selecting, at least in part, buffers for a hazard detection procedure from a set of buffers each associated with a corresponding bank of volatile memory, based on the first bank address, the hazard detection procedure detecting hazard commands subject to execution sorting conditions; as part of the hazard detection procedure and at least in part based on the selection of the buffers, comparing the first row address and the first column address from the first command with a second row address and a second column address from the buffers; and determining, at least in part based on comparing the first row address and the first column address from the first command with the second row address and the second column address from the second command, whether the first command and the second command are hazard commands subject to execution sorting conditions.

[0008] A non-transitory computer-readable medium is described. The non-transitory computer-readable medium can store code comprising instructions that, when executed by a processor of an electronic device, cause the electronic device to: receive a first command indicating a first memory address, a first row address, and a first column address; select, at least partially based on the first memory address, a buffer for a hazard detection program from a set of buffers each associated with a corresponding memory bank of volatile memory, the hazard detection program detecting a hazard command subject to an execution ordering condition; as part of the hazard detection program and at least partially based on the selection of the buffer, compare the first row address and the first column address from the first command with a second row address and a second column address from a second command in the buffer; and determine, at least partially based on the comparison of the first row address and the first column address from the first command with the second row address and the second column address from the second command, whether the first command and the second command are hazard commands subject to an execution ordering condition. Attached Figure Description

[0009] Figure 1 Examples of systems supporting hazard detection in multi-memory devices are shown, based on the examples disclosed herein.

[0010] Figure 2 Examples of memory subsystems supporting hazard detection in multi-memory devices are shown, based on the examples disclosed herein.

[0011] Figure 3 An example of an interface controller that supports hazard detection in a multi-memory device is shown, based on the examples disclosed herein.

[0012] Figure 4 Examples of process flows supporting hazard detection in multi-memory devices are shown, based on the examples disclosed herein.

[0013] Figure 5 A block diagram of an apparatus for supporting hazard detection in a multi-memory device, based on examples disclosed herein, is shown.

[0014] Figure 6 The flowchart illustrates one or more methods for hazard detection in a multi-memory device, based on the examples disclosed herein. Detailed Implementation

[0015] For example, an electronic device may include non-volatile memory (e.g., main memory for storing information during other operations) and volatile memory (e.g., secondary memory) that can be used as a cache for the non-volatile memory. This configuration allows the device to benefit from the advantages of non-volatile memory (e.g., non-volatile and persistent storage, high storage capacity, low power consumption) while maintaining compatibility with another device (e.g., a host device) through volatile memory, among other things. To support this type of configuration, the device may include an interface controller that interfaces with the host device on behalf of the volatile and non-volatile memory. The interface controller may include a queue storing commands for one or both of the volatile and non-volatile memory. If a command is received from the host device, as part of a hazard detection procedure, the interface controller may compare the command with all other commands in the queue to determine whether the command is a hazard command subject to execution ordering conditions. However, comparing a command with all commands in the queue may use many components, such as comparators (e.g., one per queue entry), which may increase power consumption and the net die area of ​​the interface controller, and may also introduce other disadvantages.

[0016] According to the techniques described herein, the number of comparators used for hazard detection can be reduced compared to other techniques by using components such as buffers (e.g., folded buffers) to determine whether a command is hazardous. For example, an interface controller may include components for each bank of volatile memory, such as folded buffers, and each component, such as folded buffers, may store commands for the bank corresponding to that component. If a command for a bank is received from a host device, the interface controller can compare the command with commands in components associated with that bank, such as folded buffers. Therefore, the interface controller can use a comparator for each folded buffer (or for each entry of a folded buffer) instead of for each entry in a queue, which can reduce power consumption for hazard detection, the collective coverage area of ​​the comparators, or both, and other advantages.

[0017] Firstly, in reference Figure 1 and 2 The features of this disclosure are described in the context of the system and memory subsystem described herein. (See references...) Figure 3 and 4 The features of this disclosure are described within the context of the interface controller and process flow. Further details can be found in the relevant references. Figure 5 and 6 The device diagrams and flowcharts describing the hazard detection in the multi-memory device illustrate and describe these and other features of this disclosure with reference to the device diagrams and flowcharts.

[0018] Figure 1An example of a system 100 supporting hazard detection in a multi-memory device is shown, based on the examples disclosed herein.

[0019] System 100 may be included in an electronic device such as a computer or telephone. 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 the interface controller 115, as well as other components of the electronic device containing 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 the 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 included 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).

[0020] The devices in system 100 can be coupled via various wires (e.g., traces, printed circuit board (PCB) wiring, redistribution layer (RDL) wiring) that enable the transmission of information (e.g., commands, addresses, data) between the devices. These wires can form channels, data buses, command buses, address buses, etc.

[0021] The memory subsystem 110 can 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 can provide (e.g., relative to volatile memory 120) benefits such as non-volatility, higher capacity, or lower power consumption. However, host device 105 may be configured incompatible with or inefficiently configured with various aspects of non-volatile memory 125. For example, host device 105 may support voltages, 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 can be configured to have 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 the protocols supported by volatile memory 120 while also benefiting from the advantages of non-volatile memory 125.

[0022] In some instances, system 100 may be contained in, or coupled to, a computing device, electronic device, mobile computing device, or wireless device. The device may be a portable electronic device. For example, the device may be a computer, laptop computer, tablet computer, smartphone, cellular phone, wearable device, Internet-connected device, etc. In some instances, the device may be configured for bidirectional wireless communication via a base station or access point. In some instances, the device associated with system 100 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 system 100 may be referred to as a user equipment (UE), station (STA), mobile terminal, etc.

[0023] Host device 105 may be configured to interface with memory subsystem 110 using a first protocol (e.g., Low Power Double Data Rate (LPDDR)) supported by interface controller 115. Therefore, in some instances, host device 105 may interface directly with interface controller 115 and indirectly with non-volatile memory 125 and volatile memory 120. In alternative instances, host device 105 may interface directly with non-volatile memory 125 and volatile memory 120. Host device 105 may also interface with other components of the electronic device comprising system 100. Host device 105 may be or include a SoC, a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or another programmable logic device, discrete gate or transistor logic, discrete hardware components, or combinations of these types of components. In some instances, host device 105 may be referred to as a host.

[0024] Interface controller 115 can be configured (e.g., based on or in response to one or more commands or requests issued by host device 105) to interface with volatile memory 120 and non-volatile memory 125 on behalf of host device 105. For example, interface controller 115 can facilitate the retrieval and storage of data in volatile memory 120 and non-volatile memory 125 on behalf of host device 105. Therefore, interface controller 115 can facilitate data transfer between various sub-components, such as data transfer between at least some of host device 105, volatile memory 120, or non-volatile memory 125. Interface controller 115 can interface with host device 105 and volatile memory 120 using a first protocol, and can interface with non-volatile memory 125 using a second protocol supported by non-volatile memory 125.

[0025] Non-volatile memory 125 may be configured to store digital information (e.g., data) for electronic devices including 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 access operation latency than 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, as described herein, non-volatile memory 125 may have a smaller page size than volatile memory 120.

[0026] 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 electronic devices containing 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.

[0027] In some instances, volatile memory 120 may have shorter access operation latency than 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).

[0028] While non-volatile memory 125 may be a higher-density memory compared to volatile memory 120, in some instances, accessing non-volatile memory 125 may take longer than accessing volatile memory 120 (e.g., due to different architectures and protocols, and other reasons). Therefore, operating volatile memory 120 as a cache can reduce latency in system 100. As an example, by retrieving data from volatile memory 120 instead of from non-volatile memory 125, access requests for data from host device 105 can be satisfied relatively quickly. To facilitate the use of volatile memory 120 as a cache, interface controller 115 may include multiple buffers 135. Buffers 135 may be located on the same die as interface controller 115 and may be configured to temporarily store data for transfer between volatile memory 120, non-volatile memory 125, or host device 105 (or any combination thereof) during one or more access operations (e.g., store and retrieve operations).

[0029] Access operations may also be referred to as access procedures or access routines, and may involve one or more sub-operations performed by one or more components in the memory subsystem 110. Examples of access operations may include storage operations in which data provided by the host device 105 is stored (e.g., written to) volatile memory 120 or non-volatile memory 125 (or both), and retrieval operations in which data requested by the host device 105 is obtained (e.g., read) from volatile memory 120 or non-volatile memory 125 and returned to the host device 105.

[0030] To store data in memory subsystem 110, host device 105 may transmit a write command (also known as a write request, store command, or store request) to interface controller 115. The write command may contain a memory address or be accompanied by a memory address targeting a location (e.g., a set of cells) in non-volatile memory 125. In some instances, the set of memory cells may also be referred to as a portion of memory. Host device 105 may also provide data to be written. Interface controller 115 may temporarily store the data in buffer 135-a. After storing the data in buffer 135-a, interface controller 115 may transfer the data from buffer 135-a to volatile memory 120 or non-volatile memory 125, or both. In write-through mode, interface controller 115 may transfer the data to both volatile memory 120 and non-volatile memory 125. In write-back mode, interface controller 115 may transfer the data only to volatile memory 120 (wherein the data is transferred to non-volatile memory 125 during a later eviction process).

[0031] In either mode, interface controller 115 may identify appropriate locations (e.g., sets of volatile memory cells) within volatile memory 120 for storing data associated with write commands. To do this, interface controller 115 may implement set-associative mapping, where addresses of non-volatile memory 125 are mapped to multiple addresses of volatile memory 120. For example, interface controller 115 may implement an n-way associative mapping that allows data from (or for) addresses of non-volatile memory 125 (e.g., locations, sets of non-volatile memory cells) to be stored at one of n addresses (e.g., locations, sets of volatile memory cells, cache blocks) of volatile memory 120, where the n addresses may be collectively referred to as a set. Therefore, interface controller 115 can manage volatile memory 120 as a cache of non-volatile memory 125 by referencing a set of n addresses of volatile memory 120 associated with a target address. Although described with reference to set-associative 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 associative mapping, and other instances).

[0032] After determining which set of n addresses is associated with the target non-volatile address, the interface controller 115 can store the data at one of the n addresses in that set. Therefore, by retrieving data from the low-latency volatile memory 120 instead of the high-latency non-volatile memory 125, subsequent (e.g., later) read commands from the host device 105 can be efficiently satisfied. Thus, by storing the data in the volatile memory 120, write commands from the host device 105 can be satisfied fully (e.g., in write-back mode) or partially (e.g., in write-through mode). To track the data stored in the volatile memory 120, the interface controller 115 can use tag addresses indicating which data is stored at different addresses in the volatile memory 120.

[0033] To retrieve data from memory subsystem 110, host device 105 transmits a read command (also referred to as a read request, retrieval command, or retrieval request) to interface controller 115. The read command can target an address in non-volatile memory 125. Upon receiving the read command, interface controller 115 can examine the requested data in volatile memory 120. For example, interface controller 115 can check whether the requested data is stored at one of n addresses associated with the target non-volatile memory address. If the data is stored at one of the n addresses, interface controller 115 can transfer the data from volatile memory 120 to buffer 135-a, making it available for transmission to host device 105. Generally, the term "hit" can be used to refer to a scenario where volatile memory 120 stores data targeted by host device 105.

[0034] If the volatile memory 120 does not store the requested data, the interface controller 115 may transfer the requested data from the non-volatile memory 125 to the buffer 135-a so that it can be transmitted to the host device 105. Generally, the term "miss" can be used to refer to a scenario where the volatile memory 120 does not store the data targeted by the host device 105. In a miss scenario, after transferring the requested data to the buffer 135-a, the interface controller 115 may transfer the requested data from the buffer 135-a to the volatile memory 120 so that subsequent read requests for the data can be satisfied through the volatile memory 120 instead of the non-volatile memory 125. For example, the interface controller 115 may store the data at one of n addresses in a set associated with the target non-volatile memory address. If other data is already stored at the n addresses, the interface controller 115 may transfer the other data to the buffer 135-b so that it can be transmitted to the non-volatile memory 125 for storage. This process can be referred to as "eviction," and the data transferred from volatile memory 120 to buffer 135-b can be referred to as "victim data."

[0035] In some cases, interface controller 115 may transfer a subset of the compromised data from buffer 135-b to non-volatile memory 125. For example, interface controller 115 may transfer one or more subsets of the data that have changed since the compromised data was initially stored in non-volatile memory 125. Data that is inconsistent between volatile memory 120 and non-volatile memory 125 (e.g., due to an update in one memory but not in another) may be referred to as “modified” or “dirty” data in some cases. In some instances (e.g., when the interface controller is operating in a mode such as write-back mode), dirty data may be data that exists in volatile memory 120 but not in non-volatile memory 125.

[0036] Therefore, if volatile memory 120 is full, interface controller 115 may execute an eviction procedure to save data from volatile memory 120 to non-volatile memory 125 (e.g., to make room for new data in volatile memory 120). In some instances, interface controller 115 may execute a "filling" procedure in which data from non-volatile memory 125 is saved to volatile memory 120. Interface controller 115 may execute a filling procedure in the event of a miss (e.g., filling volatile memory 120 with relevant data). For example, in the event of a read miss (which occurs if a read command from host device 105 targets data stored in non-volatile memory 125 instead of volatile memory 120), interface controller 115 may retrieve the data requested by the read command (from non-volatile memory 125) and, in addition to returning the data to the host device, store the data in volatile memory 120 (e.g., so that the data can be quickly retrieved in the future).

[0037] Therefore, the memory subsystem 110 may satisfy (or “fulfill”) the request using volatile memory 120 or non-volatile memory 125, depending on the hit or miss status of the request (e.g., a read command, a write command) from the host device 105. For example, in the case of a read miss, non-volatile memory 125 may satisfy the read command from the host device 105, meaning that the data returned from the host device 105 may originate from non-volatile memory 125. And in the case of a read hit, volatile memory 120 may satisfy the read command from the host device 105, meaning that the data returned from the host device 105 may originate from volatile memory 120. In some instances, the hit-to-miss ratio (“hit-miss ratio”) may be relatively high (e.g., the hit percentage (or “hit rate”) may be approximately 85%, while the miss percentage (or “miss rate”) may be approximately 15%).

[0038] In some instances, interface controller 115 may include a queue storing commands for volatile memory 120 and non-volatile memory 125. Interface controller 115 may add commands received from host device 105, as well as other (e.g., internally generated) commands, to the queue. In some instances, interface controller 115 may perform hazard detection to detect dangerous commands, which may be commands subject to execution ordering conditions. For example, consider write commands to memory banks, rows, and columns, received before read commands to those memory banks, rows, and columns. In this scenario (referred to as a read-after-write hazard), both the write command and the read command may be dangerous commands because the write command should be executed before the read command (otherwise, the read command might return erroneous data). Therefore, commands with the same address information (e.g., the same memory bank address, row address, and column address) may be dangerous commands.

[0039] According to the techniques described herein, interface controller 115 can perform hazard detection by comparing a received command with commands in a memory-specific buffer. For example, a command for memory x can be compared with commands in a buffer for memory x, rather than with commands in a queue. Memory-specific buffers can store fewer commands than queues, which allows interface controller 115 to reduce the number of comparators used for hazard detection (e.g., compared to techniques comparing commands in a queue). In practice, memory-specific buffers may each be limited to a few entries, so the total number of entries in memory-specific buffers is less than the total number of entries in queues. Therefore, interface controller 115 can reduce power consumption and increase available die space (compared to other techniques) by reducing the number of comparators used for hazard detection.

[0040] System 100 may include any number of non-transitory computer-readable media that support hazard detection as described herein. For example, host device 105, interface controller 115, volatile memory 120, or non-volatile memory 125 may include or otherwise access one or more non-transitory computer-readable media that store instructions (e.g., firmware) for performing the functions described herein that pertain to host device 105, interface controller 115, volatile memory 120, or non-volatile memory 125. For example, such instructions, when executed by host device 105 (e.g., host device controller), interface controller 115, volatile memory 120 (e.g., local controller), or non-volatile memory 125 (e.g., local controller), may cause host device 105, interface controller 115, volatile memory 120, or non-volatile memory 125 to perform the associated functions described herein.

[0041] Figure 2An example of a memory subsystem 200 supporting hazard detection in a multi-memory device is shown, according to the examples 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 in the reference... Figure 1 The host device interaction is described. The memory subsystem 200 may include an interface controller 202, volatile memory 204, and non-volatile memory 206, which may be as described in reference... Figure 1 The described interface controller 115, volatile memory 120, and non-volatile memory 125 are examples. Therefore, the interface controller 202 can represent, as referenced... Figure 1 The described host device interfaces with volatile memory 204 and non-volatile memory 206. For example, interface controller 202 can 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 advantages of non-volatile memory 206 (e.g., non-volatile, high-density storage) while maintaining compatibility with host devices that support different protocols compared to non-volatile memory 206.

[0042] exist Figure 2 In this diagram, dashed lines between components represent data flows or data transmission paths, while solid lines between components represent command flows or command transmission paths. In some cases, the memory subsystem 200 is one of several similar or identical subsystems that can be included in an electronic device. Each subsystem may be referred to as a slice and, in some instances, may be associated with a corresponding channel of the host device.

[0043] Non-volatile memory 206 can be configured to be used as main memory for a host device (e.g., memory for long-term data storage). In some cases, non-volatile memory 206 may comprise one or more arrays of FeRAM cells. Each FeRAM cell may include a select component 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 enabled word line can be sensed, for example, in parallel or simultaneously, without having to sense all FeRAM cells coupled to the enabled word line. Therefore, the page size for the FeRAM array may be different from (e.g., smaller than) the DRAM page size. In the context of a memory device, a page may refer to a row of memory cells (e.g., a group of memory cells with a common row address), and the page size may refer to the number of memory cells or column addresses in a row, or the number of column addresses accessed during an access operation. Alternatively, the page size may refer to the size of data processed 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).

[0044] The smaller page size of FeRAM arrays offers various efficiency advantages because individual FeRAM cells may require more power to read or write compared to individual DRAM cells. For example, the smaller page size for FeRAM arrays facilitates efficient energy use because a smaller number of FeRAM cells can be enabled at minute intervals of associated changes in information. In some instances, depending on the nature of the data and commands utilizing FeRAM operations, the page size of the array of FeRAM cells can, for example, change dynamically (e.g., during operation of the FeRAM cell array).

[0045] While individual FeRAM cells may require more power to read or write compared to individual DRAM cells, FeRAM cells can maintain their stored logic states for extended periods in the absence of an external power supply because the ferroelectric material in the FeRAM cell can maintain a non-zero polarization in the absence of an electric field. Therefore, including an FeRAM array in non-volatile memory 206 offers power and efficiency advantages over volatile memory cells (e.g., DRAM cells in volatile memory 204) because it reduces or eliminates constraints on performing refresh operations.

[0046] 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 a dielectric material to store charge representing a programmable state. The memory cells of volatile memory 204 may be logically grouped or arranged into one or more memory banks (as referred to herein as "banks"). For example, volatile memory 204 may comprise sixteen banks. The memory cells of a bank may be arranged in a grid or an array of intersecting columns and rows, and each memory cell may be accessed or refreshed by applying an appropriate voltage to the digital lines (e.g., column lines) and word lines (e.g., row lines) for the memory cell. A row of a bank may be referred to as a page, and the page size may refer to the number of columns or memory cells in a row (and thus the amount of data that a row can store). As mentioned, the page size of volatile memory 204 may differ from (e.g., be larger than) the page size of non-volatile memory 206.

[0047] Interface controller 202 may include various circuitry for interfacing (e.g., communicating) with other devices, such as a host device, 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 information transmission using one or more communication protocols. For example, data bus interface 208, C / A bus interface 210, data bus interface 216, and C / A bus interface 264 may support information transmission using a first protocol (e.g., LPDDR signaling), while data bus interface 212 and C / A bus interface 214 may support information transmission using a second protocol. Therefore, the various bus interfaces coupled to interface controller 202 may support different data volumes or data rates.

[0048] Data bus interface 208 can be coupled to data bus 260, transaction bus 222, and buffer circuitry system 224. Data bus interface 208 can be configured to transmit and receive data on data bus 260 and to transmit and receive control information (e.g., acknowledgment / negative acknowledgment) or metadata on transaction bus 222. Data bus interface 208 can also be configured to transfer data between data bus 260 and buffer circuitry system 224. Data bus 260 and transaction bus 222 can be coupled to interface controller 202 and host device, such that a conductive path is established between interface controller 202 and host device. In some instances, the pin of transaction bus 222 may be referred to as a Data Mask Inversion (DMI) pin. Although shown as having one data bus 260 and one transaction bus 222, any number of data buses 260 and any number of transaction buses 222 may be coupled to one or more data bus interfaces 208.

[0049] 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 on C / A bus 226. Commands and addresses received on C / A bus 226 can be associated with data received or transmitted on data bus 260. C / A bus interface 210 can also be configured to transmit commands and addresses to decoder 228, enabling decoder 228 to decode commands and forward the decoded commands and associated addresses to command circuitry system 230.

[0050] 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 on 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 on C / A bus 236 to non-volatile memory 206 (e.g., to a local controller of non-volatile memory 206). Commands and addresses transmitted on C / A bus 236 can be associated with data received or transmitted on 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.

[0051] Data bus interface 216 can 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 can be configured to transmit and receive data on data bus 238, which can be coupled to volatile memory 204. Data bus interface 216 can also be configured to transfer data between data bus 238 and memory interface circuitry 240. C / A bus interface 264 can be coupled to C / A bus 242 and memory interface circuitry 240. C / A bus interface 264 can be configured to receive commands and addresses from memory interface circuitry 240 and forward commands and addresses on C / A bus 242 to volatile memory 204 (e.g., to a local controller of volatile memory 204). Commands and addresses transmitted on C / A bus 242 can be associated with data received or transmitted on 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.

[0052] In addition to the bus and bus interface for communicating with the coupled devices, 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.

[0053] Command circuitry system 230 may be coupled to buffer circuitry system 224, decoder 228, cache management circuitry system 244, scheduler 248, and other components. Command circuitry system 230 may also be referred to as a controller and may be configured to manage commands for volatile memory and commands for non-volatile memory. Command circuitry system 230 may be configured to receive command and address information from decoder 228 and store the command and address information in queue 250. Command circuitry system 230 may include logic 262 that processes command information (e.g., from the host device) and metadata from other components (e.g., cache management circuitry system 244, buffer circuitry system 224) and uses the information to generate one or more commands for scheduler 248. Command circuitry system 230 may also be configured to transmit address information (e.g., address bits) to cache management circuitry system 244. In some instances, logic 262 may be circuitry configured to function as a finite state machine (FSM).

[0054] Buffer circuitry system 224 may be coupled to data bus interface 208, command circuitry system 230, memory interface circuitry system 234, and memory interface circuitry system 240. Buffer circuitry system 224 may include a collection of one or more buffer circuits for at least some (if not every) of the 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 memory 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 memory bank of volatile memory 204 (or both). As an example, the buffer circuitry for memory bank 0 (BK0) can be configured to store data from or for the first memory bank of the volatile memory 204 (or both), and the buffer circuitry for memory bank 15 (BK15) can be configured to store data from or for the sixteenth memory bank of the volatile memory 204 (or both).

[0055] Each set of buffer circuits in buffer circuit system 224 may include a pair of buffers. The pair of buffers may include: one buffer (e.g., an Open Page Data (OPD) buffer) configured to store data targeted by an access command (e.g., a write command or read command) from the host device; and another buffer (e.g., a Victim Page Data (VPD) buffer) configured to store data for an eviction process triggered by the access command. For example, the set of buffer circuits for BK0 may include buffers 218 and 220, which may be instances of buffers 135-a and 135-b, respectively. Buffer 218 may be configured to store BK0 data targeted by an access command from the host device. Additionally, buffer 220 may be configured to store data transferred from BK0 as part of an eviction process triggered by the access command. Each buffer in the set of buffer circuits may be configured with a size corresponding to the page size (e.g., storage capacity) of volatile memory 204. For example, if the page size of volatile memory 204 is 2kB, then the size of each buffer may be 2kB. Therefore, in some instances, the size of the buffer can be equivalent to the page size of the volatile memory 204.

[0056] Cache management circuitry system 244 may be coupled to command circuitry system 230, engine 246, scheduler 248, and other components. Cache management circuitry system 244 may include sets of cache management circuitry for one or more banks of volatile memory (e.g., each bank). As an example, cache management circuitry system 244 may include sixteen sets of cache management circuitry for BK0 through BK15. Each set of cache management circuitry may include two memory arrays configured to store metadata for volatile memory 204. As an example, the set of cache management circuitry for BK0 may include memory array 252 (e.g., a cache DRAM (CDRAM) tag array (CDT-TA)) and memory array 254 (e.g., a CDRAM active (CDT-V) array), configured to store metadata for BK0. In some instances, memory arrays for multiple banks (e.g., two banks) may be combined and referred to as groups or blocks. Memory arrays may also be referred to as arrays, local arrays, or buffers, and other suitable terms. In some cases, memory arrays may be or contain volatile memory cells, such as static RAM (SRAM) cells. However, memory arrays are not limited to SRAM.

[0057] Metadata may include tag information, validity information, or dirty information (or any combination thereof) associated with volatile memory 204, and other instances. Tag information (e.g., tag addresses) may indicate which data is stored at an address in volatile memory 204. For example, tag information for an address in volatile memory 204 may indicate a non-volatile memory address associated with data stored at that address in volatile memory 204. As mentioned, validity information may indicate whether the data stored in volatile memory 204 is actual data (e.g., data with an expected order or form) or placeholder data (e.g., random or dummy data without an expected or important order). Moreover, dirty information may indicate whether the data stored in volatile memory 204 is different from the corresponding data stored in non-volatile memory 206. For example, dirty information may indicate whether the data stored in volatile memory 204 has been updated relative to the data stored in non-volatile memory 206.

[0058] Memory array 252 may be an instance of a local array and may contain memory cells storing metadata (e.g., tag information, validity information, dirty information) of one or more associated stores of volatile memory 204. Memory array 252 may also be referred to as a tag memory array or tag memory. The metadata in memory array 252 may be stored row-wise (e.g., there may be corresponding metadata for each row associated with a volatile memory store). Interface controller 202 can examine requested data in volatile memory 204 by referring to the metadata in memory array 252. For example, interface controller 202 may receive a read command from a host device for data associated with an address in non-volatile memory 206. Interface controller 202 may use a subset of address bits to reference the metadata in memory array 252. For example, using set-associative mapping, interface controller 202 may use a first subset of address bits to determine which set of n addresses is associated with the data, and may use a second subset of address bits to determine whether any of the n addresses in the set stores the data.

[0059] In addition to storing tag information, memory array 252 may also store validity information indicating whether data in volatile memory 204 is actual data (also called valid data) or random data (also called invalid data). For example, volatile memory 204 may initially store random data and continue to do so until data is written to the volatile memory cells from a host device or non-volatile memory 206. To track which data is valid, memory array 252 may be configured to set a bit of the set of volatile memory cells (e.g., rows) when actual data is stored. This bit may be called a validity bit or validity flag. Like tag information, validity information stored in memory array 252 may be stored row-wise. Thus, in some instances, each validity bit may indicate the validity of data stored in the associated row. In some instances, memory array 252 may store dirty information indicating whether a set of volatile memory cells (e.g., rows) stores any dirty data. Similar to validity information, dirty information stored in memory array 252 may be stored row-wise.

[0060] Memory array 254 may also be an instance of a local array. Memory array 254 may also be referred to as a data memory array or data memory. Memory array 254 may be similar to memory array 252 and may also include memory cells that store metadata for one or more banks of volatile memory 204 associated with memory array 252. For example, memory array 254 may store validity information and dirt information for one or more banks of volatile memory 204. However, the metadata stored in memory array 254 may be stored by sub-blocks rather than by rows. For example, validity information stored in memory cells of memory array 254 may indicate the validity of data for a subset of volatile memory cells in a row of volatile memory 204.

[0061] Therefore, in some instances, metadata in memory array 252 may be stored row-wise (e.g., for 2kB of data) and sub-block-wise (e.g., for 64B of data). For illustration, validity information in memory array 254 may indicate the validity of each subset (e.g., 32B or 64B) of data stored in rows of volatile memory 204. Similarly, dirty information stored in memory array 254 may indicate which subsets of volatile memory cells in rows of volatile memory 204 store dirty data. Storing metadata (e.g., tag information, validity information, dirty information) row-wise in memory array 252 allows interface controller 202 to determine whether data in volatile memory 204 has a hit or a miss. Storing metadata (e.g., validity information, dirty information) in sub-blocks in memory array 254 allows interface controller 202 to determine which subsets of the data to return to the host device (e.g., during a read process) and which subsets of the data to retain in non-volatile memory 206 (e.g., during an eviction process).

[0062] Each cache management circuitry may also include a corresponding pair of registers coupled to command circuitry system 230, engine 246, memory interface circuitry system 234, memory interface circuitry system 240, and the memory array for the cache management circuitry, as well as other components. For example, the cache management circuitry may include a first register (e.g., register 256, which may be an Open Page Tag (OPT) register) configured to receive metadata (e.g., tag information, validity information, dirty information, other information, or one or more bits of any combination) from memory array 252 or scheduler 248-b, or both. The cache management circuitry may also include a second register (e.g., register 258, which may be a Victim Page Tag (VPT) register) configured to receive metadata (e.g., validity information, dirty information, or both) from memory array 254 and scheduler 248-a, or both. 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 circuitry system 230 may issue a command to read non-volatile memory 206 or volatile memory 204 based on or in response to metadata in register 256 and / or register 258 or both.

[0063] Engine 246-a may be coupled to registers 256 and 258 and scheduler 248. Engine 246-a may be configured to receive metadata from various components and issue commands to scheduler 248 based on or in response to said metadata. For example, if interface controller 202 is in a first mode, such as write-through mode, engine 246-a may issue commands to scheduler 248-b, and in response, scheduler 248-b initiates or facilitates data transfer from buffer 218 to both volatile memory 204 and non-volatile memory 206. Alternatively, if interface controller 202 is in a second mode, such as write-back mode, engine 246-a may issue commands to scheduler 248-b, and in response, scheduler 248-b initiates or facilitates data transfer from buffer 218 to volatile memory 204. In the case of a write-back operation, data stored in volatile memory 204 may eventually be transferred to non-volatile memory 206 during a subsequent (e.g., later) eviction process.

[0064] Engine 246-b may be coupled to register 258 and scheduler 248-a. Engine 246-b may be configured to receive metadata from register 258 and issue commands to scheduler 248-a based on or in response to said metadata. For example, engine 246-b may issue commands to scheduler 248-a to initiate or facilitate the transfer of dirty data from buffer 220 to non-volatile memory 206 (e.g., as part of a retrieval process). If buffer 220 holds a set of data transferred from volatile memory 204 (e.g., damaged data), engine 246-b may indicate which one or more subsets (e.g., which 64Bs) of the data set in buffer 220 should be transferred to non-volatile memory 206.

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

[0066] The memory interface circuitry 234 can communicate with the non-volatile memory 206 via one or more of the data bus interface 212 and the C / A bus interface 214. For example, the memory interface circuitry 234 can prompt the C / A bus interface 214 to forward commands issued by the memory interface circuitry 234 to the local controller in the non-volatile memory 206 via the C / A bus 236. Furthermore, the memory interface circuitry 234 can transmit or receive data from the non-volatile memory 206 via the data bus 232. In some instances, the commands issued by the memory interface circuitry 234 may be supported by the non-volatile memory 206 but not by the volatile memory 204 (e.g., the commands issued by the memory interface circuitry 234 may differ from the commands issued by the memory interface circuitry 240).

[0067] 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 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 but not by the non-volatile memory 206 (e.g., commands issued by the memory interface circuitry 240 may differ from commands issued by the memory interface circuitry 234).

[0068] In summary, the components of interface controller 202 can use non-volatile memory 206 as main memory and volatile memory 204 as cache. Such operations can be prompted by one or more access commands (e.g., read commands and write commands) received from the host device.

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

[0070] In either mode, the interface controller 202 may first check whether the volatile memory 204 has space for storing data (e.g., available memory cells). To do this, the command circuitry system 230 may refer to metadata in the appropriate memory array 252 to determine whether one or more of the n addresses associated with the non-volatile memory address are empty (e.g., storing random or invalid data) or whether one or more of the n addresses associated with the non-volatile memory address are full (e.g., storing valid data). For example, the command circuitry system 230 may determine whether one or more of the n addresses are available for writing (or not available for writing) based on tag information and validity information stored in the memory array 252. The addresses of the volatile memory 204 may be associated with a set of volatile memory cells, which may be referred to as a line, cache line, cache block, or row.

[0071] If one of the n associated addresses is available for writing, the interface controller 202 can transfer data from buffer 218 to volatile memory 204 for storage at said address (e.g., in a set of associated volatile memory cells). However, if none of the n associated addresses are available, the interface controller 202 can initiate an eviction process to free up space in volatile memory 204 for data. The eviction process may involve transferring compromised data from one of the n associated addresses to buffer 220. Dirty information for the compromised data can be transferred from memory array 254 to register 258 for identifying a dirty subset of the compromised data. After the compromised data is stored in buffer 220, new data can be transferred from buffer 218 to volatile memory 204, and compromised data can be transferred from buffer 220 to non-volatile memory 206. In some cases, a dirty subset of old data can be transferred to non-volatile memory 206 and a clean subset (e.g., an unmodified subset) can be discarded. Engine 246-b can identify a dirty subset based on or in response to dirty information transferred from memory array 254 to register 258 during the eviction process.

[0072] In another example, interface controller 202 may receive commands, such as read commands, from a host device. Read commands may be received via C / A bus 226 and transmitted to command circuitry 230 via one or more of C / A bus interface 210 and decoder 228. Read commands may include address bits targeting a memory address of non-volatile memory 206. Before attempting to access the target memory address of non-volatile memory 206, interface controller 202 may check whether volatile memory 204 stores data. To do this, command circuitry 230 may refer to metadata in memory array 252 (e.g., using a set of non-volatile memory address bits) to determine whether one or more of n addresses associated with the non-volatile memory address store the requested data. If the requested data is stored in volatile memory 204, interface controller 202 may transmit the requested data to buffer 218 for transmission to the host device via data bus 260.

[0073] If the requested data is not stored in volatile memory 204 (e.g., the requested data may be stored in non-volatile memory 206 or another location), interface controller 202 may retrieve the data from non-volatile memory 206 and transfer the data to buffer 218 for transmission to the host device via data bus 260. Alternatively, interface controller 202 may transfer the requested data from buffer 218 to volatile memory 204 for lower latency access during subsequent retrieval operations. However, before transferring the requested data, interface controller 202 may first determine whether one or more of the n associated addresses are available to store the requested data (e.g., whether one or more of the n associated addresses are empty or full). Interface controller 202 may determine the availability of the n associated addresses by communicating with the relevant cache management circuitry. If the associated addresses are available, interface controller 202 may transfer the data in buffer 218 to volatile memory 204 without performing an eviction process. Otherwise, the interface controller 202 may transfer the data from the buffer 218 to the volatile memory 204 after the recovery process.

[0074] The memory subsystem 200 can be implemented in one or more configurations, including a single-chip version and a multi-chip version. The multi-chip version may include one or more components of the memory subsystem 200, including interface controller 202, volatile memory 204, and non-volatile memory 206 (and other components or combinations thereof), on a separate chip from the chip containing one or more other components of the memory subsystem 200. For example, in a multi-chip version, the corresponding separate chip may 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.

[0075] As mentioned, queue 250 can store commands received from the host device, and command circuitry 230 can issue those commands, determined by logic 262, to other components of interface controller 202 (e.g., to scheduler 248). Therefore, queue 250 can store a relatively large number of commands (e.g., because queue 250 stores commands from both volatile memory 204 and non-volatile memory 206). According to the techniques described herein, interface controller 202 can perform hazard detection by comparing the received command with commands in a memory-specific buffer, rather than comparing the received command with all commands in queue 250. The memory-specific buffer can be smaller than the queue (e.g., containing fewer entries than the queue). Therefore, compared to other techniques, interface controller 202 can use a reduced number of comparators for hazard detection, which can improve the performance of interface controller 202.

[0076] Figure 3 An example of an interface controller 300 supporting hazard detection in a multi-memory device is shown, according to the examples disclosed herein. The interface controller 300 may be, respectively, referenced to... Figure 1 and 2 Examples of interface controller 115 or interface controller 202 described herein. Among other potential components, interface controller 300 may include controller 305, comparison logic 310, buffer 320, and command circuitry 325, which may be coupled to each other via one or more transmission lines, buses, or both. As described herein, interface controller 300 can perform hazard detection by comparing a received command with commands in one or more other components, such as buffer 320 (rather than commands in command queue 330), which can provide the various advantages described herein.

[0077] Buffers 320 (e.g., buffers 0 to n) can be configured to store received commands (e.g., commands from a host device) on a memory bank-specific basis and transmit command information to command circuitry 325 (e.g., for entry into command queue 330). For example, each buffer 320 can be configured to store received commands for a corresponding memory bank of volatile memory coupled to interface controller 300. For illustration, buffer 0 can be configured to store received commands for memory bank 0 (but not other memory banks), buffer 1 can be configured to store received commands for memory bank 1 (but not other memory banks), and so on. Therefore, interface controller 300 may include one buffer 320 for each memory bank of volatile memory. In other words, the number of buffers 320 may be equal to the number of memory banks in volatile memory. However, other configurations and numbers of buffers 320 are contemplated and are also within the scope of this disclosure. Storing a command may refer to storing information about the command (e.g., address information, identification information, command type).

[0078] In some instances, some or all of buffers 320 may be folded buffers. A folded buffer may be a buffer configured to add entries to the last available position and remove entries in any order (e.g., regardless of factors such as age (i.e., the amount of time spent in the buffer) and the order of addition). Therefore, a folded buffer may differ from a first-in, first-out (FIFO) buffer or other types of buffers configured to add and remove entries in a specific order. If an entry is removed, the folded buffer may be configured to shift down the entry above the removed entry, thereby folding the size of the buffer. In some instances, buffer 320 may have a maximum capacity that cannot be exceeded (e.g., the number of entries), which prevents the interface controller 300 from storing more commands in buffer 320 than the comparison logic 310 can handle.

[0079] Comparison logic 310 can be configured to compare address information of a command. For example, comparison logic 310 can be configured to compare the address information of a received command with the address message of the command in buffer 320. A comparison command may refer to a comparison of information about a command (e.g., address information). Therefore, comparison logic 310 can be configured to compare bank addresses, row addresses, column addresses, or combinations of these addresses. Comparison logic 310 may include comparators 335-0 to 335-x. In some instances, the number of comparators 335 may be equal to the number of buffers 320 multiplied by the maximum number of entries per buffer. However, other numbers of buffers are also within the scope of this disclosure.

[0080] The controller 305 can be configured to control the buffer 320 and the comparison logic 310 by sending control signals to the buffer 320 and the comparison logic 310, respectively. In some instances, the controller 305 can receive information (e.g., from the buffer 320, the comparison logic 310, or other components of the interface controller 300) that the controller 305 uses as the basis for controlling the buffer 320 and the comparison logic 310.

[0081] Command circuit system 325 can be used as a reference Figure 2 An example of a command circuitry system 230 is described. Command circuitry system 325 may include a command queue 330 and logic 340, the command queue storing commands (and other commands) for volatile and non-volatile memory, and the logic managing the commands. For example, logic 340 may determine the ordering and timing of issuing commands in command queue 330 to other components of interface controller 300. Generally, commands can be added to command queue 330 in response to their receipt and removed from command queue 330 when issued to one or more other components of interface controller 300.

[0082] Command queue 330 may contain various fields for different types of information (represented by corresponding entries) associated with a command. For example, command queue 330 may contain a transaction identifier (TID) field for identifying information (e.g., TID).

[0083] Alternatively, command queue 330 may include a validity field for validity information indicating whether an associated TID is valid. Alternatively, command queue 330 may include a row field for row information (e.g., row address). Alternatively, command queue 330 may include a column field for column information (e.g., column address). Alternatively, command queue 330 may include a memory field (not shown) for memory information (e.g., memory address). Alternatively, command queue 330 may include a next TID field for sorting information indicating the order in which commands are received. Alternatively, command queue 330 may include a danger (HZD) field for danger information indicating whether an associated command is a dangerous command. Alternatively, command queue 330 may include a danger TIT field for danger TID information indicating dangerous commands associated with a command.

[0084] Alternatively, command queue 330 may include a line hit field (not shown) for indicating whether line hit information exists. Alternatively, command queue 330 may include a type field (not shown) for indicating the type of command. Alternatively, command queue 330 may include a scheduling field for indicating the intended memory (e.g., volatile memory, non-volatile memory) for the command. Alternatively, command queue 330 may include a "want to publish" field for indicating whether the command is ready to be published. Alternatively, command queue 330 may include a prefetch field for indicating whether a prefetch operation is associated with the command. Alternatively, command queue 330 may include a read identifier (RID) field for RID, which distinguishes read commands from one another.

[0085] The operation of interface controller 300 is first described at a high level, and then described with reference to the received command 345. At the high level, interface controller 300 can receive commands (e.g., from a host device). Commands can indicate address information (e.g., bank address, row address, and column address). Interface controller 300 can add commands to command queue 330 and determine the bank address of the command. Interface controller 300 can select a buffer 320 for a hazard detection procedure based on the bank address. For example, interface controller 300 can select a buffer 320 configured for the bank indicated by the bank address of the command. For example, if the bank address of the command is bank n, then interface controller 300 can select buffer n (which corresponds to bank n) for the hazard detection procedure. After selecting an appropriate buffer for the hazard detection procedure, interface controller 300 can (e.g., using comparison logic 310) compare the address information of the command with the address signal of the command in the selected buffer (e.g., buffer n). For example, the interface controller 300 can compare the row address of a command with the row address of the command in buffer n, and can compare the column address of a command with the column address of the command in buffer n. It is conceivable that other address information (e.g., row address only, column address only, or other combinations of addresses) can be used for hazard detection and is also within the scope of this disclosure.

[0086] If the address information between two comparison commands matches, the interface controller 300 can determine that the command is a dangerous command subject to execution ordering conditions. Therefore, the interface controller 300 can replace the dangerous command stored in buffer n with the received dangerous command. The replacement command can refer to removing information from the received command and adding information from another command. Replacing the stored dangerous command with the received dangerous command prevents buffer overflow and allows the interface controller 300 to compare incoming commands with the latest dangerous command. The interface controller 300 can also update the command queue 330 with dangerous information. For example, the interface controller 300 can update the danger field of the stored dangerous commands (in the command queue 330) to indicate that the stored command is a dangerous command. Additionally, the interface controller 300 can update the danger TID field of the stored dangerous commands (in the command queue 330) to indicate the TID of the corresponding dangerous command (e.g., the received dangerous command).

[0087] If the address information between two comparison commands does not match, the interface controller 300 can determine that the command is not a dangerous command (e.g., the command does not execute a sorting condition and can be executed in any order). Therefore, the interface controller 300 can add the received command to buffer n (provided that buffer n has not yet reached its maximum capacity). If buffer n is at its maximum capacity, the interface controller 300 can wait before adding the received command (or a different command from command queue 330) to the buffer until the command is removed from buffer n.

[0088] Referring now to received command 345, which may be a command received from a host device. Received commands may be received in descending order, starting with command 0 and ending with command 8. Each command may have an associated TID, row address (RA), column address (CA), and bank address (BA). For ease of illustration, the addresses associated with received command 345 are limited to a few addresses (e.g., row addresses 0 and 1, column addresses 0, 2, 10, and 12, and bank address 0). However, different addresses and different numbers of addresses are contemplated and are also within the scope of this disclosure. Although described with reference to a single bank (e.g., bank 0), the techniques described herein can be implemented for any number of banks. For ease of illustration, dangerous commands are shown in the same shaded area.

[0089] After receiving command (CMD) 0, interface controller 300 can determine the memory bank associated with command 0. Interface controller 300 can determine the memory bank associated with command 0 based on the memory address of command 0, which may indicate a memory bank (e.g., memory bank 0). Interface controller 300 can then simultaneously (e.g., at partially or fully overlapping times) or in any order: 1) add command 0 to command queue 330, which may involve updating various fields of command 0, and 2) select buffer 320 for the hazard detection procedure of command 0. For example, interface controller 300 can select buffer 0 for the hazard detection procedure based on buffer 0 corresponding to memory bank 0 (e.g., the memory bank for command 0). Assuming command 0 is the first command received for memory bank 0, buffer 0 may not contain any commands. Therefore, interface controller 300 can add command 0 to buffer 0.

[0090] Upon receiving command 1, interface controller 300 can determine the memory bank (e.g., memory bank 0) associated with command 1. Then, interface controller 300 can simultaneously or in any order: 1) add command 1 to command queue 330, and 2) select buffer 320 for the hazard detection procedure of command 1. For example, interface controller 300 can select buffer 0 for the hazard detection procedure based on buffer 0 corresponding to memory bank 0 (e.g., the memory bank for command 1). Then, interface controller 300 can compare the address information of command 1 with the address information of commands stored in buffer 0. For example, interface controller 300 can compare the row address of command 1 with the row address of command 0, and can compare the column address of command 1 with the column address of command 0. Based on the comparison, interface controller 300 can determine that the address information of command 1 does not match the address information of command 0 (e.g., different from, not equal to) (e.g., because the column address of command 1 (CA = 2) is different from the column address of command 0 (CA = 0)). Therefore, interface controller 300 can add command 1 to buffer 0.

[0091] Upon receiving command 2, interface controller 300 can determine the memory bank associated with command 2 (e.g., memory bank 0). Then, interface controller 300 can simultaneously or in any order: 1) add command 2 to command queue 330, and 2) select buffer 320 for the hazard detection procedure of command 2. For example, interface controller 300 can select buffer 0 for the hazard detection procedure based on buffer 0 corresponding to memory bank 0 (e.g., the memory bank for command 2). Then, interface controller 300 can compare the address information of command 2 with the address information of commands stored in buffer 0. For example, interface controller 300 can compare the row address of command 2 with the row addresses of commands 0 and 1, and can compare the column address of command 2 with the column addresses of commands 0 and 1. Based on the comparison, interface controller 300 can determine that the address information of command 2 matches (e.g., is the same or equal to) the address information of command 1. Therefore, interface controller 300 can simultaneously or in any order: 1) replace command 1 with command 2 in buffer 0, and 2) update command queue 330 with hazard information.

[0092] Replacing command 1 with command 2 may involve removing command 1 from buffer 0 and adding command 2 to buffer 0 (e.g., as a new entry, and not necessarily in the same location as command 1). Additionally, interface controller 300 may update the danger TID field of command 2 (in buffer 0) to indicate that command 1 is a dangerous command associated with command 2. Updating command queue 330 with danger information may involve updating the danger field of command 2 to indicate that command 2 is a dangerous command, updating the danger TID field of command 2 to indicate that command 1 is a dangerous command associated with command 2, or both.

[0093] Upon receiving command 3, interface controller 300 can determine the memory bank associated with command 3 (e.g., memory bank 0). Then, interface controller 300 can simultaneously or in any order: 1) add command 3 to command queue 330, and 2) select buffer 320 for the hazard detection procedure of command 3. For example, interface controller 300 can select buffer 0 for the hazard detection procedure based on buffer 0 corresponding to memory bank 0 (e.g., the memory bank for command 3). Then, interface controller 300 can compare the address information of command 3 with the address information of commands stored in buffer 0. For example, interface controller 300 can compare the row address of command 3 with the row addresses of command 0 and command 2 (which replace command 1), and can compare the column address of command 3 with the column addresses of command 0 and command 2. Based on the comparison, interface controller 300 can determine that the address information of command 3 does not match the address information of command 0 or command 2 (e.g., different from or not equal to). Therefore, interface controller 300 can add command 3 to buffer 0.

[0094] Upon receiving command 4, interface controller 300 can determine the memory bank associated with command 4 (e.g., memory bank 0). Then, interface controller 300 can add command 4 to command queue 330 simultaneously or in any order, and 2) select buffer 320 for the hazard detection procedure of command 4. For example, interface controller 300 can select buffer 0 for the hazard detection procedure based on buffer 0 corresponding to memory bank 0 (e.g., the memory bank for command 4). Then, interface controller 300 can compare the address information of command 4 with the address information of commands stored in buffer 0. For example, interface controller 300 can compare the row address of command 4 with the row addresses of command 0, command 2 (which replaces command 1), and command 3, and can compare the column address of command 4 with the column addresses of command 0, command 2, and command 3. Based on these comparisons, interface controller 300 can determine that the address information of command 4 matches the address information of command 0. Therefore, the interface controller 300 can simultaneously or in any order: 1) replace command 0 with command 4 in buffer 0 (e.g., by removing command 0 and adding command 4), and 2) update command queue 330 with danger information.

[0095] Similar operations can be performed on commands 5 through 8, and will not be repeated here for the sake of brevity. Therefore, the interface controller 300 can perform hazard detection by comparing the received commands with the commands in the buffer 320 (instead of the commands in the command queue 330), which can provide the various advantages described herein.

[0096] Figure 4 An example of a process flow 400 supporting hazard detection in a multi-memory device, as disclosed herein, is shown. Process flow 400 can be found in reference [reference needed]. Figure 1 The memory subsystem 110 or interface controller 115 described herein, reference Figure 2 The described memory subsystem 200 or interface controller 202 or reference Figure 3 The described interface controller 300 is implemented. However, other types of devices or components (or combinations thereof) may also implement process flow 400. Process flow 400 may illustrate the operation of a device that uses a buffer (e.g., a memory-specific buffer) for hazard detection.

[0097] For ease of reference, the reference apparatus describes process flow 400. For example, aspects of process flow 400 may be implemented by means including volatile memory and 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, or both). For example, the instructions may cause the controller to perform the operation of process flow 400 if executed by the controller.

[0098] At 405, commands can be received. For example, interface controller 300 can receive commands from a host device. The received commands can be associated with address information such as bank address, row address, and column address (e.g., indicating or including said address information). In some instances, the row address can identify a row of memory cells coupled to a common word line. In some instances, the column address can identify a column of memory cells coupled to a common digital line.

[0099] At 410, the received command can be added to the command queue. For example, the interface controller 300 can add the received command to the command queue 330 based on or in response to receiving a command. At 415, a buffer for the hazard detection procedure of the received command can be selected. For example, the interface controller 300 can select from buffers 320 the buffer corresponding to the memory bank indicated by the memory bank address of the received command.

[0100] At 420, the address information of the received command can be compared with the command address information stored in the selected buffer. For example, the interface controller 300 can (e.g., via comparison logic 310) compare the address information of the received command with the address information of the command stored in the selected buffer. In some instances, comparing the address information may involve comparing the row address and column address of the received command with the corresponding row address and column address of the command stored in the buffer.

[0101] At 425, it can be determined whether a match exists between the address information. For example, interface controller 300 can determine whether the address information of the received command matches the address of any command stored in the buffer. If the row address and column address of the two commands are consistent (e.g., equal, identical), then the address information can be said to match. If it is determined at 425 that the address information does not match, the processing flow 400 can proceed to 430. At 430, it can be determined that there is no danger. For example, interface controller 300 can determine that the received command is not a dangerous command relative to any command stored in the buffer. At 435, the received command can be added to the buffer based on the fact that the received command is not a dangerous command.

[0102] If a match is determined at 425 between the address information, the processing flow 400 can proceed to 440. At 440, a danger can be determined. For example, the interface controller 300 can determine that the received command is a dangerous command relative to the commands stored in the buffer. The interface controller 300 can also determine that the stored command is a dangerous command relative to the received command. The interface controller 300 can determine that a command is dangerous based on commands with matching address information.

[0103] At 445, the command queue can be updated with hazard information. For example, interface controller 300 can update the hazard field, hazard TID field, or both of the commands stored in command queue 330. At 450, a received command can replace a command stored in the buffer. For example, interface controller 300 can replace a received command with a command stored in the buffer.

[0104] Alternative instances of the foregoing may be implemented, in which some operations may be performed in a different order than described, in parallel, or not at all. In some cases, operations may include additional features not mentioned herein, or additional operations may be added. Furthermore, certain operations may be performed multiple times, or certain combinations of repeatable or cyclical operations may be performed.

[0105] Figure 5 A block diagram 500 illustrates a device 520 supporting hazard detection in a multi-memory device according to an example disclosed herein. Device 520 may be a reference device. Figures 1 to 4 Examples of aspects of the described apparatus. Apparatus 520 or its various components may be examples of apparatus for performing various aspects of hazard detection in a multi-memory device as described herein. For example, apparatus 520 may include a receiving circuit system 525, a controller 530, a comparator circuit system 535, a buffer circuit system 545, a command circuit system 550, or any combination thereof. Each of these components may communicate with each other directly or indirectly (e.g., via one or more buses).

[0106] The receiving circuitry 525 may be configured or otherwise support means for receiving a first command indicating a first memory bank address, a first row address, and a first column address. The controller 530 may be configured or otherwise support means for selecting, at least in part, a buffer for a hazard detection procedure from a set of buffers associated with respective memory banks of the volatile memory, based on the first memory bank address, the hazard detection procedure detecting hazard commands subject to execution sorting conditions. The comparison circuitry 535 may be configured or otherwise support means for comparing, as part of a hazard detection procedure and at least in part, the first row address and first column address from the first command with the second row address and second column address from the buffer for a second command. In some instances, the controller 530 may be configured or otherwise support means for determining, at least in part, whether the first and second commands are hazard commands subject to execution sorting conditions, based on comparing the first row address and first column address from the first command with the second row address and second column address from the second command.

[0107] In some instances, a dangerous command includes a command with matching bank address, row address, and column address. In some instances, controller 530 may be configured or otherwise support means for determining that a first command and a second command are dangerous commands based at least in part on a match between a first row address and a second row address and at least in part on a match between a first column address and a second column address.

[0108] In some instances, the buffer circuit system 545 may be configured or otherwise support means for replacing the second command in the buffer with the first command, based at least in part on the determination that the first command and the second command are dangerous commands.

[0109] In some instances, the command circuitry system 550 may be configured or otherwise support means for adding a first command to a command queue, at least in part based on receiving a first command, wherein the command queue stores commands for volatile memory and commands for non-volatile memory. In some instances, the command circuitry system 550 may be configured or otherwise support means for updating the command queue, at least in part based on determining that the first command is a dangerous command.

[0110] In some instances, to support updating the command queue, the command circuit system 550 may be configured or otherwise support means for adding a transaction identifier of a first command to a first field of a second command. In some instances, to support updating the command queue, the command circuit system 550 may be configured or otherwise support means for updating a second field of a second command to indicate that the second command is a dangerous command.

[0111] In some instances, controller 530 may be configured or otherwise support means for determining that a first command and a second command are not dangerous commands based at least in part on the fact that a first row address is different from a second row address, at least in part on the fact that a first column address is different from a second column address, or both. In some instances, buffer circuitry 545 may be configured or otherwise support means for adding a first command to a buffer based at least in part on the determination that a first command and a second command are not dangerous commands.

[0112] Figure 6 A flowchart illustrating a method 600 for hazard detection in a multi-memory device according to an example disclosed herein is shown. Operation of method 600 can be implemented by the apparatus or components thereof described herein. For example, it can be implemented by reference to... Figures 1 to 5The described apparatus performs the operation of method 600. In some instances, the apparatus may execute a set of instructions to control the functional elements of the apparatus to perform the described function. Alternatively, the apparatus may use dedicated hardware to perform aspects of the described function.

[0113] At 605, the method may include receiving a first command indicating a first memory address, a first row address, and a first column address. The operation of 605 may be performed according to the examples disclosed herein. In some instances, aspects of the operation of 605 may be referenced... Figure 5 The described receiving circuit system 525 is implemented.

[0114] In 610, the method may include selecting, at least in part, a buffer for a hazard detection program from a set of buffers each associated with a corresponding memory bank of the volatile memory, based on a first memory bank address, the hazard detection program detecting hazard commands subject to execution sorting conditions. Operation of 610 may be performed according to the examples disclosed herein. In some instances, aspects of the operation of 610 may be referenced from... Figure 5 The controller 530 described is executed.

[0115] In 615, the method may include, as part of a hazard detection procedure and at least in part based on a selection buffer, comparing the first row address and first column address from a first command with the second row address and second column address from a second command in the buffer. The operation of 615 may be performed according to the examples disclosed herein. In some instances, aspects of the operation of 615 may be derived from references... Figure 5 The described comparison circuit system 535 is executed.

[0116] In 620, the method may include determining, at least in part, whether the first and second commands are dangerous commands subject to execution sorting conditions by comparing the first row address and first column address from the first command with the second row address and second column address from the second command. The operation of 620 may be performed according to the examples disclosed herein. In some instances, aspects of the operation of 620 may be derived from references... Figure 5 The controller 530 described is executed.

[0117] In some instances, the device described herein may perform one or more methods, such as method 600. 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 first command indicating a first bank address, a first row address, and a first column address; selecting, at least in part, buffers for a hazard detection procedure from a set of buffers each associated with a corresponding bank of volatile memory, based on the first bank address, the hazard detection procedure detecting a hazard command subject to an execution ordering condition; as part of the hazard detection procedure and at least in part based on the selection of the buffers, comparing the first row address and the first column address from the first command with the second row address and the second column address from the buffers; and determining, at least in part based on comparing the first row address and the first column address from the first command with the second row address and the second column address from the second command, whether the first command and the second command are hazard commands subject to an execution ordering condition.

[0118] In some instances of method 600 and the apparatus described herein, a dangerous command comprises a command having matching bank address, row address, and column address. Method 600 and some instances of the apparatus described herein may further comprise an operation, feature, circuit system, logic, device, or instruction for determining that the first command and the second command are dangerous commands based at least in part on a match between the first row address and the second row address and at least in part on a match between the first column address and the second column address.

[0119] Method 600 and some examples of the devices described herein may further include operations, features, circuit systems, logic, means, or instructions for replacing the second command in the buffer with the first command, at least in part based on determining that the first command and the second command may be dangerous commands.

[0120] Method 600 and some examples of the devices described herein may further include operations, features, circuit systems, logic, means, or instructions for: adding a first command to a command queue, at least in part based on receiving a first command, wherein the command queue stores commands for volatile memory and commands for non-volatile memory; and updating the command queue, at least in part based on determining that the first command may be a dangerous command.

[0121] In some instances of method 600 and the apparatus described herein, the update command queue may contain operations, features, circuitry, logic, means, or instructions for: adding a transaction identifier of a first command to a first field of a second command; and updating a second field of the second command to indicate that the second command may be a dangerous command.

[0122] Method 600 and some examples of the devices described herein may further include operations, features, circuit systems, logic, means, or instructions for determining that the first command and the second command are not dangerous commands, based at least in part on the fact that the first row address is different from the second row address, at least in part on the fact that the first column address is different from the second column address, or both.

[0123] Method 600 and some examples of the devices described herein may further include operations, features, circuit systems, logic, means, or instructions for adding a first command to a buffer, at least in part based on the determination that the first command and the second command are not dangerous commands.

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

[0125] An apparatus is described. The apparatus may include non-volatile memory; volatile memory; and an interface controller coupled to the non-volatile memory and the volatile memory, the interface controller being operable to cause the apparatus to: receive a first command indicating a first bank address, a first row address, and a first column address; select, at least partially based on the first bank address and from a set of buffers each associated with a corresponding bank of the volatile memory, a buffer for a hazard detection procedure that detects a hazard command subject to an execution sorting condition; as part of the hazard detection procedure and at least partially based on the selection of the buffer, compare the first row address and the first column address from the first command with a second row address and a second column address from a second command in the buffer; and determine, at least partially based on the comparison of the first row address and the first column address from the first command with the second row address and the second column address from the second command, whether the first command and the second command are hazard commands subject to an execution sorting condition.

[0126] In some instances of the device, a dangerous command comprises a command having a matching bank address, row address, and column address. In some instances, the device may include determining that a first command and a second command are dangerous commands based at least in part on a first row address matching a second row address and at least in part on a first column address matching a second column address.

[0127] In some instances, the device may include replacing a second command in a buffer with a first command based at least in part on determining that a first command and a second command may be dangerous commands. In some instances, the device may include a command queue in an interface controller operable to store commands for volatile memory and commands for non-volatile memory, wherein the interface controller is operable to cause the device to add a first command to the command queue at least in part based on receiving a first command; and to update the command queue at least in part based on determining that the first command may be a dangerous command.

[0128] In some instances, the device may include adding a transaction identifier of a first command to a first field of a second command; and updating a second field of the second command to indicate that the second command may be a dangerous command. In some instances, the device may include determining that the first and second commands are not dangerous commands based at least in part on a first row address being different from a second row address, at least in part on a first column address being different from a second column address, or both.

[0129] In some instances, the device may include adding a first command to a buffer based at least in part on the determination that the first command and the second command are not dangerous commands. In some instances of the device, the volatile memory comprises multiple banks of memory, and each of the set of buffers may be configured to store commands for a corresponding bank of memory among the multiple banks of memory.

[0130] In some instances of the device, the buffer stores commands with memory addresses that match the first memory address and does not store commands with memory addresses that do not match the first memory address. In some instances of the device, the buffer includes a folded buffer that can be configured to remove entries regardless of the storage duration in the buffer, the order in which the folded buffer was added, or both.

[0131] The information and signals described herein can be represented using any of a variety of different techniques and skills. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the foregoing description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, optical fields or optical particles, or any combination thereof. Some diagrams may illustrate signaling as a single signal; however, those skilled in the art will understand that a signal can represent a bus of signals, where the bus can have various bit widths.

[0132] 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 for those operations, the meaning of various commands or signals or both, one or more addressing schemes for one or more memories, the type of communication reserved for pins, the size of data processed at various components of an interface, the data rate supported by various components of an interface, or the bandwidth supported by various components of an interface, and other parameters and metrics, or any combination thereof. The use of shared protocols enables interaction between devices because each device can operate in a way that another device expects, recognizes, and understands. For example, two devices supporting the same protocol can interact according to the policies, procedures, and parameters defined by the protocol, while two devices supporting different protocols may be incompatible.

[0133] To illustrate, two devices supporting different protocols may be incompatible because the protocols define different addressing schemes (e.g., different numbers of address bits). As another illustration, two devices supporting different protocols can be incompatible because the protocols define different transmission procedures for responding to a single command (e.g., the 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, protocols can be considered different if the corresponding procedures or parameters defined by the two protocols change. For example, if a device supports different addressing schemes or different transmission procedures for responding to commands, the device can be said to support two different protocols.

[0134] The terms “electronic connectivity,” “conductive contact,” “connection,” and “coupling” can refer to a relationship between components that supports the flow of electrons between them. Components are considered electronically connected (or electrically contacting, connected, or coupled) to each other if any conductive path exists between them that can support the flow of signals between them at any given time. At any given time, based on (e.g., in response to) the operation of a device containing the connected components, the conductive path between electronically connected (or electrically contacting, connected, or coupled) components can be open or closed. The conductive path between connected components can be a direct conductive path between the components, or an indirect conductive path between connected components that may include intermediate components such as switches, transistors, or other components. In some instances, one or more intermediate components, such as switches or transistors, can be used to interrupt the signal flow between connected components for a period of time.

[0135] The term "coupling" refers to the condition that shifts from an open-circuit relationship between components to a closed-circuit relationship. In an open-circuit relationship, signals cannot currently travel between components via a conductive path, while in a closed-circuit relationship, signals can travel between components via a conductive path. When a component, such as a controller, couples other components together, the component initially allows a change in the flow of signals between the other components via conductive paths that were previously not permitted.

[0136] The term "isolation" refers to the relationship between components where signals cannot currently flow between them. Components are isolated from each other if there is an open circuit between them. For example, components separated by a switch positioned between two components are isolated from each other when the switch is open. When a controller separates two components, it prevents signals from flowing between the components using previously permitted conductive paths.

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

[0138] The switching components or transistors discussed herein may represent field-effect transistors (FETs) and include a three-terminal device comprising a source, drain, and 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, such as degenerate, semiconductor regions. The source and drain may be separated by lightly doped semiconductor regions or channels. If the channel is n-type (i.e., the majority carriers are electrons), the FET may be called an n-type FET. If the channel is p-type (i.e., the majority carriers are holes), the FET may be called a p-type FET. The channel may be capped by an insulating gate oxide. The conductivity of the channel can be controlled by applying a voltage to the gate. For example, applying a positive or negative voltage to an n-type FET or a p-type FET, respectively, can cause the channel to become conductive. When a voltage greater than or equal to the threshold voltage of the transistor is applied to the gate, the transistor may be “turned on” or “activated.” When a voltage less than the threshold voltage of the transistor is applied to the gate, the transistor may be “turned off” or “deactivated.”

[0139] 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," 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 concepts of the described instances.

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

[0141] As used herein, the term “generally” means that a modified feature (e.g., a verb or adjective modified by the term “generally”) need not be absolute but must be close enough to obtain the advantage of the feature. As used herein, the term “in parallel” means that the described actions or phenomena occur during a period of time that are at least partially overlapping in time, can be substantially simultaneous, or are offset in time. As used herein, unless otherwise described or referenced, a “set” of objects may refer to one or more of the objects.

[0142] The various illustrative blocks and modules described in connection with this disclosure 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).

[0143] The functions described herein can be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions can be stored as one or more instructions or codes on or transmitted over a computer-readable medium. Other examples and implementations are within the scope of this disclosure and the appended claims. For example, due to the nature of software, the functions described above can be implemented using software executed by a processor, hardware, firmware, hardwired, or any combination thereof. Features implementing the functions can also be physically located in various locations, including distributed implementations such that portions of the functions 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, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). 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”.

[0144] Computer-readable media includes both non-transitory computer-readable storage media and communication media, with communication media encompassing any media that facilitates the transfer of a computer program from one place to another. Non-transitory storage media can be any available media accessible by a general-purpose or special-purpose computer. By way of example, and not limitation, non-transitory computer-readable media may include RAM, ROM, electrically erasable programmable read-only memory (EEPROM), compressed optical disc (CD) ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage devices, or any other non-transitory media that can be used to carry or store desired program code components in the form of instructions or data structures and is accessible by a general-purpose or special-purpose computer or a general-purpose or special-purpose processor. Furthermore, any connection 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 copy data magnetically, while optical discs use lasers to copy data optically. Combinations of these are also included within the scope of computer-readable media.

[0145] The description provided herein enables those skilled in the art to make or use this disclosure. Those skilled in the art will appreciate the various modifications that can be made to this disclosure, and that the general principles defined herein can be applied to other variations without departing from the scope of this disclosure. Therefore, this disclosure is not limited to the examples and designs described herein, but is given the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An apparatus comprising: a non-volatile memory; a volatile memory; and an interface controller coupled with the non-volatile memory and the volatile memory, the interface controller operable to cause the apparatus to: receive a first command indicative of a first bank address, a first row address, and a first column address; select, based at least in part on the first bank address and from a set of buffers each associated with a respective bank of the volatile memory, a buffer for a hazard detection procedure, the hazard detection procedure to detect a hazard command constrained by an execution ordering condition; as part of the hazard detection procedure and based at least in part on selecting the buffer, compare the first row address and the first column address from the first command with a second row address and a second column address from a second command in the buffer; and based at least in part on comparing the first row address and the first column address from the first command with the second row address and the second column address from the second command, determine whether the first command and the second command are hazard commands constrained by an execution ordering condition.

2. The apparatus of claim 1, wherein a hazard command comprises a command having matching bank address, row address, and column address.

3. The apparatus of claim 1, wherein the interface controller is operable to: based at least in part on the first row address matching the second row address and based at least in part on the first column address matching the second column address, determine that the first command and the second command are hazard commands.

4. The apparatus of claim 3, wherein the interface controller is operable to: based at least in part on determining that the first command and the second command are hazard commands, replace the second command in the buffer with the first command.

5. The apparatus of claim 4, further comprising: a command queue in the interface controller operable to store commands for the volatile memory and commands for the non-volatile memory, wherein the interface controller is operable to cause the apparatus to: based at least in part on receiving the first command, add the first command to the command queue; and based at least in part on determining that the first command is a hazard command, update the command queue.

6. The apparatus of claim 5, wherein the interface controller is operable to cause the apparatus to update the command queue by operable to cause the apparatus to: add a transaction identifier for the first command to a first field of the second command; and update a second field of the second command to indicate that the second command is a hazard command.

7. The apparatus of claim 1, wherein the interface controller is operable to: based at least in part on the first row address being different from the second row address, based at least in part on the first column address being different from the second column address, or both, determine that the first command and the second command are not hazard commands. ​ 8. The apparatus of claim 7, wherein the interface controller is operable to: add the first command to the buffer based at least in part on determining that the first command and the second command are not dangerous commands.

9. The apparatus of claim 1, wherein the volatile memory comprises a plurality of memory banks, and wherein each buffer of the set of buffers is configured to store commands for a respective memory bank of the plurality of memory banks.

10. The apparatus of claim 1, wherein the buffer stores a command having a memory bank address that matches the first memory bank address, and does not store a command having a memory bank address that does not match the first memory bank address.

11. The apparatus of claim 1, wherein the buffer comprises a folding buffer configured to remove entries without regard to a storage duration in the buffer, an order of addition to the folding buffer, or both.

12. A method comprising: receiving a first command indicating a first memory bank address, a first row address, and a first column address; selecting, based at least in part on the first memory bank address and from a set of buffers each associated with a respective memory bank of a volatile memory, a buffer for a dangerous command detection procedure that detects dangerous commands that are subject to an execution ordering condition; as part of the dangerous command detection procedure and based at least in part on selecting the buffer, comparing the first row address and the first column address from the first command with a second row address and a second column address from a second command in the buffer; and determining, based at least in part on comparing the first row address and the first column address from the first command with the second row address and the second column address from the second command, whether the first command and the second command are dangerous commands that are subject to an execution ordering condition.

13. The method of claim 12, wherein a dangerous command comprises a command having matching memory bank address, row address, and column address.

14. The method of claim 12, further comprising: determining, based at least in part on the first row address matching the second row address and based at least in part on the first column address matching the second column address, that the first command and the second command are dangerous commands.

15. The method of claim 14, further comprising: replacing, based at least in part on determining that the first command and the second command are dangerous commands, the second command in the buffer with the first command.

16. The method of claim 15, further comprising: adding, based at least in part on receiving the first command, the first command to a command queue, wherein the command queue stores commands for the volatile memory and commands for a non-volatile memory; and updating the command queue based at least in part on determining that the first command is a dangerous command.

17. The method of claim 16, wherein updating the command queue comprises: adding a transaction identifier of the first command to a first field of the second command; and updating a second field of the second command to indicate that the second command is a dangerous command.

18. The method of claim 12, further comprising: determining that the first command and the second command are not dangerous commands based at least in part on the first row address being different than the second row address, based at least in part on the first column address being different than the second column address, or both.

19. The method of claim 18, further comprising: based at least in part on determining that the first command and the second command are not dangerous commands, adding the first command to the buffer.

20. A non-transitory computer-readable medium storing code, the code comprising instructions that, when executed by a processor of a device, cause the device to: receive a first command indicating a first bank address, a first row address, and a first column address; based at least in part on the first bank address and from a set of buffers each associated with a respective bank of volatile memory, select a buffer for a dangerous command detection procedure that detects dangerous commands constrained by an execution ordering condition; as part of the dangerous command detection procedure and based at least in part on selecting the buffer, compare the first row address and the first column address from the first command to a second row address and a second column address from a second command in the buffer; and based at least in part on comparing the first row address and the first column address from the first command to the second row address and the second column address from the second command, determine whether the first command and the second command are dangerous commands constrained by an execution ordering condition.

21. The non-transitory computer-readable medium of claim 20, wherein the instructions, when executed by the processor of the device, cause the device to: based at least in part on the first row address matching the second row address and based at least in part on the first column address matching the second column address, determine that the first command and the second command are dangerous commands.

22. The non-transitory computer-readable medium of claim 21, wherein the instructions, when executed by the processor of the device, cause the device to: based at least in part on determining that the first command and the second command are dangerous commands, replace the second command in the buffer with the first command.

23. The non-transitory computer-readable medium of claim 22, wherein the instructions, when executed by the processor of the device, cause the device to: based at least in part on receiving the first command, add the first command to a command queue, wherein the command queue stores commands for the volatile memory and commands for non-volatile memory; and based at least in part on determining that the first command is a dangerous command, update the command queue.

24. The non-transitory computer-readable medium of claim 23, wherein the instructions that cause the device to update the command queue comprise instructions that cause the device to: add a transaction identifier of the first command to a first field of the second command; and update a second field of the second command to indicate that the second command is a dangerous command.

25. The non-transitory computer-readable medium of claim 20, wherein the instructions, when executed by the processor of the device, cause the device to: determine that the first command and the second command are not dangerous commands based at least in part on the first row address being different from the second row address, based at least in part on the first column address being different from the second column address, or both; and add the first command to the buffer based at least in part on determining that the first command and the second command are not dangerous commands.

Images