Modulating credit allocations in memory subsystems

This document describes systems and techniques for modulating credit allocations in memory subsystems. The described systems and techniques can provide a feedback mechanism to a credit controller to improve the bandwidth at a memory interface. The memory controller monitors statistics associated with transaction requests served to one or more random access memories (RAMs) of the memory subsystem. The memory controller can then provide suggestions to the credit controller or to the one or more clients to modulate the number of credits allocated to one or more clients. In this way, the described systems and techniques can improve the efficiency of the memory controller in managing the transaction requests and the bandwidth at the memory interface.

This application is a national stage entry of International Application No. PCT/US2020/057293, filed Oct. 26, 2020, the disclosure of which is incorporated herein by reference in its entirety.

BACKGROUND

Memory controllers in systems on chips (SoCs) can include a buffer to temporarily store transactions before sending them to memory. The buffer allows a memory controller to schedule the transactions and maximize the bandwidth of an interface to the memory. To further manage the bandwidth, memory controllers often subdivide the buffer into credits. The SoC can allocate, based on a desired or required quality of service (QoS) for clients accessing the memory, the credits to the clients or different traffic classes of the clients. The number of credits, allocated to a traffic class, however, is generally static and may not maximize the bandwidth at the memory interface based on actual transaction traffic at the memory.

SUMMARY

This document describes systems and techniques for modulating credit allocations in memory subsystems. The described systems and techniques can provide a feedback mechanism to a credit controller or one or more clients of a memory subsystem to improve the bandwidth at a memory interface. The memory controller monitors statistics associated with transaction requests served to one or more random access memories (RAMs) of the memory subsystem. The memory controller can then provide suggestions to the credit controller or the one or more clients to modulate the number of credits allocated to one or more clients with access to the RAMs. In this way, the described systems and techniques can improve the efficiency of the memory controller in managing the transaction requests and the bandwidth at the memory interface.

For example, a memory subsystem of a system on chip (SoC) includes a credit controller and a memory controller. The credit controller allocates a respective number of credits to one or more clients of the memory subsystem. The memory controller is operably connected to one or more RAMs. The memory controller includes a buffer, which can store transaction requests from the clients to access data in the RAMs. The memory controller can monitor, for each client, statistics of the transaction requests served by the memory controller and generate, based on the statistics, a signal to indicate to the credit controller to modulate the respective number of credits allocated to at least one of the clients.

This document also describes other methods, configurations, and systems for modulating credit allocations in memory subsystems.

This Summary is provided to introduce simplified concepts for modulating credit allocations in memory subsystems, which is further described below in the Detailed Description and Drawings. This Summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

DETAILED DESCRIPTION

Overview

This document describes systems and techniques to modulate credit allocations in memory subsystems. Memory controllers in SoCs can subdivide an internal buffer into credits. A credit controller can allocate the credits to different clients or traffic classes of clients. In this way, the memory controller can allocate its buffer and schedule transactions to maximize bandwidth at a memory interface.

Memory subsystems can define a traffic class as a set of memory transactions that require a particular treatment to guarantee a certain quality of service (QoS) or obtain a particular system performance. The SoC or credit controller can allocate a different virtual channel identification (VCID) to each traffic class to simplify the credit allocation.

Existing memory controllers may include a relatively large buffer to improve efficiencies in serving transactions to the memory and improve the bandwidth at the memory interface. These memory subsystems generally statically allocate the number of credits assigned to the clients and traffic classes. Such memory subsystems, however, are not able to dynamically adjust the allocated credits to improve the bandwidth at the memory interface in response to actual memory transactions.

In contrast, the described systems and techniques modulate credit allocations to clients, traffic classes, or VCIDs based on real-time statistics of served transactions. In this way, the described systems and techniques can suggest modulation of the allocated credits. The memory controller can also provide a closed-feedback mechanism to a credit controller, or at least some clients, to enable efficient management and delivery of transaction requests. As a result, the described systems and techniques can increase the bandwidth at the memory interface.

