JP7657963B2 - Credit Scheme for Multi-Queue Memory Controllers - Patent application - Google Patents

Description

Computer systems commonly use inexpensive, high-density dynamic random access memory (DRAM) chips for main memory. Most DRAM chips sold today conform to various double data rate (DDR) DRAM standards promulgated by the Joint Electron Devices Engineering Council (JEDEC). DDR DRAM uses conventional DRAM memory cell arrays with high-speed access circuits to achieve high transfer rates and improve memory bus utilization. A DDR memory controller may interface with multiple DDR channels to accommodate more DRAM modules and exchange data with the memory faster than using a single channel. For example, some memory controllers include two or four DDR memory channels.

Modern DDR memory controllers maintain queues for storing pending memory access requests, allowing them to be selected out of order relative to the order in which they were generated or stored to increase efficiency. To prevent memory access requests from being rejected because a particular queue is full, the memory controller's data interface controls the flow of memory access requests using a credit control scheme in which request credits are provided to various parts of the host system, such as its data interface fabric, allowing the host system to submit memory requests for entry into the command queue. The memory controller also needs to be flexible enough that it can be configured for different memory types, densities and memory channel topologies, but does not require a large amount of additional circuit area that can increase chip costs to support these different modes.

1 is a block diagram of an accelerated processing unit (APU) and memory system known in the prior art; 2 is a block diagram of a partial data processing system including a dual channel memory controller suitable for use in an APU similar to FIG. 1 , according to some embodiments. FIG. 3 is a block diagram of a credit control circuit suitable for implementing the credit control circuit of FIG. 2 according to some embodiments. FIG. 11 is a flow diagram of a process for managing request credits, according to some embodiments. FIG. 11 is a flow diagram of another process for managing request credits in a dual channel memory controller.

In the following description, the use of the same reference numbers in different figures indicates similar or identical items. Unless otherwise noted, the word "coupled" and its related verb forms include both direct and indirect electrical connections by means known in the art, and unless otherwise noted, any description of a direct connection also refers to an alternative embodiment using a suitable form of indirect electrical connection.

The memory controller includes an address decoder, a first command queue, a second command queue, and a request credit control circuit. The address decoder has a first input for receiving memory access requests, a first output, and a second output. The first command queue has an input connected to the first output of the address decoder for receiving memory access requests for the first memory channel, and a number of entries for holding the memory access requests. The second command queue has an input connected to the second output of the address decoder for receiving memory access requests for the second memory channel, and a number of entries for holding the memory access requests. The request credit control circuit is connected to the first command queue and the second command queue. The request credit control circuit is operable to track the number of outstanding request credits and issue request credits based on the number of available entries in the first command queue and the second command queue.

The method includes receiving a plurality of memory access requests at a memory controller. Addresses of the memory access requests are decoded, and one of a first memory channel and a second memory channel is selected to receive each of the memory access requests. After decoding the addresses, the method includes sending each memory access request to one of a first command queue associated with the first memory channel and a second command queue associated with the second memory channel. In response to a specified event, the method includes issuing request credits based on the number of available entries in the first command queue and the second command queue.

The data processing system includes a data fabric, a first and a second memory channel, and a memory controller connected to the data fabric and the first and second memory channels to fulfill memory access requests received over the data fabric from at least one memory access engine. The memory controller includes an address decoder, a first command queue, a second command queue, and a request credit control circuit. The address decoder has a first input for receiving memory access requests, a first output, and a second output. The first command queue has an input connected to a first output of the address decoder for receiving memory access requests for the first memory channel, and a number of entries for holding memory access requests. The second command queue has an input connected to a second output of the address decoder for receiving memory access requests for the second memory channel, and a number of entries for holding memory access requests. The request credit control circuit is connected to the first command queue and the second command queue. The request credit control circuit is operable to track a number of outstanding request credits and issue request credits based on the number of available entries in the first command queue and the second command queue.

1 is a block diagram of an accelerated processing unit (APU) 100 and memory system 130 known in the prior art. The APU 100 is an integrated circuit suitable for use as a processor in a host data processing system and generally includes a central processing unit (CPU) core complex 110, a graphics core 120, a set of display engines 122, a data fabric 125, a memory management hub 140, a set of peripheral controllers 160, a set of peripheral bus controllers 170, and a system management unit (SMU) 180.

