US 7428607 B2
A method and apparatus for supporting heterogeneous agents in on-chip busses. In one embodiment, the method includes the detection of a bus arbitration event between at least a first bus agent and a second bus agent. In one embodiment, a bus arbitration event is detected when at least the first bus agent and the second bus agent assert their respective bus request signals in a single clock cycle. Once a bus arbitration event is detected, bus ownership may be granted to both the first bus agent and the second bus agent, when the first bus agent and the second bus agent have different grant-to-valid latencies. In the embodiment, heterogeneous bus agents may coexist on a bus without requiring wasted or unused bus cycles following establishment of bus ownership. Other embodiments are described and claimed.
1. A bus control system, comprising:
N first bus agents that each have different grant-to-valid latencies and that communicate with said bus;
M second bus agents that have corresponding grant-to-valid latencies and that communicate with said bus; and
a controller that determines said grant-to-valid latencies of said first and second bus agents and that grants concurrent ownership of said bus to each of said N first bus agents and non-concurrent ownership of said bus to each of said M second bus agents based on said determination, wherein M and N are integers greater than 1.
2. The system of
3. The system of
4. The system of
5. The system of
6. The system of
7. The system of
8. The system of
9. The system of
10. A method for operating a bus, comprising:
determining grant-to-valid latencies of N first bus agents and M second bus agents, wherein said N first bus agents each have different grant-to-valid latencies and said M second bus agents have corresponding grant-to-valid latencies; and
granting concurrent ownership of said bus to each of said N first bus agents and non-concurrent ownership of said bus to each of said M second bus agents based on said determination, wherein M and N are integers greater than or equal to 1.
11. The method of
12. The method of
13. The method of
14. The method of
15. The method of
16. The method of
This is a continuation of U.S. application Ser. No. 10/797,771 Pat. No. 7,143,220, filed Mar. 10, 2004.
One or more embodiments of the invention relate generally to the field of integrated circuit and computer system design. More particularly, one or more of the embodiments of the invention relates to a method and apparatus for supporting heterogeneous agents in on-chip busses.
Communications between devices that make up an electronic system are typically performed using one or more busses that interconnect such devices. These busses may be dedicated busses coupling only two devices, or they may be used to connect more than two devices. The busses may be formed entirely on a single integrated circuit die, thus being able to connect two or more devices on the same chip. Alternatively, a bus may be formed on a separate substrate than the devices, such as on a printed wiring board.
In computer systems employing advanced architectures and processors, bus transactions typically occur in a pipelined manner. Specifically, the next memory access may start after a previous transaction request is issued; and all components or phases of a bus transaction are not required to complete before another bus transaction may be initiated. Accordingly, requests from numerous bus agents may be pending at any one time. Generally, an arbitration scheme is used to aware bus ownership to a bus agent. However, varying grant-to-valid latencies of the various bus agents may result in unused or wasted bus cycle. As a result, the wasted bus cycles may degrade bus bandwidth and access latency.
The various embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which:
A method and apparatus for supporting heterogeneous agents in on-chip busses are described. In one embodiment, the method includes the detection of a bus arbitration event between at least a first bus agent and a second bus agent. In one embodiment, a bus arbitration event is detected when at least the first bus agent and the second bus agent assert their respective bus request signals in a single clock cycle. Once a bus arbitration event is detected, bus ownership may be granted to both the first bus agent and the second bus agent, when the first bus agent and the second bus agent have different grant-to-valid latencies. In the embodiment, heterogeneous bus agents may coexist on a bus without requiring wasted or unused bus cycles following establishment of bus ownership.
Representatively, computer system 100 comprises a processor system bus (front side bus (FSB)) 104 for communicating information between processor (CPU) 102 and chipset 200. As described herein, the term “chipset” is used in a manner to collectively describe the various devices coupled to CPU 102 to perform desired system functionality. As described herein, each device that resides on FSB 104 is referred to as bus agent of FSB 104. As such, the various agents of computer system 100 are required to arbitrate for access to FSB 102.
Representatively, chipset 200 may include graphics block 110, such as, for example, a graphics chipset, as well as hard drive devices (HDD) 130 and main memory 120. In one embodiment, chipset 200 is configured to include a memory controller and/or an input/output (I/O) controller. In an alternate embodiment, chipset 200 is or may be configured to operated as or include a system controller. In one embodiment, main memory 120 may include, but is not limited to, random access memory (RAM), dynamic RAM (DRAM), static RAM (SRAM), synchronous DRAM (SDRAM), double data rate (DDR) SDRAM (DDR-SDRAM), Rambus DRAM (RDRAM) or any device capable of supporting high-speed buffering of data.
As further illustrated, a plurality of I/O devices 140 (140-1, . . . , 140-N) may be coupled to chipset 200 via bus 150. As described above, each device that resides on a bus (such as FSB 104 and bus 150) is referred to as a bus agent. In one embodiment, each bus agent arbitrates for bus ownership by asserting a bus request signal. In one embodiment, computer system 100 may be configured according to a three-bus system, including, but not limited to, an address bus, a data bus and a transaction bus. Accordingly, a bus agent issues an address bus request signal (ABR), a data bus request signal (DBR) or a transaction bus request (TBR) signal to request bus ownership.
A bus transaction can exhibit several bus protocol events. These include an arbitration event to determine bus ownership, between competing bus agents. Thereafter, the transaction enters the request phase where the bus owner drives transaction address information. Accordingly, when the request phase includes a data request, the bus agent requesting data may be referred to herein as an “initiator bus agent”. Following transaction initiation, a data phase results in a bus agent providing the requested data to the initiator bus agent. As described herein, the bus agent from which data is requested is referred to herein as a “completer bus agent”. As further described herein, the completer bus agent may be referred to as a “master bus agent”, whereas the initiator bus agent may be referred to as a “target bus agent”.
Accordingly, computer systems, such as computer system 100, generally utilize shared bus architectures to provide communication among devices. Devices, such as processors, memory controllers, I/O controllers and direct memory access (DMA) units are usually connected via a shared bus. In general, only one device can drive the bus at a given time. Hence, it is necessary to arbitrate between devices requesting bus ownership to prevent multiple devices from driving the bus simultaneously.
In one embodiment, bus 150 is configured as an on-chip, pipelined bus shared by devices with various grant-to-valid latencies. As a result, bus 150 requires no turnaround cycles, since bus 150 may be implemented as an on-chip bus utilizing a logical OR gate or a multiplexed (MUX) based implementation. In on-chip bus implementations, it is generally is feasible for an agent to place a request on the bus in cycle n+1 if it receives a bus grant from arbitration logic in clock cycle n. In other words, the bus agents of an on-chip bus are assumed to have a single clock cycle a grant-to-valid latency for placing a request on the bus after receiving bus ownership.
For example, as illustrated with reference to
In response to assertion of BR signal 310, arbitration logic issues, or asserts, bus grant signal BG 312 in clock cycle 3 and expects bus agent 140-2 to drive data during clock cycle 4, as illustrated. In one embodiment, arbitration logic includes assertion logic (not shown) to assert bus grant signals BG 312 and 322. Generally, arbitration logic 210 can use this fact to efficiently arbitrate an on-chip bus (e.g., bus 150/FSB 104). Accordingly, when the bus agent can place a request on the bus in cycle n+1, following a bus grant from arbitration logic 210 in cycle n, the bus agent is said to have a grant-to-valid latency of one clock cycle.
Conventional arbitration logic is designed according to a fixed grant-to-valid, such as one clock cycle. Accordingly, conventional design of arbitration logic requires that each bus agent have a fixed grant-to-valid latency, referred to herein as a “fast bus agent”. As a result, slow bus agents are required to be coupled to a separate bus. As described herein, a “slow bus agent” refers to a bus agent having a grant-to-valid latency that exceeds the fixed grant-to-valid latency of fast bus agents. Therefore, when a slow bus agent is coupled to a bus, including fast bus agents, unused or wasted bus cycles may be caused by inclusion of the slow bus agent.
Referring again to
Accordingly, as illustrated in
In one embodiment, arbitration logic 210 may compare grant-to-valid latencies of bus agent 140-1 and 140-2 using bus grant logic (not shown). When the grant-to-valid latencies of the respective bus agents do not match, in clock cycle 3, arbitration logic 210 may issue a bus grant signal to both fast bus agent 140-1 and slow bus agent 140-2. Representatively, fast bus agent 140-1 drives data during clock cycle 4. Conversely, slow bus agent 140-2 drives data in clock cycle 5. In other words, slow bus agent 140-2 cannot use the bus cycle following the assertion of BG signal 312. Bus agent 140-2 will drive the bus two cycles after detecting assertion of BG signal 310.
As illustrated, arbitration logic 210 grants bus ownership, or concurrent bus ownership, to both fast bus agent 140-1 and slow bus agent 140-2 in clock cycle 8 by simultaneously asserting B6 signal 312 and B6 signal 322. Representatively, fast bus agent 140-1 drives the bus in clock cycle 9 and slow bus agent 140-2 drives the bus in clock cycle 10. Accordingly, bus cycles are not wasted when supporting heterogeneous bus agents (bus agents which have non-matching grant-to-valid latencies). As illustrated, when a bus agent has no operation to perform on the bus while having bus ownership, the bus agent may generate null bus cycles, as illustrated in clock cycles 6 and 11.
Accordingly, as illustrated in
Representatively, in clock cycle 5, slow bus agent 140-2 may once again request bus ownership by driving BR signal 310. During clock cycle 6, arbitration logic 210 grants slow bus agent 140-2 bus ownership by asserting BG signal 312. However, also during clock cycle 6, fast bus agent 140-1, which includes a single bus cycle grant-to-valid latency, may request bus ownership by driving BR signal 320. As illustrated, bus agent 140-1 may be immediately granted bus ownership in clock cycle 8, while bus agent 140-2 drives data in clock cycle 8. As such, bus agent 140-1 may drive data during bus cycle 9 following granting of bus ownership in bus cycle 8.
Accordingly, bus agents may simultaneously assert their respective bus request signal, resulting in a bus arbitration event. As illustrated with reference to
Referring again to
Accordingly, at process block 550, concurrent bus ownership is granted to the first bus agent and the second bus agent. Although bus agents are generally not allowed to simultaneously drive a bus, the first and second bus agents will receive concurrent bus ownership. However, due to the different grant-to-valid latencies of the first and second bus agents, the first bus agent, which may be, for example, a fast bus agent drives the bus prior to the slow bus and completes driving of the bus prior to granting of the bus to a slow bus agent. As a result, concurrent bus ownership may be granted to fast and slow bus agents without causing simultaneous driving of the bus.
However, if the first grant-to-valid latency is not equal to the second grant-to-valid latency, control flow branches to process block 550 of
In any representation of the design, the data may be stored in any form of a machine readable medium. An optical or electrical wave 660 modulated or otherwise generated to transport such information, a memory 650 or a magnetic or optical storage 640, such as a disk, may be the machine readable medium. Any of these mediums may carry the design information. The term “carry” (e.g., a machine readable medium carrying information) thus covers information stored on a storage device or information encoded or modulated into or onto a carrier wave. The set of bits describing the design or a particular of the design are (when embodied in a machine readable medium, such as a carrier or storage medium) an article that may be sealed in and out of itself, or used by others for further design or fabrication.
It will be appreciated that, for other embodiments, a different system configuration may be used. For example, while the system 100 includes a single CPU 102, for other embodiments, a multiprocessor system (where one or more processors may be similar in configuration and operation to the CPU 102 described above) may benefit from the concurrent bus ownership by bus agent with different grant-to-valid of various embodiments. Further different type of system or different type of computer system such as, for example, a server, a workstation, a desktop computer system, a gaming system, an embedded computer system, a blade server, etc., may be used for other embodiments.
Having disclosed exemplary embodiments and the best mode, modifications and variations may be made to the disclosed embodiments while remaining within the scope of the embodiments of the invention as defined by the following claims.