Adjusting Credit Allocation in a Memory Subsystem

Abstract

This document describes systems and techniques for regulating credit allocation in a memory subsystem. The described systems and techniques can provide a feedback mechanism to a credit controller (116) for bandwidth at a memory interface. A memory controller (114) monitors statistics associated with transaction requests provided to one or more random access memories (RAMs) (206-1, 206-2) of the memory subsystem. The memory controller (114) can then provide recommendations to the credit controller (116) or to one or more clients (108-1, 108-2, 108-3) to regulate the number of credits allocated to the one or more clients (108-1, 108-2, 108-3). In this way, the described systems and techniques can improve the efficiency of the memory controller (114) in managing transaction requests and the bandwidth at the memory interface.

Description

Background Art

[0001] Memory controllers in a system-on-chip (SoC) can include buffers for temporarily storing transactions before sending the transactions to memory. The buffers allow the memory controller to schedule transactions and maximize the bandwidth to the memory interface. To further manage bandwidth, the memory controller typically subdivides the buffer into credits. The SoC can assign credits to clients or different traffic classes of clients based on the desired or required quality of service (QoS) of the clients accessing the memory. However, the number of credits assigned to a traffic class is static and cannot maximize the bandwidth at the memory interface based on the actual transaction traffic at the memory. Summary of the Invention

[0002] This document describes systems and techniques for adjusting credit allocation in a memory subsystem. The described systems and techniques can provide a feedback mechanism to a credit controller or one or more clients of the memory subsystem to increase the bandwidth at the memory interface. The memory controller monitors statistics associated with transaction requests provided to one or more random access memories (RAMs) of the memory subsystem. The memory controller can then provide advice to the credit controller or one or more clients to adjust the number of credits allocated to one or more clients accessing the RAM. In this way, the described systems and techniques can increase the efficiency of the memory controller in managing transaction requests and the bandwidth at the memory interface.

[0003] For example, a memory subsystem of a system-on-chip (SoC) includes a credit controller and a memory controller. The credit controller assigns a corresponding number of credits to one or more clients of the memory subsystem. The memory controller is operatively connected to one or more RAMs. The memory controller includes a buffer that can store transaction requests from the clients to access data in the RAM. The memory controller can monitor statistics of the transaction requests serviced by the memory controller for each client and generate a signal based on the statistics to instruct the credit controller to adjust the corresponding number of credits assigned to at least one of the clients.

[0004] This document also describes other methods, configurations, and systems for adjusting credit allocation in a memory subsystem.

[0005] The Summary of the Invention is provided to introduce a simplified concept for adjusting credit allocation in a memory subsystem, which will be further described in the following Detailed Description and Drawings. The Summary of the Invention is not intended to identify the essential features of the claimed subject matter nor to be used to determine the scope of the claimed subject matter. Brief Description of the Drawings

[0006] Details of one or more aspects of adjusting credit allocation in a memory subsystem are described in this document with reference to the following figures. The same numbers are used throughout the figures to refer to like features and components.

[0007] Figure 1 An example device diagram of a user equipment in which systems and techniques for adjusting credit allocation in a memory subsystem can be implemented is shown.

[0008] Figure 2 An example device diagram of a system-on-chip (SoC) in which systems and techniques for adjusting credit allocation in the memory subsystem of the SoC can be implemented is shown.

[0009] Figure 3 An example diagram of a memory subsystem that can adjust credit allocation is shown.

[0010] Figure 4 An example diagram is shown that depicts a difference metric monitored by a statistical monitoring module of a memory controller.

[0011] Figure 5 An example diagram is shown that depicts credits allocated to clients based on occupancy metrics and difference metrics, as well as an example diagram that depicts a feedback signal from the memory controller.

[0012] Figure 6 A flowchart depicting an example operation of adjusting credit allocation in a memory subsystem is shown. Detailed Description

[0013] This document describes systems and techniques for adjusting credit allocation in a memory subsystem. A memory controller in a system-on-chip (SoC) can subdivide an internal buffer into credits. A credit controller can allocate the credits to different clients or classes of client traffic. In this way, the memory controller can allocate the buffer of the memory controller and schedule transactions to maximize the bandwidth at the memory interface.

[0014] The memory subsystem can define a class of traffic as a set of memory transactions that require specific handling to guarantee a specific quality of service (QoS) or achieve a specific system performance. The SoC or the credit controller can assign a different virtual channel identifier (VCID) to each class of traffic to simplify credit allocation.

[0015] Existing memory controllers can include relatively large buffers to improve the efficiency of servicing transactions to memory and to increase the bandwidth at the memory interface. These memory subsystems typically statically allocate: the number of credits assigned to clients and classes of traffic. However, such memory subsystems cannot dynamically adjust the allocated credits in response to actual memory transactions to increase the bandwidth at the memory interface.

