Patent Description:
Priority levels, which affect quality of service for requesting clients, are often used for memory-request arbitration. Clients may have various requirements that dictate respective priorities of the memory requests they generate. By utilizing priority levels, the arbiter can prioritize memory requests within the memory-request buffer for granting.

Traditionally, priority levels may be fixed for each memory request in the memory-request buffer. While this approach can effectively indicate that memory requests have different priorities, it cannot adapt when clients' requirements change. For example, a video card may determine that a display buffer is about to underrun and may have no means to expedite associated memory requests.

<CIT> relates to a memory protocol with command priority. An apparatus can execute a command that includes a read identification number based on a priority assigned to the read identification number in a register.

<CIT> relates to a programmable integrated circuit memory controller that interfaces between master modules and system memory. The memory controller may receive memory access requests from the masters via ports that have associated priority values and fulfill the memory access requests by configuring system memory to respond to the memory access requests.

<CIT> relates to memory systems for receiving communication information from external devices via virtual channels and the control methods of these memory systems.

Techniques and apparatuses are described that enable memory-request priority up-leveling. These techniques and apparatuses enable a client to dynamically adjust priority levels of memory requests within a memory-request buffer (e.g., read and/or write memory requests) via a side channel to a memory controller. By asserting an up-level indication corresponding to a virtual channel identification (VCID) over the side channel, the client can increase original priority-levels for memory requests within the memory-request buffer for which the VCID is indicated. Furthermore, because the VCID is indicated for related memory requests, priority up-leveling may be achieved while accounting for memory request dependency.

Aspects described below include a memory controller configured to perform a method that receives a memory request from a client over a virtual channel (VC) and adds the memory request to a memory-request buffer, along with an indication of a VCID of the VC and an original priority-level for the memory request. The method then indicates the VCID for related memory requests within the memory-request buffer. The method also determines that an up-level indication corresponding to the VCID is being asserted and, based on the up-level indication being asserted, increases original priority-levels of memory requests with the VCID indicated (e.g., the memory request and the related memory requests) to respective up-leveled priority levels. The memory controller may implement the method in hardware (e.g. using digital logic circuitry configured to perform the method) or in a combination of hardware and software (e.g., by a processor and a computer-readable medium, where the medium includes instructions that cause the processor to perform the method).

Aspects described below also include a method performed by a memory controller. The method includes receiving a memory request from a client over a VC and adding the memory request to a memory-request buffer along with an indication of a VCID of the VC and an original priority-level for the memory request. The method also includes indicating the VCID for related memory requests within the memory-request buffer. The method further includes determining that an up-level indication corresponding to the VCID is being asserted and, based on the up-level indication being asserted, increasing original priority-levels with the VCID indicated (e.g., the memory request and the related memory requests) to respective up-leveled priority levels.

Apparatuses and techniques enabling memory-request priority up-leveling are described with reference to the following drawings. The same numbers are used throughout the drawings to reference like features and components:.

Memory requests may have associated priority levels that affect quality of service for clients. Although the clients may be able to set priority levels when the memory requests are generated, the priority levels are generally static and unable to be manipulated by the clients after the memory requests are received by a memory controller. Some memory controllers can accelerate memory requests; they often do so, however, irrespective of the clients. Many times, the clients are aware of conditions that the memory controller is not (e.g., a local buffer that is about to underrun). Such conditions can lead to poor quality-of-service for the clients, even with memory-controller-based acceleration. Furthermore, traditional acceleration techniques may fail to account for related memory requests within the memory-request buffer (e.g., memory-request dependency). Failing to account for such dependency can also lead to poor quality of service for the clients due to parent memory requests holding up child memory requests even when the child memory requests are accelerated by the memory controller.

This document describes techniques and apparatuses that enable memory-request priority up-leveling. These techniques and apparatuses enable a client to dynamically adjust priority levels of memory requests within a memory-request buffer via a side channel to a memory controller. By asserting an up-level indication corresponding to a VCID over the side channel, the client can increase original priority-levels for memory requests within the memory-request buffer that have the VCID indicated. In some cases, the up-leveling may occur in as little as a single clock cycle. Furthermore, because the VCID is indicated for related memory requests, priority up-leveling may be achieved while accounting for memory request dependency. Although the following discussion describes acceleration of memory requests through priority up-leveling, the techniques can easily be applied to deceleration of memory requests though priority down-leveling.