As a non-limiting example, a memory subsystem of an SoC includes a credit controller and a memory controller. The credit controller can allocate a respective number of credits to one or more clients. The memory controller is operably connected to one or more RAMs and the credit controller. The memory controller also includes a buffer that can store transaction requests from the clients to access data in the RAMs. The memory controller can monitor, for each client of the one or more clients, statistics of the transaction requests served by the memory controller. The memory controller can then determine, based on the statistics, whether memory throughput would be increased by increasing or decreasing a respective number of credits allocated to at least one client of the one or more clients. The memory controller can generate, based on a determination that the memory throughput would be increased, an output signal. The output signal can indicate to the credit controller that the respective number of credits allocated to the at least one client should be increased or decreased.

This example is just one illustration of modulating credit allocations in memory subsystems to improve the bandwidth at a memory interface. Other example configurations and methods are described throughout this document. This document now describes additional example methods, configurations, and components for the described modulation of credit allocations in memory subsystems.

Example Devices

FIG.1illustrates an example device diagram100of a user device102in which systems and techniques for modulating credit allocations in a memory subsystem can be implemented. The user device102may include additional components and interfaces omitted fromFIG.1for the sake of clarity.

The user device102can be a variety of consumer electronic devices. As non-limiting examples, the user device102can be a mobile phone102-1, a tablet device102-2, a laptop computer102-3, a desktop computer102-4, a computerized watch102-5, a wearable computer102-6, a video game console102-7, or a voice-assistant system102-8.

The user device102can include one or more radio frequency (RF) transceivers104for communicating over wireless networks. The user device102can tune the RF transceivers104and supporting circuitry (e.g., antennas, front-end modules, amplifiers) to one or more frequency bands defined by various communication standards.

The user device102also includes the SoC106. The SoC106generally integrates several components of the user device102into a single chip, including a central processing unit, memory, and input and output ports. The SoC106can include a single core or multiple cores. In the depicted implementation, the SoC106includes one or more clients108and a memory subsystem110. The SoC106can include other components, including communication units (e.g., modems), input/output controllers, and system interfaces.

The clients108provide transaction requests to read or write data to random access memory (RAM)112of the memory subsystem110. The clients108can include, as non-limiting examples, a display system, a graphics processing unit, a central processing unit, a communication unit, input/output controllers, and system interfaces of the SoC106.

The memory subsystem110includes the RAM112, a memory controller114, and a credit controller116. The RAM112is a suitable storage device (e.g., static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), synchronous dynamic RAM (SDRAM)) to store data accessible by the clients108. In other implementations, the RAM112can be located outside the SoC106.

The memory controller114manages the transaction requests of the clients108to the RAM112. The memory controller114can buffer and serve the transaction requests to the RAM112to increase the bandwidth of the memory subsystem110. In particular, the memory controller can schedule the transaction requests to improve the bandwidth of an interface between the RAM112and the memory controller114. The memory controller114can include hardware, firmware, software, or a combination thereof.

The credit controller116can allocate a portion of the buffer in the memory controller114to the clients108. The allocated portion of the buffer (referred to in this document as “credits”) represents a bandwidth guarantee for the respective clients108at the RAM112. The credit controller116can include hardware, firmware, software, or a combination thereof.

A fabric (not illustrated inFIG.1) is operably connected to the clients108via respective virtual channels. The fabric can forward the transaction requests from the clients108to the memory controller114. In some implementations, the fabric is a multiplexer. The credit controller116can be implemented in the fabric, in any or all of the clients108, as a stand-alone component in the SoC106, or as a stand-alone component outside of the SoC106.

The memory controller114can also monitor statistics related to transactions served to the RAM112. Based on the statistics, the memory controller114can provide feedback to the credit controller116and/or the clients108to potentially modulate (e.g., decrease, increase, maintain) the credits allocated to one or more of the clients108. In this way, the described systems and techniques can dynamically modulate the credit allocations among the clients108and improve the QoS for the clients108.