[0016] In contrast, the described systems and techniques adjust credit allocation to a client, business category, or VCID based on real-time statistics of service-based transactions. In this way, the described systems and techniques can recommend an adjustment to the allocated credit. The memory controller can also provide a closed feedback mechanism to the credit controller or at least some clients to enable effective management and delivery of transaction requests. As a result, the described systems and techniques can increase the bandwidth at the memory interface.

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

[0018] This example is merely illustrative of adjusting credit allocation in a memory subsystem to increase the bandwidth at the 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 adjustment of credit allocation in a memory subsystem.

[0019] Example Device

[0020] Figure 1 Example device diagram 100 of a user device 102 is shown in which the systems and techniques for adjusting credit allocation in a memory subsystem can be implemented. For clarity, user device 102 can include additional components and interfaces that are omitted from Figure 1 herein.

[0021] User device 102 can be various consumer electronic devices. As a non-limiting example, user device 102 can be a mobile phone 102-1, a tablet device 102-2, a laptop computer 102-3, a desktop computer 102-4, a computerized watch 102-5, a wearable computer 102-6, a video game console 102-7, or a voice assistant system 102-8.

[0022] User equipment 102 may include one or more radio frequency (RF) transceivers 104 for communicating over a wireless network. User equipment 102 may tune the RF transceivers 104 and supporting circuitry (e.g., antennas, front-end modules, amplifiers) to one or more frequency bands defined by various communication standards.

[0023] User equipment 102 also includes a System on Chip (SoC) 106. The SoC 106 generally integrates several components of the user equipment 102 into a single chip, including a central processing unit, memory, and input and output ports. The SoC 106 may include a single core or multiple cores. In the depicted implementation, the SoC 106 includes one or more clients 108 and a memory subsystem 110. The SoC 106 may include other components, including a communication unit (e.g., a modem), an input / output controller, and a system interface.

[0024] Clients 108 provide read or write data transaction requests to the random access memory (RAM) 112 of the memory subsystem 110. As a non-limiting example, clients 108 may include a display system, a graphics processing unit, a central processing unit, a communication unit, an input / output controller, and a system interface of the SoC 106.

[0025] Memory subsystem 110 includes RAM 112, a memory controller 114, and a credit controller 116. RAM 112 is 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 clients 108. In other implementations, RAM 112 may be located outside of the SoC 106.

[0026] Memory controller 114 manages the transaction requests of clients 108 to RAM 112. Memory controller 114 may buffer and service the transaction requests to RAM 112 to increase the bandwidth of the memory subsystem 110. In particular, the memory controller may schedule the transaction requests to improve the bandwidth of the interface between RAM 112 and the memory controller 114. Memory controller 114 may include hardware, firmware, software, or a combination thereof.

[0027] Credit controller 116 may allocate a portion of the buffer in memory controller 114 to clients 108. The allocated portion of the buffer (referred to herein as “credit”) represents a bandwidth guarantee for the corresponding client 108 at RAM 112. Credit controller 116 may include hardware, firmware, software, or a combination thereof.

[0028] Fabric (in Figure 1(not shown) is operatively connected to the client 108 via respective virtual channels. The architecture can forward transaction requests from the client 108 to the memory controller 114. In some implementations, the architecture is a multiplexer. In any or all of the clients 108, the credit controller 116 can be implemented as a separate component in the SoC 106 or as a separate component outside the SoC 106 within the architecture.

[0029] The memory controller 114 can also monitor statistics related to transactions servicing the RAM 112. Based on the statistics, the memory controller 114 can provide feedback to the credit controller 116 and / or the client 108 to potentially adjust (e.g., decrease, increase, maintain) the credit allocated to one or more of the clients 108. In this way, the described systems and techniques can dynamically adjust the credit allocation among the clients 108 and improve the QoS for the clients 108.

[0030] The user device 102 also includes a computer-readable storage medium (CRM) 118. The CRM 118 is a suitable storage device for storing device data of the user device 102 (e.g., random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), flash memory). The device data can include an operating system, one or more applications, user data, and multimedia data. In other implementations, the CRM 118 can store the operating system and a subset of the applications, user data, and multimedia data of the SoC 106.

[0031] The operating system generally manages the hardware and software resources of the user device 102 and provides common services. The operating system and applications are typically executable by the SoC 106 to enable communication and user interaction with the user device 102, which may require access to data in the RAM 112 of the memory subsystem 110.

[0032] Figure 2 An example device diagram 200 of the SoC 106 is shown in which systems and techniques for adjusting credit allocation in the memory subsystem 110 of the SoC 106 can be implemented. The SoC 106 and the memory subsystem 110 can include additional components not shown in Figure 2 not shown.