<FIG> illustrates a process flow <NUM> for adding memory requests to a memory buffer and indicating VCIDs for related memory requests. The process flow <NUM> is generally implemented in an electronic device (not shown) that is discussed below in regard to <FIG>. As shown in <FIG>, the process flow <NUM> includes a client <NUM> that sends a memory request <NUM> (e.g., read and/or write memory request) to a memory controller <NUM>. The client <NUM> may be a component or aspect of an application, operating system, processor, core of a processor, piece of hardware, or any other entity that can generate memory requests requesting to read from or write to a memory <NUM>.

The memory request <NUM> has a VCID <NUM> associated with the memory request <NUM>, an original priority-level <NUM>, a memory address <NUM>, and an optional transaction identification (ID) <NUM>. The memory address <NUM> indicates a physical or virtual memory address associated with the memory request <NUM>. Although discussed in terms of a memory address <NUM>, the memory request <NUM> may include a request for a plurality of memory addresses. The transaction ID <NUM> may be included in the memory request <NUM> and may be used for memory request dependency, as discussed below.

The original priority-level <NUM> may indicate a priority of the memory request <NUM> that is dictated by the client and used for memory request arbitration. Some clients, (e.g., a real-time client) may generate high-priority memory requests compared to other clients (e.g., a non-real-time client). The original priority-level <NUM> may, for example, be a value in a range from <NUM> to <NUM>.

The memory request <NUM> is received by the memory controller <NUM> over a VC <NUM>, and the VCID <NUM> corresponds to the VC <NUM>. Thus, the VCID <NUM> of the memory request <NUM> may be inherent to the memory controller <NUM> based on the VC <NUM>. The VC <NUM> may also be associated with the client. For example, the VC <NUM> (and thus the VCID <NUM>) may be determined based on information about the client <NUM> (e.g., ID, type, or location). Alternatively, the memory request <NUM> may explicitly contain the VCID <NUM> corresponding to the VC <NUM>. Regardless of how the VCID <NUM> is determined, the memory controller <NUM> adds the memory request <NUM> to a memory-request buffer <NUM> along with an indication of the VCID <NUM>.

Noted that the system may have a fixed number of VCs and, thus, a fixed number of VCIDs over which memory requests may be received. Because of the multiple VCs, the memory controller <NUM> may utilize multiplexing of incoming memory requests. As the VCs are virtual, two or more of the VCs (including all of the VCs) may share a common physical channel. Furthermore, multiple clients can share a VC (and thus send memory requests over a same VCID). Conversely, a client may utilize multiple VCs (and thus send memory requests with different VCIDs).

A dependency module <NUM> of the memory controller <NUM> analyses other memory-requests <NUM> within the memory-request buffer <NUM> that were previously added with corresponding VCID indications <NUM> and determine if any related memory requests exist. In order to find related memory requests (e.g., parent memory requests), the dependency module <NUM> may search for memory addresses or transaction IDs of the other memory-requests <NUM> that match those of the memory request <NUM>.

The other memory-requests <NUM> have respective VCID indications <NUM> that were indicated upon entering the memory-request buffer <NUM> (similar to the memory request <NUM>). If a related memory request exists in the memory-request buffer <NUM>, the dependency module <NUM> determines if the VCID <NUM> is indicated for the related memory request. The VCID indications <NUM> of the other memory-requests <NUM> may be for the VCID <NUM> or other VCIDs supported by the system. For example, if the related request was received over the VC <NUM>, then the VCID <NUM> may already be indicated for the related request. If, however, the VCID <NUM> is not already indicated for the related memory request (e.g., the related memory request was received over a different VC and thus has a different VCID indicated), then the dependency module <NUM> may indicate the VCID <NUM> for the related memory request. The indication of the VCID <NUM> for the related memory request is additive and not a replacement indication. As such, the related memory request will be associated with the VCID <NUM> as well as a VCID for a VC over which the related memory request was received (if different than the VC <NUM>).