The user device102also includes computer-readable storage media (CRM)118. The CRM118is a suitable storage device (e.g., random-access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), Flash memory) to store device data of the user device102. The device data can include an operating system, one or more applications, user data, and multimedia data. In other implementations, the CRM118can store the operating system and a subset of the applications, user data, and multimedia data of the SoC106.

The operating system generally manages hardware and software resources of the user device102and provides common services. The operating system and the applications are generally executable by the SoC106to enable communications and user interaction with the user device102, which may require accessing data in the RAM112of the memory subsystem110.

FIG.2illustrates an example device diagram200of the SoC106in which systems and techniques for modulating credit allocations in the memory subsystem110of the SoC106can be implemented. The SoC106and the memory subsystem110can include additional components, which are not illustrated inFIG.2.

The SoC106includes multiple clients108and the memory subsystem110. In the depicted implementation, the clients108include a Client A108-1, a Client B108-2, and a Client C108-3. The SoC106can include fewer or additional clients108. In this example, the clients108are located outside the memory subsystem110. In other implementations, the clients108or a portion of the clients108can be located in the memory subsystem110.

As described above, the clients108can provide transaction requests to read or write data to the RAM112. One or more clients108can provide real-time traffic202and non-real-time traffic204to the memory subsystem110. In this example, the transaction requests of the Client A108-1include the real-time traffic202and the non-real-time traffic204.

The memory subsystem110includes the RAM112, the memory controller114, and the credit controller116. The RAM112includes at least one storage device. In the depicted implementation, the RAM112includes two storage devices: an SDRAM206-1and an SDRAM206-2. The SDRAM206-1and the SDRAM206-2can store data for the clients108or data accessible by the clients108. The SDRAM206-1and the SDRAM206-2are operably connected to the memory controller114.

The memory controller114can include a buffer208, a statistic monitoring module210, and a credit allocation feedback module212. The buffer208temporarily stores transaction requests of the clients108. The buffer208or another component of the memory controller114can also send the transaction requests to the SDRAM206-1and the SDRAM206-2to increase bandwidth at the memory interface.

The statistic monitoring module210can monitor the transaction requests served to the SDRAM206-1and the SDRAM206-2. For example, the statistic monitoring module210can determine statistics on a number of hits (e.g., page hits at the SDRAM206-1or the SDRAM206-2), conflicts (e.g., the SDRAM206-1or the SDRAM206-2closing a page before opening a requested page), allocated bandwidth for the clients108(e.g., the traffic class assigned to the client108serving the transaction request), an efficiency of the transaction requests, and a desired bandwidth. The statistic monitoring module210can be implemented in hardware, digital logic, or a combination thereof in the memory controller114.

The credit allocation feedback module212can provide feedback to the credit controller116or the clients108. The feedback can provide a suggestion to module the credits allocated to one or more clients108. For example, the credit allocation feedback module212can suggest that the credit controller116decreases the number of credits allocated to the Client B108-2. The memory controller114generally does not know the number of credits allocated to a particular traffic class or VCID. As a result, the credit allocation feedback module212can provide, based on the statistics determined by the statistic monitoring module210, the feedback while being agnostic to the credit allocations.

This document describes the operation of the memory subsystem110, specifically the operations of the memory controller114and the credit controller116, in greater detail with respect toFIG.3.

Example Configurations

This section illustrates an example configuration of a hardware-based memory subsystem to module credit allocations, which may occur separately or together in whole or in part. This section describes the example configuration in relation to a drawing for ease of reading.

