Patent Grant
9270610
1. Technical Field
This disclosure is directed to integrated circuits (IC's), and more particularly, to controlling the flow of transactions between agents of an IC.
2. Description of the Related Art
To prioritize some transactions over other transactions in the movement through an integrated circuit (IC) such as a system on chip (SoC) fabric, a quality-of-service (QoS) mechanism may be implemented such that an agent generating a transaction may also provide information representing the QoS associated with that transaction. In a typical scenario, arbiters and queues in the path of a memory request or transaction containing QoS information should be capable of processing that information or forwarding the information to a subsequent circuit which is then capable of processing it.
Arbitration in such an SoC may be based on QoS indicators, or more generally, priority levels. Thus some transactions may have a higher priority level than others. Generally speaking, an arbitration unit may allow a transaction having a higher priority level to advance over one with a lower priority level.
Various embodiments of a method and apparatus for controlling transaction flow in a communications fabric is disclosed. In one embodiment, an IC includes a communications fabric connecting multiple agents to one another. Each agent may include an interface coupling itself to at least one other agent. Each interface may include multiple queues for storing information corresponding to pending transactions. Also included in each interface is an arbitration unit and control logic. The control logic may determine which transactions are presented to the arbitration unit for arbitration. In one embodiment, the control logic may inhibit certain transactions from being presented to the arbitration unit so that other higher priority transactions may advance. In another embodiment, the control logic may reduce the priority level of some transactions for arbitration purposes to prevent the blocking of other higher priority transactions.
In one embodiment, an interface unit may include separate queues each assigned to one of a number of virtual channels. The virtual channels may include a real time virtual channel, a low latency virtual channel, and a bulk virtual channel. Transactions corresponding to these virtual channels (e.g., real time transactions for the real time channel) may be stored in corresponding queues. Multiple queues may be present for at least the real time virtual channels, if not all of the virtual channels. Each of the real time transactions may have one of a high, medium, or low priority. A control circuit may determine if the real time queue includes any real time high priority transactions at its head (i.e., if a real time high priority is the oldest transaction stored therein), and if so, inhibit real time medium and real time low at the heads of other queues associated with the real time virtual channel from being presented to the arbitration unit until the real time high priority transactions have been presented. If no real time high priority transactions are at the head of any of the real time queues, but real time medium transactions are at the head of at least one of the real time queues, real time low transactions at the head of any other ones of the real time queues may be inhibited from being presented to the arbitration unit. Real time high transactions may have a higher priority than any other transactions. Real time medium transactions may have a higher priority than real time low transaction and bulk transactions, but may be arbitrated with low latency transactions. Real time low transactions may be arbitrated with bulk transactions. In some embodiments, this scheme may be extended to non-real time transactions. For example, low latency and bulk transactions may be inhibited along with real time medium and real time low transactions when a real time high transaction is at the head of a queue. Similarly, if a low latency transaction is at the head of a queue, real time low and bulk transactions may be inhibited.
In another embodiment, first and second queues may each store transactions from different virtual channels, and thus may include real time, low latency, and bulk transactions. The queues may be operated on a first-in, first-out basis, and thus a transaction at the head of each queue may be provided to the arbitration unit for arbitration. In some cases, particularly if a non-real time transaction at the head of a queue is blocking a higher priority real time transaction, control logic may demote (in terms of priority level) a transaction at the head of the other queue. For example, if the head of a first queue is a bulk transaction and the head of the second queue is a real time medium priority transaction, the control logic may reduce the priority level of the transaction at the head of the second queue to a real time low priority transaction so that it may be arbitrated with the bulk transaction. This may allow the bulk transaction to pass sooner and thus prevent it from blocking higher priority real time transactions that are behind it in its respective queue.
The following detailed description makes reference to the accompanying drawings, which are now briefly described.
While susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to be limiting to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the disclosure as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include”, “including”, and “includes” mean including, but not limited to.
Various units, circuits, or other components may be described as “configured to” perform a task or tasks. In such contexts, “configured to” is a broad recitation of structure generally meaning “having circuitry that” performs the task or tasks during operation. As such, the unit/circuit/component can be configured to perform the task even when the unit/circuit/component is not currently on. In general, the circuitry that forms the structure corresponding to “configured to” may include hardware circuits. Similarly, various units/circuits/components may be described as performing a task or tasks, for convenience in the description. Such descriptions should be interpreted as including the phrase “configured to.” Reciting a unit/circuit/component that is configured to perform one or more tasks is expressly intended not to invoke 35 U.S.C. §112, paragraph six interpretation for that unit/circuit/component.
Turning now to
IC 10 in the embodiment shown also includes a power management unit 18, which is coupled to at least some, if not all, of functional blocks 15. Power management unit 18 may perform various actions to control the consumption of power by IC 10, such as clock gating individual functional blocks, power gating individual functional blocks and so on. Power management unit 18 may also change an operating clock frequency or an operating voltage of an individual functional block 15 in order to reduce its power usage while otherwise being active.
IC 10 may implement a communications fabric to enable communications between the various functional blocks 15. Each of the functional blocks 15 in the embodiment shown is coupled to at least one other functional block 15 by a communications link 12. In the embodiment shown, each communications link 12 is a point-to-point communications link, supporting communications between the pair of functional blocks 15 to which it is coupled. Moreover, each of the communications links 12 may support two-way communications between the two functional blocks 15 to which it is coupled. Functional blocks 15 that are coupled to one another by a given communications link 12 may be said to be logically adjacent to one another for the purposes of this disclosure. Thus, functional blocks 15 as shown in
Transactions in the communications fabric of IC 10 may be designated as one of a number of different types. In one embodiment, transactions may be classified as real time transactions, low latency transactions, or bulk transactions. Real time transactions may be defined as transactions having a guaranteed response time, or latency, i.e. the response time is within a given designated time frame. Real time transactions as discussed herein may have a variable priority level. In one embodiment, real time transactions may have a high, medium, or low priority level. Transactions that are not real time (low latency and bulk in this embodiment) may be defined as transactions for which a response time is not guaranteed. Low latency transactions may be further defined herein as transactions for which performance is improved when completed with lower latency. Bulk transactions may be defined herein as transactions for which performance is not dependent on the latency of completing the same. Both low latency and bulk transactions as defined herein may have fixed priority levels. Real time high priority transactions in the embodiment shown may have the highest priority over all other transaction types, but may be subject to arbitration when competing for resources with other real time high priority transactions. Real time medium transactions as defined herein may have priority over real time low transactions and bulk transactions, but may be subject to arbitration when competing for resources with low latency transactions. Real time low priority transactions as defined herein may be subject to arbitration with bulk transactions. As previously noted, the priority of real time transactions is variable and may thus be changed between a point of origin and a point of destination.
It is noted that communications links implemented as shared buses are also possible and contemplated, and such buses may support implementation of various features discussed below.
Each LIU 24 in the embodiment shown includes a transmit unit 22 and a receiver unit 23. The receive unit 23 of each LIU 24 may receive data from a transmit unit 22 of a correspondingly coupled LIU 24 in another functional block. Data received by a receive unit 23 may be conveyed to the core logic of its corresponding functional block or to a transmit unit 22 in another LIU 24 of the same functional block 15. Data may be conveyed to the core logic when the corresponding functional block 15 is the final destination (or target) of a particular transaction received by a receive unit 23. When the corresponding functional block 15 is an intermediate point for a received transaction, its corresponding data may be conveyed to a transmit unit 22 in another LIU 24 in the same instance of functional block 15.
Each transmit unit 22 in the embodiment shown is coupled to receive data from either the core logic of its respective functional block 15, or from a receive unit 23 of another LIU 24 in that functional block 15. Each transmit unit 22 may transmit data, in the form of transactions, to a receive unit 23 of an LIU 24 in another functional block 15. The transactions may be arranged as packets, frames, or any other suitable form. Each of the transmit units 22 may include circuitry for storing pending transactions and associated information, as well as circuitry for arbitrating between pending transactions. Various embodiments of circuitry for controlling the flow of transactions transmitted from an LIU are discussed below.
Turning now to
Each of the queues is coupled to provide transaction information to an arbitration unit 350. During a given cycle of operation for one embodiment of transmit unit 22, transactions may be conveyed from various ones of the queues to arbitration unit 350. The transaction received by arbitration unit 350 may be conveyed from the head of each queue (i.e., the oldest transaction in each queue, which are implemented as FIFOs). Arbitration unit 350 may arbitrate between the received transactions to determine the next one to be serviced, and thus transmitted from transmit unit 22. Arbitration unit 350 may use any suitable arbitration scheme, such as round-robin, weighted arbitration, age-based arbitration, and so on, as well as arbitration schemes that combine one or more arbitration types.
Control unit 340 in the embodiment shown is coupled to each of the queues. The transactions conveyed to arbitration unit 350 may be selected by control unit 340. More particularly, control unit 340 is coupled to determine which transactions are at the head of each of the queues, and may determine whether these transactions may be forwarded to arbitration unit 350 during a given cycle. Control unit 340 may use various selection criteria to determine which transactions are selected from the various queues. In one embodiment, the selection criteria may be based on credits applied to each queue, which are factored in when control unit 340 is determining which queues from which to select transactions for the next arbitration cycle. However, any suitable criteria to ensure forward progress for transactions in each of the queues may be used.
As previously noted, real time high priority transactions have priority over all other transactions. Real time medium priority transactions may have the same priority (and thus be arbitrated with) low latency transactions, while real time low priority transactions have the same priority (and may thus be arbitrated with) bulk transactions. In some cases, such as in a credit based system, a transaction at the head of a queue might not be selected for a lack of credits or other reason. This may prevent the forward progress of some transactions and could thus adversely impact performance, particularly with real time transactions, which are to be completed within a guaranteed time frame. However, in the embodiment shown, control unit 340 may nevertheless be configured to override the selection criteria to allow some real time transactions to advance.
Control unit 340 in the embodiment shown is configured to determine which transactions are present at the head of each of the queues. If control unit 340 determines that any real time high priority transactions are at the head of at least one of the real time queues, it may inhibit real time medium priority and real time low priority transactions from being forwarded to arbitration unit 350 if such transactions are at the head of other real time queues. This may allow the real time high priority transactions to advance and thus to be completed within their designated time frame. In the case that real time medium priority transactions are at the head of a real time queue but while no real time high priority transactions at the head of another real time queue, control unit 340 may inhibit real time low priority transactions that are also at the head of a real time queue from being forwarded to arbitration unit 350. The real time medium transactions may be forwarded to arbitration unit 350. Arbitration unit 350 may arbitrate between the real time medium transactions and low latency transactions if present during the same cycle of arbitration. The real time medium transactions may be advanced over any bulk transactions presented to arbitration unit 350 during the same arbitration cycle.
In this manner, if a real time high transaction cannot be chosen by the arbiter for some reason (e.g., due to a lack of credits in a credit-based system), real time medium/low and low latency/bulk transactions are not presented to the arbitration unit and thus are not chosen to be forwarded even if they are otherwise eligible. This may in turn prevent lower priority transactions from occupying system resources, thereby allowing the higher priority transactions to make progress once they are eligible to be chosen by the arbiter.
Method 400 begins with the determining the priority of transactions at the head of each of the real time queues (block 405). For example, control unit 340 as shown in
If no real time high priority transactions are present at the head of any real time queues (block 410, no), method 400 advances to block 420. If real time medium priority transactions are present at the head of any of the real time queues (block 420, yes), then real time low priority transactions also at the head of a real time queue may be inhibited from advancing to the arbitration unit (block 425). In some embodiments, bulk transactions may also be inhibited from advancing to the arbitration unit. Real time medium transactions may, when eligible, be advanced to the arbitration unit, where they may be arbitrated against low latency transactions or advanced ahead of bulk transactions. If no real time medium transactions are present the method advances to block 430. In block 430, the control unit may select transactions from the heads of the various queues for presentation to the arbitration unit. The arbitration unit may then arbitrate between the transactions presented thereto, and inform the control unit of the arbitration outcome. Method 400 may then advance to the next cycle (block 435), and thus return to block 405.
In some embodiments, the scheme may also be extended to non-real time transactions. For example, if a low latency transaction is at the head of a queue, real time low and bulk transactions may be inhibited. The low latency transaction may then advance to the arbitration unit when eligible.
Since both queues are arranged as FIFOs in this embodiment, a transaction at the head of each queue is provided to arbitration unit 350 for arbitration during each cycle. The head of a queue may be defined in this example as being the location storing the oldest transaction in that queue (i.e. the first transaction stored therein from all transactions within that queue). In the illustrated example, the transactions will advance in the indicated direction of flow, with the older transactions toward the right and the newer transactions toward the left. It is noted that this example is not intended to imply a physical arrangement, but rather a logical arrangement. Thus, a given physical storage location in a given queue may logically be at the head of the queue when it is storing the oldest transaction therein, but is otherwise not logically at the head of the queue.
Control unit 340 may maintain a record of the priority level each transaction stored in queues 510 and 520, along with a record of the ordering of these transactions. The record may be updated each time a transaction is advanced and a new transaction is written into a queue. As previously noted, the priority of real time transactions is variable and may thus be changed in some cases. In the embodiment shown, control unit 340 is configured to change the priority of real time transactions if it is necessary to allow other real time transactions to advance in a timely manner. In particular, control unit 340 may change the priority of some real time transaction in order to prevent the blocking of other real time transactions.
In the example shown in the three oldest transactions in queue 510 are real time transactions, including a real time high transaction at the head of the queue followed by two real time medium transactions. A low latency transaction follows the real time medium transaction. In queue 520, a bulk transaction is at the head of the queue, followed by another bulk transaction, and then followed by a real time high priority transaction. Because of the arrangement shown, the real time high transaction shown in queue 520 may be blocked from advancement for a certain amount of time due to the presence of the bulk transaction at the head of queue 520 and the real time and low latency transactions in the oldest positions of queue 510. If the priorities are left unchanged, each of the first three real time transactions in queue 510, plus the oldest low latency transaction, will all advance through arbitration unit 350 before the bulk transaction at the head of queue 520 can be arbitrated with another transaction of equal priority (which, in this case, is the oldest bulk transaction in queue 510). Thus, the real time high transaction may be prevented from advancing at least until the real time and low latency transactions have been cleared from the four oldest positions of queue 510. Furthermore, the real time high priority transaction in queue 520 may be further delayed until the bulk transaction in the second position also advances.
In order to reduce the delay of the real time high transaction in queue 520, control unit 340 may reduce the priority level of the real time transaction at the head of queue 510. For example, control unit 340 may reduce the priority of the real time high transaction at the head of queue 510 to real time low priority, and then present the transactions at the heads of each queue to arbitration unit 350. Since real time low transactions have equal priority to bulk transactions, the bulk transaction at the head of queue 520 has a chance of winning the arbitration and advancing. Similarly, the real time medium priority transactions following the real time high transaction in queue 510 may also have their respective priorities reduced to real time low when they reach the head of the queue. This in turn increases the probability that the real time high transaction in the third position of queue 520 will reach the head of queue 520 and thus advance.
Thus, control unit 340 may reduce the priority level of a real time high priority transaction at the head of a queue to real time medium or real time low priority in order to enable the advancement of a real time transaction in the other queue. Similarly, a real time medium priority transaction at the head of one queue may have its priority reduced to real time low by control unit 340 in situation where a bulk transaction is blocking another real time transaction in the other queue. In general, control unit 340 may alter the priority of any real time transaction at the head of a queue in any manner that can prevent the blocking of other real time transactions that are not at the head of a queue. This in turn may enable real time transactions to be completed within their guaranteed time frames. Embodiments are also possible and contemplated wherein control unit 340 may at times present transactions to arbitration unit 350 out of order if necessary to prevent real time transactions from being blocked.
Method 600 begins with a control unit determining the priority of transactions stored in first and second queues (block 605). More particularly, the control unit may determine the priority of each transaction stored in one of the queues, as well as the ordering thereof, may be determined by the control unit. After determining the priority and ordering of the transactions in each of the queues, the control unit may determine if a real time transaction in a first queue is being blocked by one or more other transactions in the first queue (block 610). For example, as shown in the example of queue 520 in
If no real time transactions are being blocked (block 610, no), then the transactions at the head of each of the queues may be presented to the arbitration unit (block 620), where they may be arbitrated if they have equal priority with one another (e.g., when a real time medium transaction and a low latency transaction are presented to the arbiter). In some cases, a transaction at the head of one queue will have a higher priority than the transaction at the head of the other queue (e.g., when a real time medium and a bulk transaction are presented to the arbitration unit). In such cases, the transaction having the higher priority will win the arbitration by default. The transaction that loses the arbitration may then be presented to the arbitration unit during the next arbitration cycle.
If the control unit determines that a real time transaction is being blocked in one queue and a real time transaction is at the head of the other queue (block 610, yes), it may reduce the priority of the real time transaction at the head of the other queue (block 615). For example, a real time high transaction at the head of one queue may have its priority reduced to real time medium if a low latency transaction is at the head of the other queue (i.e. the queue in which the real time transaction is blocked). A real time high or real time medium transaction at the head of one queue may have its priority reduced to real time low if a bulk transaction at the head of the other queue is blocking a real time transaction. Thereafter, the transactions at the head of each queue may be presented to the arbitration unit and arbitrated as equals (block 620). After the arbitration is complete, method 600 proceeds to the next cycle (block 625) and thus back to the determining of the priority and ordering of each of the transactions stored in first and second queues.
While the virtual channels that have been discussed herein in terms of real time and non-real time virtual channels, embodiments utilizing other designations for virtual channels are also possible and contemplated. Furthermore, while a particular priority scheme has been discussed herein (e.g., real time high, medium and low transactions), other priority schemes are also possible within the scope of this disclosure.
Turning next to
The peripherals 154 may include any desired circuitry, depending on the type of system 150. For example, in one embodiment, the system 150 may be a mobile device (e.g. personal digital assistant (PDA), smart phone, etc.) and the peripherals 154 may include devices for various types of wireless communication, such as WiFi, Bluetooth, cellular, global positioning system, etc. The peripherals 154 may also include additional storage, including RAM storage, solid-state storage, or disk storage. The peripherals 154 may include user interface devices such as a display screen, including touch display screens or multitouch display screens, keyboard or other input devices, microphones, speakers, etc. In other embodiments, the system 150 may be any type of computing system (e.g. desktop personal computer, laptop, workstation, net top etc.).
The external memory 158 may include any type of memory. For example, the external memory 158 may be SRAM, dynamic RAM (DRAM) such as synchronous DRAM (SDRAM), double data rate (DDR, DDR2, DDR3, LPDDR1, LPDDR2, etc.) SDRAM, RAMBUS DRAM, etc. The external memory 158 may include one or more memory modules to which the memory devices are mounted, such as single inline memory modules (SIMMs), dual inline memory modules (DIMMs), etc.
Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.
| Number | Name | Date | Kind |
|---|---|---|---|
| 6091709 | Harrison et al. | Jul 2000 | A |
| 6256315 | Barbas et al. | Jul 2001 | B1 |
| 6490611 | Shen et al. | Dec 2002 | B1 |
| 6747976 | Bensaou et al. | Jun 2004 | B1 |
| 6754223 | Lussier et al. | Jun 2004 | B1 |
| 7162540 | Jasen et al. | Jan 2007 | B2 |
| 7433365 | Burch et al. | Oct 2008 | B1 |
| 7665069 | Weber | Feb 2010 | B2 |
| 7813348 | Gupta et al. | Oct 2010 | B1 |
| 7933205 | Shaw et al. | Apr 2011 | B1 |
| 7990989 | Jensen | Aug 2011 | B2 |
| 20030219014 | Kotabe et al. | Nov 2003 | A1 |
| 20060053117 | McAlpine et al. | Mar 2006 | A1 |
| 20060200456 | Zohar et al. | Sep 2006 | A1 |
| 20070201365 | Skoog et al. | Aug 2007 | A1 |
| 20080008203 | Frankkila et al. | Jan 2008 | A1 |
| 20100067542 | Grenot | Mar 2010 | A1 |
| 20100281193 | Kojima et al. | Nov 2010 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20140241376 A1 | Aug 2014 | US |