The dependency module <NUM> may assign/indicate the VCID indications <NUM> of the other memory-requests <NUM> (including the memory request <NUM> after being added to the memory-request buffer <NUM>) via a field for each memory request. The field may have a width equal to a number of VCs supported by the system. In some implementations, a vector may be used to represent the field (e.g., a VCID vector). The field may be part of a lookup table that contains the memory requests, or the field may be attached or appended to each of the memory requests. By using the field, each memory request in the memory-request buffer <NUM> may have indications of each of the VCIDs of the system. Although the memory request <NUM> has been described as being added to the memory-request buffer <NUM> prior to actions of the dependency module <NUM>, the memory request <NUM> may be added to the memory-request buffer <NUM> concurrently with or after the actions of the dependency module <NUM>.

By performing such actions, each memory request within the memory-request buffer <NUM> includes an indication of at least one VCID corresponding to the VC over which the respective memory request was received along with indications of VCIDs of any related memory requests (e.g., children of the respective memory request). By indicating VCIDs of children memory requests for parent memory requests (e.g., by the dependency module <NUM>), a VCID is used to priority up-level not only memory requests that were received over the corresponding VC, but also related memory requests (e.g., parents of the memory requests that were received over the corresponding VC). Priority up-leveling is discussed further below in regard to <FIG>.

<FIG> illustrates an example process flow <NUM> for memory-request priority up-leveling. The process flow <NUM> is generally a continuation of the process flow <NUM> and, thus, may also be implemented in the electronic device (not shown) that is discussed below in regard to <FIG>. The process flow <NUM> generally occurs after the process flow <NUM>. As such, the process flow <NUM> occurs after the dependency module <NUM> has placed the memory request <NUM> within the memory-request buffer <NUM> and indicated the VCID <NUM> for any related requests. Thus, memory requests <NUM> include memory request <NUM> and the other memory-requests <NUM> along with their corresponding VCID indications <NUM> and priority levels <NUM>.

As shown, the process flow <NUM> includes the client <NUM> asserting an up-level indication <NUM> with a corresponding up-level amount <NUM> for the VCID <NUM> for receipt by an up-level module <NUM> of the memory controller <NUM>. The up-level indication <NUM> and the up-level amount <NUM> are received over a side channel <NUM> to the memory controller <NUM>. The side channel <NUM> may be a different channel than that over which the memory requests <NUM> were received. In this way, the up-leveling is asynchronous with the memory requests <NUM>. Other side channels may exist for the other VCIDs. Similar to the VCs for which they pertain, the respective side channels may share a common physical channel.

As will be discussed further below, the up-level module <NUM> may consider the up-level indication <NUM> as being asserted until it is changed or deasserted by the client <NUM>. Furthermore, although the same client (e.g., the client <NUM>) as in <FIG> is shown, noted that the up-level indication <NUM> may be asserted and the up-level amount <NUM> set by another client. For example, the other client may have one or more memory requests <NUM> that were received over VC <NUM>.

The VCID <NUM> associated with the up-level indication <NUM> and the up-level amount <NUM> may, similar to the memory request <NUM>, be inherent to the memory controller <NUM> based on a VC over which the up-level indication <NUM> is received (e.g., a VC of the side channel <NUM>). In such a situation, the VCID <NUM> may be inherent to the up-level module <NUM>. Alternatively, the up-level indication <NUM> and the up-level amount <NUM> may be received along with an explicit indication of the VCID <NUM>.

The up-level module <NUM> searches the memory requests <NUM> within the memory-request buffer <NUM> for indications of the VCID <NUM>. As mentioned above, in addition to the memory request <NUM>, at least some of the memory requests <NUM> that were received over the same VC as the memory request <NUM>, along with at least some of the memory requests <NUM> that are related to the memory request <NUM>, may include an indication of the VCID <NUM>.

Respective priority levels <NUM> of the memory requests <NUM> having the indication of the VCID <NUM> are increased from respective original priority-levels (e.g., original priority-level <NUM>) to respective up-leveled priority levels based on the up-level amount <NUM>. The up-level amount <NUM> may be a fixed amount, e.g., the priority levels <NUM> of the memory requests <NUM> having the indication of the VCID <NUM> are set to a specific level. Alternatively, the up-level amount <NUM> may be a multiplier, e.g., the priority levels <NUM> of the memory requests <NUM> having the indication of the VCID <NUM> are multiplied by the multiplier.