[0033] SoC 106 includes multiple clients 108 and a memory subsystem 110. In the depicted implementation, clients 108 include client A 108-1, client B 108-2, and client C 108-3. SoC 106 may include fewer or more clients 108. In this example, clients 108 are located outside of memory subsystem 110. In other implementations, clients 108 or a portion of clients 108 may be located within memory subsystem 110.

[0034] As described above, clients 108 may provide transaction requests to read or write data to RAM 112. One or more clients 108 may provide real-time traffic 202 and non-real-time traffic 204 to memory subsystem 110. In this example, the transaction requests of client A 108-1 include real-time traffic 202 and non-real-time traffic 204.

[0035] Memory subsystem 110 includes RAM 112, a memory controller 114, and a credit controller 116. RAM 112 includes at least one storage device. In the described implementation, RAM 112 includes two storage devices: SDRAM 206-1 and SDRAM 206-2. SDRAM 206-1 and SDRAM 206-2 may store data for or accessible by clients 108. SDRAM 206-1 and SDRAM 206-2 are operatively connected to memory controller 114.

[0036] Memory controller 114 may include a buffer 208, a statistical monitoring module 210, and a credit allocation feedback module 212. Buffer 208 temporarily stores the transaction requests of clients 108. Buffer 208, or another component of memory controller 114, may also send transaction requests to SDRAM 206-1 and SDRAM 206-2 to increase the bandwidth at the memory interface.

[0037] Statistical monitoring module 210 may monitor the transaction requests serviced to SDRAM 206-1 and SDRAM 206-2. For example, statistical monitoring module 210 may determine statistics related to the number of hits (e.g., page hits at SDRAM 206-1 or SDRAM 206-2), conflicts (e.g., SDRAM 206-1 or SDRAM 206-2 closing a page before an open request for the page), the bandwidth allocated to clients 108 (e.g., the traffic class assigned to the client 108 servicing the transaction request), the efficiency of the transaction requests, and the desired bandwidth. Statistical monitoring module 210 may be implemented in memory controller 114 in hardware, digital logic, or a combination thereof.

[0038] The credit allocation feedback module 212 can provide feedback to the credit controller 116 or the client 108. The feedback can provide suggestions for adjusting the credit allocated to one or more clients 108. For example, the credit allocation feedback module 212 can suggest that the credit controller 116 reduce the number of credits allocated to client B 108 by 2. The memory controller 114 is generally unaware of the number of credits allocated to a particular traffic class or VCID. Thus, when agnostic to the credit allocation, the credit allocation feedback module 212 can provide feedback based on the statistics determined by the statistical monitoring module 210.

[0039] This document Figure 3 describes the operation of the memory subsystem 110 in more detail, particularly the operation of the memory controller 114 and the credit controller 116.

[0040] Example configuration

[0041] This section illustrates example configurations of a hardware-based memory subsystem for adjusting credit allocation, which can occur individually, or all or in part together. For ease of reading, this section describes the example configurations with respect to the drawings.

[0042] Figure 3 An example diagram 300 of a memory subsystem 110 that can adjust credit allocation is shown. The memory subsystem 110 can include additional components not shown in Figure 3 . The memory subsystem 110 provides a hardware implementation for sending feedback to the upstream client 108 or the credit controller 116 based on statistics collected by the memory controller 114. The feedback can suggest adjusting the number of credits allocated to a particular traffic class or a particular client. The feedback loop is completed by the client 108 or the credit controller 116, which takes action on the feedback and adjusts the credit allocation. In this way, the memory controller 114 can improve the performance of the memory subsystem 110.

[0043] Similar to Figure 2, the memory subsystem 110 includes one or more RAMs 112 (e.g., SDRAM 206-1, SDRAM 206-2), a memory controller 114, a credit controller 116, an architecture 312, and one or more clients 108 (e.g., client A 108-1, client B 108-2, client C 108-3). The client 108 is operably connected to the architecture 312 via an internal bus. This document refers to the internal bus as the virtual channel 302. Each virtual channel 302 is assigned a unique identifier, which is referred to in this document as the virtual channel identifier (VCID). The architecture 312, the credit controller 116, or the client 108 may assign a VCID to a specific traffic class. As described above, a traffic class represents the specific processing required for a transaction request to meet a specific QoS for the client 108. For example, real-time traffic 202 (e.g., from a display client) may require different QoS processing compared to non-real-time traffic 204.

[0044] In the depicted implementation, client A 108-1 is operably connected to the architecture 312 via virtual channel 302-1. Client B 108-2 is operably connected to the architecture 312 via virtual channel 302-2, and client C 108-3 is operably connected to the architecture 312 via virtual channel 302-3.

[0045] The credit controller 116 may subdivide the buffer 208 of the memory controller 114 ( Figure 3 not shown therein) into credits and allocate the credits to different traffic classes to manage the bandwidth available for different traffic classes. The credits assigned to different traffic classes and thus to different VCID translate into a bandwidth guarantee for each VCID at the buffer 208 of the memory controller 114. In other implementations, the credit controller 116 may allocate credits among the clients 108 based on an idle pool. The idle pool allows the credit controller 116 to dynamically allocate credits to the clients 108 based on feedback from the memory controller 114, traffic class designation, the number of available idle credits, or a combination thereof.