FIG.3illustrates an example diagram300of the memory subsystem110that can modulate credit allocations. The memory subsystem110can include additional components, which are not illustrated inFIG.3. The memory subsystem110provides a hardware implementation to send feedback, based on statistics gathered by the memory controller114, to upstream clients108or the credit controller116. The feedback can suggest modulation of the number of credits allocated to a particular traffic class or a particular client. The feedback loop is completed by the clients108, or the credit controller116, acting on the feedback and modulating the credit allocation. In this way, the memory controller114can increase the performance of the memory subsystem110.

Similar toFIG.2, the memory subsystem110includes one more RAMs112(e.g., the SDRAM206-1, the SDRAM206-2), the memory controller114, the credit controller116, the fabric312, and one or more clients108(e.g., the Client A108-1, the Client B108-2, the Client C108-3). The clients108are operably connected to the fabric312via internal busses. This document refers to the internal busses as virtual channels302. Each virtual channel302is assigned a unique identification, referred to as a virtual channel identification (VCID) in this document. The fabric312, the credit controller116, or the clients108can assign the VCIDs to a particular traffic class. As described above, a traffic class represents a particular treatment required for transaction requests to satisfy a particular QoS for the client108. For example, real-time traffic202(e.g., from a display client) may require different QoS treatment than non-real-time traffic204.

In the depicted implementation, the Client A108-1is operably connected to the fabric312via the virtual channel302-1. The Client B108-2is operably connected to the fabric312via the virtual channel302-2, and the Client C108-3is operably connected to the fabric312via the virtual channel302-3.

The credit controller116can subdivide the buffer208(not illustrated inFIG.3) of the memory controller114into credits and allocate the credits to different traffic classes to manage the bandwidth available to the different traffic classes. The credits allocated to the different traffic classes, and thus the different VCIDs, translates into a bandwidth guarantee for each VCID at the buffer208of the memory controller114. In other implementations, the credit controller116can allocate credits among the clients108based on a free pool. A free pool allows the credit controller116to dynamically allocate credits to the clients108based on feedback from the memory controller114, a traffic class assignment, a number of free credits available, or a combination thereof.

The fabric312is operably connected to the memory controller114via internal bus304. The fabric312sends memory transactions from the clients108to the memory controller114via the internal bus304. The memory controller114temporarily stores the transaction requests in the buffer208.

The memory controller114is operably connected to the SDRAMs206via internal busses306. In the depicted implementation, the memory controller114is operably connected to the SDRAM206-1and206-2via the internal busses306-1and306-2, respectively. The memory controller114serves the transaction requests to the SDRAMs206via the respective internal busses306. As described with respect toFIG.2, the statistic monitoring module210(not illustrated inFIG.3) monitors statistics of the memory transactions served to the SDRAMs206.

The memory controller114is also operably connected to the credit controller116via a sideband channel308. In some implementations, the memory controller114can also operably connect to one or more clients108via a sideband channel310. In other implementations, the memory controller114can operably connect to the clients108via the sideband channel310but does not operably connect to the credit controller116via the sideband channel308.

Based on the statistics generated by the statistic monitoring module210, the credit allocation feedback module212(not illustrated inFIG.3) can suggest modulating the credit allocation for one or more clients108. In this way, the memory controller114can ensure that the buffer208is maximally efficient. If a particular VCID can achieve the same throughput with a smaller allocation of credits, then the credit controller116or the clients108can allocate the spare credits to a different VCID, traffic class, or client108that would benefit from additional credits.

For example, the memory controller114can send, via the sideband channel308or the sideband channel310, at least one of the suggestion signals listed in Table 1. For example, the suggestion signals r_decrease_credits and w_decrease_credits suggest decreasing the number of credits allocated to one or more of the clients108. In this way, the credit controller116or the clients108can use the suggestion signals to dynamically modulate a maximum occupancy of the buffer208for a particular VCID. In a free pool allocation system, the credit controller116or the clients108take into account the suggestion signals to modulate credit allocations among VCIDs. In modulating the credit allocations, the credit controller116also considers minimum credit allocations, QoS specifications, and urgency-based considerations in modulating the credits allocated to a particular VCID.

