CROSS REFERENCE TO RELATED APPLICATIONThis patent application is related to commonly owned U.S. patent application Ser. No. 08/855,062; filed Jun. 30, 1997; entitled “Apparatus, Method and System for Dual Accelerated Graphics Ports” by Ronald T. Horan, Gary W. Thome and Sompong P. Olarig, and is hereby incorporated by reference for all purposes.[0001]
BACKGROUND OF THE INVENTION1. Field of the Invention[0002]
The present invention relates to computer systems using at least one bus bridge to interface with at least one central processing unit, a video graphics processor, random access memory and input-output peripheral devices together, and more particularly, in utilizing at least one bus bridge in a computer system to enable the computer system to interface with more than one input-output device of the same type.[0003]
2. Description of the Related Technology[0004]
Use of computers, especially personal computers, in business and at home is becoming more and more pervasive because the computer has become an integral tool of most information workers who work in the fields of accounting, law, engineering, insurance, services, sales and the like. Rapid technological improvements in the field of computers have opened many new applications heretofore unavailable or too expensive for the use of older technology mainframe computers. These personal computers may be used as stand-alone workstations (high end individual personal computers) or linked together in a network by a “network server” which is also a personal computer which may have a few additional features specific to its purpose in the network. The network server may be used to store massive amounts of data, and may facilitate interaction of the individual workstations connected to the network for electronic mail (“E-mail”), document databases, video teleconferencing, white boarding, integrated enterprise calendar, virtual engineering design and the like. Multiple network servers may also be interconnected by local area networks (“LAN”) and wide area networks (“WAN”).[0005]
A significant part of the ever-increasing popularity of the personal computer, besides its low cost relative to just a few years ago, is its ability to run sophisticated programs and perform many useful and new tasks. Personal computers today may be easily upgraded with new peripheral devices for added flexibility and enhanced performance. A major advance in the performance of personal computers (both workstation and network servers) has been the implementation of sophisticated peripheral devices such as video graphics adapters, local area network interfaces, SCSI bus adapters, fill motion video, redundant error checking and correcting disk arrays, and the like. These sophisticated peripheral devices are capable of data transfer rates approaching the native speed of the computer system microprocessor central processing unit (“CPU”). The peripheral devices' data transfer speeds are achieved by connecting the peripheral devices to the microprocessor(s) and associated system random access memory through high-speed expansion local buses. Most notably, a high speed expansion local bus standard has emerged that is microprocessor independent and has been embraced by a significant number of peripheral hardware manufacturers and software programmers. This high-speed expansion bus standard is called the “Peripheral Component Interconnect” or “PCI.” A more complete definition of the PCI local bus may be found in the PCI Local Bus Specification, revision 2.1; PCI/PCI Bridge Specification, revision 1.0; PCI System Design Guide, revision 1.0; PCI BIOS Specification, revision 2.1, and Engineering Change Notice (“ECN”) entitled “Addition of ‘New Capabilities’ Structure,” dated May 20, 1996, the disclosures of which are hereby incorporated by reference. These PCI specifications and ECN are available from the PCI Special Interest Group, P.O. Box 14070, Portland, Oreg. 97214.[0006]
A computer system has a plurality of information (data and address) buses such as a host bus, a memory bus, at least one high speed expansion local bus such as the PCI bus, and other peripheral buses such as the Small Computer System Interface (SCSI), Extension to Industry Standard Architecture (EISA), and Industry Standard Architecture (ISA). The microprocessor(s) of the computer system communicates with main memory and with the peripherals that make up the computer system over these various buses. The microprocessor(s) communicates to the main memory over a host bus to memory bus bridge. The peripherals, depending on their data transfer speed requirements, are connected to the various buses which are connected to the microprocessor host bus through bus bridges that detect required actions, arbitrate, and translate both data and addresses between the various buses.[0007]
Increasingly sophisticated microprocessors have revolutionized the role of the personal computer by enabling complex applications software to run at mainframe computer speeds. The latest microprocessors have brought the level of technical sophistication to personal computers that, just a few years ago, was available only in mainframe and mini-computer systems. Some representative examples of these new microprocessors are the “PENTIUM” and “PENTIUM PRO” (registered trademarks of Intel Corporation). Advanced microprocessors are also manufactured by Advanced Micro Devices, Cyrix, IBM and Motorola.[0008]
These sophisticated microprocessors have, in turn, made possible running complex application programs using advanced three dimensional (“3-D”) graphics for computer aided drafting and manufacturing, engineering simulations, games and the like. Increasingly complex 3-D graphics require higher speed access to ever-larger amounts of graphics data stored in memory. This memory may be part of the video graphics processor system, but, preferably, would be best (lowest cost) if part of the main computer system memory. Intel Corporation has proposed a low cost but improved 3-D graphics standard called the “Accelerated Graphics Port” (AGP) initiative. With AGP 3-D, graphics data, in particular textures, may be shifted out of the graphics controller local memory to computer system memory. The computer system memory is lower in cost than the graphics controller local memory and is more easily adapted for a multitude of other uses besides storing graphics data.[0009]
The proposed Intel AGP 3-D graphics standard defines a high-speed data pipeline, or “AGP bus,” between the graphics controller and system memory. This AGP bus has sufficient bandwidth for the graphics controller to retrieve textures from system memory without materially affecting computer system performance for other non-graphics operations. The Intel 3-D graphics standard is a specification that provides signal, protocol, electrical, and mechanical specifications for the AGP bus and devices attached thereto. This specification is entitled “Accelerated Graphics Port Interface Specification version 2.0,” dated May 4, 1998; and also “Accelerated Graphics Port Interface Specification version 1.0,” dated Jul. 31, 1996 are hereby incorporated by reference. The AGP specification, both versions 2.0 and 1.0, are available from Intel Corporation, Santa Clara, Calif.[0010]
The AGP interface specification uses the 66 MHz PCI (Revision 2.1) specification as an operational baseline, with three performance enhancements to the PCI specification which are used to optimize the AGP specification for high performance 3-D graphics applications. These enhancements are: 1) pipelined memory read and write operations, 2) de-multiplexing of address and data on the AGP bus by use of side-band signals, and 3) data transfer rates of 133 MHz for data throughput in excess of 500 megabytes per second (“MB/s”). The remaining AGP specification does not modify the PCI specification, but rather provides a range of graphics-oriented performance enhancements for use by 3-D graphics hardware and software designers. The AGP specification is neither meant to replace or diminish full use of the PCI standard in the computer system. The AGP specification creates an independent and additional high speed local bus for use by 3-D graphics devices such as a graphics controller, wherein the other input-output (“I/O”) devices of the computer system may remain on any combination of the PCI, SCSI, EISA and ISA buses.[0011]
To functionally enable this AGP 3-D graphics bus, new computer system hardware and software are required. This requires new computer system core logic designed to function as a host bus/memory bus/PCI bus to AGP bus bridge meeting the AGP specification, and new Read Only Memory Basic Input Output System (“ROM BIOS”) and Application Programming Interface (“API”) software to make the AGP dependent hardware functional in the computer system. The computer system core logic must still meet the PCI standards referenced above and facilitate interfacing the PCI bus(es) to the remainder of the computer system. In addition, new AGP compatible device cards must be designed to properly interface, mechanically and electrically, with the AGP bus connector. A suitable computer system employing the AGP specification is shown in FIG. 1. The prior art computer system has at least one[0012]central processing unit102 connected to ahost bus103 which, in turn, is connected to acore logic104. Thecore logic104 is a chipset of components for linking the systemrandom access memory106 via thememory bus105 to thehost bus103 and theprimary PCI bus109 throughDRAM control202. Thecore logic104 also contains the circuitry related to theAGP bus107, such as AGP tomemory bridge204 and the PCI tomemory bridge212. An AGP-compliant device, such as thevideo graphics controller110, is connected to theAGP bus107. In this example, avideo display112 is connected to thevideo graphics controller110. Various other I/O devices101 are connected to theprimary PCI bus109.
Both AGP bus transactions and PCI bus transactions may be run over the AGP interface. An AGP master (graphics) device may transfer data to system memory using either AGP transactions or PCI transactions. The[0013]core logic104 can access the AGP master device only with PCI transactions. Traffic on the AGP interface may consist of a mixture of interleaved AGP and PCI transactions. The access request and data queue structures are illustrated in FIG. 2.
AGP transactions are run in a split transaction fashion where the request for data transfer is “disconnected” from the data transfer itself. The AGP master initiates an AGP transaction with an access request. The[0014]core logic104 responds to the access request by directing the corresponding data transfer at a later time. The fact that the access requests are separated from the data transfers allows the AGP master to issue several access requests in a pipelined fashion while waiting for the data transfers to occur. Pipelining access requests results in having several read and/or write requests outstanding in the core logic's request queue208 (within the AGP to memory bridge204) at any point in time. Therequest queue208 is divided into high priority and low priority sub-queues (not shown), each of which deal with respective accesses according to separate priority and ordering rules. The AGP master tracks the state of the request queue in order to limit the number of outstanding requests and identify data transactions.
The[0015]core logic104 processes the access requests present in itsrequest queue208. Read data will be obtained fromsystem memory106 and returned at the core logic's initiative via the read data returnqueue206. Write data will be provided by the AGP device at the core logic's direction when space is available in the core logic'swrite data queue210. Therefore, AGP transaction traffic will generally consist of interleaved access requests and data transfers.
All PCI transactions on the AGP have their own queues—separate from the AGP transaction queues. Each queue has its own access and ordering rules. Not shown in FIG. 2 is the core logic queue which handles processor accesses directly to the[0016]PCI target interface238 of the AGP master, all of which are executed as non-pipelined PCI bus transactions.
On the other end of the[0017]AGP bus107, the AGP-compliant device (e.g.,video graphics controller110 in FIG. 1) has anAGP interface230 with read data returnqueue232, read/writerequest queue234, and writedata queue236 that correspond to the readdata return queue206, read and writerequest queue208, and writedata queue210 of the AGP tomemory bridge204 within thecore logic104. The AGP-compliant device also has aPCI target interface238. The queues within theAGP interface230 and thePCI target interface238 are connected to the data source/sink239 of the device.
AGP and PCI device cards are not physically or electrically interchangeable even though there is some commonality of signal functions between the AGP and PCI interface specifications. The present AGP specification only makes allowance for a single AGP device on an AGP bus. Whereas the PCI specification allows two PCI devices on a PCI bus running at 66 MHz. The single AGP device is capable of functioning in both a 1× mode (264 MB/s peak) and a 2× mode (532 MB/s peak). The defined as either a 32 bit or 64 bit bus, or four or eight bytes per data transfer, respectively. The AGP bus, however, has additional side-band signals which enables it to transfer blocks of data more efficiently than is possible using a PCI bus.[0018]
An AGP bus running in the 2× mode provides sufficient video data throughput (532 MB/s peak) to allow increasingly complex 3-D graphics applications to run on personal computers. Some personal computer uses do not require high end 3-D graphics, but would greatly benefit from having an additional AGP card slot for accepting an additional input-output device such as another video graphics card (dual head monitors), a high speed network interface card (“NIC”), a SCSI adapter, a wide area network digital router, and the like. Since the AGP specification is comprised of a superset of the 66 MHz, 32 bit PCI specification, a PCI device may also function on the AGP bus (different card slot connectors for the AGP and PCI device cards would be necessary). Thus, embedded (directly connected to the computer system motherboard) or card slot pluggable AGP and PCI devices could share the same AGP/PCI bus, controller and arbiter of a core logic chipset used in a computer system.[0019]
What is needed is a computer system that can accommodate more than one AGP-compatible device and that has increased bandwidth to accommodate the increased number of AGP-compatible devices.[0020]
SUMMARY OF THE INVENTIONThe present invention overcomes the above-identified problems as well as other shortcomings and deficiencies of existing technologies by providing in a computer system an AGP to AGP bridge that is capable of linking one or more AGP-compatible devices to a standard AGP bus that is connected to a standard AGP-compatible core logic chipset. Specifically, the present invention provides a computer system having at least one central processing unit, system memory, and a core logic capable of accepting an AGP bus. An AGP to AGP bridge is also provided that is connected to the standard AGP bus of the core logic. The AGP to AGP bridge can accommodate two or more AGP-compatible devices that can be accessed through the standard AGP bus via the AGP to AGP bridge. A PCI to memory bridge is also provided within the core logic that is connected to the AGP bus so that PCI devices may be connected to the AGP to AGP bridge and communicate with the core logic. The AGP to AGP bridge is fitted with an overall flow control logic that controls the transfer of data to or from the various AGP devices and the standard AGP bus that is connected to the core logic of the computer system.[0021]
In the preferred embodiment of the present invention, the AGP to AGP bridge has a second AGP bus and a third AGP bus. If more than two buses are present on the AGP to AGP bridge, then the control of the internal, multiple FIFOs is managed by having a data flow pointer that keeps track of how many bytes of the returning read data belong to which AGP device. The AGP to AGP bridge of the present invention can utilize a standard 32-bit AGP bus. Furthermore, the AGP to AGP bridge can be constructed as a 64-bit bus that is bifurcated into two (dual) 32-bit buses in order to enhance bandwidth. The latter embodiment allows the dual primary AGP buses to work directly with the standard (32-bit) AGP chipset. To the core logic chipset, each AGP bus behaves fully as a standard AGP device but can operate concurrently. This allows each AGP device to have its own private bus and to run at maximum speed concurrently. Another advantage of this alternate embodiment is that it can support any number of AGP devices/slots on the secondary AGP buses.[0022]
In yet another alternate embodiment of the present invention, the dual 32-bit buses can be combined to form a single 64-bit bus to increase the available bandwidth. In this alternate embodiment, the AGP to AGP bridge can be an external application specific integrated circuit (ASIC) that interfaces directly with the standard AGP core logic chipset. To the core logic chipset, the AGP to AGP bridge behaves fully as a superset of the standard 32-bit AGP device. This allows doubling of the bus bandwidth without running the bus at higher clock frequencies, i.e. 2×66 MHz. Currently, most AGP devices could not meet the AC timing at 66 MHz. Therefore, this alternate embodiment is the only viable solution for doubling the bus bandwidth without running the bus at 133 MHz. In yet another alternate embodiment, the AGP to AGP bridge can accommodate the single 64-bit AGP bus (connected to a special 64-bit core logic chipset) for increased performance.[0023]
In yet another alternate embodiment of the present invention, the AGP to AGP bridge acts as a bus repeater and allows the AGP to AGP bridge to work with standard “off-the-shelf” bi-directional transceivers or FIFOs. The alternate embodiment enables the AGP bus to be extended, thus allowing the computer system to support more than one AGP device/slot. However, this alternate embodiment adds additional latency to all the bus transactions and requires the core logic chipset to control the data flow from both directions.[0024]
Other and further features and advantages will be apparent from the following description of presently preferred embodiments of the invention, given for the purpose of disclosure and taken in conjunction with the accompanying drawings.[0025]
BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 is a block diagram of a prior art computer system;[0026]
FIG. 2 is a block diagram of a prior art AGP device interface with the core logic of a computer system;[0027]
FIG. 3 is a block diagram of a computer system of the present invention;[0028]
FIG. 4[0029]ais a block diagram of an embodiment of the AGP to AGP bridge of the present invention;
FIG. 4[0030]bis a block diagram of the preferred embodiment utilizing the AGP to AGP bridge of the present invention;
FIG. 4[0031]cis a block diagram of an alternate embodiment utilizing the AGP to AGP bridge of the present invention;
FIG. 4[0032]dis a block diagram of an alternate embodiment utilizing the AGP to AGP bridge of the present invention;
FIG. 4[0033]eis a block diagram of the preferred embodiment of the AGP to AGP bridge of the present invention;
FIG. 5 is a block diagram of the PCI to PCI bridge of the present invention;[0034]
FIG. 6 is a flowchart of the function of the Second AGP Bus Request Interface of the present invention;[0035]
FIG. 7 is a flowchart of the function of the Second AGP Bus Reply Interface of the present invention;[0036]
FIG. 8 is a flowchart of the function of the Third AGP Bus Request Interface of the present invention;[0037]
FIG. 9 is a flowchart of the function of the Third AGP Bus Reply Interface of the present invention;[0038]
FIG. 10 is a flowchart of the function of the First AGP Bus Request Interface of the present invention;[0039]
FIG. 11 is a flowchart of the function of the First AGP Bus Reply Interface of the present invention;[0040]
FIG. 12 is a block diagram showing the state machines within the Control Flow Logic of the present invention;[0041]
FIG. 13 is a flowchart for the first state machine within the Flow Control Logic of the present invention;[0042]
FIG. 14 is a flowchart for the second state machine within the Flow Control Logic of the present invention;[0043]
FIG. 15 is a flowchart for the third state machine within the Flow Control Logic of the present invention;[0044]
FIG. 16 is a block diagram of an alternate embodiment of the present invention;[0045]
FIG. 17 is a flowchart for peer-to-peer enabled requests of the second AGP read and write request queue;[0046]
FIG. 18 is a flowchart for peer-to-peer enabled requests of the third AGP read and write request queue;[0047]
FIG. 19 is a flowchart for peer-to-peer replies in the second AGP read and write request queue;[0048]
FIG. 20 is a flowchart for peer-to-peer replies in the third AGP read and write request queue.[0049]
FIG. 21 is a flowchart for peer-to-peer write request in the second AGP write data queue; and[0050]
FIG. 22 is a flowchart for peer-to-peer write requests in the third AGP write data queue.[0051]
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTSThe present invention is an apparatus, method and system for providing an AGP to AGP bus in a computer system that is capable of allowing multiple AGP devices to be connected to a single AGP bus on a core logic chipset.[0052]
The AGP bus was developed to have sufficient data bandwidth for a video controller in a computer system, up to 532 megabytes per second (“MB/s”), to run increasingly complex three dimensional (“3-D”) graphics applications such as, for example, games and engineering simulations. Not all computer applications, however, require the capability of running 3-D graphics at 532 MB/s, but would greatly benefit by having an additional AGP card slot or PCI card slot for another video graphics card, a high speed NIC, a SCSI adapter, a wide area network digital router, or the like. Computers used as network servers or workstations would greatly benefit by having the ability to use two AGP devices, or an AGP device and a PCI device at a combined data transfer rate of 532 MB/s or 264 MB/s per device. In addition, disclosed hereinbelow is an embodiment of the present invention that is capable of data transfer rates of 532 MB/s for each AGP device.[0053]
For illustrative purposes, preferred embodiments of the present invention are described hereinafter for computer systems utilizing the Intel x86 microprocessor architecture and certain terms and references will be specific to that processor platform. AGP and PCI are interface standards, however, that are hardware independent and may be utilized with any host computer designed for these interface standards. It will be appreciated by those skilled in the art of computer systems that the present invention may be adapted and applied to any computer platform utilizing the AGP and PCI interface standards.[0054]
The PCI specifications referenced above are readily available and are hereby incorporated by reference. The AGP specification referenced above is readily available from Intel Corporation, and is hereby incorporated by reference. Further definition and enhancement of the AGP specification version 1.0 referenced above is more fully defined in “Compaq's Supplement to the ‘Accelerated Graphics Port Interface Specification Version 1.0’,” Revision 0.8, dated Apr. 1, 1997, and was included in commonly owned co-pending U.S. patent application Ser. No. 08/853,289, filed May 9, 1997, entitled “Dual Purpose Apparatus, Method and System for Accelerated Graphics Port and Peripheral Component Interconnect” by Ronald T. Horan and Sompong P. Olarig, and which is hereby incorporated by reference.[0055]
Referring now to the drawings, the details of preferred embodiments of the present invention are schematically illustrated. Like elements in the drawings will be represented by like numbers, and similar elements will be represented by like numbers with a different lower case letter suffix. Referring now to FIG. 3, a schematic block diagram of a computer system utilizing the present invention is illustrated. A computer system is generally indicated by the numeral[0056]100 and comprises a central processing unit102 (“CPU”),core logic104, system random access memory106 (“RAM”), avideo graphics controller110, alocal frame buffer108, avideo display112, a PCI/SCSI bus adapter114, a PCI/EISA/ISA bridge116, and a PCI/IDE controller118. Multiplevideo graphics controllers110,local frame buffers108 andvideo displays112 can be added to the added to thecomputer system100. Single or multilevel cache memory (not illustrated) may also be included in thecomputer system100 according to the current art of microprocessor computer systems. Thecentral processing unit102 may be a plurality ofCPUs102 in a symmetric or asymmetric multi-processor configuration.
The[0057]central processing unit102 is connected to thecore logic104 through ahost bus103. Thesystem RAM106 is connected to thecore logic104 through amemory bus105. The video graphics controller(s)110 is connected to thecore logic104 through thefirst AGP bus107. Thevideo graphics controller110 is an AGP-compatible device in that it is capable of being connected to and accept/write messages from/to thefirst AGP bus107. Video graphics controllers are not the only devices that are AGP-compatible. Other devices, such as a second I/O device166 may have this capability. In the preferred embodiment of the present invention, two AGP devices may be connected to AGP toAGP bridge160. In the preferred embodiment of the present invention, the AGP toAGP bridge160 is an application specific integrated circuit (ASIC) that interfaces directly with thestandard AGP chipset104. To thecore logic104 chipset, the AGP toAGP bridge160 behaves fully as a standard AGP device. Therefore, the 32-bit version of the AGP to AGP bridge160 of the present invention does not require any special side-band control signals other than the standard AGP bus protocol as would be required by a bus repeater. However, the 64-bit version of the AGP to AGP bridge160 of the present invention would require a special side-band control signal. Finally, in an alternate embodiment of the present invention, a bus repeater could be substituted for the AGP toAGP bridge160.
In the preferred embodiment of the present invention, the AGP to AGP bridge[0058]160 links two AGP buses to thefirst AGP bus107. This allows the control of the internal FIFOs to be simplified. An internal arbiter in the flow control logic260 (see FIG. 4a) can keep track of the outstanding requests on the primary (first) AGP bus based upon the currently active bus grant signal. However, in an alternate embodiment of the present invention, the AGP toAGP bridge160 may be expanded to include any number of AGP buses for each AGP toAGP bridge160, such as afourth AGP bus168 as shown in FIG. 3. In this alternate embodiment, the control of the internal multiple FIFOs can be managed by having a data flow pointer within theflow control logic260 that keeps track of how many bytes of the returning read data belong to which AGP device. In either embodiment, by linking the AGP toAGP bridge160 to thefirst AGP bus107, the trace length between the AGP device and thecore logic104 is increased moderately. However, the point-to-point lengths (e.g., between thecore logic104 and the first AGP interface target andarbiter248 is reduced, thereby allowing the AGP devices to run at a higher (or maximum) clock frequency. This configuration allows each AGP port to run at its maximum speed without additional electrical loading while maintaining signal integrity. Furthermore, use of the AGP toAGP bus160 allows the AGP devices attached thereto to reside farther away, physically, from the core logic104 (i.e., the motherboard) that was heretofore possible, enabling a wider range of choices for the physical configuration of the computer system.
Alternatively, the preferred embodiment of the AGP to AGP bridge[0059]160 (i.e., one that connects two AGP buses to the standard single AGP bus), may be connected to other AGP toAGP bridges160 in a tree like structure in order to obtain the desired number ofAGP devices166 as shown in FIG. 16.
In yet another alternate embodiment of the present invention, the AGP to AGP bridge is replaced with a bus repeater. In this embodiment, the bus repeater utilizes “off-the-shelf” bi-directional transceivers or FIFOs. This alternate embodiment enables an even wider range of choices for the physical placement of the AGP devices, which can be located remotely from the core logic unit and allows the computer system to support more than one AGP device/slot. However, this alternate embodiment adds additional latency to all the bus transactions and requires the core logic chipset to control the data flow from both directions.[0060]
As shown in FIG. 3, The PCI/[0061]SCSI bus adapter114, PCI/EISA/ISA bridge116, and PCI/IDE controller118 are connected to thecore logic104 through aprimary PCI bus109. Also connected to thePCI bus109 are a network interface card122 (“NIC”) and a PCI/PCI bridge124. Some of the PCI devices such as theNIC122 and PCI/PCI bridge124 may plug into PCI connectors on thecomputer system100 motherboard (not illustrated).
Again referring to FIG. 3,[0062]hard disk130 andtape drive132 are connected to the PCI/SCSI bus adapter114 through aSCSI bus111. TheNIC122 is connected to alocal area network119. The PCI/EISA/ISA bridge116 connects over an EISA/ISA bus113 to a ROM-BIOS140, non-volatile random access memory142 (“NVRAM”),modem120, and input-output controller126. Themodem120 connects to antelephone line121. The input-output controller126 interfaces with akeyboard146, real-time clock144 (“RTC”),mouse148, floppy disk drive150 (“FDD”), as well asserial port152 andparallel port154. ACD ROM drive134 and adisk drive128 can be connected to PCI/IDE controller118. The EISA/ISA bus113 is a slower information bus than thePCI bus109, but it costs less to interface with the EISA/ISA bus113.
AGP, being a superset of PCI, uses the PCI signals along with some side band signals in order to operate. The AGP side band signals are PIPE#, RBF#, and ST[2:0]. The optional AGP signals are side-band address ports SBA[7:0], AD_STB[1:0], and SB_STB. The above-mentioned signals can be used for performance enhancements, such as 2× (double-speed) mode and side-band addressing. The AGP-compliant device must also be a PCI slave (although PCI master status is optional). The use of side-band signaling enables the transfer of data on both the rising and falling edge of the clock cycle, effectively doubling the data transfer rate. The AGP-compliant device (“AGP device”) is an AGP master only, and the[0063]core logic104 acts as an AGP target only.
In the preferred embodiment of the present invention, the[0064]first AGP bus107 is a standard 32-bit bus. However, in an alternate embodiment of the present invention, theAGP bus107 may consist of a 64-bit bus that acts as two dual 32-bit AGP buses. An alternate embodiment of the AGP to AGP bridge160 of the present invention can utilize the dual 32-bit buses to enhance bandwidth, or, alternatively, the preferred embodiment of the AGP to AGP bridge160 of the present invention can be fitted onto each of the dual 32-bit AGP buses, thereby allowing secondary and tertiary AGP buses. This alternate embodiment allows the dual primary AGP buses to work directly with the standard AGP chipset. To the core logic chipset, each AGP bus behaves fully as a standard AGP device but can operate concurrently. This allows each AGP device to have its own private bus and to run at maximum speed concurrently. Another advantage of this alternate embodiment is that it can support any number of AGP devices/slots on the secondary AGP buses.
In yet another alternate embodiment of the present invention, the 64-bit bus is not bifurcated. Instead, the 64-bit bus is utilized (with a special core logic chipset) to increase the available bandwidth. In this alternate embodiment, the AGP to AGP bridge can be an external ASIC that interfaces directly with the standard AGP core logic chipset. To the core logic chipset, the AGP to AGP bridge behaves filly as a superset of the standard 32-bit AGP device. This allows doubling of the bus bandwidth without running the bus at higher clock frequencies, i.e. 2×66 MHz. Currently, most AGP devices may not meet the AC timing at 66 MHz. Therefore, this alternate embodiment may be the only viable solution for doubling the bus bandwidth without running the bus at 133 MHz. An alternate embodiment of the AGP to AGP bridge can accommodate the single 64-bit AGP bus for increased performance.[0065]
In yet another embodiment of the present invention, the[0066]first AGP bus107 is a 64-bit bus that is utilized as a single 64-bit AGP bus. The 64-bit bus provides additional data bandwidth for the agent or system that requires it. In this alternate embodiment, the AGP toAGP bridge160 can be an external ASIC that interfaces directly with thecore logic104 without requiring modification of thecore logic104. To thecore logic104, the AGP toAGP bridge160 with the 64-bit AGP bus107 behaves as a superset of the standard 32-bit AGP device. This alternate embodiment allows the doubling of the bus bandwidth without running the bus at higher clock frequencies, i.e., the effective bandwidth is twice that of the current 66 MHz clock speed. This relieves the necessity of running thefirst AGP bus107 at 133 MHz to obtain acceptable bandwidth.
When running the two 32-bit buses as a single 64-bit bus, the following signals are needed for 64-bit operation, Request (REQ64#), ACK64#, C/BE[7:4]#, AD[63:32], and ST[3:2]. In this scenario, the 64-bit agent must default to 32-bit mode unless a 64-bit transaction is negotiated. Since there is only one AGP device supported by the[0067]standard core logic 104 chipset, the 64-bit bus transaction can be statically negotiated during POST. REQ64# can be drive low by the AGP 64-bit master and ACK64# can be asserted low by the 64-bit device target. This situation is unlike the PCI which are dynamically negotiated once per transaction between the master and the target. If REQ64# and ACK64# are not both active, then the standard 32-bit AGP bus operation is performed instead of the 64-bit bus operation. Both REQ64# and ACK64# are externally pulled up to ensure proper behavior when mixing 32-bit and 64 bit agents if multiple AGP agents are supported.
Although there is no ordering relationship between AGP and PCI, the AGP specification does have some ordering requirements. First, the AGP-compliant target must return read data in the same order as it was requested. Second, AGP write operations are processed by the AGP-compliant target in the order in which they are requested. Third, read data that is returned will be coherent with previously issued AGP write requests. Fourth, an AGP write may bypass one or more previously issued AGP read operations. The fifth requirement is that PCI transactions initiated by an AGP-compliant master or AGP-compliant target must follow the ordering rules specified in the PCI specification. Sixth, high priority reads and writes have the highest priority for memory services. Seventh, an AGP flush command will return after all previous low priority and high priority write commands have been completed. The final requirement is that an AGP fence command forces write commands after itself in order not to pass any read commands before itself.[0068]
The system architecture of the AGP to AGP bridge[0069]160 of the present invention is shown in FIG. 4a. The AGP toAGP bridge160, in support of the AGP specification, has aPCI interface161, with the remainder of thebridge160 being devoted to AGP-related transactions. ThePCI interface161 is connected to the first interface target andarbiter248. ThePCI interface161 is also connected to the second interface target andarbiter258 and to the third interface target andarbiter278. Because there are no ordering requirements between the PCI and the AGP transactions, the PCI and the AGP sections can act independently of each other. The AGP to AGP bridge160 of the present invention therefore allows other I/O controllers to take advantage of the AGP bus in systems that are not fully utilizing the AGP bus bandwidth.
FIG. 4[0070]ashows two AGP buses, thesecond AGP bus162 and thethird AGP bus164, both being bridged into a singlefirst AGP bus107. Thefirst AGP bus107 is connected to thecore logic104. Each bus has a read/write request queue, a read data return queue, and a write data queue. As mentioned before, AGP transactions are split transactions. Read and write requests are queued up initially and then each request is serviced one-by-one according to the ordering relationship mentioned above. The AGP toAGP bridge160 is a target on thesecond AGP bus162 and thethird AGP bus164. Consequently, an arbiter is required for thesecond AGP bus162 and thethird AGP bus164. The AGP toAGP bridge160 is a master on thefirst AGP bus107.
In the preferred embodiment of the present invention, the AGP to AGP bridge[0071]160 of the present invention has three sets of AGP interfaces, each of which contains three queues. As per the AGP specification, thefirst AGP interface240 has a first read data returnqueue242, first read and writerequest queue244, and a firstwrite data queue246. The first read data returnqueue242 must have a minimum of 72 bytes. In the preferred embodiment of the present invention, the first read data return queue should have 296 bytes to ensure adequate performance. Of the 296 bytes, 40 bytes should be reserved for RBF# (Read Buffer Full) spillover. The RBF# spillover is to be used when the master interface on thefirst AGP bus107 has asserted an RBF# after the target has initiated a response. In this case, the master must have a few bytes of buffer space in order to receive the read data from the target. This is for compliance with the AGP specification, which requires that a generic AGP device must have 40 bytes of buffer space available for this purpose.
The[0072]first AGP interface240 is of conventional design so that, to thefirst AGP bus107, the AGP toAGP bridge160 appears to be just a standard AGP device and is thus treated as such. Furthermore, the AGP toAGP bridge160 card fits into a standard AGP port that is connected to thefirst AGP bus107. This enables any computer system with an AGP-compatible core logic and AGP port to accommodate the present invention without any hardware changes whatsoever.
The[0073]first AGP interface240 is connected to thesecond AGP interface250 and thethird AGP interface270 as shown in FIG. 4a. Thesecond AGP interface250 is connected to the second interface target andarbiter258. Similarly, the third interface target andarbiter278 is connected to thethird AGP interface270. Thesecond AGP interface250 has a second read data returnqueue252, a second read and writerequest queue254, and a secondwrite data queue256 that correspond to the three queues in thefirst AGP interface240. The second read data returnqueue252 must have a minimum of 32 bytes. Thethird AGP interface270 has a third read data returnqueue272, a third read and writerequest queue274, and a thirdwrite data queue276. The third read data returnqueue272 must have a minimum of 32 bytes. The second read data returnqueue252 is connected to the first read data returnqueue242. Similarly, the third read data returnqueue272 is also connected to the first read data returnqueue242 as shown in FIG. 4a. Likewise, the second read and writerequest queue254 and the third read and writerequest queue274 are both connected to the first read and writerequest queue244. Finally, the secondwrite data queue256 and the thirdwrite data queue276 are connected to the firstwrite data queue246. The first writedata return queue246, the second writedata return queue256, and the third writedata return queue274 all must have a minimum of 64 bytes available because 64 bytes is the size of the longest write on an AGP bus. All of the elements within the AGP toAGP bridge160, with the sole exception of thePCI interface161, are connected to theflow control logic260 as shown in FIG. 4a. ThePCI interface161 is an intermediary that connects the first AGP interface. The function of theflow control logic260 will be explained below.
FIG. 4[0074]bshows a block diagram of the preferred embodiment of the present invention, wherein the AGP to AGP bridge160 (as shown in FIG. 4a) connects ageometry processor302 and arendering processor304 to thefirst AGP bus107. A geometry processor is used to generate triangles and geometric vertices. The output of thegeometry processor302 is then passed to therendering processor304 which performs post processing and forwards the resultant information to the graphics display (e.g., a monitor or screen). In the typical scenario, thegeometry processor302 obtains raw data from theCPU102 or thesystem memory106 via thecore logic104, theAGP bus107, and the AGP toAGP bridge160. Similarly, therendering processor304 receives texture data (typically from the system memory106) via the AGP toAGP bridge160. As shown in FIG. 4b, thegeometry processor302 is connected to the AGP toAGP bridge160 via thesecond AGP bus162. Similarly, therendering processor304 is connected to the AGP toAGP bridge160 via thethird AGP bus164. A separate connection between the second AGP Request andData Queues252 and the third AGP Request andData Queues270 is included in the present invention as shown in FIG. 4b. The separate connection between second AGP Request andData Queues252 and the third AGP Request andData Queues270 enables direct transfer of geometric vertices and other data from thegeometry processor302 to therendering processor304 without tying up bandwidth or other resources outside of the AGP toAGP bridge160. Furthermore, if necessary, the overallflow control logic260 can enable information to be transferred to both thegeometry processor302 and therendering processor304 simultaneously. More importantly, however, thegeometry processor302 can communicate with therendering processor304 without having to go through thecore logic104. This relieves thecontrol logic104 to perform other tasks, thereby increasing the overall performance of the computer system. More detail of the preferred embodiment of the AGP to AGP bridge can be found later in the discussion of FIG. 4e.
An alternate embodiment of the present invention is illustrated in FIG. 4[0075]c. In this embodiment, the AGP toAGP bridge160, thegeometry processor302 and therendering processor304 all reside on a single printed circuit board (PCB) or PC card. This configuration enables a graphics intensive PC card to be built as a single unit and then plugged into theAGP bus107.
In yet another alternate embodiment of the present invention is illustrated in FIG. 4[0076]d. In this alternate embodiment, the AGP toAGP bridge160 is connected to theAGP bus107 in the normal fashion. However, unlike the embodiment shown in FIG. 4c, in this embodiment, thegeometry processor302 is embedded or resides on its owngeometry processor board303 which is a printed circuit board or PC card that is capable of accommodating ageometry processor board303. Similarly, therendering processor304 is embedded on its ownrendering processor board305 as shown in FIG. 4d. As with thegeometry processor board303, therendering processor board305 is a printed circuit board or PC card that is capable of accommodating arendering processor304. This embodiment enables the geometry processor and the rendering processor to be upgraded or replaced separately, without affecting the rest of the computer system. In this alternate embodiment, the AGP toAGP bridge160 does not reside on either thegeometry processor board303 or therendering processor board304. Instead, the AGP toAGP bridge160 could reside on its own PCB or PC card, or it can be incorporated into thecore logic chipset104. This configuration, therefor, provides added flexibility.
FIG. 4[0077]eis a block diagram of the preferred embodiment of the AGP to AGP bridge of the present invention. The preferred embodiment AGP toAGP bridge160 differs from the embodiment illustrated in FIG. 4ain that the preferred embodiment accommodates peer to peer transfer between thegeometry processor302 and the rendering processor304 (of FIG. 4b). In order to accommodate peer-to-peer transfer, the second and third AGP interfaces have to be both a master and a target. However, according to the AGP specification, the device is always a master and the chipset is always a target. In the first embodiment of the AGP to AGP bridge160 (see FIG. 4a), standard AGP interfaces are used. For example thesecond AGP interface250 and thethird AGP interface270 were targets and thefirst AGP interface240 was a master.
In the preferred embodiment, the AGP to AGP bridge[0078]160 (shown in FIG. 4e) is designed to enhance the support of peer-to-peer traffic. The queue blocks (252,254, and256) of thesecond AGP interface250 are all bi-directional. Similarly, the queue blocks (272,274 and276) of thethird AGP interface270 are also bi-directional. Each bi-directional queue consists of two independent queues, one for each direction of traffic. For instance, there is a second AGP read and write request queue that contains requests from thesecond AGP bus162 and is meant for thefirst AGP bus107 or thethird AGP bus164. Similarly, there is another second AGP read and write request queue in the opposite direction which contains peer-to-peer requests from thethird AGP bus164 directed toward thesecond AGP bus162. The bi-directionality between thefirst AGP interface240, thesecond AGP interface250, and thethird AGP interface270 can be facilitated by use ofdata buses241,243 and245 as shown in FIG. 4e.
The overall[0079]flow control logic260 of the preferred embodiment must be cognizant of the peer-to-peer address ranges supported by each AGP bus. The overallflow control logic260 must be able to recognize from the address of the request whether or not it is a peer-to-peer or a bridge-to-host access. For example, when there is a request in the second AGP read and writerequest queue254, the overallflow control logic260 determines whether the request is a peer-to-peer transaction or a bridge-to-host access. If the request is a peer-to-peer transaction, then the request is sent to the third AGP read and writerequest queue274 viabus243. Otherwise, the request is sent to the first AGP read and writerequest queue244. Likewise, when there is a request in the third AGP read and writerequest queue274, the overallflow control logic260 determines whether the request is a peer-to-peer transaction or a bridge-to-host access. If the request is a peer-to-peer transaction, the request is sent to the second AGP read and writerequest queue254 viabus243. Otherwise, the request is sent to the first AGP read and writerequest queue244 viabus243. This method is described in the flow diagram in FIGS. 17 and 18.
The flow of data is illustrated in FIGS.[0080]17-20. The discussion of FIGS.17-20 is found later in this specification. It should be noted however that the process of actually transferring the request from the second AGP queues to the third AGP queues, or vice versa, is similar to the transfer of request from the second AGP queue or the third AGP queue to the first AGP queue. If the request is a read request, then the read request is transferred to the other queue if there is space in that other queue. If the request is a write request, then the write request must be transferred and also the write data must also be transferred.
When there is a read request (originated from the third AGP bus) that needs to be run on the[0081]second AGP bus162, the second AGP read and writerequest queue254 is responsible for initiating the read transaction on the bus. Once the data has been returned to the second AGP read data returnqueue252, the data is then transferred internally to the third AGP read data returnqueue272. Likewise, when there is a read request (originated from the second AGP bus) that needs to be run on the third AGP bus, the third AGP read and write request queue is responsible to initiate the read transaction on the bus. Once the data has been returned to the third AGP read data returnqueue272, the data is then transferred internally to the second AGP read data returnqueue252. This flow is similar to a read request from thefirst AGP interface240 and the transfer of the read reply to thesecond AGP interface250 or to thethird AGP interface270 as illustrated in FIGS. 11, 14 and15.
When there is a write request originating form the[0082]third AGP bus164 that must be sent over thesecond AGP bus162, the second AGP read and writerequest queue254 is responsible for initiating the write transaction on the bus. The corresponding write data will be available in the second AGPwrite data queue256. Likewise, when there is a write request originating form thesecond AGP bus162 that must be sent over thethird AGP bus164, the third AGP read and writerequest queue274 is responsible for initiating the write transaction on the bus. The corresponding write data will be available in the third AGPwrite data queue276. This flow is similar to the completion of a write request from thefirst AGP interface240 as illustrated in FIG. 11.
FIG. 5 shows the block diagram of the[0083]PCI interface161 of the AGP to AGP bridge160 of the present invention. ThePCI interface161 is connected to theAGP bus107. ThePCI interface161 has a first PCI master/target interface238 that connects theAGP bus107 to a first PCItarget state machine282 and a first PCImaster state machine284. The first PCItarget state machine282 is connected to a second PCImaster state machine288 and a third PCItarget state machine296. The first PCImaster state machine284 is connected to a second PCItarget state machine286 and a third PCItarget state machine298 as shown in FIG. 5. The second PCItarget state machine286 and the second PCImaster state machine288, in turn, are connected to a second PCI master/target arbiter290. Likewise, the third PCItarget state machine296 and the third PCImaster state machine298 are connected to the third PCI master/target arbiter292.
Operation of the Second and Third Read and Write Request Queue[0084]
When the AGP device on either the[0085]second AGP bus162 or thethird AGP bus164 needs to send a request to the AGP toAGP bridge160, they will first assert the Request (REQ#) line. When the corresponding queues (second read and writerequest queue254 and third read and write request queue274) have space to accept this request, the AGP toAGP bridge160 will assert a Grant (GNT#) and the appropriate bits in the PCI status register (not shown). The AGP device will start transferring the request by asserting PIPE# or using the side-band addressing mentioned previously. The address, command, and length is stored in the second read and writerequest queue254 and third read and writerequest queue274. The AGP toAGP bridge160 can do this simultaneously for both buses. When the master has completed transferring all the requests it has, the AGP toAGP bridge160 will process the write commands. The master will need to get write data into the AGP toAGP bridge160 so that, when thecore logic104 requests the data, the master will have the data available. The master will assert GNT# and set a status bit indicating a write request on the corresponding bus. The master will store the write data in the write data queues (either the secondwrite data queue256 or the thirdwrite data queue276, depending upon whether the master is connected to thesecond AGP bus162 or thethird AGP bus164, respectively).
The read and write request queues ([0086]244,254,274) will do all the ordering inside its queue block. Each read and write request queue will have a separate queue for high priority reads and writes in order to allow the queue to bypass the low priority requests. The read and write request queues (244,254,274) will also accommodate other ordering rules such as writes bypassing reads, fence and flush.
Operation of the Second and Third Write Data Queues[0087]
When the AGP to[0088]AGP bridge160 executes a write cycle on the AGP buses, it stores the write data in the write data queues (246,256, and276). The write data will be stored in the same order in which it was received on the bus. However, it may not be practical to allocate space for the maximum allowable length of write accesses for the situation where all accesses in the queue are writes. Therefore, in the preferred embodiment of the present invention, write data queue space will be limited and the AGP toAGP bridge160 can only run write cycles on thefirst AGP bus107 when the AGP toAGP bridge160 has space in the firstwrite data queue246 to accept the entire write data.
Operation of the First Read and Write Request Queue[0089]
In this scenario, the[0090]first AGP bus107 is affected and the AGP toAGP bridge160 is a master. The AGP toAGP bridge160 has to wait for a GNT# from the core logic104 (or, in an alternate embodiment of the present invention, other AGP bridges) before the AGP toAGP bridge160 can start transferring requests to thecore logic104. The first read and writerequest queue244 will accept requests from the second read and writerequest queue254 and the third read and writerequest queue274. TheAGP interface230 needs to follow all of the AGP ordering rules inside the first read and writerequest queue244. In the preferred embodiment of the present invention, the first read and writerequest queue244 will use some fair algorithm to service the second read and writerequest queue254 and the third read and writerequest queue274. Strict alternation is one option algorithm. However, it may be possible for the first read and writerequest queue244 to treat all accesses inside of itself equally. What this means is that, the first read and writerequest queue244 will allow all writes to bypass all reads regardless of whether the write came from thesecond AGP bus162 or thethird AGP bus164. The first read and writerequest queue244 will also block all future writes from bypassing reads if there is a fence access. This technique is non-optimal since accesses from thethird AGP bus164 do not care about ordering with accesses fromsecond AGP bus162. However, the implementation of this block will be simpler with this assumption. When requests are transferred from the second read and writerequest queue254, and the third read and writerequest queue274 to the first read and writerequest queue244, the originating bus number has to be kept track of, in order to be able to return the data to the right bus.
Operation of the First Write Data Queue[0091]
When a write request is transferred from the second read and write[0092]request queue254 or the third read and writerequest queue274 to the first read and writerequest queue244, the corresponding write data must be transferred from the secondwrite data queue256 or the thirdwrite data queue276 to the firstwrite data queue246. If the write data is not available in the secondwrite data queue256 or the thirdwrite data queue276 yet, then the write access should not be moved to the firstwrite data queue246. This might stall other accesses from proceeding through them even if they might have been capable of doing so. However, under this methodology, when the access is run on thefirst AGP bus107 and thecore logic104 needs the write data, the computer system will not have to stall the operation with excessive wait states which would be detrimental to performance.
Operation of the First Read Data Return Queue[0093]
When the[0094]core logic104 responds to a read request, the data is kept in the first read data returnqueue242. From there, the data is matched up with the originating request. The data is transferred to the corresponding second read data returnqueue252 or the third read data returnqueue272. Then the request can be retired from the first read and writerequest queue244.
Operation of the Second and the Third Data Return Queues[0095]
When there is read data in either the second read data return[0096]queue252 or the third read data returnqueue272, the AGP toAGP bridge160 asserts GNT# at the first opportunity, and then starts to transfer data to the AGP device that issued the read request. The random data that is returned on a fence operation is also returned through the second read data returnqueue252 or the third read data returnqueue272.
Operation of the Overall Flow Control Logic[0097]
The[0098]flow control logic260 is responsible for control of data between all the other blocks in the AGP toAGP bridge160. Requests can be transferred from the second read and writerequest queue254 and the third read and writerequest queue274 to the first read and writerequest queue244 only when there is space in the queue in the first read and writerequest queue244. Thesecond AGP interface250 and thethird AGP interface270 can accept requests from thesecond AGP bus162 and thethird AGP bus164, respectively, only when there is space in the second read and writerequest queue254 and the third read and writerequest queue274, respectively. Theflow control logic260 generally controls the flow from thesecond AGP interface250 and thethird AGP interface270 into thefirst AGP interface240. Theflow control logic260 also controls the flow of data back from thefirst AGP interface240 to thesecond AGP interface250 and thethird AGP interface270. Theflow control logic260 also controls the flow between the AGP toAGP bridge160 and the AGP interfaces (240,250 and270) on their respective AGP buses (107,162 and164).
The request operation of the second interface target and[0099]arbiter258 is illustrated in FIG. 6. The operation is started instep602. First, a check is made if there is a request on thesecond AGP bus162,step604. If no request is present,step604 is repeated until the result is positive (i.e., YES). If a request is present on thesecond AGP bus162, then the request is added to the second read and writerequest queue254,step606. Finally, instep608, the requests are reordered according to the appropriate ordering rules. In the preferred embodiment of the present invention, the ordering rules are a predefined set of ordering rules. However, it is within the scope of the present invention to utilize a dynamically created set of ordering rules based upon conditions at that instant time.
The reply operation of the second interface target and[0100]arbiter258 is illustrated in FIG. 7. The operation is started instep702. First, a control signal to start a transaction is received from theflow control logic260,step704. Next, instep706, three sub-steps take place. First, an arbitration is performed and a read reply transaction is started. Second, data is retrieved from the readdata return queue256. Third, wait states are inserted, if necessary, when instructed by theflow control logic260.
The request operation of the third interface target and[0101]arbiter278 is illustrated in FIG. 8. The operation is started instep802. First, a check is made if there is a request on thethird AGP bus164,step804. If no request is present,step804 is repeated until the result is positive (i.e., YES). If a request is present on thethird AGP bus164, then the request is added to the third read data returnqueue272,step806. Finally, instep808, the requests are reordered according to the appropriate ordering rules. In the preferred embodiment of the present invention, the ordering rules are a predefined set of ordering rules. However, it is within the scope of the present invention to utilize a dynamically created set of ordering rules based upon condition at that instant of time.
The reply operation of the third interface target and[0102]arbiter278 is illustrated in FIG. 9. The operation is started instep902. First, a control signal to start a transaction is received from theflow control logic260,step904. Next, instep906, three sub-steps take place. First, an arbitration is performed and a read reply transaction is started. Second, data is retrieved from the third read and writerequest queue274. Third, wait states are inserted, if necessary, when instructed by theflow control logic260.
The request operation of the[0103]first AGP bus107 is illustrated in FIG. 10. The operation is started instep1002. First, instep1004, a check is made to determine if a request is in the first read and writerequest queue244. If a request is present, (i.e., the result is YES), then step1006 is undertaken. Instep1006, a check is made to determine if additional request can be queued to the first interface target andarbiter248. It should be noted that the total number of requests that can be queued at any one time is programmed into each AGP master during the configuration setup. If further requests can be queued, then step1008 is performed. Duringstep1008, an arbitration is performed and the requests are queued. In addition, instep1008, the status of the request in the queue is changed if so requested.
The reply operation of the[0104]first AGP bus107 is shown in FIG. 11. The operation is started instep1102. First, a check is made to determine if there is a reply in thefirst AGP bus107,step1104. If so, then step1106 is performed where a check is made to determine if the reply is a write statement. If so,step1108 is performed, otherwise, execution jumps to step1110. Instep1108, data is supplied from the firstwrite data queue246. The data is then retired from the first read and writerequest queue244 and the first read data returnqueue242. Instep1110, a check is made to determine if the reply is a read statement. If so, execution continues ontostep1112, otherwise, execution jumps to step1120. Instep1112, the data is stored in the first read data returnqueue242 and the corresponding read request is moved to the first read data returnqueue242. Further, instep1112, theflow control logic260 is triggered to start moving this data towards either thesecond AGP bus162 or thethird AGP bus164. Next, instep1114, wait states at a subsequent block are inserted if the first read data returnqueue242 is full or is less than 32 bytes while in 2× mode or 16 bytes while in 1× mode until access has been completed on thefirst AGP bus107. Thereafter, instep1116, a check is made to see if an RBF# has been asserted. If so, then step1118 is executed wherein the buffer space that was reserved for RBF# spillover is utilized and an ASAP wait state is inserted on a subsequent boundary per the AGP specification. If not, execution skips to step1120. Instep1120, a check is made to determine if the reply is a fence. If so, then, instep1122, the access is completed and theflow control logic260 is triggered accordingly.
FIG. 12 illustrates the four major state machines implemented within the[0105]flow control logic260. Theflow control logic260 has several parallel and somewhat independent functions. Each of these functions will be described and illustrated below.
Referring again to FIG. 12, the[0106]first state machine1300 requests a transfer from either the second read and writerequest queue254 or the third read and writerequest queue274 to the first read and writerequest queue244. Thesecond state machine1400 is the control for the RBF#. Thethird state machine1500 is for read data transfers from the first read data returnqueue242 to either the second read data returnqueue252 or the third read data returnqueue272. Thefourth state machine1202 controls the information to the second interface target andarbiter258 and the third interface target andarbiter278 when a read access is completing on either of those buses, respectively.
The function of the[0107]first state machine1300 is shown in FIG. 13. The operation is started instep1302. First, a check is made to determine if the requested transfer is in the second read and writerequest queue254. If not, execution is jumped to step1324 to perform the same check with regard to the third read and writerequest queue274. If the requested transfer is in the second read and writerequest queue254, then execution continues to step1306 where a check is made to determine if the requested transfer is a write. If not, then execution jumps to step1314, otherwise, execution continues to step1308. Instep1308, a check is made to determine if the write was complete in thesecond AGP bus162. If so, then execution jumps to step1324, otherwise, execution continues on to step1310 where another check is made to determine if there is space in the firstwrite data queue246 for the entire access. If not, then execution jumps to step1324, otherwise, execution continues to step1312 wherein the write cycle is executed on thesecond AGP bus162 and the write data is stored in the firstwrite data queue246. The request is then marked as completed on thesecond AGP bus162 to completestep1312.
In[0108]step1314, a check is made to determine if space is available in the first read and writerequest queue244 of thefirst AGP bus107. If not, execution is looped back tostep1304, otherwise, execution continues ontostep1316. Instep1316, a check is made to determine if the request is a write. If not, execution is jumped to step1322, otherwise, execution continues on to step1318 where a check is made to determine if there is space in the firstwrite data queue246. If not, then execution is looped back tostep1304, otherwise, execution continues on to step1320 wherein the data and request are transferred and the first AGP queues are reordered according to the appropriate ordering rules. Execution then jumps to step1324. Instep1322, to which execution jumps if the request is not a write, the request is transferred and thefirst AGP bus107 queue is reordered according to the appropriate ordering rules.Steps1324 through1342 are similar tosteps1304 through1322 only that, in this case, the AGP bus affected is thethird AGP bus164 instead of thesecond AGP bus162. There are some minor differences, however.
In[0109]step1324, a check is made to determine if the request is in the third read and writerequest queue274. If not, execution is looped back to the start atstep1304, otherwise, execution continues to step1326. Instep1326, a check is made to determine if the request is a write statement. If not, execution is jumped to step1334, otherwise, execution continues on to step1328 where a check is made to determine if the write was complete in thethird AGP bus164. If so, then execution is jumped to step1334, otherwise, execution continues on to step1330 where a check is made to determine if space is available in the firstwrite data queue246 for the entire access. If not, execution is looped back tostep1324, otherwise, execution continues on to step1332 where the write cycle is executed on thethird AGP bus164 and the write data is stored in the firstwrite data queue246. The request is then marked as completed on thethird AGP bus164 to completestep1332.
In[0110]step1334, a check is made to determine if space is available in the first read and writerequest queue244. If not, execution is looped back tostep1324, otherwise, execution continues on to step1336 where a check is made to determine if the request is a write. If not, execution is jumped to step1342, otherwise, execution continues on to step1338 where a check is made to determine if space is available on the firstwrite data queue246. If not, execution is looped back tostep1324, otherwise, execution continues on to step1340 where the data and the request is transferred to the appropriate queues of thefirst AGP bus107 and those queues are reordered according to the ordering rules. Execution is then looped back to the start atstep1304. If the request is a not write, then, as mentioned before,step1342 is executed wherein the request is transferred to the appropriate queue in thefirst AGP bus107 and those queues are reordered according to the appropriate ordering rules.
The function of the[0111]second state machine1400 is illustrated in FIG. 14. Referring now to FIG. 14, the operation of the RBF# control is accomplished in the following steps. The process is started instep1402. First, instep1404, a check is made to determine if the next read on the first read and writerequest queue244 is small enough to fit within the internal buffer space in the AGP toAGP bridge160. If so, then execution is looped back tostep1404, otherwise, execution continues on to step1406 where a check is made to determine if the next read request is from thesecond AGP bus162. If not, execution is jumped to step1418 where the same check is made for thethird AGP bus164. Otherwise, execution continues on to step1408 where a check is made to determine if the RBF# on thesecond AGP bus162 has been asserted. If not, then execution is looped back tostep1404. Otherwise, execution continues on to step1410 where the RBF# for thefirst AGP bus107 is asserted. Next, instep1412, a check is made to determine if the RBF# of thesecond AGP bus162 has been de-asserted. If not, then step1412 is repeated. If so, then execution continues on to step1416 wherein the RBF# for thefirst AGP bus107 is de-asserted. Execution is then looped back tostep1404.
If the next read request was not from the[0112]second AGP bus162, then it must have come from thethird AGP bus164. In that case,step1418 is performed and, upon testing positive, a check is made to determine if the RBF# of thethird AGP bus164 has been asserted,step1420. If not, execution is looped back tostep1404, otherwise, execution continues to step1422 where the RBF# for thefirst AGP bus107 is asserted. Next, instep1424, a check is made to determine if the RBF# of thethird AGP bus164 has been de-asserted. If not,step1424 is repeated. Otherwise, instep1426, the RBF# of thefirst AGP bus107 is de-asserted and execution is looped back tostep1404.
The function of the[0113]third state machine1500 is illustrated in FIG. 15. FIG. 15 shows a flow diagram of a read data transfer from thesecond AGP bus162 or thethird AGP bus164 to thefirst AGP bus107. The process starts instep1502. Next, instep1504, a check is made to determine if there is a reply in the first read data return queue242 (even if the entire read data has not yet arrived). If so, then execution proceeds to step1506 where a check is made to determine if the reply is for thesecond AGP bus162. If not, execution shifts to step1512 in order to handle a transfer from thethird AGP bus164. Otherwise, execution proceeds to step1508 where a check is made to determine if there is sufficient space in the second read data returnqueue252. If so, execution proceeds to step1510 where the data is transferred (as it comes in) to the second read data returnqueue252. Also instep1510, the second interface target andarbiter258 is triggered to start a transaction on thesecond AGP bus162 and to complete the transfer of the entire requested size and, if the second read data returnqueue252 becomes full, to wait for it to empty.
If the reply is not for the[0114]second AGP bus162, then it must be for thethird AGP bus164, promptingstep1512 to be executed. Instep1512, a check is made to verify that the reply is for thethird AGP bus164. If so, then step1514 is executed wherein a check is made to determine if there is sufficient space available in the third read data returnqueue272. If so, then execution proceeds to step1516, where the data is transferred (as it comes in) to the third read data returnqueue272. Also instep1516, the third interface target andarbiter278 is triggered to start a transaction on thethird AGP bus164 and to complete the transfer of the entire requested size and, if the third read data returnqueue272 becomes full, to wait for it to empty.
Handling Peer-to-Peer Transactions[0115]
If the AGP to[0116]AGP bridge160 is to handle peer-to-peer transactions, several additional steps of the method of the present invention must be taken. For example, FIG. 17 illustrates the steps needed if there is a request in the second AGP read and write request queue254 (see FIG. 4e). First, the peer-to-peer enabled processing starts instep1702. Next, instep1704, a cheek is made to determine if there is a request in the second AGP read and writerequest queue254. If no request is present (i.e., the result ofstep1704 is “No”), then step1704 is repeated until a request is present. If a request is present, then a check is made to determine if the request is a peer-to-peer request,step1706. If the request is a peer-to-peer request (i.e., the result ofstep1706 is “Yes”), then the request is transferred to the third AGP read and writerequest queue274 of FIG. 4einstep1708. If the request is not a peer-to-peer request (i.e., the result ofstep1706 is “No”), then the request is transferred to the first AGP read and writerequest queue244 instep1710.
The situation of a request in the[0117]third AGP interface270 is similar to that of thesecond AGP interface250. For example, FIG. 18 illustrates the steps needed if there is a request in the second AGP read and write request queue274 (see FIG. 4e). First, the peer-to-peer enabled processing starts instep1802. Next, instep1804, a check is made to determine if there is a request in the third AGP read and writerequest queue274. If no request is present (i.e., the result ofstep1804 is “No”), then step1804 is repeated until a request is present. If a request is present, then a check is made to determine if the request is a peer-to-peer request,step1806. If the request is a peer-to-peer request (i.e., the result ofstep1806 is “Yes”), then the request is transferred to the second AGP read and writerequest queue254 of FIG. 4einstep1808. If the request is not a peer-to-peer request (i.e., the result ofstep1806 is “No”), then the request is transferred to the first AGP read and writerequest queue244instep1810.
In the case of peer-to-peer enabled embodiments AGP to AGP bridge[0118]160 of the present invention, replies are handled expeditiously. Recall that in the peer-to-peer enabled embodiment of the AGP to AGP bridge of the present invention the second AGP read and write request queues have two queues in order to enable bi-directionality. In the case of peer-to-peer replies, these are handled in a two step operation as shown in FIG. 19. The process starts instep1902. Instep1904, a check is made to determine if a reply is in the second AGP read data return queue252 (see FIG. 4e). If not,step1904 is repeated until a reply is in the queue. Otherwise, the reply is transferred to the third AGP readdata queue272. Similarly, peer-to-peer replies in the third AGP read data return queue is handled according to FIG. 20. The process starts instep2002. A check is made instep2004 to determine if a reply is in the third AGP read data return queue272 (see FIG. 4e). If not,step2004 is repeated until a reply is in the queue. Otherwise, the reply is transferred to the second AGP read data return queue instep2006.
Peer-to-peer requests are handled a similar manner to replies. For example, requests in the second AGP write data queue[0119]256 (see FIG. 4e) that are peer-to-peer are handled according to FIG. 21. The process starts atstep2102. Instep2104, a check is made to determine if a request is in the second AGP write data queue256 (see FIG. 4e). If not,step2104 is repeated until a request is in the queue. Otherwise, the request is transferred to the third AGPwrite data queue276 instep2106. Similarly, requests in the third AGP write data queue276 (see FIG. 4e) that are peer-to-peer are handled according to FIG. 22. The process starts atstep2202. Instep2204, a check is made to determine if a request is in the third AGP write data queue276 (see FIG. 4e). If not,step2204 is repeated until a request is in the queue. Otherwise, the request is transferred to the second AGPwrite data queue256 instep2206.
The present invention, therefore, is well adapted to carry out the objects and attain the ends and advantages mentioned, as well as others inherent therein. While the present invention has been depicted, described, and is defined by reference to particular preferred embodiments of the invention, such references do not imply a limitation on the invention, and no such limitation is to be inferred. The invention is capable of considerable modification, alternation, and equivalents in form and function, as will occur to those of ordinary skill in the pertinent arts. The depicted and described preferred embodiments of the invention are exemplary only, and are not exhaustive of the scope of the invention. Consequently, the invention is intended to be limited only by the spirit and scope of the appended claims, giving full cognizance to equivalents in all respects.[0120]