[0046] The architecture 312 is operably connected to the memory controller 114 via an internal bus 304. The architecture 312 sends memory transactions from the client 108 to the memory controller 114 via the internal bus 304. The memory controller 114 temporarily stores the transaction request in the buffer 208.

[0047] Memory controller 114 is operatively connected to SDRAM 206 via internal bus 306. In the depicted implementation, memory controller 114 is operatively connected to SDRAM 206-1 and 206-2 via internal buses 306-1 and 306-2, respectively. Memory controller 114 services transaction requests to SDRAM 206 via respective internal buses 306. As described with respect to Figure 2 as described, statistical monitoring module 210 ( Figure 3 not shown in

[0048] ) monitors statistics of memory transactions serviced to SDRAM 206.

[0049] Memory controller 114 is also operatively connected to credit controller 116 via sideband channel 308. In some implementations, memory controller 114 may also be operatively connected to one or more clients 108 via sideband channel 310. In other implementations, memory controller 114 may be operatively connected to client 108 via sideband channel 310 instead of being operatively connected to credit controller 116 via sideband channel 308. Figure 3 Based on the statistics generated by statistical monitoring module 210, credit allocation feedback module 212 (

[0050] not shown in

[0051] ) may suggest adjusting the credit allocation for one or more clients 108. In this way, memory controller 114 can ensure that buffer 208 is maximally efficient. If a particular VCID can achieve the same throughput with a smaller credit allocation, then credit controller 116 or client 108 can allocate spare credits to a different VCID, traffic class, or client 108 that would benefit from additional credits.

[0052] Signal Name Width Description r_decrease_credits [Num_vc-1:0] Suggestion for decreasing credits r_hold_credits [Num_vc-1:0] Suggestion for holding credits r_increase_credits [Num_vc-1:0] Suggestion for increasing credits w_decrease_credits [Num_vc-1:0] Suggestion for decreasing credits w_hold_credits [Num_vc-1:0] Suggestion for holding credits w_increase_credits [Num_vc-1:0] Suggestion for increasing credits

[0053] In operation, the statistical monitoring module 210 can monitor several metrics to assist the credit assignment feedback module 212. In particular, the statistical monitoring module 210 can determine a differential metric and an occupancy metric for transaction requests serviced by the memory controller 114 for each clock cycle of the memory subsystem 110. Transaction requests include a VCID, or other data identifying the client 108 that services the transaction request. In this way, the statistical monitoring module 210 can determine the differential metric and the occupancy metric for each of one or more clients 108. In other implementations, the statistical monitoring module 210 can determine and monitor additional metrics. Refer to Figure 4 is described in more detail a differential metric that represents the efficiency seen by a particular VCID at the interface to the SDRAM 206. Regarding Figure 5 is described in more detail the occupancy metric, which infers the number of credits assigned to a particular VCID.

[0054] As Figure 3 depicted, the memory subsystem 110 can implement the management and regulation of credit assignment in hardware. In other implementations, credit management and rebalancing can be implemented at the kernel level or the driver level.

[0055] Figure 4 shows an example diagram 4400, which shows the differential metric monitored by the statistical monitoring module 210 of the memory controller 114. In this implementation, the statistical monitoring module 210 monitors the differential metric for a particular VCID of the memory subsystem 110.

[0056] The differential metric represents the efficiency of the VCID at the interface to one or both of the SDRAMs 206. As an example, a VCID with transaction requests that result in a relatively large proportion of hits will have a higher efficiency than a VCID with more random transaction requests that cause a higher proportion of conflicts. In this document, a hit refers to a page hit at the SDRAM 206. A page hit can occur when the page (e.g., row) of the SDRAM 206 requested by the transaction request is already open. A miss refers to a transaction request for a page that is closed at the SDRAM 206. A conflict refers to the SDRAM 206 having an open page different from the page requested by the transaction request, resulting in the open page being closed.

[0057] Transaction requests at SDRAM 206 typically result in a specific command sequence. For example, a read (RD) or write (WR) command first involves sending an activate (ACT) command. The ACT command loads the entire page of SDRAM 206 into the row buffer. A subsequent RD command addressing columns of that page returns data. Similarly, a subsequent WR command addressing columns of that page writes the data in the transaction request to the addressed columns. After the access to the page is complete, SDRAM 206 closes the page by issuing a precharge (PRE) command. Typically, a transaction request to SDRAM 206 can include opening, accessing, and closing a page. If a transaction request addresses a page or row buffer that is not currently open, the transaction request incurs an additional penalty for closing the open page.

