Patent Description:
Patent Publication No. <CIT>describes A hybrid memory controller performs receiving first and second central processing unit (CPU) requests to write to/read from a hybrid memory group, identifying a volatile memory device and a non-volatile memory device as a first target and second target of the first and second CPU requests, respectively, by decoding and address mapping of the first and second CPU requests, queuing the first and second CPU requests in first and second buffers, respectively, generating, based on an arbitration policy, a first command corresponding to one of the first and second CPU requests to an associated one of the first and second targets, and generating a second command corresponding to another one of the first and second CPU requests to an associated another one of the first and second targets, and transmitting the first and second commands to respective ones of the volatile and non-volatile memory devices. Separate command queues are used for nonvolatile and volatile transactions.

Modem DDR memory controllers maintain queues to store pending memory access requests to allow them to pick the pending memory access requests out of order in relation to the order in which they were generated or stored to increase efficiency. To prevent memory access requests being denied because a particular queue is full, the data interface of a 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 allowing them to send memory requests for entry into a command queue. Memory controllers also need to be flexible enough so they can be configured for different memory types, densities, and memory channel topologies, but to do so without requiring a large amount of additional circuit area that would add to chip cost to support these different modes.

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

A memory controller includes 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 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 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 to issue a request credit based on a number of available entries of the first and second command queues.

A method includes receiving a plurality of memory access requests at a memory controller. The addresses of the memory access requests are decoded, and one of a first memory channel and a second memory channel are 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. Responsive to a designated event, the method includes issuing a request credit based on a number of available entries of the first and second command queues.

A data processing system includes a data fabric, first and second memory channels, and a memory controller connected 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 accessing 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 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. 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 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 to issue a request credit based on a number of available entries of the first and second command queues.

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

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

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

Display engines <NUM> render and rasterize objects generated by graphics core <NUM> for display on a monitor. Graphics core <NUM> and display engines <NUM> are bidirectionally connected to a common memory management hub <NUM> through data fabric <NUM> for uniform translation into appropriate addresses in memory system <NUM>.

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

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

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

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

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

Memory management hub <NUM> is an instantiation of a memory controller having two memory channel controllers and uses a shared power engine <NUM> to control operation of both memory channel controller <NUM> and memory channel controller <NUM> in a manner that will be described further below. Each of memory channels <NUM> and <NUM> 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 also provide low power modes to save power for battery-powered applications such as laptop computers, and also provide built-in thermal monitoring.

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

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

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

<FIG> illustrates in block diagram form a partial data processing system <NUM> including a dual-channel memory controller <NUM> that is suitable for use in an APU like that of <FIG>. Depicted is a dual-channel memory controller <NUM> connected to data fabric <NUM>, to which it can communicate with a number of memory agents present in data processing system <NUM> including a coherent slave agent <NUM> and a coherent master agent <NUM>. Dual-channel memory controller <NUM> is capable of replacing the two separate memory channel controllers <NUM> and <NUM> (<FIG>) and controlling two DDRx channels together in a manner transparent to data fabric <NUM> and the various memory addressing agents in data processing system <NUM> such that a single memory controller interface <NUM> can be employed to send memory access commands and receive results. Also, dual channel memory controller <NUM> is capable of controlling two sub-channels as defined, for example, in the DDR5 specification for use with DDR5 DRAMS, or those sub-channels defined in the High Bandwidth Memory <NUM> (HBM2) and HBM3 standards. Dual-channel memory controller <NUM> generally includes interface <NUM>, a credit control circuit <NUM>, an address decoder <NUM>, and two instances of memory channel control circuitry <NUM> each allocated to a different memory channel. Each instance of memory channel control circuitry <NUM> includes a memory interface queue <NUM>, a command queue <NUM>, a content addressable memory (CAM) <NUM>, replay control logic <NUM> including a replay queue <NUM>, a timing block <NUM>, a page table <NUM>, an arbiter <NUM>, an error correction code (ECC) check circuit <NUM>, an ECC generation block <NUM>, a data buffer <NUM>, and refresh control logic <NUM>, including an activate counter <NUM>. In other embodiments, only the command queues <NUM>, arbiters <NUM>, and memory interface queues <NUM> are duplicated for each memory channel or sub-channel used, with the remaining depicted circuitry being adapted for use with two channels. Further, while the depicted dual-channel memory controller includes two instances of an arbiter <NUM>, command queue <NUM>, and memory interface queue <NUM> for controlling two memory channels or sub-channels, other embodiments may include more instances, such as three or four or more, which are employed to communicate with DRAM on three or four channels or sub-channels according to the credit management techniques herein.

