Patent Description:
A non-volatile dual-inline memory module with persistent storage ("NVDIMM-P") is a storage class memory that can be used in place of standard DDR DIMMs, but includes persistent memory. The use of persistent, or "non-volatile", memory with a memory channel that supports volatile memory such as DRAM presents some new problems. Reading from non-volatile memory on a non-volatile DIMM is a slower process than reading from DRAM. Non-volatile memory reads typically complete in a nondeterministic time, as opposed to DRAM reads which complete faster in a deterministic, known time. Dealing with differences such as these presents various challenges in designing memory controllers that can interact with non-volatile DIMMs.

<CIT>) describes a system, apparatus, and method for scheduling memory requests for issue to two different memory types. A computing system includes one or more clients for processing applications. A heterogeneous memory channel within a memory controller transfers memory traffic between the memory controller and a memory bus connected to each of a first memory and a second memory different from the first memory. The memory controller determines a next given point in time that does not already have read response data scheduled to be driven on the memory bus. The memory controller determines whether there is time to schedule a first memory access command for accessing the first memory and a second memory access command for accessing the second memory. If there is sufficient time for each, then one of the access commands is selected based on weighted criteria.

<CIT>) discloses a memory controller includes a command queue, an arbiter, and a replay queue. The command queue receives and stores memory access requests. The arbiter is coupled to the command queue for providing a sequence of memory commands to a memory channel. The replay queue stores the sequence of memory commands to the memory channel, and continues to store memory access commands that have not yet received responses from the memory channel. When a response indicates a completion of a corresponding memory command without any error, the replay queue removes the corresponding memory command without taking further action. When a response indicates a completion of the corresponding memory command with an error, the replay queue replays at least the corresponding memory command.

<CIT> discloses a memory access technology and a computer system, where the computer system includes a memory controller and a medium controller connected to the memory controller. In the computer system, when detecting that an error occurs in first data that is returned by the medium controller in response to a first send command, the memory controller determines sequence information of the first send command in a plurality of send commands that have been sent by the memory controller within a time period from a time point at which the first send command is sent to a current time, and sends a data retransmission command to the medium controller to instruct the medium controller to resend the first data based on the sequence information.

Further advantageous embodiments are defined by the dependent claims.

In the following description, the use of the same reference numerals in different drawings indicates similar or identical items. Unless otherwise noted, the word "coupled" and its associated verb forms include both direct connection and indirect electrical connection by means known in the art, and unless otherwise noted any description of direct connection implies alternate embodiments using suitable forms of indirect electrical connection as well.

A memory controller includes a command queue, a memory interface queue, a non-volatile command queue (NV queue), a replay queue, and a replay control circuit. The command queue has a first input for receiving memory access commands including volatile reads, volatile writes, non-volatile reads, and non-volatile writes, and an output, and having a plurality of entries. The memory interface queue has an input for receiving commands selected from the command queue, and an output for coupling to a heterogeneous memory channel to which is coupled at least one non-volatile dual in-line memory module (DIMM). The NV queue is coupled to the output of the command queue for storing non-volatile read commands that are placed in the memory interface queue. The replay queue coupled to the output of the command queue for storing selected memory access commands that are placed in the memory interface queue. The replay control circuit detects, based on information received over the heterogeneous memory channel, that an error has occurred requiring a recovery sequence, and in response to the error, initiates the recovery sequence including transmitting selected memory access commands that are stored in the replay queue, and transmitting non-volatile reads that are stored in the NV queue.

A method responds to errors in a memory system. The method includes receiving a plurality of memory access requests including volatile memory reads, volatile memory writes, non-volatile memory reads, and non-volatile memory writes. Memory access commands for fulfilling the memory access requests are placed in a memory interface queue. The memory access commands are transmitted from the memory interface queue to a heterogeneous memory channel coupled to a volatile dual in-line memory module (DIMM) and a non-volatile DIMM. Selected memory access commands that are placed in the memory interface queue are stored in a replay queue. Non-volatile reads that are placed in the memory interface queue are stored in a non-volatile command queue (NV queue). Based on information received over the heterogeneous memory channel, the method detects that an error has occurred requiring a recovery sequence, and in response to the error, initiates the recovery sequence including (i) transmitting selected memory access commands that are stored in the replay queue, and (ii) transmitting non-volatile reads that are stored in the NV queue. storing memory access commands that are placed in the memory interface queue in at least one storage queue.