The up-level indication <NUM> is a dynamic indication that can be easily asserted or deasserted by the client <NUM>. As such, when the client <NUM> asserts the up-level indication <NUM>, e.g., by setting a bit of the side channel <NUM>, priority levels of associated requests are increased. The priority levels of the associated requests may stay increased until the up-level indication is deasserted by the client, e.g., by returning the bit. Accordingly, responsive to determining that the up-level indication <NUM> for the VCID <NUM> has been deasserted by the client <NUM>, the up-level module <NUM> returns the priority levels <NUM> of the memory requests <NUM> having the indication of the VCID <NUM> to the respective original priority-levels. Furthermore, the up-level amount <NUM> can be changed dynamically by the client <NUM> (or another requesting client) irrespective of whether the up-level indication <NUM> is currently asserted and/or being received. Noted that the changes in priority levels, and thus acceleration/deceleration, may occur in as little as a single clock cycle.

The priority levels <NUM> are sent to and/or viewed by an arbiter <NUM> that grants the memory request <NUM> based on the priority level of the memory request <NUM> (or, because priority level is only one factor for use in memory-request arbitration, the arbiter <NUM> may decline or defer the memory request <NUM>). The arbiter <NUM> may grant the memory request <NUM> while the up-level indication <NUM> is asserted or deasserted. Generally, the arbiter <NUM> is more likely to grant the memory request <NUM> while the priority level of the memory request <NUM> is up-leveled. The memory request <NUM>, however, may be granted after the up-level indication <NUM> is deasserted. Thus, the priority level for the memory request <NUM> at grant may be the original priority-level <NUM> or an up-leveled priority level. Regardless of the priority level when the memory request <NUM> is granted, the arbiter sends a memory-request grant <NUM> that corresponds to the memory request <NUM> to the client <NUM>. Other memory-requests of the memory requests <NUM> (including the related memory requests that are generally granted prior to the memory request <NUM>) also have associated memory grants sent to their respective clients.

In order to accommodate the multiple VCs of the system, the memory controller <NUM> may utilize multiplexing for one or more operations. For example, up-level indications asserted over VC <NUM> may be multiplexed with up-level indications asserted over other VCs. As such, the up-level module <NUM> may multiplex up-leveling of memory requests over multiple VCs. Similarly, the priority levels <NUM> may be multiplexed when viewed/analyzed by the arbiter <NUM>.

By utilizing the above techniques, performance of the memory controller <NUM> may not be affected by increasing a depth of the memory request buffer <NUM> (e.g., a number of memory requests able to be stored/tracked in the buffer). For example, a number of the operations discussed above may be irrespective of the depth. Furthermore, increasing the depth of the memory request buffer <NUM> may merely require a linear growth in area (as opposed to exponential or some other non-linear growth). Also, there may be no need to maintain additional pointers for the parent memory transactions.

<FIG> illustrates an example electronic device <NUM> in which memory-request priority up-leveling can be implemented. The electronic device <NUM> is illustrated with various non-limiting examples of the electronic device <NUM>: a smartphone <NUM>-<NUM>, a laptop <NUM>-<NUM>, a television <NUM>-<NUM>, a desktop <NUM>-<NUM>, a tablet <NUM>-<NUM>, and a wearable device <NUM>-<NUM>. As shown on the right, the electronic device <NUM> includes at least one processor <NUM>, computer-readable media <NUM>, and the memory controller <NUM>.

The processor <NUM> (e.g., an application processor, microprocessor, digital-signal processor (DSP), or controller) executes code stored within the computer-readable media <NUM> to implement an operating system <NUM> and optionally one or more applications <NUM> that are stored within a storage media <NUM> (e.g., one or more non-transitory storage devices such as a hard drive, SSD, flash memory, read-only memory (ROM), EPROM, or EEPROM) of the computer-readable media <NUM>. Although the operating system <NUM> or the applications <NUM> generally act as the client <NUM>, as described below, other components can also generate the memory request <NUM>.

The computer-readable media <NUM>, which may be transitory or non-transitory, also includes the memory <NUM> (e.g., one or more non-transitory computer-readable storage devices such as a random access memory (RAM, DRAM, or SRAM)) that is requested to be accessed (e.g., read from or written to) by the client <NUM> through the memory request <NUM>.