Interface <NUM> has a first bidirectional connection to data fabric <NUM> over a communication bus, and a second bidirectional connection to credit control circuit <NUM>. In this embodiment, interface <NUM> employs scalable data port (SDP) links for establishing several channels to communicate with data fabric <NUM>, but other interface link standards are also suitable for use. For example, in another embodiment the communication bus is compatible with the advanced extensible interface version four specified by ARM Holdings, PLC of Cambridge, England, known as "AXI4", but can be other types of interfaces in yet other embodiments. Interface <NUM> translates memory access requests from a first clock domain known as the "FCLK" (or "MEMCLK") domain to a second clock domain internal to dual-channel memory controller <NUM> known as the "UCLK" domain. Similarly, memory interface queue <NUM> provides memory accesses from the UCLK domain to a "DFICLK" domain associated with the DFI interface.

Credit control circuit <NUM> includes a bidirectional communication link to interface <NUM>, which can be shared with address decoder <NUM> or can include dedicated SDP channels for managing request credits. Credit control circuit <NUM> also has inputs connected to both command queues <NUM>, shown in the drawing as those shared with address decoder <NUM>. Credit control circuit <NUM> generally controls request credits allocated to the data fabric for both memory channels. As further described below, the control process performed by credit control circuit <NUM> includes tracking a number of outstanding request credits, and issuing a request credit in response to a memory access request being de-allocated from one of the first and second command queues <NUM> if a number of outstanding request credits is lower than a smallest number of available entries of the first and second command queues <NUM>, and if not, issuing no request credit responsive to the memory access request being de-allocated. Credit control circuit <NUM> also operates to issue a request credit without a corresponding de-allocation from the first or second command queue <NUM> if a memory access request is received that is allocated to one of the first and second command queues <NUM> with a highest number of available entries.

Address decoder <NUM> has a bidirectional link to credit control circuit <NUM>, a first output connected to a first command queue <NUM> (labelled "Command Queue <NUM>"), and a second output connected to a second command queue <NUM> (labelled "Command Queue <NUM>"). Address decoder <NUM> decodes addresses of memory access requests received over data fabric <NUM> through interface <NUM>. The memory access requests include access addresses in the physical address space represented in a normalized format. Based on the access addresses, address decoder <NUM> selects one of the memory channels, with an associated one of command queues <NUM>, to handle the request. The channel selected is identified to credit control circuit <NUM> for each request so that credit issuance decisions may be made. Address decoder <NUM> converts the normalized addresses into a format that can be used to address the actual memory devices in memory system <NUM>, as well as to efficiently schedule related accesses. This format includes a region identifier that associates the memory access request with a particular rank, a row address, a column address, a bank address, and a bank group. On startup, the system BIOS queries the memory devices in memory system <NUM> to determine their size and configuration, and programs a set of configuration registers associated with address decoder <NUM>. Address decoder <NUM> uses the configuration stored in the configuration registers to translate the normalized addresses into the appropriate format. Each memory access request is loaded into the command queue <NUM> for the memory channel selected by address decoder <NUM>.

Each command queue <NUM> is a queue of memory access requests received from the various memory accessing engines in APU <NUM>, such as CPU cores <NUM> and <NUM> and graphics core <NUM>. Each command queue <NUM> is bidirectionally connected to a respective arbiter <NUM> for selecting memory access requests from the command queue <NUM> to be issued over the associated memory channel. Each command queue <NUM> stores the address fields decoded by address decoder <NUM> as well other address information that allows the respective arbiter <NUM> to select memory accesses efficiently, including access type and quality of service (QoS) identifiers. Each CAM <NUM> includes information to enforce ordering rules, such as write after write (WAW) and read after write (RAW) ordering rules.