The CPU core complex 110 includes a CPU core 112 and a CPU core 114. In this example, the CPU core complex 110 includes two CPU cores, but in other embodiments, the CPU core complex 110 can include any number of CPU cores. Each of the CPU cores 112 and 114 is bidirectionally connected to a system management network (SMN) that forms a control fabric and a data fabric 125, and can provide memory access requests to the data fabric 125. Each of the CPU cores 112 and 114 may be a single core, or may be a core complex having two or more single cores that further share certain resources such as caches.

The graphics core 120 is a high-performance graphics processing unit (GPU) capable of performing graphics processing such as vertex processing, fragment processing, shading, and texture blending in a highly integrated and parallel manner. The graphics core 120 is bidirectionally connected to the SMN and to the data fabric 125 and can provide memory access requests to the data fabric 125. In this regard, the APU 100 can support either a unified memory architecture in which the CPU core complex 110 and the graphics core 120 share the same memory space, or a memory architecture in which the CPU core complex 110 and the graphics core 120 share a portion of the memory space, but the graphics core 120 also uses a private graphics memory that is not accessible by the CPU core complex 110.

The display engine 122 renders and rasterizes objects generated by the graphics core 120 for display on a monitor. The graphics core 120 and the display engine 122 are bidirectionally connected to a common memory management hub 140 via the data fabric 125 for uniform translation to appropriate addresses in the memory system 130.

The data fabric 125 includes a crossbar switch for routing memory access requests and responses between any memory access agent and the memory management hub 140. The data fabric also includes a system memory map defined by the basic input/output system (BIOS) to determine where to send memory accesses based on the system configuration, as well as buffers for each virtual connection.

The peripheral controllers 160 include a universal serial bus (USB) controller 162 and a Serial Advanced Technology Attachment (SATA) interface controller 164, each of which is bidirectionally connected to a system hub 166 and an SMN bus. These two controllers are merely exemplary of peripheral controllers that may be used in the APU 100.

The peripheral bus controllers 170 include a system controller or "Southbridge" (SB) 172 and a Peripheral Component Interconnect Express (PCIe) controller 174, each of which is bidirectionally connected to an input/output (I/O) hub 176 and the SMN bus. The I/O hub 176 is also bidirectionally connected to the system hub 166 and the data fabric 125. Thus, for example, a CPU core can program registers in the USB controller 162, the SATA interface controller 164, the SB 172, or the PCIe controller 174, with accesses routed by the data fabric 125 through the I/O hub 176. Software and firmware for APU 100 is stored in a system data drive or system BIOS memory (not shown), which may be any of a variety of non-volatile memory types, such as read-only memory (ROM), flash, electrically erasable programmable ROM (EEPROM), etc. Typically, the BIOS memory is accessed via a PCIe bus and the system data drive is accessed via a SATA interface.

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

The memory management hub 140 and its associated physical interfaces (PHYs) 151 and 152 are integrated with the APU 100 in this embodiment. The memory management hub 140 includes memory channels 141 and 142 and a power engine 149. The memory channel 141 includes a host interface 145, a memory channel controller 143, and a physical interface 147. The host interface 145 bidirectionally connects the memory channel controller 143 to the data fabric 125 via a serial presence detect link (SDP). The physical interface 147 bidirectionally connects the memory channel controller 143 to the PHY 151 and conforms to the DDR PHY Interface (DFI) specification. The memory channel 142 includes a host interface 146, a memory channel controller 144, and a physical interface 148. Host interface 146 bidirectionally connects memory channel controller 144 to data fabric 125 via another SDP. Physical interface 148 bidirectionally connects memory channel controller 144 to PHY 152 and conforms to the DFI specification. Power engine 149 is bidirectionally connected to SMU 180 via the SMN bus, to PHYs 151 and 152 via the APB, and to memory channel controllers 143 and 144. PHY 151 has a bidirectional connection to memory channel 131. PHY 152 has a bidirectionally connected memory channel 133.

Memory management hub 140 is an instantiation of a memory controller with two memory channel controllers and uses a shared power engine 149 to control the operation of both memory channel controller 143 and memory channel controller 144 in a manner further described below. Each of memory channels 141 and 142 can connect to state-of-the-art DDR memories such as DDR version five (DDR5), DDR version four (DDR4), low power DDR4 (LPDDR4), graphics DDR version five (GDDR5), and high bandwidth memory (HBM), and can be adapted for future memory technologies. These memories provide high bus bandwidth and high speed operation. At the same time, they provide low power modes to conserve power for battery-powered applications such as laptop computers, as well as built-in thermal monitoring.