The memory controller <NUM> contains a memory-controller processor <NUM> and a memory controller computer-readable media <NUM>. The memory-controller processor <NUM> (e.g., an application processor, microprocessor, digital-signal processor (DSP), or controller) executes code stored within the memory controller computer-readable media <NUM> to implement the dependency module <NUM> and the up-level module <NUM> that are implemented at least partially in hardware of the memory controller <NUM>. The memory controller computer-readable media <NUM> (e.g., one or more non-transitory storage devices) also includes the memory-request buffer <NUM>. The memory controller <NUM> also contains the arbiter <NUM>.

Although described in terms of a separate processing system (e.g., with a separate processor and separate computer-readable media), aspects of the memory controller <NUM> may be implemented in conjunction with the processor <NUM> or by the processor <NUM>. Similarly, the memory controller <NUM> (or processor <NUM>) may perform functions described herein by executing instructions that are stored within the storage media <NUM>. The memory <NUM> and aspects of the memory controller <NUM> may also be combined (e.g., implemented as part of an SoC).

Although the memory controller <NUM> is described in terms of memory requests to access the memory <NUM>, the techniques described herein can easily be applied for memory requests to access storage media <NUM>. For example, the memory controller <NUM> may be a hard drive controller, SSD controller, or the like. Alternatively, the memory controller <NUM> may be implemented by the processor <NUM> to access storage media <NUM>.

The electronic device <NUM> can include one or more communication systems (not shown) that enable wired and/or wireless communication of device data, such as received data, transmitted data, or other information as described above. Example communication systems include NFC transceivers, WPAN radios compliant with various IEEE <NUM> (Bluetooth™) standards, WLAN radios compliant with any of the various IEEE <NUM> (WiFi™) standards, WWAN (3GPP-compliant) radios for cellular telephony, wireless metropolitan area network (WMAN) radios compliant with various IEEE <NUM> (WiMAX™) standards, infrared (IR) transceivers compliant with an Infrared Data Association (IrDA) protocol, and wired local area network (LAN) Ethernet transceivers. In some cases, aspects of the communication system may act as the client <NUM> by generating memory requests based on received data or data to be transmitted (e.g., a communication buffer).

The electronic device <NUM> may also include one or more data input ports (not shown) by which any type of data, media content, and/or other inputs can be received (e.g., user-selectable inputs, messages, applications, music, television content, recorded video content, and any other type of audio, video, and/or image data received from any content and/or data source). The data input ports may include USB ports, coaxial cable ports, fiber optic ports for optical fiber interconnects or cabling, and other serial or parallel connectors (including internal connectors) for flash memory, DVDs, CDs, and the like. These data input ports may be used to couple the electronic device to components, peripherals, or accessories such as keyboards, microphones, or cameras, and may also act as the client <NUM> by which the memory request <NUM> is received (e.g., the memory request is generated by a remote device).

Although not shown, the electronic device <NUM> can also include a system bus, interconnect, crossbar, or data transfer system that couples the various components within the device. A system bus or interconnect can include any one or combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and/or a processor or local bus that utilizes any of a variety of bus architectures.

In some implementations, the electronic device <NUM> also includes an audio and/or video-processing system (not shown) that processes audio data and/or passes through the audio and video data to an audio system (not shown) and/or to a display system (not shown) (e.g., a video buffer or a screen of a smart phone or camera). The audio system and/or the display system may include any components that process, display, and/or otherwise render audio, video, display, and/or image data and may act as the client <NUM>. Display data and audio signals can be communicated to an audio component and/or to a display component via an RF (radio frequency) link, S-video link, HDMI (high-definition multimedia interface), composite video link, component video link, DVI (digital video interface), analog audio connection, or another similar communication link, such as the media data port. In some implementations, the audio system and/or the display system are external or separate components of the electronic device <NUM>. Alternatively, the display system can be an integrated component of the example electronic device <NUM>, such as part of an integrated touch interface.

<FIG> is an example illustration <NUM> of VCIDs being indicated for memory requests. The example illustration <NUM> shows VCID indications <NUM> for three memory requests <NUM> (memory request <NUM>, memory request <NUM>, and memory request <NUM>) that are received chronologically (e.g., memory request <NUM> is received first, memory request <NUM> is received second, and memory request <NUM> is received third). The memory requests <NUM> are generally similar to the memory request <NUM> when first received and then similar to the other memory-requests <NUM> after the memory requests are placed in the memory-request buffer <NUM>. The VCID indications <NUM> are shown as 0x0, 0x1, and 0x2 merely for display purposes. As discussed above, any number of VCID indications <NUM> in any fashion (e.g., table, vector, field, etc.) may be utilized.