A data processing system includes a central processing unit, a data fabric coupled to the central processing unit, and a memory controller coupled to the data fabric for fulfilling memory access requests from the central processing unit. The memory controller includes a command queue, a memory interface queue, a non-volatile command queue (NV queue), a replay queue, and a replay control circuit. The command queue has a first input for receiving memory access commands including volatile reads, volatile writes, non-volatile reads, and non-volatile writes, and an output, and having a plurality of entries. The memory interface queue has an input for receiving commands selected from the command queue, and an output for coupling to a heterogeneous memory channel to which is coupled at least one non-volatile dual in-line memory module (DIMM). The NV queue is coupled to the output of the command queue for storing non-volatile read commands that are placed in the memory interface queue. The replay queue coupled to the output of the command queue for storing selected memory access commands that are placed in the memory interface queue. The replay control circuit detects, based on information received over the heterogeneous memory channel, that an error has occurred requiring a recovery sequence, and in response to the error, initiates the recovery sequence including transmitting selected memory access commands that are stored in the replay queue, and transmitting non-volatile reads that are stored in the NV queue.

<FIG> illustrates in block diagram form an accelerated processing unit (APU) <NUM> and memory system <NUM> known in the prior art. APU <NUM> is an integrated circuit suitable for use as a processor in a host data processing system, and includes generally a central processing unit (CPU) core complex <NUM>, a graphics core <NUM>, a set of display engines <NUM>, a memory management hub <NUM>, a data fabric <NUM>, a set of peripheral controllers <NUM>, a set of peripheral bus controllers <NUM>, and a system management unit (SMU) <NUM>.

CPU core complex <NUM> includes a CPU core <NUM> and a CPU core <NUM>. In this example, CPU core complex <NUM> includes two CPU cores, but in other embodiments CPU core complex <NUM> can include an arbitrary number of CPU cores. Each of CPU cores <NUM> and <NUM> is bidirectionally connected to a system management network (SMN), which forms a control fabric, and to data fabric <NUM>, and is capable of providing memory access requests to data fabric <NUM>. Each of CPU cores <NUM> and <NUM> may be unitary cores, or may further be a core complex with two or more unitary cores sharing certain resources such as caches.

Graphics core <NUM> is a high performance graphics processing unit (GPU) capable of performing graphics operations such as vertex processing, fragment processing, shading, texture blending, and the like in a highly integrated and parallel fashion. Graphics core <NUM> is bidirectionally connected to the SMN and to data fabric <NUM>, and is capable of providing memory access requests to data fabric <NUM>. In this regard, APU <NUM> may either support a unified memory architecture in which CPU core complex <NUM> and graphics core <NUM> share the same memory space, or a memory architecture in which CPU core complex <NUM> and graphics core <NUM> share a portion of the memory space, while graphics core <NUM> also uses a private graphics memory not accessible by CPU core complex <NUM>.

Display engines <NUM> render and rasterize objects generated by graphics core <NUM> for display on a monitor. Graphics core <NUM> and display engines <NUM> are bidirectionally connected to common memory management hub <NUM> for uniform translation into appropriate addresses in memory system <NUM>, and memory management hub <NUM> is bidirectionally connected to data fabric <NUM> for generating such memory accesses and receiving read data returned from the memory system.

Data fabric <NUM> includes a crossbar switch for routing memory access requests and memory responses between any memory accessing agent and memory management hub <NUM>. It also includes a system memory map, defined by the system basic input/output system (BIOS), for determining destinations of memory accesses based on the system configuration, as well as buffers for each virtual connection.

Peripheral controllers <NUM> include a universal serial bus (USB) controller <NUM> and a Serial Advanced Technology Attachment (SATA) interface controller <NUM>, each of which is bidirectionally connected to a system hub <NUM> and to the SMN bus. These two controllers are merely exemplary of peripheral controllers that may be used in APU <NUM>.

Peripheral bus controllers <NUM> include a system controller or "Southbridge" (SB) <NUM> and a Peripheral Component Interconnect Express (PCIe) controller <NUM>, each of which is bidirectionally connected to an input/output (I/O) hub <NUM> and to the SMN bus. I/O hub <NUM> is also bidirectionally connected to system hub <NUM> and to data fabric <NUM>. Thus for example a CPU core can program registers in USB controller <NUM>, SATA interface controller <NUM>, SB <NUM>, or PCIe controller <NUM> through accesses that data fabric <NUM> routes through I/O hub <NUM>. Software and firmware for APU <NUM> are stored in a system data drive or system BIOS memory (not shown) which can be any of a variety of non-volatile memory types, such as read-only memory (ROM), flash electrically erasable programmable ROM (EEPROM), and the like. Typically, the BIOS memory is accessed through the PCIe bus, and the system data drive through the SATA interface.