Arbiters <NUM> are each bidirectionally connected to a respective command queue <NUM> for selecting memory access requests to be fulfilled with appropriate commands. Arbiters <NUM> generally improve efficiency of its respective memory channel by intelligent scheduling of accesses to improve the usage of the memory bus of the memory channel. Each arbiter <NUM> uses a respective timing block <NUM> to enforce proper timing relationships by determining whether certain accesses in the respective command queue <NUM> are eligible for issuance based on DRAM timing parameters. For example, each DRAM has a minimum specified time between activate commands, known as "tRC". Each timing block <NUM> maintains a set of counters that determine eligibility based on this and other timing parameters specified in the JEDEC specification, and is bidirectionally connected to replay queue <NUM>. Each page table <NUM> maintains state information about active pages in each bank and rank of the respective memory channel for arbiter <NUM>, and is bidirectionally connected to its respective replay queue <NUM>. Arbiter <NUM> uses the decoded address information, timing eligibility information indicated by timing block <NUM>, and active page information indicated by page table <NUM> to efficiently schedule memory accesses while observing other criteria such as quality of service (QoS) requirements. For example, arbiter <NUM> implements a preference for accesses to open pages to avoid the overhead of precharge and activation commands required to change memory pages, and hides overhead accesses to one bank by interleaving them with read and write accesses to another bank. In particular during normal operation, arbiter <NUM> normally keeps pages open in different banks until they are required to be precharged prior to selecting a different page. Arbiter <NUM>, in some embodiments, determines eligibility for command selection based on at least on respective values of activate counter <NUM> for target memory regions of the respective commands.

Each error correction code (ECC) generation block <NUM> determine the ECC of write data to be sent to the memory. ECC check circuits <NUM> check the received ECC against the incoming ECC.

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

Each instance of refresh control logic <NUM> includes state machines for various powerdown, refresh, and termination resistance (ZQ) calibration cycles that are generated separately from normal read and write memory access requests received from memory accessing agents. For example, if a memory rank is in precharge powerdown, it must be periodically awakened to run refresh cycles. Refresh control logic <NUM> generates refresh commands periodically and in response to designated conditions to prevent data errors caused by leaking of charge off storage capacitors of memory cells in DRAM chips. Each instance of refresh control logic <NUM> includes an activate counter <NUM>, which in this embodiment has a counter for each memory region which counts a rolling number of activate commands sent over the memory channel to a memory region. The memory regions are memory banks in some embodiments, and memory sub-banks in other embodiments. In addition, refresh control logic <NUM> periodically calibrates ZQ to prevent mismatch in on-die termination resistance due to thermal changes in the system.

In response to write memory access requests received from interface <NUM>, ECC generation blocks <NUM> compute an ECC according to the write data. Data buffers <NUM> store the write data and ECC for received memory access requests. Data buffers <NUM> output the combined write data/ECC to a respective memory interface queue <NUM> when a respective arbiter <NUM> picks the corresponding write access for dispatch to the memory channel.

For embodiments with more than two memory channels or sub-channels, additional command queues, arbiters, and memory interface queues are added in parallel to those depicted, using to a single address decoder <NUM> and credit control circuit <NUM>. Such a design allows the credit control scheme discussed below to be employed with more than two channels or sub-channels, with corresponding efficiencies gained in using queue capacity and channel capacity. As discussed, the entire group of memory channel control circuitry <NUM> may also be reproduced for each channel or sub-channel, or the same logic blocks may be employed with additional capacity added to track the added command queues, arbiters, and memory interface queues.

<FIG> illustrates a block diagram of a credit control circuit <NUM> suitable for implementing credit control circuit <NUM> of <FIG> according to some embodiments. Credit control circuit <NUM> includes outstanding credit tracking logic <NUM>, queue <NUM> occupancy logic <NUM>, queue <NUM> occupancy logic <NUM>, interface logic <NUM>, credit issue logic <NUM>, a request monitor <NUM>, a command queue monitor <NUM>, and a first-in-first-out (FIFO) credit queue <NUM> ("FIFO queue <NUM>"). Outstanding credit tracking logic <NUM> generally maintains a count of request credits that have been issued, issues new request credits, and tracks request credits that are redeemed when an associated memory access request is received at memory controller <NUM>. The request credits are issued to one or more requesting agents on the data fabric, In this embodiment, a request credit is one of two types, initial credits and additional credits which are issued because of the higher capacity provided by the use of two command queues and two channels or sub-channels. The use of additional credits allows credit control circuit <NUM> to issue further credits over the number of initial credits under certain conditions order to more fully and efficiently utilize the capacity of both command queues. The additional credits are tracked by outstanding credit tracking logic in the same way as initial credits, and count toward the total outstanding credits.