Memory system 130 includes memory channel 131 and memory channel 133. Memory channel 131 includes a set of dual inline memory modules (DIMMs) connected to DDRx bus 132, including representative DIMMs 134, 136, and 138 that, in this example, correspond to separate ranks. Similarly, memory channel 133 includes a set of DIMMs connected to DDRx bus 129, including representative DIMMs 135, 137, and 139.

The APU 100 acts as the central processing unit (CPU) of the host data processing system and provides the 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 100 also implements various system monitoring and power saving functions. One system monitoring function in particular is thermal monitoring. For example, if APU 100 becomes too hot, SMU 180 can reduce the frequency and voltage of CPU cores 112, 114 and/or graphics core 120. If APU 100 becomes too hot, the SMU can be shut down completely. Thermal events can also be received from external sensors by SMU 180 via the SMN bus, and SMU 180 can reduce the clock frequency and/or power supply voltage accordingly.

FIG. 2 is a block diagram of a partial data processing system 200 including a dual channel memory controller 210 suitable for use in an APU such as FIG. 1. The dual channel memory controller 210 is shown connected to the data fabric 125 and can communicate with several memory agents present in the data processing system 200, including a coherent slave agent 250 and a coherent master agent 260. The dual channel memory controller 210 replaces two separate memory channel controllers 143 and 144 (FIG. 1) and can control two DDRx channels together in a manner that is transparent to the various memory addressing agents in the data fabric 125 and the data processing system 200, so that a single memory controller interface 212 can be used to send memory access commands and receive results. The dual channel memory controller 210 can also control two sub-channels, such as those defined in the DDR5 specification for use with DDR5 DRAMs, or those sub-channels defined in the High Bandwidth Memory 2 (HBM2) and HBM3 standards. Dual channel memory controller 210 generally includes an interface 212, a credit control circuit 221, an address decoder 222, and two instances of memory channel control circuitry 223, each assigned to a different memory channel. Each instance of memory channel control circuitry 223 includes a memory interface queue 214, a command queue 220, a content addressable memory (CAM) 224, a replay control logic 231 including a replay queue 230, a timing block 234, a page table 236, an arbiter 238, an error correction code (ECC) check circuit 242, an ECC generation block 244, a data buffer 246, and a refresh control logic 232 including an activation counter 248. In other embodiments, only the command queue 230, the arbiter 238, and the memory interface queue 214 are duplicated for each memory channel or sub-channel used, and the remaining illustrated circuitry is adapted for use with two channels. Additionally, although the illustrated dual channel memory controller includes two instances of arbiter 238, command queue 220, and memory interface queue 214 to control two memory channels or sub-channels, other embodiments may include more instances, such as three or four or more, used to communicate with DRAM over three or four channels or sub-channels in accordance with the credit management techniques herein.

Interface 212 has a first bidirectional connection to data fabric 125 via a communication bus and a second bidirectional connection to credit control circuit 221. In this embodiment, interface 212 uses a Scalable Data Port (SDP) link to establish several channels for communicating with data fabric 125, although other interface link standards are suitable for use. For example, in another embodiment, the communication bus conforms to the Advanced Scalable Interface Version 4 specified by ARM Holdings, PLC of Cambridge, UK, known as "AXI4", although other types of interfaces may be used in other embodiments. Interface 212 translates memory access requests from a first clock domain known as the "FCLK" (or "MEMCLK") domain to a second clock domain internal to dual channel memory controller 210, known as the "UCLK" domain. Similarly, memory interface queue 214 provides memory access from the UCLK domain to the "DFICLK" domain associated with the DFI interface.

The credit control circuit 221 includes a bidirectional communication link to the interface 212, which may be shared with the address decoder 222 or may include a dedicated SDP channel for managing request credits. The credit control circuit 221 also has inputs connected to both command queues 220, and is shown in the figure as being shared with the address decoder 222. The credit control circuit 221 generally controls the request credits allocated to the data fabric for both memory channels. As described further below, the control process performed by the credit control circuit 221 includes tracking the number of outstanding request credits, issuing a request credit in response to a memory access request being deallocated from either the first or second command queue 220 if the number of outstanding request credits is less than the minimum number of available entries in the first and second command queues 220, and not issuing a request credit in response to a memory access request being deallocated otherwise. The credit control circuit 221 also operates to issue a request credit without a corresponding deallocation from the first or second command queue 220 when a memory access request is received that is allocated to either the first or second command queue 220 that has the maximum number of available entries.