The memory request <NUM> is received over a VC with a VCID of 0x2. As such, when added to the memory-request buffer <NUM>, VCID 0x2 is indicated for the memory request <NUM>, as shown in an example representation <NUM> of the memory-request buffer <NUM>. Next, the memory request <NUM> is received over a VC with a VCID of 0x1. As such, when added to the memory-request buffer <NUM>, VCID Ox1 is indicated for the memory request <NUM>, as shown in an example representation <NUM> of the memory-request buffer <NUM>. The memory request <NUM> is related to the memory request <NUM> (based on transaction IDs and/or memory addresses). More specifically, the memory request <NUM> is determined to be dependent upon memory request <NUM> (e.g., memory request <NUM> is a child of memory request <NUM>). Accordingly, the dependency module <NUM> from <FIG> indicates VCID 0x1 for the memory request <NUM>, as shown in an example representation <NUM> of the memory-request buffer <NUM>. As noted above, the change in VCID indications <NUM> for the memory request <NUM> may be performed prior to, concurrently with, or after the memory request <NUM> is added to the buffer. The change from example representation <NUM> to example representation <NUM> is merely illustrative of the change due to memory request dependency.

Subsequently, the memory request <NUM> is received over the VC with the VCID of 0x2. The memory request <NUM> is not related to memory request <NUM> or <NUM>. As such, when added to the memory-request buffer <NUM>, VCID 0x2 is indicated for the memory request <NUM>, as shown in an example representation <NUM> of the memory-request buffer <NUM>. Accordingly, after the memory request <NUM> has been placed in the memory-request buffer <NUM>, an up-level indication for VCID 0x0 does not up-level any of the memory requests <NUM>, <NUM>, or <NUM>. Similarly, an up-level indication for VCID Ox1 up-levels the memory request <NUM> and the memory request <NUM>. Also, an up-level indication for VCID 0x2 up-levels the memory request <NUM> and the memory request <NUM>.

Because of the indication of VCID 0x1 for the memory request <NUM> (which was received over a different VC than that of VCID 0x1), the priority level of the memory request <NUM> is up-leveled responsive to an up-level indication for VCID 0x1 (e.g., to up-level a priority level of the memory request <NUM>). Without accounting for memory request dependency, the priority level of the memory request <NUM> may not be up-leveled responsive to the up-level indication for VCID 0x1, resulting in the memory request <NUM> waiting until the memory request <NUM> is granted and potentially nullifying the up-leveled priority of the memory request <NUM>.

The following discussion describes a method for memory-request priority up-leveling. This method can be implemented utilizing the previously described examples, such as the process flow <NUM>, the process flow <NUM>, the electronic device <NUM>, and the illustration <NUM> shown in <FIG>. Aspects of the method <NUM> are illustrated in <FIG> and <FIG>, which are shown as operations <NUM> through <NUM> performed by one or more entities (e.g., memory controller <NUM>). The order in which operations of this method are shown and/or described is not intended to be construed as a limitation, and any number or combination of the described method operations can be combined in any order to implement a method or an alternate method.

<FIG> and <FIG> illustrate an example method <NUM> for memory-request priority up-leveling. At <NUM>, a memory request is received. For example, the memory controller <NUM> may receive the memory request <NUM> from the client <NUM> over a VC with the VCID <NUM> and may contain the original priority-level <NUM>, the memory address <NUM>, and optionally the transaction ID <NUM>.

At <NUM>, the memory request, the VCID and the original priority-level are added to a memory-request buffer. For example, the memory controller <NUM> may add the memory request <NUM> to the memory-request buffer <NUM> with the original priority-level <NUM> and the VCID <NUM> indicated.

At <NUM>, contents of the memory-request buffer are analyzed to determine if one or more related memory requests exist. For example, the dependency module <NUM> may compare transaction IDs or memory addresses of the other memory-requests <NUM> within the memory-request buffer <NUM> to those of the memory request <NUM>. If the dependency module <NUM> identifies a related request ("YES" at <NUM>), then at <NUM>, the dependency module <NUM> indicates the VCID <NUM> for the related memory requests. For example, the dependency module <NUM> may indicate the VCID <NUM> within the VCID indications <NUM> of the other memory-requests <NUM> that are related to the memory request <NUM>. In some implementations, this may involve marking the VCID <NUM> of the memory request <NUM> within a corresponding VCID vector of the related/dependent memory requests (e.g., by setting a vector component within the VCID vector).