Queue <NUM> occupancy logic <NUM> and queue <NUM> occupancy logic <NUM> maintain a count of the number of unallocated entries in the respective command queues. In some embodiments, the count is produced by subtracting the current number of occupied entries for each command queue from the command queue size. In other embodiments, unoccupied entries are tracked directly from the command queue, or indirectly based on tracking the entries that are loaded to each command queue and the entries that are deallocated from each command queue.

Request monitor <NUM> monitors incoming requests that are allocated by address decoder <NUM> to a respective command queue, including which queue receives each request. This information is used by credit issue logic <NUM> in determining when and whether a new request credit is issued. Command queue monitor <NUM> monitors both command queues to determine when requests are de-allocated from the command queue. FIFO queue <NUM> holds additional request credits that are issued when commands are de-allocated from each command queue under certain conditions, as described with respect to <FIG>. These credits are released to the fabric as soon as credit issue logic <NUM> determines this is allowed, as further described below. Credit issue logic <NUM> employs the number of outstanding credits, the queue occupancy of each queue, and the monitored information from request monitor <NUM> and command queue monitor <NUM> to decide when to issue request credits, as further described below with respect to <FIG> and <FIG>. In some versions, the credit control functionality is embodied in monitoring logic circuity inside the memory controller's arbiter (such as arbiter <NUM>, <FIG>). In other versions, the process may be performed by digital logic or a controller having similar functionality while using different methods of arbitration than those employed in sub-arbiters <NUM> and final arbiter <NUM> described above.

<FIG> is a flow diagram <NUM> of a process for managing request credits according to some embodiments. The depicted process is suitable for being performed by a credit control circuit such as credit control circuit <NUM> of <FIG> 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 which tracks outstanding request credits and monitors two or more command queues for a dual-channel memory controller. The process generally works to manage request credits for memory access requests for both memory channels associated with Command Queue <NUM> and Command Queue <NUM>. The request credits are employed by the data fabric independently of which command queue and memory channel may ultimately be selected to receive the associated access requests. That is, the presence of two memory channels or sub-channels managed by the memory controller is transparent to the data fabric and the various memory agents which access the data fabric. For embodiments.

In response to the two memory channels being initialized at block <NUM>, the process at block <NUM> issues initial request credits to the data fabric, which are redeemed for incoming read or write commands. Write commands also require the use of data credits to manage the data buffers <NUM> (<FIG>). Data credits are managed separately than the initial credits and additional credits discussed herein. The number of initial request credits is determined by the size of command queues <NUM>. Preferably, enough initial request credits are release to fill half of the entries in each command queue <NUM>, ensuring that if all credits happen to be redeemed to place commands in single queue, it does not overflow. 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 not equal in size, the size of the smaller command queue is used to determine the number of initial credits, ensuring that the credit process is initialized with an amount of credits that are not greater than the smallest command queue. At this point, the data fabric possesses request credits which may be employed by one or more memory access agents connected to the data fabric to send requests to memory controller <NUM>.

At block <NUM>, the process begins receiving read and write memory access requests, each having an associated request credit. For each received access request, at block <NUM> the credit control circuit redeems an outstanding request credit, for example at outstanding credit tracking logic <NUM> (<FIG>). The access request is also processed by address decoder <NUM> to decode the associated address and select one of the memory channels to receive the memory access requests based on the address. At block <NUM>, the request is allocated to the memory channel by loading it into the command queue for the selected memory channel under control of address decoder <NUM>. Credit control circuit <NUM> monitors the access requests that are loaded into each command queue at block <NUM>.

At block <NUM>, the process determines if one or more additional request credits have already been issued and are pending for release at the credit control circuit FIFO queue <NUM> (<FIG>). The release of additional request credits is further described with respect to <FIG>. If an additional request credit is pending for release, the process goes to block <NUM> where no request credits is released for the current incoming request. If not, the process continues to block <NUM>, where it determines if both command queues are at their maximum occupancy. If so, the process goes to block <NUM>. If not, the process goes to block <NUM>, where the process determines if 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 <NUM>, the process goes to block <NUM>. If not, the process goes to block <NUM>.