Address decoder 222 has a bidirectional link to credit control circuit 221 and a first output connected to a first command queue 220 (labeled "Command Queue 0") and a second output connected to a second command queue 220 (labeled "Command Queue 1"). Address decoder 222 decodes the addresses of memory access requests received on data fabric 125 via interface 212. The memory access request includes an access address in a physical address space represented in a normalized format. Based on the access address, address decoder 222 selects one of the memory channels with an associated one of command queues 220 to process the request. The selected channel is identified to credit control circuit 221 for each request so that a credit issuance decision can be made. Address decoder 222 converts the normalized address into a format that can be used to address the actual memory devices in memory system 130 and to efficiently schedule the associated accesses. This format includes a region identifier that associates the memory access request with a particular rank, row address, column address, bank address, and bank group. At power-up, the system BIOS interrogates the memory devices in memory system 130 to determine their size and configuration, and programs a set of configuration registers associated with address decoder 222. Address decoder 222 uses the configuration stored in the configuration registers to convert normalized addresses into the appropriate format. Each memory access request is loaded into command queue 220 for the memory channel selected by address decoder 222.

Each command queue 220 is a queue of memory access requests received from various memory access engines in APU 100, such as CPU cores 112 and 114 and graphics core 120. Each command queue 220 is bidirectionally connected to a respective arbiter 238 for selecting memory access requests from command queue 220 to be issued through the associated memory channel. Each command queue 220 stores address fields decoded by address decoder 222, as well as other address information that allows the respective arbiter 238 to efficiently select memory accesses, including access type and quality of service (QoS) identifiers. Each CAM 224 contains information for implementing ordering rules, such as write after write (WAW) and read after write (RAW) ordering rules.

Each arbiter 238 is bidirectionally connected to a respective command queue 220 to select memory access requests to be executed with the appropriate command. The arbiters 238 generally improve the efficiency of their respective memory channels by intelligent scheduling of accesses to improve usage of the memory channel's memory bus. Each arbiter 238 uses its respective timing block 234 to enforce the appropriate timing relationships by determining whether a particular access in its respective command queue 220 is eligible for issue based on DRAM timing parameters. For example, each DRAM has a minimum specified time between activation commands known as " _tRC ". Each timing block 234 maintains a set of counters that determine eligibility based on this and other timing parameters defined in the JEDEC specifications, and is bidirectionally connected to the replay queue 230. Each page table 236 maintains state information regarding active pages in each bank and rank of its respective memory channel for the arbiter 238, and is bidirectionally connected to its respective replay queue 230. The arbiter 238 uses the decoded address information, the timing eligibility information indicated by the timing block 234, and the active page information indicated by the page table 236 to efficiently schedule memory accesses while adhering to other criteria such as quality of service (QoS) requirements. For example, the arbiter 238 implements prioritization of accesses to open pages and hides overhead accesses to one bank by interleaving them with read and write accesses to another bank to avoid the overhead of precharge and activate commands required to change memory pages. In particular, during normal operation, the arbiter 238 typically keeps pages open in different banks until these pages need to be precharged before selecting a different page. The arbiter 238, in some embodiments, determines the eligibility of a command selection based on at least the respective values of the activation counters 248 for the target memory regions of the respective commands.

Each error correction code (ECC) generation block 244 determines the ECC of the write data sent to the memory. The ECC check circuit 242 checks the received ECC against the incoming ECC.

Each replay queue 230 is a temporary queue for storing a memory access selected by arbiter 238 awaiting a response, such as an address and command parity response. Replay control logic 231 accesses ECC check circuitry 242 to determine whether the returned ECC is correct or indicates an error. Replay control logic 231 initiates and controls a replay sequence in which an access is replayed in the event of a parity or ECC error in one of these cycles. The replayed command is placed in memory interface queue 214.

Each instance of the refresh control logic 232 includes state machines for various power-down, refresh, and termination resistor (ZQ) calibration cycles that are generated separately from normal read and write memory access requests received from memory access agents. For example, when a memory rank is in precharge power-down, the refresh control logic must be periodically awakened to perform refresh cycles. The refresh control logic 232 periodically generates refresh commands in response to defined conditions to prevent data errors caused by charge leakage from storage capacitors of memory cells in the DRAM chip. Each instance of the refresh control logic 232 includes an activation counter 248, which in this embodiment has a counter for each memory region that counts the rolling number of activation commands sent to the memory region over the memory channel. The memory region is a memory bank in some embodiments and a memory sub-bank in other embodiments. Additionally, the refresh control logic 232 periodically calibrates the ZQ to prevent on-die termination resistor mismatches due to thermal changes in the system.