SMU <NUM> is a local controller that controls the operation of the resources on APU <NUM> and synchronizes communication among them. SMU <NUM> manages power-up sequencing of the various processors on APU <NUM> and controls multiple off-chip devices via reset, enable and other signals. SMU <NUM> includes one or more clock sources (not shown), such as a phase locked loop (PLL), to provide clock signals for each of the components of APU <NUM>. SMU <NUM> also manages power for the various processors and other functional blocks, and may receive measured power consumption values from CPU cores <NUM> and <NUM> and graphics core <NUM> to determine appropriate power states.

Memory management hub <NUM>, and its associated physical interfaces (PHYs) <NUM> and <NUM> are integrated with APU <NUM> in this embodiment. Memory management hub <NUM> includes memory channels <NUM> and <NUM> and a power engine <NUM>. Memory channel <NUM> includes a host interface <NUM>, a memory channel controller <NUM>, and a physical interface <NUM>. Host interface <NUM> bidirectionally connects memory channel controller <NUM> to data fabric <NUM> over a serial presence detect link (SDP). Physical interface <NUM> bidirectionally connects memory channel controller <NUM> to PHY <NUM>, and conforms to the DDR PHY Interface (DFI) Specification. Memory channel <NUM> includes a host interface <NUM>, a memory channel controller <NUM>, and a physical interface <NUM>. Host interface <NUM> bidirectionally connects memory channel controller <NUM> to data fabric <NUM> over another SDP. Physical interface <NUM> bidirectionally connects memory channel controller <NUM> to PHY <NUM>, and conforms to the (DFI Specification. Power engine <NUM> is bidirectionally connected to SMU <NUM> over the SMN bus, to PHYs <NUM> and <NUM> over the Advanced Peripheral Bus (APB), and is also bidirectionally connected to memory channel controllers <NUM> and <NUM>. PHY <NUM> has a bidirectional connection to memory channel <NUM>. PHY <NUM> has a bidirectional connection memory channel <NUM>.

Memory management hub <NUM>, and its associated physical interfaces (PHYs) <NUM> and <NUM> are integrated with APU <NUM> in this embodiment. Memory management hub <NUM> includes memory channels <NUM> and <NUM> and a power engine <NUM>. Memory channel <NUM> includes a host interface <NUM>, a memory channel controller <NUM>, and a physical interface <NUM>. Host interface <NUM> bidirectionally connects memory channel controller <NUM> to data fabric <NUM> over a serial presence detect link (SDP). Physical interface <NUM> bidirectionally connects memory channel controller <NUM> to PHY <NUM>, and conforms to the DDR PHY Interface (DFI) Specification. Memory channel <NUM> includes a host interface <NUM>, a memory channel controller <NUM>, and a physical interface <NUM>. Host interface <NUM> bidirectionally connects memory channel controller <NUM> to data fabric <NUM> over another SDP. Physical interface <NUM> bidirectionally connects memory channel controller <NUM> to PHY <NUM>, and conforms to the DFI Specification. Power engine <NUM> is bidirectionally connected to SMU <NUM> over the SMN bus, to PHYs <NUM> and <NUM> over the Advanced Peripheral Bus (APB), and is also bidirectionally connected to memory channel controllers <NUM> and <NUM>. PHY <NUM> has a bidirectional connection to memory channel <NUM>. PHY <NUM> has a bidirectional connection memory channel <NUM>.

Memory system <NUM> includes a memory channel <NUM> and a memory channel <NUM>. Memory channel <NUM> includes a set of dual inline memory modules (DIMMs) connected to a DDRx bus <NUM>, including representative DIMMs <NUM>, <NUM>, and <NUM> that in this example correspond to separate ranks. Likewise, memory channel <NUM> includes a set of DIMMs connected to a DDRx bus <NUM>, including representative DIMMs <NUM>, <NUM>, and <NUM>.

APU <NUM> operates as the central processing unit (CPU) of a host data processing system and provides various buses and interfaces useful in modern computer systems. These interfaces include two double data rate (DDRx) memory channels, a PCIe root complex for connection to a PCIe link, a USB controller for connection to a USB network, and an interface to a SATA mass storage device.

APU <NUM> also implements various system monitoring and power saving functions. In particular one system monitoring function is thermal monitoring. For example, if APU <NUM> becomes hot, then SMU <NUM> can reduce the frequency and voltage of CPU cores <NUM> and <NUM> and/or graphics core <NUM>. If APU <NUM> becomes too hot, then it can be shut down entirely. Thermal events can also be received from external sensors by SMU <NUM> via the SMN bus, and SMU <NUM> can reduce the clock frequency and/or power supply voltage in response.

<FIG> illustrates in block diagram form a memory controller <NUM> that is suitable for use in an APU like that of <FIG>. Memory controller <NUM> includes generally a memory channel controller <NUM> and a power controller <NUM>. Memory channel controller <NUM> includes generally an interface <NUM>, a memory interface queue <NUM> ("memory interface queue", "queue"), a command queue <NUM>, an address generator <NUM>, a content addressable memory (CAM) <NUM>, replay control logic <NUM> including a replay queue <NUM>, a refresh logic block <NUM>, a timing block <NUM>, a page table <NUM>, an arbiter <NUM>, an error correction code (ECC) check circuit <NUM>, an ECC generation block <NUM>, a data buffer <NUM>, a non-volatile (NV) buffer <NUM>, and a NV queue <NUM>.

Interface <NUM> has a first bidirectional connection to data fabric <NUM> over an external bus, and has an output. In memory controller <NUM>, this external bus is compatible with the advanced extensible interface version four specified by ARM Holdings, PLC of Cambridge, England, known as "AXI4", but can be other types of interfaces in other embodiments. Interface <NUM> translates memory access requests from a first clock domain known as the FCLK (or MEMCLK) domain to a second clock domain internal to memory controller <NUM> known as the UCLK domain. Similarly, memory interface queue <NUM> provides memory accesses from the UCLK domain to a DFICLK domain associated with the DFI interface.

Address generator <NUM> decodes addresses of memory access requests received from data fabric <NUM> over the AXI4 bus. The memory access requests include access addresses in the physical address space represented in a normalized format. Address generator <NUM> converts the normalized addresses into a format that can be used to address the actual memory devices in memory system <NUM>, as well as to efficiently schedule related accesses. This format includes a region identifier that associates the memory access request with a particular rank, a row address, a column address, a bank address, and a bank group. On startup, the system BIOS queries the memory devices in memory system <NUM> to determine their size and configuration, and programs a set of configuration registers associated with address generator <NUM>. Address generator <NUM> uses the configuration stored in the configuration registers to translate the normalized addresses into the appropriate format. Address generator <NUM> decodes the address range of the memory, including NVDIMM-P memory, and stores a decoded signal indicating whether the memory access request is a request to NVDIMM-P in command queue <NUM>. Arbiter <NUM> can then prioritize the NVDIMM-P requests with appropriate priority relative to other requests. Command queue <NUM> is a queue of memory access requests received from the memory accessing agents in APU <NUM>, such as CPU cores <NUM> and <NUM> and graphics core <NUM>. Command queue <NUM> stores the address fields decoded by address generator <NUM> as well other address information that allows arbiter <NUM> to select memory accesses efficiently, including access type and quality of service (QoS) identifiers. CAM <NUM> includes information to enforce ordering rules, such as write after write (WAW) and read after write (RAW) ordering rules.

Error correction code (ECC) generation block <NUM> determines the ECC of write data to be sent to the NVDIMM-P. ECC check circuit <NUM> checks the received ECC against the incoming ECC.

Replay queue <NUM> is a temporary queue for storing selected memory accesses picked by arbiter <NUM> that are awaiting responses, such as address and command parity responses. Replay control logic <NUM> accesses ECC check circuit <NUM> to determine whether the returned ECC is correct or indicates an error. Replay control logic <NUM> initiates and controls a replay sequence in which accesses are replayed in the case of a parity or ECC error of one of these cycles. Replayed commands are placed in the memory interface queue <NUM>.

Refresh logic <NUM> includes state machines for various powerdown, refresh, and termination resistance (ZQ) calibration cycles that are generated separately from normal read and write memory access requests received from memory accessing agents. For example, if a memory rank is in precharge powerdown, it must be periodically awakened to run refresh cycles. Refresh logic <NUM> generates refresh commands periodically to prevent data errors caused by leaking of charge off storage capacitors of memory cells in DRAM chips. In addition, refresh logic <NUM> periodically calibrates ZQ to prevent mismatch in on-die termination resistance due to thermal changes in the system.

Arbiter <NUM> is bidirectionally connected to command queue <NUM> and is the heart of memory channel controller <NUM>. It improves efficiency by intelligent scheduling of accesses to improve the usage of the memory bus. Arbiter <NUM> uses timing block <NUM> to enforce proper timing relationships by determining whether certain accesses in command queue <NUM> are eligible for issuance based on DRAM timing parameters. For example, each DRAM has a minimum specified time between activate commands, known as "tRC". Timing block <NUM> maintains a set of counters that determine eligibility based on this and other timing parameters specified in the JEDEC specification, and is bidirectionally connected to replay queue <NUM>. Page table <NUM> maintains state information about active pages in each bank and rank of the memory channel for arbiter <NUM>, and is bidirectionally connected to replay queue <NUM>.

NV buffer <NUM> stores NV read commands in NV queue <NUM>, both for use in replay sequences, and for managing NV read responses. NV buffer <NUM> is bidirectionally connected to memory interface queue <NUM> for handling RD_RDY and SEND commands, as further described below.

In response to write memory access requests received from interface <NUM>, ECC generation block <NUM> computes an ECC according to the write data. Data buffer <NUM> stores the write data and ECC for received memory access requests. It outputs the combined write data/ECC to memory interface queue <NUM> when arbiter <NUM> picks the corresponding write access for dispatch to the memory channel.

Power controller <NUM> generally includes an interface <NUM> to an advanced extensible interface, version one (AXI), an APB interface <NUM>, and a power engine <NUM>. Interface <NUM> has a first bidirectional connection to the SMN, which includes an input for receiving an event signal labeled "EVENT_n" shown separately in <FIG>, and an output. APB interface <NUM> has an input connected to the output of interface <NUM>, and an output for connection to a PHY over an APB. Power engine <NUM> has an input connected to the output of interface <NUM>, and an output connected to an input of memory interface queue <NUM>. Power engine <NUM> includes a set of configuration registers <NUM>, a microcontroller (µC) <NUM>, a self refresh controller (SLFREF/PE) <NUM>, and a reliable read/write timing engine (RRW/TE) <NUM>. Configuration registers <NUM> are programmed over the AXI bus, and store configuration information to control the operation of various blocks in memory controller <NUM>. Accordingly, configuration registers <NUM> have outputs connected to these blocks that are not shown in detail in <FIG>. Self refresh controller <NUM> is an engine that allows the manual generation of refreshes in addition to the automatic generation of refreshes by refresh logic <NUM>. Reliable read/write timing engine <NUM> provides a continuous memory access stream to memory or I/O devices for such purposes as DDR interface maximum read latency (MRL) training and loopback testing.

Memory channel controller <NUM> includes circuitry that allows it to pick memory accesses for dispatch to the associated memory channel. In order to make the desired arbitration decisions, address generator <NUM> decodes the address information into predecoded information including rank, row address, column address, bank address, and bank group in the memory system, and command queue <NUM> stores the predecoded information. Configuration registers <NUM> store configuration information to determine how address generator <NUM> decodes the received address information. Arbiter <NUM> uses the decoded address information, timing eligibility information indicated by timing block <NUM>, and active page information indicated by page table <NUM> to efficiently schedule memory accesses while observing other criteria such as quality of service (QoS) requirements. For example, arbiter <NUM> implements a preference for accesses to open pages to avoid the overhead of precharge and activation commands required to change memory pages, and hides overhead accesses to one bank by interleaving them with read and write accesses to another bank. In particular during normal operation, arbiter <NUM> normally keeps pages open in different banks until they are required to be precharged prior to selecting a different page.

<FIG> illustrates in block diagram form a data processing system <NUM> according to some embodiments. Data processing system <NUM> includes an APU <NUM> and a memory system <NUM>. Various other parts of the system are not shown in order to focus on the memory arrangement. APU <NUM> includes memory controllers like memory controller <NUM> (<FIG>) supporting heterogeneous memory channels to interface with memory system <NUM>. In addition to normal DDRx memory channels, APU <NUM> supports NVDIMM-P <NUM> on a heterogeneous memory channel <NUM> having both normal registered DIMMs or RDIMMs <NUM> and <NUM> and NVDIMM-P <NUM>, in addition to a homogeneous memory channel <NUM> having only RDIMMs <NUM>, <NUM>, and <NUM> connected over bus <NUM>. Other DIMM types such as LRDIMMs and UDIMMs are supported in some embodiments. While in this embodiment heterogeneous memory channel <NUM> connects to both NVDIMM-Ps and RDIMMs, the heterogeneous memory channel has the ability to interface with all NVDIMM-P type DIMMs in some embodiments.

According to the draft NVDIMM-P standard, transactions between the memory controller on APU <NUM> and NVDIMM-P <NUM> are protected by "Link" ECC. Link ECC ensures data integrity for the data transfer between the memory controller and the NVDIMM over bus <NUM>. In accordance with known ECC mechanisms, it protects against data corruption on the link caused by a random or transient error. The protection varies according to the ECC code used. The ECC may allow, for example, single-bit correction with multiple-bit error detection. In response to detecting an uncorrectable error, the memory controller can replay the transaction so that a transient or random error will not persist, and can also report both correctable and uncorrectable errors to the operating system.

While NVDIMM-P type DIMMs are described in this embodiment, other embodiments, not falling under the scope of the independent claims, employ the techniques herein to interface with other types of storage class memory (SCM) modules over a heterogeneous memory channel. As used herein, SCM indicates a memory module with non-volatile memory that is addressable in the system memory space. The non-volatile memory in an SCM module can be buffered with RAM and/or paired with RAM on board the SCM module. The SCM memory address map appears alongside conventional DRAM population from the operating system (OS) perspective. The OS is typically aware that the SCM defined address range is a "different" type of memory than conventional memory. This distinction is to inform the OS that this memory may be more latent and has a persistent quality. The OS can map the SCM memory as Direct Access memory or Filesystem Access memory. Direct Access implies the OS accessing the SCM address range as physical addressable memory. File system access implies the OS manages the persistent memory as part of the file system and manages access to the SCM via file-based API. Ultimately the request comes to the memory controller within the SCM address range independent of how the OS at a higher level manages the access.

<FIG> is a flow diagram of a process <NUM> for handing memory access commands according to some embodiments. Process <NUM> is focused on the handling of non-volatile read commands, and is suitable for implementation with memory controller <NUM> of <FIG>, or other memory controller arrangements. Process <NUM> begins at block <NUM> where it receives a plurality of memory access requests including volatile memory reads, volatile memory writes, non-volatile memory reads, and non-volatile memory writes. At block <NUM>, memory access commands for filling the requests are scheduled and placed in a memory interface queue. Block <NUM> typically involves decoding memory access commands for the memory access requests, and may include holding the memory access commands in a command queue before they are scheduled and placed in the memory interface queue by an arbiter such as arbiter <NUM> (<FIG>).

At block <NUM>, process <NUM> stores the non-volatile read commands that are placed in the memory interface queue in a non-volatile command queue (NV queue). At block <NUM>, memory access commands from the memory interface queue are transmitted over a heterogeneous memory channel coupled to at least one non-volatile dual in-line memory module (DIMM). The memory channel is also coupled to at least one volatile DIMM.

As shown at block <NUM>, for non-volatile read commands transmitted over the heterogeneous memory channel, the non-volatile DIMM will typically respond after a nondeterministic time period due to the unpredictable process of reading the requested data, which may be in non-volatile memory at the non-volatile DIMM, in DRAM at the non-volatile DIMM, or in a cache at the media controller. During the nondeterministic time period, other memory access commands are typically sent from the memory interface queue. When the media controller at the non-volatile DIMM completes the process of reading the requested data, it sends a ready response signal "RD RDY" to the memory controller. The process waits to receive the RD RDY for each non-volatile read. Typically, the RD RDY signal is sent and received on a separate sub-channel of the heterogeneous memory channel than a sub-channel on which the memory interface queue receives responses to the memory access commands. For example, with a NVDIMM-P memory channel, the RD_RDY signal is typically sent on a "RSP_R" line of the memory channel separate from the "CMD" and "DQ" lines on which commands and data are transmitted.

At block <NUM>, the RD_RDY signal is received from the non-volatile DIMM indicating that responsive data is available for an associated one of the non-volatile read commands. A control circuit, which in this example is NV buffer <NUM> (<FIG>), receives the RD_RDY signal. In response, at block <NUM>, NV buffer <NUM> places a SEND command in the memory interface queue. The SEND command is thereby scheduled or queued for transmission to the non-volatile DIMM.

Upon receiving the SEND command, the non-volatile DIMM media controller transmits the responsive data that was read for the non-volatile read command, including an associated identifier for the command back to the memory controller. The associated identifier in this embodiment is a read identifier "RID" for the read command. At block <NUM>, the responsive data and associated identifier are received from the non-volatile DIMM at the memory controller. In response, the NV buffer at the memory controller uses the associated identifier to identify the non-volatile read command in the NV queue with the same associated identifier. At block <NUM>, the responsive data is provided in fulfillment the associated non-volatile read request for which the non-volatile ready command was produced. This fulfills the request, and the associated non-volatile read command is removed from the NV queue.

In some embodiments, process <NUM> at block <NUM> includes scheduling the memory access commands with an arbiter such as arbiter <NUM> (<FIG>). In one example, before placing the memory access commands in the memory interface queue, the process groups non-volatile read commands with other non-volatile read commands or volatile read commands. In some embodiments, process <NUM> at block <NUM> further includes, before placing the send command in the memory interface queue, grouping the send command with a group of non-volatile or volatile read commands before placing the send command in the memory interface queue. Because the response time of the SEND command is deterministic, memory interface queue <NUM> can intermingle SEND commands with other commands to volatile memory, such as normal DDRx reads and WRITEs, as well as non-volatile WRITEs.

<FIG> is a flow diagram of a process for handling errors. <FIG> are a sequence of diagrams <NUM> and <NUM> illustrating the process of <FIG>. Referring to <FIG>, process <NUM> generally handles storing commands and providing a recovery sequence in which the channel and the non-volatile DIMM are reset, and then recent commands are replayed to correct errors. While the blocks are shown in a particular order, this order is not limiting and some of the blocks occur in parallel on an ongoing basis. Process <NUM> is suitable to be performed by memory controller <NUM> (<FIG>) or other memory controllers with a suitable NV queue and replay queue and error detection capabilities.

At block <NUM>, copies of non-volatile read commands are stored in the NV queue as they are placed in the memory interface queue for transmission to the respective non-volatile DIMM. This is illustrated in diagram <NUM> by arrow <NUM> showing commands going to the memory interface queue as they are selected for transmission, and arrow <NUM> showing a copy of non-volatile read commands being stored in the NV queue. Other types of commands have copies stored in the replay queue as shown at block <NUM>, including non-volatile writes, volatile writes, volatile reads, SEND commands, and other memory access commands. Diagram <NUM> at arrow <NUM> shows the other commands being stored in the replay queue. Blocks <NUM> and <NUM> occur on an ongoing basis as the memory controller handles memory access requests.

While no errors are detected, process <NUM> continues to store commands in the NV queue and the replay queue, where they are held until they are fulfilled and removed from their respective queue. Process <NUM> at block <NUM> detects whether there was an error at one of the DIMMs or on the memory channel which requires a recovery sequence, and begins a recovery sequence and goes to one of block <NUM>, <NUM>, or <NUM> depending on the nature of the error(s) detected. If the error detected is a command parity error, process <NUM> goes from block <NUM> to block <NUM>, where it sends a command to clear parity errors at each DIMM on the memory channel. If a write or read ECC error is detected, process <NUM> goes to block <NUM>, where it clears the write or read ECC status. If both a command parity error and a write/read ECC error are detected, process <NUM> goes to block <NUM>, where it sends the command to clear parity errors at each DIMM on the channel, and then goes to block <NUM> where it clears the write or read ECC status. In some embodiments, block <NUM> also proceeds to block <NUM> if the process is unable to determine an error type, clearing errors for both error types to ensure the error status is completely cleared. Then process <NUM> goes to block <NUM> to continue the recovery sequence.

At block <NUM>, if Multi-Purpose Register (MPR) mode is currently active, it is disabled. The memory controller resets the first-in-first-out (FIFO) buffers of the PHY at block <NUM>. At block <NUM>, all of the read ID's (RIDs) are reset in the non-volatile DIMMs on the memory channel and the channel buffer. In some embodiments, block <NUM> includes sending a reset RID (RST RID) command, waiting for a ready (RDY) response, and sending a SEND command, and waiting for a resulting data packet to confirm that all outstanding reads have been reset so the non-volatile DIMM does not send any more RDY responses for pending read commands.

If write credits are needed, they are requested and obtained at block <NUM>. In some embodiments, block <NUM> includes sending a write status command to determine how many write credits are available for the non-volatile DIMM, determining if more write credits are needed, and then requesting and obtaining more write credits. The requests may include looping through multiple write credit requests until sufficient write credits are received.

If the MPR mode was active prior to the recovery sequence, it is again enabled at block <NUM> in order to place the non-volatile DIMM in the same condition it was in when the error occurred to replay the necessary commands.

At this point the recovery sequence has reset and cleared the various parts of the channel and non-volatile DIMM in order to begin replaying commands. At block <NUM>, process <NUM> begins replaying commands starting with selected commands from the replay queue. The selected commands include any volatile reads, multi-purpose register (MPR)-related commands, SEND commands associated with MPR-related commands, volatile writes, and non-volatile writes that are present in the replay queue. SEND commands associated with non-volatile reads are stored in the replay queue for reporting and debug purposes, but are not transmitted at block <NUM>. FLUSH commands present in the replay queue are also not replayed.

Preferably the blocks from block <NUM> to block <NUM> are performed under control of replay control logic <NUM> (<FIG>) or a similar replay control circuit. Then the process passes control to NV buffer <NUM> in order to complete non-volatile read command replays.

At block <NUM>, process <NUM> includes replaying all non-volatile reads that are stored in the NV queue by sending them to the memory interface queue. Preferably, this occurs after transmitting all the selected memory access commands that are stored in the replay queue. As explained with respect to <FIG>, non-volatile reads have a nondeterministic response time, which means the SEND commands that were originally transmitted following a RD RDY response for a non-volatile read are not necessarily transmitted again in the same order. To handle this ordering, process <NUM> includes skipping SEND commands stored in the replay queue that are associated with non-volatile reads, and at block <NUM> responding to the RD-RDY responses as they arrive for non-volatile reads by generating new SEND commands in response to read ready (RD_RDY) responses received from the non-volatile DIMM during the recovery sequence. At this point, the replay sequence is complete and the memory controller ends the replay sequence and returns to its normal operating conditions.

Thus, a memory controller and data processing system as described herein improves the ability of the memory controller to interface with non-volatile DIMMs. Moreover, the memory controller herein reduces the length of the memory interface queue by eliminating the need for the memory interface queue to hold non-volatile read commands that have nondeterministic and potentially long latencies until they are fulfilled.

Memory controller <NUM> of <FIG> or any portions thereof, such as arbiter <NUM>, may be described or represented by a computer accessible data structure in the form of a database or other data structure which can be read by a program and used, directly or indirectly, to fabricate integrated circuits. For example, this data structure may be a behavioral-level description or register-transfer level (RTL) description of the hardware functionality in a high level design language (HDL) such as Verilog or VHDL. The description may be read by a synthesis tool which may synthesize the description to produce a netlist including a list of gates from a synthesis library. The netlist includes a set of gates that also represent the functionality of the hardware including integrated circuits. The netlist may then be placed and routed to produce a data set describing geometric shapes to be applied to masks. The masks may then be used in various semiconductor fabrication steps to produce the integrated circuits. Alternatively, the database on the computer accessible storage medium may be the netlist (with or without the synthesis library) or the data set, as desired, or Graphic Data System (GDS) II data.

Claim 1:
A memory controller (<NUM>), comprising:
a command queue (<NUM>) having a first input for receiving memory access commands including volatile reads, volatile writes, non-volatile reads, and non-volatile writes, and an output, and having a plurality of entries; and
a memory interface queue (<NUM>) having an input coupled to the output of the command queue, and an output for coupling to a heterogeneous memory channel which is coupled to a volatile dual in-line memory module, DIMM, and a non-volatile DIMM;
a non-volatile command queue, NV queue, (<NUM>) coupled to the output of the command queue for storing non-volatile read commands that are placed in the memory interface queue;
characterized in that the memory controller further comprises:
a replay queue (<NUM>) coupled to the output of the command queue for storing selected memory access commands that are placed in the memory interface queue; and
a replay control circuit (<NUM>) for detecting, based on information received over the heterogeneous memory channel, that an error has occurred requiring a recovery sequence, and in response to the error, initiating the recovery sequence including transmitting selected memory access commands that are stored in the replay queue, and transmitting non-volatile reads that are stored in the NV queue, wherein the recovery sequence further includes skipping (<NUM>) SEND commands stored in the replay queue that are associated with non-volatile reads, and generating new SEND commands in response to read ready, RD_RDY, responses received from the non-volatile DIMM during the recovery sequence.