At block <NUM>, the process determines if the request allocated to the command queue with a highest number of available entries. If so, the process goes to block <NUM> where it causes a request credit to be issued to the data fabric. Credit issue logic <NUM> (<FIG>), or other suitable digital logic or control circuitry, performs the request credit issuance and updates the outstanding credits. Request credit issuances at block <NUM> are done without a corresponding de-allocation of a command from one of the command queues, which is beneficial in the depicted process because it allows more efficient use of the two command queues. If the access request is not allocated to the command queue with the most available entries at block <NUM>, the process goes to block <NUM> where it issues no request credit responsive to this particular access request being allocated.

Using the depicted process, performance advantages are achieved because each command queue is utilized to a higher capacity by allowing "extra" or additional request credits to be issued when commands are allocated to the less-occupied command queue. Further performance advantages are achieved when the depicted process is employed in combination with a dual-arbiter memory controller architecture such as that depicted in <FIG>, allowing each memory channel to be arbitrated separately while generally operating with a larger number of commands available in the command queue for the arbiter to select than if a more pessimistic approach is used without the queue capacity checking shown in <FIG> and <FIG>.

While flow chart <NUM> depicts blocks <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> occurring in order, in actual implementation these decisions are made by digital logic and, in various embodiments, are made in any suitable order or in parallel with logic circuits checking for the some or all of the depicted conditions simultaneously.

<FIG> is a flow diagram <NUM> of another process for managing request credits at a dual-channel memory controller. In this embodiment, the process is performed by credit control circuit <NUM> along with the process of <FIG> to provide two different ways request credits are issued for a dual-channel memory controller, or a memory controller for two or more memory channels or sub-channels.

At block <NUM>, the process begins responsive to a memory access request being de-allocated from either one of the two command queues. At block <NUM>, the process obtains a number of available entries at each command queue. This information is preferably maintained at the credit control circuit, for example in queue <NUM> occupancy logic <NUM> and queue <NUM> occupancy logic <NUM> (<FIG>). In some embodiments, the process may access the command queue directly at block <NUM> to obtain or calculate the number of available entries in each command queue. The relevant numbers are those after taking into account the de-allocated request at block <NUM>.

At block <NUM>, the process checks if a number of outstanding request credits is lower than a smallest number of available entries of the two command queues and, if so, issues a additional request credit at block <NUM>. This request credit is preferably loaded to FIFO queue <NUM> (<FIG>), and released to the data fabric as soon as possible. Outstanding credit tracking logic <NUM> preferably counts the additional request credit as outstanding when it leaves FIFO queue <NUM> and is confirmed received by the recipient memory agent on the data fabric. If number of outstanding request credits is not lower than a smallest number of available entries of the two command queues at block <NUM>, the process goes to block <NUM> where it issues no request credit responsive to the memory access request being de-allocated at block <NUM>.

This credit issue process has the advantage of allowing more efficient use of two command queues, while ensuring that the number of outstanding credits will not become higher than the available entries of the most occupied queue. The data fabric and the requesting memory agent(s) attached thereto preferably have no information as to whether a particular request credit is an initial credit or an additional credit, making the credit tracking process transparent to the data fabric. The data fabric is able to treat the 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 the two memory channels is combined in a manner transparent to the data fabric, while enabling request credits to be issued more aggressively than they would be if a typical credit management process for a single command queue were employed.

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

Claim 1:
A memory controller (<NUM>), comprising:
an address decoder (<NUM>) having a first input for receiving memory access requests, a first output, and a second output;
a first command queue (<NUM>) having an input coupled to the first output of the address decoder for receiving memory access requests for a first memory channel (<NUM>), and a number of entries for holding memory access requests;
a second command queue (<NUM>) having an input coupled to the second output of the address decoder for receiving memory access requests for a second memory channel (<NUM>), and a number of entries for holding memory access requests; and
a request credit control circuit (<NUM>) 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, characterized in that:
the request credit control circuit (<NUM>) is further operable to issue a request credit based on a number of available entries of the first and second command queues, wherein the request credit control circuit is coupled to a data fabric (<NUM>) of a data processing unit and operable to issue request credits to a memory-accessing agent (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) over the data fabric.