The ECC generation block 244 calculates the ECC according to the write data in response to a write memory access request received from the interface 212. The data buffer 246 stores the write data and ECC for the received memory access request. The data buffer 246 outputs the combined write data/ECC to the respective memory interface queue 214 when the respective arbiter 238 selects the corresponding write access for dispatch to the memory channel.

In embodiments having more than two memory channels or sub-channels, additional command queues, arbiters, and memory interface queues are added in parallel to those shown, using a single address decoder 222 and credit control circuitry 221. Such a design allows the credit control scheme described below to be used with more than two channels or sub-channels, with corresponding efficiencies in using queue and channel capacity. As described, the entire group of memory channel control circuits 223 may be duplicated for each channel or sub-channel, or the same logic blocks may be used with the additional capacity added to track the added command queues, arbiters, and memory interface queues.

3 illustrates a block diagram of a credit control circuit 300 suitable for implementing the credit control circuit 221 of FIG. 2, according to some embodiments. The credit control circuit 300 includes outstanding credit tracking logic 302, queue 0 occupancy logic 304, queue 1 occupancy logic 306, interface logic 308, credit issuing logic 310, request monitor 312, command queue monitor 314, and a first-in-first-out (FIFO) credit queue 316 (FIFO queue 316). The outstanding credit tracking logic 302 generally maintains a count of issued request credits, issues new request credits, and tracks request credits that are enabled when an associated memory access request is received at the memory controller 210. The request credits are issued to one or more request agents on the data fabric. In this embodiment, the request credits are one of two types: initial credits and additional credits that are issued due to the higher capacity provided by the use of two command queues and two channels or sub-channels. The use of additional credits allows the credit control circuitry 300 to issue more credits beyond the initial number of credits under certain conditions in order to more fully and efficiently utilize the capacity of both command queues. The additional credits are tracked by the outstanding credits tracking logic in the same manner as the initial credits and are counted toward the total outstanding credits.

Queue 0 occupancy logic 304 and queue 1 occupancy logic 306 maintain a count of the number of unallocated entries in their respective command queues. In some embodiments, the count is generated by subtracting the current number of occupied entries in each command queue from the command queue size. In other embodiments, the unallocated entries are tracked directly from the command queues, or indirectly based on tracking the entries loaded into and deallocated from each command queue.

The request monitor 312 monitors incoming requests assigned by the address decoder 222 to each command queue, including which queue receives each request. This information is used by the credit issuing logic 310 in determining if and whether new request credits are issued. The command queue monitor 314 monitors both command queues to determine when requests are deallocated from the command queues. The FIFO queue 316 holds additional request credits that are issued when commands are deallocated from each command queue under certain conditions, as described with respect to FIG. 5. These credits are released to the fabric as soon as the credit issuing logic 300 determines that this is permitted, as described further below. The credit issuing logic 310 uses the number of outstanding credits, the queue occupancy of each queue, and monitored information from the request monitor 312 and the command queue monitor 314 to determine when to issue request credits, as described further below with respect to FIGS. 4 and 5. In some versions, the credit control function is implemented by monitoring logic circuitry within the memory controller's arbiter (e.g., arbiter 238, FIG. 2). In other versions, the process may be performed by digital logic or a controller having similar functionality, while using a different arbitration method than that used in the sub-arbiter 305 and final arbiter 350 discussed above.

4 is a flow diagram 400 of a process for managing request credits, according to some embodiments. The illustrated process is suitable for execution by a credit control circuit, such as the credit control circuit 300 of FIG. 3 embodied in a dual channel memory controller, a memory controller coupled to two or more memory channels or sub-channels, or another suitable digital control circuit that tracks outstanding request credits and monitors two or more command queues for a dual channel memory controller. The process generally functions to manage request credits for memory access requests for both memory channels associated with command queue 0 and command queue 1. The request credits are used by the data fabric regardless of which command queue and memory channel may ultimately be selected to receive the associated access request. That is, the existence of two memory channels or sub-channels managed by the memory controller is transparent to the data fabric and the various memory agents accessing the data fabric.