TABLE 1Signal nameWidthDescriptionr_decrease_credits[Num_vc-1:0]Suggestion to decrease creditsr_hold_credits[Num_vc-1:0]Suggestion to hold creditsr_increase_credits[Num_vc-1:0]Suggestion to increase creditsw_decrease_credits[Num_vc-1:0]Suggestion to decrease creditsw_hold_credits[Num_vc-1:0]Suggestion to hold creditsw_increase_credits[Num_vc-1:0]Suggestion to increase credits

In operation, the statistic monitoring module210can monitor several metrics to assist the credit allocation feedback module212. In particular, the statistic monitoring module210can determine a disparity metric and an occupancy metric for transaction requests served by the memory controller114for each clock cycle of the memory subsystem110. The transaction requests include the VCID or other data identifying the clients108that served the transaction requests. In this way, the statistic monitoring module210can determine the disparity metric and the occupancy metric for each of the one or more clients108. In other implementations, the statistic monitoring module210can determine and monitor additional metrics. The disparity metric, which represents an efficiency seen by a particular VCID at an interface to the SDRAMs206, is described in greater detail with respect toFIG.4. The occupancy metric, which infers the number of credits allocated to a certain VCID, is described in greater detail with respect toFIG.5.

As depicted inFIG.3, the memory subsystem110can implement the management and modulation of credit allocations in hardware. In other implementations, the credit management and re-balancing can be implemented at the kernel level or a driver level.

FIG.4illustrates an example chart400illustrating the disparity metric monitored by the statistic monitoring module210of the memory controller114. In this implementation, the statistic monitoring module210monitors the disparity metric for a particular VCID of the memory subsystem110.

The disparity metric represents an efficiency for a VCID at the interface to one or both of the SDRAMs206. As an example, a VCID with transaction requests that result in a relatively large proportion of hits will have greater efficiency than a VCID with more random transaction requests leading to a higher proportion of conflicts. In this document, a hit refers to a page hit at the SDRAMs206. A page hit can occur when a required page (e.g., row) of the SDRAM206for the transaction request is already open. A miss refers to a transaction request for a page that is closed at the SDRAM206. A conflict refers to an SDRAM206having a different page open than required for a transaction request, resulting in the open page being closed.

A transaction request at the SDRAMs206generally results in a particular sequence of commands. For example, a read (RD) or write (WR) command first involves sending an activation (ACT) command. The ACT command loads an entire page of the SDRAM206into the row buffer. A subsequent RD command addressing a column of that page returns the data. Similarly, a subsequent WR command addressing that page writes the data in the transaction request into the addressed column. After access of that page is complete, the SDRAM206closes the page by issuing a precharge (PRE) command. In general, a transaction request to the SDRAMs206can involve opening, accessing, and closing pages. If the transaction request addresses a page or row buffer that is not currently open, the transaction request incurs an additional penalty of closing the already open page.

The memory controller114tries to maximize the bandwidth at the interface to the SDRAMs206while also simultaneously satisfying the QoS parameters for the transaction requests. These two requirements can cause the memory controller114to serve the transaction requests out of order. The client108, traffic class, or VCID that sends transaction requests that result in a series of hits will have lower latency than one that experiences many conflicts. As a result, the credit allocation feedback module212can use statistics on hits, conflicts, allocated bandwidth, and desired bandwidth to define performance metrics. The credit allocation feedback module212can then use the performance metrics to suggest modulating the credits allocated to different clients108, traffic classes, or VCIDs to improve system performance.

The statistic monitoring module210can define the disparity metric for a particular VCID as the sum of hits minus the sum of conflicts:
Disparity[VCi]=Σhits−Σconflicts  (1)

