Credit Scheme for Multi-Queue Memory Controllers - Patent application
A dual channel memory controller with an address decoder, command queues, and a request credit control circuit addresses the inefficiencies in managing memory access requests across multiple DDR channels, achieving enhanced memory access efficiency and flexibility without increasing chip costs.
Patent Information
- Application Number
- JP2023559128
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2021-03-31
- Filing Date
- 2022-03-21
- Publication Date
- 2025-04-07
- Estimated Expiration
- 2042-03-21
AI Technical Summary
Existing DDR memory controllers face challenges in efficiently managing memory access requests across multiple channels while maintaining flexibility to support different memory types, densities, and topologies without increasing chip costs.
The implementation of a dual channel memory controller with an address decoder, two command queues, and a request credit control circuit, which tracks outstanding request credits and issues them based on available entries in the command queues, allowing for efficient memory access management across two DDR channels.
This solution enhances memory access efficiency by allowing for more aggressive issuance of request credits, thereby maximizing the utilization of command queues and memory channels, while maintaining transparency to the data fabric and host system.
Smart Images

Figure 0007657963000001 
Figure 0007657963000002 
Figure 0007657963000003
Abstract
Description
[Background technology]
[0001] 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 circuitry 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.
[0002] Modern DDR memory controllers maintain queues for storing pending memory access requests and allow the pending memory access requests 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 data interface of the memory controller 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, to enable the host system to submit memory requests for entry into the command queue. Also, the memory controller 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. [Brief description of the drawings]
[0003] [Figure 1] 1 is a block diagram of an accelerated processing unit (APU) and memory system known in the prior art. [Diagram 2] 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 , in accordance with some embodiments. [Diagram 3] 3 is a block diagram of a credit control circuit suitable for implementing the credit control circuit of FIG. 2 according to some embodiments. [Figure 4] FIG. 11 is a flow diagram of a process for managing request credits, according to some embodiments. [Diagram 5] FIG. 11 is a flow diagram of another process for managing request credits in a dual channel memory controller. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0004] 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.
[0005] 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 a 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 a 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 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.
[0006] The method includes receiving a plurality of memory access requests at a memory controller, where 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 designated event, the method includes issuing request credits based on a number of available entries in the first command queue and the second command queue.
[0007] The data processing system includes a data fabric, first and second memory channels, and a memory controller coupled to the data fabric and the first and second memory channels for fulfilling 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 coupled 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 the memory access requests. The second command queue has an input coupled 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 the memory access requests. The request credit control circuit is coupled 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 a number of available entries in the first command queue and the second command queue.
[0008] 1 is a block diagram of an accelerated processing unit (APU) 100 and memory system 130 known in the prior art. 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.
[0009] CPU core complex 110 includes CPU core 112 and CPU core 114. In this example, CPU core complex 110 includes two CPU cores, but in other embodiments, CPU core complex 110 may include any number of CPU cores. Each of CPU cores 112 and 114 is bidirectionally connected to a system management network (SMN) that forms a control fabric and to data fabric 125, and may provide memory access requests to data fabric 125. Each of 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.
[0010] Graphics core 120 is a high-performance graphics processing unit (GPU) capable of performing graphics operations such as vertex processing, fragment processing, shading, texture blending, etc., in a highly integrated and parallel manner. Graphics core 120 is bidirectionally connected to the SMN and data fabric 125 and can provide memory access requests to data fabric 125. In this regard, APU 100 can support either a unified memory architecture in which CPU core complex 110 and graphics core 120 share the same memory space, or a memory architecture in which CPU core complex 110 and graphics core 120 share a portion of the memory space, but graphics core 120 also uses private graphics memory that is not accessible by CPU core complex 110.
[0011] A 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 a data fabric 125 for uniform translation to appropriate addresses in the memory system 130.
[0012] Data fabric 125 includes a crossbar switch for routing memory access requests and responses between any memory accessing agent and memory management hub 140. The data fabric also includes a system memory map defined by the basic input / output system (BIOS) as well as buffers for each virtual connection to determine where to send memory accesses based on the system configuration.
[0013] 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 the SMN bus. These two controllers are merely exemplary of peripheral controllers that may be used with APU 100.
[0014] 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. I / O hub 176 is also bidirectionally connected to system hub 166 and data fabric 125. Thus, for example, a CPU core can program registers in USB controller 162, SATA interface controller 164, SB 172, or PCIe controller 174, with accesses routed by data fabric 125 through 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 the PCIe bus, and the system data drives are accessed via the SATA interface.
[0015] 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.
[0016] Memory management hub 140 and its associated physical interfaces (PHYs) 151 and 152 are integrated with APU 100 in this embodiment. Memory management hub 140 includes memory channels 141 and 142 and power engine 149. Memory channel 141 includes host interface 145, memory channel controller 143, and physical interface 147. Host interface 145 bidirectionally connects memory channel controller 143 to data fabric 125 via a serial presence detect link (SDP). Physical interface 147 bidirectionally connects memory channel controller 143 to PHY 151 and conforms to the DDR PHY Interface (DFI) specification. Memory channel 142 includes host interface 146, memory channel controller 144, and 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 complies with 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.
[0017] 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 described further 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.
[0018] 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, which in this example correspond to individual ranks. Similarly, memory channel 133 includes a set of DIMMs connected to DDRx bus 129, including representative DIMMs 135, 137, and 139.
[0019] The APU 100 acts as the central processing unit (CPU) of the host data processing system and provides a variety of buses and interfaces useful in modern computer systems, including 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.
[0020] The APU 100 also implements various system monitoring and power saving functions. One system monitoring function in particular is thermal monitoring. For example, if the APU 100 gets too hot, the SMU 180 can reduce the frequency and voltage of the CPU cores 112, 114 and / or the graphics core 120. If the APU 100 gets too hot, the SMU can be shut down completely. Thermal events can also be received from external sensors by the SMU 180 via the SMN bus, and the SMU 180 can reduce the clock frequency and / or power supply voltage accordingly.
[0021] 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. Dual channel memory controller 210 is shown connected to data fabric 125 and can communicate with several memory agents present in data processing system 200, including coherent slave agent 250 and coherent master agent 260. 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 transparent to various memory addressing agents in data fabric 125 and data processing system 200, such that a single memory controller interface 212 can be used to send memory access commands and receive results. Dual channel memory controller 210 can also control two sub-channels, such as those defined in the DDR5 specification for use with DDR5 DRAM, or those sub-channels defined in the High Bandwidth Memory 2 (HBM2) and HBM3 standards. The dual channel memory controller 210 generally includes an interface 212, a credit control circuit 221, an address decoder 222, and two instances of a memory channel control circuit 223, each assigned to a different memory channel. Each instance of the memory channel control circuit 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 command queue 230, arbiter 238, and memory interface queue 214 are replicated for each memory channel or sub-channel used, with the remaining illustrated circuitry adapted for use with two channels. Additionally, while 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.
[0022] Interface 212 has a first bidirectional connection to data fabric 125 via a communication bus and a second bidirectional connection to credit control circuitry 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 Extensible Interface version 4 specified by ARM Holdings, PLC of Cambridge, UK, known as "AXI4," although other types of interfaces are possible 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.
[0023] Credit control circuitry 221 includes a bidirectional communication link to interface 212, which may be shared with address decoder 222 or may include a dedicated SDP channel for managing request credits. Credit control circuitry 221 also has inputs connected to both command queues 220 and is shown in the figures as being shared with address decoder 222. Credit control circuitry 221 generally controls request credits allocated to the data fabric for both memory channels. As described further below, the control process performed by credit control circuitry 221 includes tracking the number of outstanding request credits, issuing request credits in response to a memory access request being deallocated from either of first and second command queues 220 if the number of outstanding request credits is less than the minimum number of available entries in first and second command queues 220, and not issuing request credits 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 having the maximum number of available entries.
[0024] 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 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 having an associated one of command queues 220 to process the request. The selected channel is identified to credit control circuit 221 on a per-request basis 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 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.
[0025] 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 over an 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 types and quality of service (QoS) identifiers. Each CAM 224 contains information for enforcing ordering rules, such as write after write (WAW) and read after write (RAW) ordering rules.
[0026] 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 utilization of the memory channel's memory bus. Each arbiter 238 uses a respective timing block 234 to enforce the appropriate timing relationships by determining whether a particular access in a respective command queue 220 is eligible for issue based on DRAM timing parameters. For example, each DRAM may have a "t RCEach timing block 234 maintains a set of counters that determine eligibility based on this and other timing parameters defined in the JEDEC specification, and is bidirectionally connected to the replay queue 230. Each page table 236 maintains state information about active pages in each bank and rank of the respective memory channel for an 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 to avoid the overhead of precharge and activate 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, the arbiter 238 typically keeps pages open in different banks until they need to be precharged before selecting a different page. The arbiter 238, in some embodiments, determines eligibility for command selection based on at least the respective values of the activation counters 248 for the target memory regions of each command.
[0027] Each error correction code (ECC) generation block 244 determines the ECC of the write data sent to the memory. An ECC check circuit 242 checks the received ECC against the incoming ECC.
[0028] 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. Replayed commands are placed in memory interface queue 214.
[0029] 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 a 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.
[0030] 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 the 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.
[0031] 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 circuit 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.
[0032] 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 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 circuit 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.
[0033] 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.
[0034] The request monitor 312 monitors the 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 a new request credit should be issued. The command queue monitor 314 monitors both command queues to determine when a request is deallocated from the command queue. The FIFO queue 316 holds additional request credits that are issued when a command is 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 a request credit, 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-arbiters 305 and final arbiter 350 discussed above.
[0035] FIG. 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.
[0036] 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 data buffer 246 (FIG. 2). Data credits are managed separately from the initial credits and additional credits described herein. The number of initial request credits is determined by the size of 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 memory controller 210.
[0037] 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 validates the outstanding request credit, e.g., in outstanding credit tracking logic 302 (FIG. 3). The access request is also processed by 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 control of address decoder 222. Credit control circuitry 300 monitors the access requests that are loaded into each command queue at block 410.
[0038] 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 at block 416 the outstanding request credits are at a maximum value, the process proceeds to block 420. If not, the process proceeds to block 418.
[0039] At block 418, the process determines whether the request was 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 is not 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.
[0040] Using the illustrated process, a performance advantage is achieved because 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 Figure 2, a further performance advantage is achieved because 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 when using the more pessimistic approach without queue capacity checks shown in Figures 4 and 5.
[0041] 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.
[0042] Figure 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 credit control circuit 300 in conjunction with the process of Figure 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.
[0043] 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 circuits, 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.
[0044] 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 an additional request credit at block 508. This request credit is preferably loaded into the FIFO queue 316 (FIG. 3) and released to the data fabric as soon as possible. If the two command queues have an equal number of available entries, the process issues a request credit if the number of outstanding request credits is less than the equal number of available entries, and does not issue a request credit in response to a memory access request being deallocated if not (if not less).The outstanding credit tracking logic 302 preferably counts additional request credits as outstanding when the additional request credits are confirmed to 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.
[0045] 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 rises 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.
[0046] 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, the 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.
[0047] 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 more than two 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), and the like. While 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 that are not included in a particular module, such as DRAM installed on a host motherboard. It is therefore intended that the appended claims cover all modifications of the disclosed embodiments that fall within the scope of the disclosed embodiments.
Claims
1. 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.
2. 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 .
3. 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 .
4. 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 .
5. 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 .
6. 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 .
7. the first command queue has a different size than the second command queue. The memory controller of claim 1 .
8. 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 .
9. 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.
10. 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.
11. 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.
12. 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.
13. 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.
14. 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.
15. 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.
16. 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.
17. 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.
18. 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.
19. 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.
20. 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.
21. 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.
22. 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.
23. 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.
Citation Information
Patent Citations
Data storage device, memory control device and method
JP2013137624A
Memory controller with flexible address decoding
JP2019520660A
Storage device flow control
US20050257022A1
Memory access control
US20140317360A1
System and Method for Communication Link Management in a Credit-Based System
US20200004700A1