In response to the two memory channels being initialized in block 402, the process in block 404 issues initial request credits to the data fabric, which are enabled for incoming read or write commands. Write commands also require the use of data credits to manage the data buffer 246 (FIG. 2). The data credits are managed separately from the initial and additional credits described herein. The number of initial request credits is determined by the size of the command queues 220. Preferably, enough initial request credits are released to fill half of the entries in each command queue 220, ensuring that there will be no overflow if all credits are enabled to place commands in a single queue. If the two command queues are equal in size, the number of credits released is typically the size of one command queue. If the two command queues are unequal in size, the size of the smaller command queue is used to determine the initial number of credits, ensuring that the credit process is initialized with an amount of credits no greater than the smallest command queue. At this point, the data fabric owns request credits that can be used by one or more memory access agents connected to the data fabric to send requests to the memory controller 210.

At block 406, the process begins receiving read and write memory access requests, each having an associated request credit. For each received access request, at block 408, the credit control circuitry activates the outstanding request credit, for example in the outstanding credit tracking logic 302 (FIG. 3). The access request is also processed by the address decoder 222 to decode the associated address and select one of the memory channels for receiving the memory access request based on the address. At block 410, the request is assigned to a memory channel by loading the command queue of the selected memory channel under the control of the address decoder 222. The credit control circuitry 300 monitors the access requests that are loaded into each command queue at block 410.

At block 412, the process determines whether one or more additional request credits have already been issued and are pending release in the credit control circuit FIFO queue 316 (FIG. 3). The release of additional request credits is further described with respect to FIG. 5. If additional request credits are pending release, the process proceeds to block 420, where no request credits are released for the current incoming request. If not, the process proceeds to block 414, where the process determines whether both command queues are at maximum occupancy. If so, the process proceeds to block 420. If not, the process proceeds to block 416, where the process determines whether the outstanding request credits are at a maximum value. The maximum value is configurable and is typically set to the sum of the maximum occupancy of both command queues. If the outstanding request credits are at a maximum value at block 416, the process proceeds to block 420. If not, the process proceeds to block 418.

At block 418, the process determines whether the request has been assigned to the command queue with the most available entries. If so, the process proceeds to block 422, where the request credit is issued to the data fabric. The credit issuance logic 310 (FIG. 3) or other suitable digital or control circuitry performs the request credit issuance and updates the outstanding credits. The request credit issuance at block 422 is performed without a corresponding deallocation of commands from either of the command queues, which is beneficial in the illustrated process because it allows for more efficient use of the two command queues. At block 418, if the access request has not been assigned to the command queue with the most available entries, the process proceeds to block 420, where the request credit is not issued in response to this particular access request being assigned.

Using the illustrated process, a performance advantage is achieved since each command queue is utilized to a higher capacity by allowing "extra" or additional request credits to be issued if a command is assigned to a less occupied command queue. When the illustrated process is used in combination with a dual arbiter memory controller architecture such as that shown in FIG. 2, a further performance advantage is achieved since each memory channel can be arbitrated separately while generally operating with a larger number of commands available in the command queue for the arbiter to select from than would be the case if a more pessimistic approach without queue capacity checks were used as shown in FIGS. 4 and 5.

Although flowchart 400 shows blocks 410, 412, 414, 416, and 418 occurring in sequence, in an actual implementation, these decisions are made by digital logic and in various embodiments in any suitable order or in parallel with logic circuitry that checks some or all of the conditions shown simultaneously.

FIG. 5 is a flow diagram 500 of another process for managing request credits in a dual channel memory controller. In this embodiment, the process is performed by the credit control circuitry 300 in conjunction with the process of FIG. 4 to provide two different ways in which request credits may be issued to a dual channel memory controller, or a memory controller for two or more memory channels or sub-channels.

At block 502, the process begins in response to a memory access request being deallocated from one of two command queues. At block 504, the process obtains the number of available entries in each command queue. This information is preferably maintained in the credit control circuitry, e.g., queue 0 occupancy logic 304 and queue 1 occupancy logic 306 (FIG. 3). In some embodiments, the process may directly access the command queues at block 504 to obtain or calculate the number of available entries in each command queue. The relevant number is the number after taking into account the deallocated request at block 502.