The disparity metric can be an 8-bit unsigned value with some initial offset value (e.g., 32). Each time a transaction request receives a grant in a request scheduler of the memory controller114, the statistic monitoring module210updates the number of hits and conflicts belonging to that VCID in the next clock cycle and updates the disparity value. In this way, the statistic monitoring module210can determine an efficiency associated with a particular VCID using counters while avoiding a need to use division or multiplication to generate the disparity metric. The statistic monitoring module210generally does not consider misses because each conflict eventually leads to a miss. In another implementation, the statistic monitoring module210can define the disparity metric in terms of misses instead of conflicts. The statistic monitoring module210can also saturate the disparity metric at a maximum value414(e.g.,255) and a minimum value416(e.g.,0) to avoid the disparity value rolling over (e.g., to avoid an integer overflow or underflow, which can cause an error in the value of the disparity metric).

The chart400illustrates an example disparity value402generated by the statistic monitoring module210for Client A108-1for time windows404,406,408,410, and412. At the beginning of the time window404, the disparity value402for the Client A108-1starts at an initial offset value of 32. During the time window404, the memory controller114does not serve any transaction requests for the Client A108-1, and the disparity value402remains at a value of 32.

During the time window406, the memory controller114serves transaction requests that result in page hits, and the disparity value402has a positive slope. The disparity value402saturates at the maximum value414after a certain number of page hits.

During the time window408, the statistic monitoring module210includes a decay factor that slowly brings the disparity value402back to the initial offset value when there are no transaction requests for that VCID. In this way, the statistic monitoring module210can avoid the hit rate of an old transaction-request thread from affecting the feedback signal for a current transaction-request thread.

During the time window410, the disparity value402oscillates around the initial offset value by going below as well as above the initial offset value. The oscillation of the disparity value402can result from a series of transaction requests resulting in a conflict and then in a page hit. Consider after a transaction request is sent and results in a conflict, the same transaction request becomes a page hit and results in a positive score that offsets the negative score. During the time window412, the memory controller114does not serve any transaction requests for the VCID, and the disparity value402remains at the initial offset value.

In response to a low disparity value402, the credit allocation feedback module212does not necessarily suggest decreasing the credit allocation to a particular VCID. The VCID may have been assigned a small number of credits and expected a small bandwidth at the memory controller114. As a result, relatively low efficiency or bandwidth at the interface to the SDRAM206is expected and does not trigger a suggestion to decrease the credits allocated to that VCID. To this end, the credit allocation feedback module212uses the occupancy metric, which is described with respect toFIG.5, along with the disparity metric, to generate the credit-allocation feedback.

FIG.5illustrates an example chart502illustrating credits504allocated to a client108based on an occupancy metric and the disparity metric and an example chart518illustrating a feedback signal520from the memory controller114. In this implementation, the statistic monitoring module210monitors the occupancy metric for a particular VCID of the memory subsystem110.

As described above, the occupancy metric represents an inference by the statistics monitoring module210of the number of credits504allocated to a VCID. Because the allocation of credits is managed by the credit controller116and/or the one or more clients108, the memory controller114does not have direct knowledge of the number of credits504allocated to a particular VCID. The statistics monitoring module210can use the number of entries in the buffer208used by a particular VCID to infer the credits504allocated to the VCID. In other words, the occupancy metric for a particular virtual channel is the number of buffer entries used by that virtual channel.

The credit allocation feedback module212can determine the feedback signal520for each VCID based on the occupancy metric and the disparity metric collected by the statistics monitoring module210as follows:
K×Occupancy[VCi]—Disparity[VCi]>Threshold[VCi],  (2)
where K is a constant scaling factor to get both the occupancy metric and the disparity metric within the same range. If the preceding is true, then the credit allocation feedback module212suggests that the credits504allocated to the VCID be decreased. The credit controller116and/or the client108can use the feedback signal520to perform a successive approximation of a maximum number of credits504to allocate to the VCID.