If the dependency module <NUM> does not identify related memory requests ("NO" at <NUM>), then the process continues to step <NUM>. Although illustrated as subsequent to step <NUM>, steps <NUM> and <NUM> may occur concurrently with or prior to step <NUM>.

At <NUM>, a determination that the up-level indication is being asserted for the VCID is made. For example, the up-level module <NUM> may determine that the up-level indication <NUM> is being asserted for the VCID <NUM>. The up-level indication may be asserted by the client that created the memory request (e.g., client <NUM>) or another client.

At <NUM>, original priority-levels of the requests with the VCID are increased to up-leveled priority levels. For example, the up-level module <NUM> may increase the priority levels <NUM> of the memory requests <NUM> having the indication of the VCID <NUM> from respective original priority-levels to respective up-leveled priority levels. The increase may be based on the up-level amount <NUM>. The memory requests that have their priority levels <NUM> increased may include memory requests that were received over the VC corresponding to the VCID <NUM> along with memory requests related to the memory request <NUM>. Furthermore, the dependency module <NUM> generally acts on each of the memory requests <NUM> within the memory-request buffer <NUM>. As such, memory requests that are related to the memory requests <NUM> that are received over the VC corresponding to the VCID <NUM> may also have their priority levels <NUM> up-leveled.

At <NUM>, a determination is made as to whether the up-level indication is still being asserted. For example, the up-level module <NUM> may determine if the up-level indication <NUM> is still being asserted by the client <NUM>. If the up-level indication <NUM> is no longer being asserted ("NO" at <NUM>), then at <NUM>, the up-leveled priority levels are returned to the original priority-levels. For example, the up-level module <NUM> may decrease the priority levels <NUM> of the memory requests <NUM> having the indication of the VCID <NUM> from the up-leveled priority levels to the respective original priority-levels (including the related memory requests that have the VCID indicated). If the up-level indication is still being asserted ("YES" at <NUM>), then the up-leveled priority levels persist, and the method proceeds to <NUM>.

Irrespective of the priority level (e.g., whether step <NUM> is performed or not), at <NUM>, the memory request is granted. For example, the memory controller <NUM> may write data to, or read data from, the memory <NUM> in accordance with the memory request <NUM>. As discussed above, because priority level is one factor for use in memory-request arbitration, other factors may be utilized for memory grants, which can lead to the memory request being granted while the priority level is up-leveled or at its original value. Generally, however, the up-leveled priority levels may cause an arbiter to grant the corresponding memory requests sooner than if the priority levels are not up-leveled. In other words, while priority up-leveling can increase chances of grant, conditions may change between when the up-level indication is asserted and a time of grant. In such cases, a client may decide that the up-leveled priority level may be returned to the original priority-level before the memory request is granted. As such, the memory request may be granted with the original priority-level. Noted that the process may send the priority levels to another entity that grants (or arbitrates on) the request and the other memory-requests within the memory-request buffer <NUM>.

Claim 1:
A method for memory-request priority adjustment performed by a memory controller (<NUM>), the method comprising:
receiving (<NUM>) a memory request (<NUM>) from a client (<NUM>) over a virtual channel, VC (<NUM>), the memory request having an original priority-level (<NUM>);
adding (<NUM>) the memory request (<NUM>) to a memory-request buffer (<NUM>) along with:
an indication of a virtual channel identification, VCID (<NUM>), of the VC (<NUM>); and
the original priority-level (<NUM>) for the memory request (<NUM>);
determining (<NUM>) that an adjustment indication (<NUM>) corresponding to the VCID (<NUM>) is asserted;
increasing (<NUM>) or decreasing the original priority-level (<NUM>) of the memory request (<NUM>) to an adjusted priority level (<NUM>) based on the asserted adjustment indication (<NUM>);
determining that one or more other memory-requests (<NUM>) within the memory-request buffer (<NUM>) have an indication of the VCID (<NUM>); and
increasing (<NUM>) or decreasing, based on the adjustment indication, respective original priority-levels (<NUM>) of the other memory requests (<NUM>) to respective priority levels (<NUM>).