At block 506, the process checks whether the number of outstanding request credits is less than the minimum number of available entries in the two command queues, and if so, issues additional request credits at block 508. The request credits are preferably loaded into the FIFO queue 316 (FIG. 3) and released to the data fabric as soon as possible. If the number of available entries in the two command queues is equal, the process issues request credits if the number of outstanding request credits is less than the equal number of available entries, and if not (not less), does not issue request credits in response to the memory access request being deallocated. The outstanding credit tracking logic 302 preferably counts additional request credits as outstanding when it is determined that the additional request credits have left the FIFO queue 316 and been received by a receiving memory agent on the data fabric. If at block 506, the number of outstanding request credits is not less than the minimum number of available entries in the two command queues, the process proceeds to block 510 and does not issue request credits in response to the memory access request being deallocated at block 502.

This credit issuance process has the advantage of allowing more efficient use of the two command queues while ensuring that the number of outstanding credits never gets higher than the available entries of the most occupied queue. The data fabric and the requesting memory agents attached to it preferably have no information about whether a particular requested credit is an initial credit or an additional credit, making the credit tracking process transparent to the data fabric. The data fabric can treat a dual channel memory controller as if it were a single controller with a higher throughput capacity than that of a single channel. The capacity of the two command queues and two memory channels is combined in a manner that is transparent to the data fabric while allowing requested credits to be issued more aggressively than if a typical credit management process for a single command queue were used.

The dual channel memory controller 210 of FIG. 2, or any portion thereof, such as the credit management circuit 221 and the address decoder 222, may be described or represented by a computer-accessible data structure in the form of a database or other data structure that may be read by a program and used directly or indirectly to manufacture an integrated circuit. For example, this data structure may be a behavioral 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 that may synthesize the description to generate a netlist that includes a list of gates from a synthesis library. The netlist includes a set of gates that also represent the functionality of the hardware that comprises the integrated circuit. The netlist may then be placed and routed to generate a data set that describes the geometric shapes that are applied to a mask. The mask may then be used in various semiconductor manufacturing processes to manufacture the integrated circuit. Alternatively, the database on the computer-accessible storage medium may be a netlist (with or without a synthesis library) or a data set, or Graphics Data System (GDS) II data, as desired.

While specific embodiments have been described, various modifications to these embodiments will be apparent to those skilled in the art. For example, while a dual channel memory controller is used as an example, the techniques herein may be applied to three or more memory channels to combine their capacities in a manner that is transparent to the data fabric and the host data processing system. For example, three or four memory channels may be controlled using the techniques herein by providing separate command queues and memory channel control circuits for each channel while providing a single interface, address decoder, and credit control circuitry that issues request credits to the data fabric independent of the individual memory channels. Additionally, the internal architecture of the dual channel memory controller 210 may vary in different embodiments. The dual channel memory controller 210 may interface with other types of memory other than DDRx, such as high bandwidth memory (HBM), RAMbus DRAM (RAMbus DRAM, RDRAM), etc. Although the illustrated embodiment shows each rank of memory corresponding to a separate DIMM or SIMM, in other embodiments, each module may support multiple ranks. Still other embodiments may include other types of DRAM modules or DRAM not contained in a specific module, such as DRAM attached to a host motherboard. Accordingly, the appended claims are intended to cover all modifications of the disclosed embodiments that fall within the scope of the disclosed embodiments.

Claims (23)