As an example, the chart502illustrates the credits504allocated to a particular client108(e.g., Client B108-2). The chart518illustrates the feedback signal520provided by the credit allocation feedback module212to the credit controller116about suggestions for modulating the credits504allocated to the Client B108-2. During the time window510, the credit controller116allocated a maximum number of credits506(e.g., 12 credits) to the Client B108-2. The credit allocation feedback module212sends a hold suggestion to the credit controller116for the Client B108-2during the time window510.

In the time window512, the statistics monitoring module210determines that the occupancy metric for the VCID associated with the Client B108-2is more than a threshold value larger than the disparity metric for this VCID. In response, the credit allocation feedback module212sends a r_decrease_credits signal to the memory controller114. When the credit controller116sees the decrease suggestion for a T number of clock cycles522, the credit controller116can modulate the number of credits504allocated to the Client B108-2downward by a number of credits towards a minimum number of credits508. The decrease in the number of credits504allocated to the Client B108-2can continue until the feedback signal520no longer includes a r_decrease_credits suggestion. The number of credits504allocated to the Client B108-2generally will not drop below the minimum number of credits508.

During the time windows514and516, the feedback signal520no longer includes a r_decrease_credits suggestion for the T number of clock cycles522, and the number of credits504allocated to the Client B108-2is increased back towards the maximum number of credits506.

The credit controller116can allocate the credits taken away from the Client B108-2to a different client or to a free pool of credits. In this way, the memory subsystem110can efficiently utilize the buffer208of the memory controller114by modulating the credits allocated to different VCIDs. In addition, the credit controller generally tries to allocate the maximum number of credits506to the clients108in an absence of a decrease-credits suggestion from the memory controller114.

Example Methods

FIG.6is a flowchart illustrating example operations600of modulating credit allocations in memory subsystems. The operations600are described in the context of the memory subsystem110ofFIGS.1and2. The operations600may be performed in a different order or with additional or fewer operations.

At602, a respective number of credits are allocated by a credit controller to one or more clients. For example, the credit controller116can allocate a respective number of credits to the one or more clients108.

At604, transaction requests from the one or more clients to access data in one or more RAMs are stored by a memory controller. The memory controller is operably connected to the one or more RAMs and the credit controller. For example, the memory controller114is operably connected to the one or more RAMs112(e.g., the SDRAM206-1, the SDRAM206-2) and the credit controller116. The memory controller114includes the buffer208to store transaction requests, from the one or more clients108, to access data in the one or more RAMs112.

At606, statistics for transaction requests served to the one or more RAMs are monitored by the memory controller for each client of the one or more clients. For example, the memory controller114can monitor, for each client108of the one or more clients108, statistics for transaction requests served to the one or more RAMs112.

At608, the memory controller determines, based on the statistics, whether memory throughput would be increased by increasing or decreasing the respective number of credits allocated to at least one client of the one or more clients. For example, the memory controller114can determine, based on the statistics, whether memory throughput would be increased by increasing or decreasing the respective number of credits allocated to at least one client108of the one or more clients108.

At610, an output signal is generated by the memory controller to indicate that the respective number of credits should be increased or decreased. The output signal is based on a determination that the memory throughput would be increased. The output signal is sent by the memory controller to the credit controller. For example, the memory controller114can generate an output signal to indicate that the respective number of credits should be increased or decreased. The output signal is based on a determination that the memory throughput to the RAMs112would be increased. The memory controller114can send, via the side channel308, the output signal to the credit controller116. The memory controller114can also send the output signal directly to the at least one of the one or more clients108.

At612, the respective number of credit allocated to the at least one client of the one or more clients is modulated by the credit controller and based on the output signal. For example, the credit controller116can modulate, based on the output signal, the respective number of credits allocated to the at least one client108of the one or more clients108.

Examples

In the following section, examples are provided.