[0058] Memory controller 114 attempts to maximize the bandwidth at the interface to SDRAM 206 and also, at the same time, satisfy the QoS parameters of the transaction requests. These two requirements can cause memory controller 114 to service transaction requests out of order. A client 108, traffic class, or VCID that sends a transaction request that results in a series of hits will have a lower latency than a client 108, traffic class, or VCID that experiences many conflicts. Thus, credit assignment feedback module 212 can use statistics related to hits, conflicts, allocated bandwidth, and desired bandwidth to define performance metrics. Credit assignment feedback module 212 can then use the performance metrics to suggest adjustments to the credits assigned to different clients 108, traffic classes, or VCIDs to improve system performance.

[0059] Statistical monitoring module 210 can define a difference metric for a particular VCID as the sum of hits minus the sum of conflicts:

[0060] Difference[VC i = ∑hits - ∑conflicts (1)

[0061] The difference metric can be an 8-bit unsigned value with some initial offset value (e.g., 32). Whenever a transaction request receives permission in the request scheduler of the memory controller 114, the statistical monitoring module 210 updates the number of hits and conflicts belonging to that VCID in the next clock cycle and updates the difference value. In this way, the statistical monitoring module 210 can use a counter to determine the efficiency associated with a particular VCID while avoiding the need to use division or multiplication to generate the difference metric. The statistical monitoring module 210 generally does not consider misses because each conflict ultimately results in a miss. In another implementation, the statistical monitoring module 210 can define the difference metric based on misses rather than conflicts. The statistical monitoring module 210 can also saturate the difference metric at a maximum value 414 (e.g., 255) and a minimum value 416 (e.g., 0) to avoid the difference value flipping (e.g., to avoid integer overflow or underflow that may cause the value of the difference metric to be incorrect).

[0062] FIG. 400 shows example difference values 402 generated by the statistical monitoring module 210 for client A108-1 for time windows 404, 406, 408, 410, and 412. At the start of time window 404, the difference value 402 for client A 108-1 starts at an initial offset value of 32. During time window 404, the memory controller 114 does not service any transaction requests for client A 108-1, and the difference value 402 remains at the value of 32.

[0063] During time window 406, the memory controller 114 services transaction requests that result in page hits, and the difference value 402 has a positive slope. After a certain number of page hits, the difference value 402 saturates at the maximum value 414.

[0064] During time window 408, the statistical monitoring module 210 includes a decay factor that slowly brings the difference value 402 back to the initial offset value when there are no transaction requests for that VCID. In this way, the statistical monitoring module 210 can avoid the hit rate of old transaction request threads from affecting the feedback signal for the current transaction request thread.

[0065] During time window 410, the difference value 402 oscillates around the initial offset value by being below and above the initial offset value. The oscillation of the difference value 402 can be caused by a series of transaction requests that result in conflicts and then page hits. Considering that after a transaction request is sent and causes a conflict, that transaction request becomes a page hit and results in a positive fraction canceling out a negative fraction. During time window 412, the memory controller 114 does not service any transaction requests for the VCID, and the difference value 402 remains at the initial offset value.

[0066] In response to a low difference value 402, the credit allocation feedback module 212 need not recommend reducing the credit allocation for a particular VCID. The VCID may have been assigned a small number of credits and is expected to have a small bandwidth at the memory controller 114. Thus, a relatively low efficiency or bandwidth is expected at the interface to the SDRAM 206, and a recommendation to reduce the credits allocated to that VCID is not triggered. To this end, the credit allocation feedback module 212 uses the occupancy metric Figure 5 described and the difference metric to generate credit allocation feedback.

[0067] Figure 5 FIG. 502 shows an example graph showing the credits 504 allocated to the client 108 based on the occupancy metric and the difference metric, and FIG. 518 shows an example graph showing the feedback signal 520 from the memory controller 114. In this implementation, the statistical monitoring module 210 monitors the occupancy metric of a particular VCID of the memory subsystem 110.

[0068] As described above, the occupancy metric represents the inference of the statistical monitoring module 210 about the number of credits 504 allocated to the VCID. Since the allocation of credits is managed by the credit controller 116 and / or one or more clients 108, the memory controller 114 does not directly know the number of credits 504 allocated to a particular VCID. The statistical monitoring module 210 can use the number of entries used by a particular VCID in the buffer 208 to infer the credits 504 allocated to the VCID. In other words, the occupancy metric of a particular virtual channel is the number of buffer entries used by that virtual channel.

[0069] The credit allocation feedback module 212 can determine the feedback signal 520 for each VCID based on the occupancy metric and the difference metric collected by the statistical monitoring module 210, as follows:

[0070] K × occupancy[VC i - difference[VC i > threshold[VC i (2)

[0071] where K is a constant scaling factor to bring both the occupancy metric and the difference metric into the same range. If the former is true, the credit allocation feedback module 212 recommends: reducing the credits 504 allocated to the VCID. The credit controller 116 and / or the client 108 can use the feedback signal 520 to perform a successive approximation of the maximum number of credits 504 allocated to the VCID.

[0072] As an example, FIG. 502 shows the credits 504 assigned to a particular client 108 (e.g., client B 108-2). FIG. 518 shows the feedback signal 520 provided by the credit allocation feedback module 212 to the credit controller 116 regarding the recommendation for adjusting the credits 504 assigned to client B 108-2. During the time window 510, the credit controller 116 assigns the maximum number of credits 506 (e.g., 12 credits) to client B 108-2. The credit allocation feedback module 212 sends a hold recommendation to the credit controller 116 for client B 108-2 during the time window 510.

[0073] In the time window 512, the statistical monitoring module 210 determines that the occupancy metric of the VCID associated with client B 108-2 is greater than a threshold, which is greater than the differential metric of the VCID. In response, the credit allocation feedback module 212 sends an r_reduce_credits signal to the memory controller 114. When the credit controller 116 sees the reduction recommendation for T clock cycles 522, the credit controller 116 can adjust the number of credits 504 assigned to client B 108-2 downward toward the minimum number of credits 508. The reduction in the number of credits 504 assigned to client B 108-2 can continue until the feedback signal 520 no longer includes the r_decrease_credits recommendation. The number of credits 504 assigned to client B 108-2 generally does not drop below the minimum number of credits 508.

[0074] During the time windows 514 and 516, the feedback signal 520 no longer includes the r_reduce_credits recommendation for T clock cycles 522, and the number of credits 504 assigned to client B 108-2 increases back toward the maximum number of credits 506.

[0075] The credit controller 116 can allocate the credits taken from client B 108-2 to a different client or to an idle pool of credits. In this way, the memory subsystem 110 can effectively utilize the buffer 208 of the memory controller 114 by adjusting the credits assigned to different VCID. Additionally, in the absence of a credit reduction recommendation from the memory controller 114, the credit controller generally attempts to assign the maximum number of credits 506 to the client 108.

[0076] Example method

[0077] Figure 6 is a flowchart showing an example operation 600 for adjusting credit allocation in a memory subsystem. Operation 600 is at Figure 1 and Figure 2described in the context of the memory subsystem 110. Operation 600 may be performed in a different order or with additional or fewer operations.

[0078] At 602, the credit controller assigns a corresponding number of credits to one or more clients. For example, the credit controller 116 may assign a corresponding number of credits to one or more clients 108.

[0079] At 604, the memory controller stores transaction requests from one or more clients for accessing data in one or more RAMs. The memory controller is operatively connected to one or more RAMs and the credit controller. For example, the memory controller 114 is operatively connected to one or more RAMs 112 (e.g., SDRAM 206-1, SDRAM 206-2) and the credit controller 116. The memory controller 114 includes a buffer 208 for storing transaction requests from one or more clients 108 for accessing data in one or more RAMs 112.

[0080] At 606, the memory controller monitors statistics of transaction requests served to one or more RAMs for each of one or more clients. For example, the memory controller 114 may monitor statistics of transaction requests served to one or more RAMs 112 for each of one or more clients 108.

[0081] At 608, the memory controller determines based on the statistics whether increasing or decreasing the corresponding number of credits assigned to at least one of one or more clients will increase the memory throughput. For example, the memory controller 114 may determine based on the statistics whether increasing or decreasing the corresponding number of credits assigned to at least one of one or more clients 108 will increase the memory throughput.

[0082] At 610, the memory controller generates an output signal to indicate that the corresponding number of credits should be increased or decreased. The output signal is based on the determination that the memory throughput will be increased. The output signal is sent by the memory controller to the credit controller. For example, the memory controller 114 may generate an output signal to indicate that the corresponding number of credits should be increased or decreased. The output signal is based on the determination that the memory throughput of the RAM 112 will be increased. The memory controller 114 may send the output signal to the credit controller 116 via the side channel 308. The memory controller 114 may also send the output signal directly to at least one of one or more clients 108.

[0083] At 612, the respective number of credits assigned to at least one of one or more clients is adjusted by a credit controller based on an output signal. For example, credit controller 116 may adjust the respective number of credits assigned to at least one of one or more clients 108 based on the output signal.

[0084] Example

[0085] Examples are provided in the following sections.

[0086] Example 1: A memory subsystem of a system-on-chip (SoC): A memory controller operatively connected to a credit controller, the memory controller including a buffer configured to store transaction requests from one or more clients for accessing data in one or more RAMs, the memory controller being configured to: for each of the one or more clients, monitor statistics of transaction requests serviced by the memory controller; determine based on the statistics whether memory throughput will increase by increasing or decreasing the respective number of credits assigned to at least one of the one or more clients; and generate an output signal based on the determination that memory throughput increases, the output signal being configured to indicate to the credit controller that the respective number of credits assigned to at least one of the one or more clients should be increased or decreased.

[0087] Example 2: The memory subsystem according to Example 1, wherein: the credit controller is operatively connected to the one or more clients via respective virtual channels, the virtual channels being associated with respective virtual channel identifiers (VCIDs); and the memory controller is further configured to associate the statistics of each client with the respective VCID.

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

[0089] Example 4: The memory subsystem according to any of the preceding examples, wherein the statistics include at least two of the number of page hits in one or more RAMs, the number of conflicts for closing pages in one or more RAMs before another page can be opened, or the inference of the respective number of credits assigned to a client.

[0090] Example 5: The memory subsystem according to Example 4, wherein the memory controller is further configured to: define a difference metric for each of the one or more clients, the difference metric representing the number of page hits minus the number of conflicts; and define an occupancy metric for each of the one or more clients, the occupancy metric representing an inference of the corresponding number of credits assigned to the client, wherein a recommendation to adjust the corresponding number of credits assigned to at least one of the one or more clients is based on a comparison of the occupancy metric and the difference metric for each of the one or more clients.

[0091] Example 6: The memory subsystem according to Example 5, wherein the difference metric includes: a maximum threshold, representing the maximum value of the difference metric; and a default threshold, representing the initial offset value of the difference metric.

[0092] Example 7: The memory subsystem according to Example 6, wherein the difference metric further includes: an attenuation factor that causes the difference metric to return to the default threshold after a period of time without any transaction requests.

[0093] Example 8: The memory subsystem according to any one of Examples 4 to 7, wherein the memory controller determines the occupancy metric based on the number of entries in the buffer used by each of the one or more clients.

[0094] Example 9: The memory subsystem according to any of the preceding examples, wherein the one or more RAMs include low-power double data rate synchronous dynamic random access memory (LPDDR SDRAM).

[0095] Example 10: The memory subsystem according to any of the preceding examples, wherein the memory controller includes an application specific integrated circuit (ASIC) memory controller.

[0096] Example 11: The memory subsystem according to any of the preceding examples, wherein the SoC is embedded in a user device.

[0097] Example 12: The memory subsystem according to Example 11, wherein the user device is a mobile phone, a laptop computer, a tablet computer, a portable video game console, or a wearable device.

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

[0099] Example 14: The credit controller according to Example 13, wherein: the credit controller is operatively connected to the one or more clients via respective virtual channels, the virtual channels being associated with respective virtual channel identifiers (VCIDs); and the statistics monitored by the memory controller for each of the one or more clients are associated with the respective VCID.

[0100] Example 15: The credit controller according to any one of Examples 13 and 14, wherein the credit controller receives a recommendation from the memory controller via a side channel.

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

[0102] Conclusion

[0103] Although various configurations and methods for regulating credit allocation in a memory subsystem have been described in language specific to features and / or methods, it should be understood that the subject matter of the appended claims need not be limited to the specific features or methods described. Rather, the specific features and methods are disclosed as non-limiting examples for regulating credit allocation in a memory subsystem.

Claims

1. A memory subsystem of a system-on-chip (SoC), comprising: A memory controller operatively connected to a credit controller, the memory controller including a buffer configured to store transaction requests from one or more clients for accessing data in one or more random access memories (RAMs), the memory controller being configured to: For each of the one or more clients, monitor statistics of the transaction requests served by the memory controller, the statistics including at least two of the following: the number of page hits in the one or more RAMs, the number of conflicts that require closing a page of the one or more RAMs before another page can be opened, and an inference of the corresponding number of credits assigned to the client; Based on the statistics, determine whether increasing or decreasing the corresponding number of credits assigned to at least one of the one or more clients will increase the memory throughput; and Based on determining that the memory throughput will increase, generate an output signal configured to indicate to the credit controller that the corresponding number of credits assigned to the at least one of the one or more clients should be increased or decreased.

2. The memory subsystem according to claim 1, wherein: The credit controller is operatively connected to the one or more clients via respective virtual channels, the virtual channels being associated with respective virtual channel identifiers (VCIDs); and The memory controller is further configured to associate the statistics for each client with the respective VCID.

3. The memory subsystem according to claim 1, wherein: The memory controller is further configured to transmit the output signal to the credit controller via a side channel.

4. The memory subsystem according to claim 1, wherein, The memory controller is further configured to: For each of the one or more clients, define a difference metric that represents the number of page hits minus the number of conflicts; And For each of the one or more clients, define an occupancy metric that represents an inference of the corresponding number of credits assigned to the client, Wherein the output signal for adjusting the corresponding number of credits assigned to at least one of the one or more clients is based on a respective comparison of the occupancy metric and the difference metric for the one or more clients.

5. The memory subsystem according to claim 4, wherein, The difference metric includes: A maximum threshold that represents the maximum value of the difference metric; and A default threshold that represents an initial offset value of the difference metric.

6. The memory subsystem according to claim 5, wherein, The difference metric further includes an attenuation factor that causes the difference metric to return to the default threshold after a period of time without any transaction requests.

7. The memory subsystem according to claim 4, wherein, The memory controller determines the occupancy metric based on the number of entries in the buffer used by each of the one or more clients.

8. The memory subsystem according to claim 1, wherein, The one or more RAMs include low-power double data rate synchronous dynamic random access memory (LPDDR SDRAM).

9. The memory subsystem according to claim 1, wherein, The memory controller includes an application specific integrated circuit (ASIC) memory controller.

10. The memory subsystem according to any one of claims 1-9, wherein, The SoC is embedded in a user device.

11. The memory subsystem according to claim 10, wherein, The user device is a mobile phone, a laptop computer, a tablet computer, a portable video game console, or a wearable device.

12. A credit controller, the credit controller being configured to: allocate a corresponding number of credits to one or more clients of a memory subsystem of a system-on-chip SoC, the one or more clients being configured to send transaction requests for accessing data in one or more RAMs of the memory subsystem to a memory controller of the memory subsystem, the memory controller being configured to monitor statistics of the transaction requests of the one or more clients, the statistics including at least two of: a number of page hits in the one or more RAMs, a number of conflicts of pages of the one or more RAMs that require closing before another page can be opened, and an inference of the corresponding number of credits allocated to the client; receive a signal from the memory controller and based on the statistics monitored by the memory control, the signal indicating that the corresponding number of credits allocated to the one or more clients should be increased or decreased; and dynamically change the corresponding number of credits allocated to the one or more clients based on the signal.

13. The credit controller according to claim 12, wherein: the credit controller is operably connected to the one or more clients via corresponding virtual channels, the virtual channels being associated with corresponding virtual channel identifiers VCID; and the statistics monitored by the memory controller for each of the one or more clients are associated with the corresponding VCID.

14. The credit controller according to any one of claims 12 and 13, wherein The credit controller receives the signal from the memory controller via a side channel.

15. A client of a system-on-chip SoC, the client being configured to: send a transaction request for accessing data in one or more RAMs to a memory controller of a memory subsystem of the SoC; receive a signal from the memory controller and based on statistics monitored by the memory controller, the signal indicating that the number of credits allocated to the client should be increased or decreased, the statistics including at least two of: a number of page hits in the one or more RAMs, a number of conflicts of pages of the one or more RAMs that require closing before another page can be opened, and an inference of the corresponding number of credits allocated to the client; and dynamically change the number of credits for future transaction requests based on the signal.

16. A method for regulating credit allocation in a memory subsystem, the method comprising: receiving, by a memory controller operably connected to a credit controller, transaction requests from one or more clients for accessing data in one or more random access memories RAMs associated with the memory controller; Store the transaction requests received from the one or more clients in a buffer of the memory controller; For each of the one or more clients, monitor statistics of the transaction requests received by the memory controller, the statistics including at least two of the following: the number of page hits in the one or more RAMs, the number of conflicts requiring closing the pages of the one or more RAMs before another page can be opened, and the inference of the corresponding number of credits assigned to the client; Determine based on the statistics whether increasing or decreasing the corresponding number of credits assigned to at least one of the one or more clients will increase memory throughput; and Generate an output signal based on determining that the memory throughput will increase, the output signal being configured to indicate to the credit controller that the corresponding number of credits assigned to the at least one of the one or more clients should be increased or decreased.

17. The method according to claim 16, wherein: The credit controller is operably connected to the one or more clients via respective virtual channels, the virtual channels being associated with respective virtual channel identifiers VCID, and the method further includes: Associate the statistics for each client with the corresponding VCID of the virtual channel through which the credit controller is operably coupled to the client.

18. The method according to claim 16, further comprising: Transmit the output signal to the credit controller via a side channel.

19. The method according to claim 16, further includes: Define a difference metric for each of the one or more clients, the difference metric representing the number of page hits minus the number of conflicts; And Define an occupancy metric for each of the one or more clients, the occupancy metric representing the inference of the corresponding number of credits assigned to the client, wherein the output signal for adjusting the corresponding number of credits assigned by the credit controller to the at least one client is based on a comparison of the occupancy metric and the difference metric of the at least one client.

20. The method according to claim 19, wherein, The difference metric includes at least one of the following: A maximum threshold, the maximum threshold representing the maximum value of the difference metric; and A default threshold, the default threshold representing the initial offset value of the difference metric.

21. The method according to claim 20, wherein, The difference metric further includes a decay factor that causes the difference metric to return to the default threshold after a period of time without any transaction requests.

22. The method according to claim 19, further comprising: Determine the occupancy metric based on the number of entries in the buffer used by each of the one or more clients.

Images