1. A memory controller, comprising:
an address decoder having a first input for receiving a memory access request, a first output, and a second output;
a first command queue having an input coupled to the first output of the address decoder for receiving memory access requests for a first memory channel, and a number of entries for holding memory access requests;
a second command queue having an input coupled to the second output of the address decoder for receiving memory access requests for a second memory channel, and a number of entries for holding memory access requests;
a request credit control circuit coupled to the first command queue and the second command queue, the request credit control circuit operable to track a number of outstanding request credits and to issue request credits to a data fabric based on a number of available entries in the first command queue and the second command queue.
Memory controller. issuance of a credit request based on a number of available entries in the first command queue and the second command queue includes issuing a credit request when a number of outstanding request credits is less than a minimum number of available entries in the first command queue and the second command queue.
The memory controller of claim 1 . the request credit control circuitry is coupled to a data fabric of the data processing unit and is operable to issue request credits to memory accessing agents via the data fabric;
The memory controller of claim 1 . the request credit control circuitry is operable to issue a request credit without a corresponding deallocation from the first command queue or the second command queue when a memory access request is received that is assigned to a command queue among the first command queue and the second command queue that has a maximum number of available entries.
The memory controller of claim 1 . a first arbiter coupled to the first command queue to select an entry from the first command queue, place the entry in a first memory interface queue, and transmit the entry over the first memory channel;
a second arbiter coupled to the second command queue to select an entry from the second command queue, place the entry in a second memory interface queue, and transmit the entry over the second memory channel.
The memory controller of claim 1 . the address decoder is operable to direct each memory access request to either the first command queue or the second command queue based on a target address of the memory access request.
The memory controller of claim 1 . the first command queue has a different size than the second command queue.
The memory controller of claim 1 . at least one additional command queue; and at least one additional arbiter coupled to the additional command queue;
the request credit control circuitry is operable to issue request credits in response to a memory access request being deallocated from any of the command queues if a number of outstanding request credits is less than a minimum number of entries available among all command queues, and to not issue request credits in response to the memory access request being deallocated otherwise.
The memory controller of claim 1 . 1. A method comprising:
receiving a plurality of memory access requests at a memory controller;
decoding addresses of the memory access requests and selecting one of a first memory channel and a second memory channel for receiving each of the memory access requests;
sending each memory access request after decoding the address to one of a first command queue associated with the first memory channel and a second command queue associated with the second memory channel;
and issuing request credits to a data fabric based on a number of available entries in the first command queue and the second command queue in response to a specified event.
method. issuance of a credit request based on a number of available entries in the first command queue and the second command queue includes issuing a credit request when a number of outstanding request credits is less than a minimum number of available entries in the first command queue and the second command queue.
10. The method of claim 9 . issuing a request credit without a corresponding deallocation from the first command queue or the second command queue when a memory access request is received that is assigned to a command queue among the first command queue and the second command queue that has a maximum number of available entries.
The method of claim 10 . the specified event is a memory access request being deallocated from either the first command queue or the second command queue;
10. The method of claim 9 . selecting an entry from the first command queue using a first arbiter, placing the entry in a first memory interface queue, and transmitting the entry over the first memory channel;
selecting an entry from the second command queue with a second arbiter, placing the entry in a second memory interface queue, and transmitting the entry over the second memory channel.
10. The method of claim 9 . directing each memory access request to either the first command queue or the second command queue based on a target address of the memory access request.
10. The method of claim 9 . 1. A data processing system comprising:
Data Fabric and
a first memory channel and a second memory channel;
a memory controller coupled to the data fabric and to the first and second memory channels to fulfill memory access requests received via the data fabric from at least one memory access engine;
The memory controller includes:
an address decoder having a first input for receiving a memory access request, a first output, and a second output;
a first command queue having an input coupled to the first output of the address decoder for receiving memory access requests for a first memory channel, and a number of entries for holding memory access requests;
a second command queue having an input coupled to the second output of the address decoder for receiving memory access requests for a second memory channel, and a number of entries for holding memory access requests;
a request credit control circuit coupled to the first command queue and the second command queue, the request credit control circuit operable to track a number of outstanding request credits and to issue request credits to the data fabric based on a number of available entries in the first command queue and the second command queue.
Data processing system. issuance of a credit request based on a number of available entries in the first command queue and the second command queue includes issuing a credit request when a number of outstanding request credits is less than a minimum number of available entries in the first command queue and the second command queue.
16. The data processing system of claim 15 . the request credit control circuitry is coupled to the data fabric and is operable to issue request credits to memory accessing agents via the data fabric.
16. The data processing system of claim 15 . the request credit control circuitry is operable to issue a request credit without a corresponding deallocation from the first command queue or the second command queue when a memory access request is received that is assigned to a command queue among the first command queue and the second command queue that has a maximum number of available entries.
16. The data processing system of claim 15 . a queue occupancy circuit operable to calculate a current number of available command entries in each command queue for said request credit control circuit;
16. The data processing system of claim 15 . a first arbiter coupled to the first command queue to select an entry from the first command queue, place the entry in a first memory interface queue, and transmit the entry over the first memory channel;
a second arbiter coupled to the second command queue to select an entry from the second command queue, place the entry in a second memory interface queue, and transmit the entry over the second memory channel.
16. The data processing system of claim 15 . the address decoder is operable to direct each memory access request to either the first command queue or the second command queue based on a target address of the memory access request.
16. The data processing system of claim 15 . the memory access engine is a coherent memory slave controller coupled to the data fabric for executing memory access requests from at least one data processing unit;
16. The data processing system of claim 15 . the memory access engine is a coherent memory master controller coupled to the data fabric for executing memory access requests from at least one data processing unit;
16. The data processing system of claim 15 .

Images