Example 1: A memory subsystem of a system on chip (SoC) comprising: a memory controller operably connected to a credit controller, the memory controller comprising a buffer configured to store transaction requests, from one or more clients, to access data in one or more RAMs, the memory controller configured to: monitor, for each client of the one or more clients, statistics of the transaction requests served by the memory controller; determine, based on the statistics, whether memory throughput would be increased by increasing or decreasing a respective number of credits allocated to at least one client of the one or more clients; and generate, based on a determination that the memory throughput would be increased, an output signal, the output signal configured to indicate to a credit controller that the respective number of credits allocated to the at least one client of the one or more clients should be increased or decreased.

Example 2: The memory subsystem of example 1, wherein: the credit controller is operably connected to the one or more clients via respective virtual channels, the virtual channels associated with a respective virtual channel identification (VCID); and the memory controller is further configured to associate the statistics for each client to the respective VCID.

Example 3: The memory subsystem of any preceding example, wherein: the memory controller is further configured to send the suggestion to the credit controller via a side channel.

Example 4: The memory subsystem of any preceding example, wherein the statistics comprise at least two of a number of page hits in the one or more RAMs, a number of conflicts that require closing a page of the one or more RAMs before another page can be opened, or an inference of the respective number of credits allocated to the client.

Example 5: The memory subsystem of example 4, wherein the memory controller is further configured to: define, for each client of the one or more clients, a disparity metric that represents the number of page hits minus the number of conflicts; and define, for each client of the one or more clients, an occupancy metric that represents the inference of the respective number of credits allocated to the client, wherein the suggestion to modulate the respective number of credits allocated to the at least one client of the one or more clients is based on a comparison of the occupancy metric to the disparity metric for each client of the one or more clients.

Example 6: The memory subsystem of example 5, wherein the disparity metric comprises: a maximum threshold that represents a maximum value for the disparity metric; and a default threshold that represents an initial offset value for the disparity metric.

Example 7: The memory subsystem of example 6, wherein the disparity metric further comprises a decay factor that causes the disparity metric to regress to the default threshold after a time period without any transaction requests.

Example 8: The memory subsystem of any of examples 4 through 7, wherein the memory controller determines the occupancy metric based on a number of entries in the buffer used by each client of the one or more clients.

Example 9: The memory subsystem of any preceding example, wherein the one or more RAMs comprise low-power double data rate synchronous dynamic random access memories (LPDDR SDRAMs).

Example 10: The memory subsystem of any preceding example, wherein the memory controller comprises an application-specific integrated circuit (ASIC) memory controller.

Example 11: The memory subsystem of any preceding example, wherein the SoC is embedded in a user device.

Example 12: The memory subsystem of example 11, wherein the user device is a mobile phone, a laptop, a tablet, a portable video game console, or a wearable device.

Example 13: A credit controller, the credit controller configured to: allocate a respective number of credits to one or more clients of a memory subsystem of a system on chip (SoC), the one or more clients configured to send transaction requests to access data in one or more RAMs; receive, from the memory controller and based on statistics monitored by the memory controller, a signal indicating that the respective number of credits allocated to the one or more clients should be increased or decreased; and dynamically change, based on the signal, the respective number of credits allocated to the one or more clients.

Example 14: The credit controller of example 13, wherein: the credit controller is operably connected to the one or more clients via respective virtual channels, the virtual channels associated with a respective virtual channel identification (VCID); and the statistics monitored by the memory controller for each client of the one or more clients are associated to the respective VCID.

Example 15: The credit controller of any of examples 13 and 14, wherein the credit controller receives the suggestion, from the memory controller, via a side channel.

Example 16: A client of a system on chip (SoC), the client configured to: send, to a memory controller of a memory subsystem of the SoC, a transaction request to access data in one or more RAMs; receive, from the memory controller and based on statistics monitored by the memory controller, a signal indicating that the a number of credits allocated to the client should be increased or decreased; and dynamically change, based on the signal, the number of credits used for future transaction requests.

CONCLUSION

While various configurations and methods for modulating credit allocations in memory subsystems have been described in language specific to features and/or methods, it is to be understood that the subject of the appended claims is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as non-limiting examples of modulating credit allocations in memory subsystems.