System and method for supporting access to multiple I/O hub nodes in a host bridge

[0001] U.S. patent application Ser. No. 09/569,574, filed concurrently herewith and entitled “SYSTEM AND METHOD FOR SHARING I/O ADDRESS TRANSLATION CACHING ACROSS MULTIPLE PCI HOST BRIDGES” is assigned to the same assignee hereof and contains subject matter related, in certain respect, to the subject matter of the present application. The above identified patent application is incorporated herein by reference.

[0002] 1. Technical Field of the Invention

[0003] This invention pertains to an I/O bus to host bridge in a processor system. More particularly, it relates to a PCI/host bridge apparatus and method providing redundant link connections in support of multiple I/O hubs.

[0004] 2. Background Art

[0005] A host bridge chip as defined by Peripheral Component Interconnect (PCI) Local Bus Specification provides an interconnect between an I/O subsystem and one or more processors in a processing system. (See PCI 2.2 spec: “PCI Local Bus Specification” Revision 2.2, Dated Dec. 18, 1998.)

[0006] A PCI host bridge provides an interconnect between an I/O subsystem and one or more processors in a processing system. A host bridge typically provides data buffering capabilities for transferring read and write data between the I/O subsystem and the processors. Read and write commands or transactions that originate on the PCI bus and are destined for system memory are typically referred to as DMAs.

[0007] A PCI host bridge may also provide a means for translating addresses from a PCI memory address space to a system memory address space. A host bridge chip may provide a hardware mechanism to fetch table entries from system memory which describe how to map PCI addresses into system memory addresses. The host bridge uses a table entry to determine the system memory location to which a DMA operation will be directed.

[0008] The prior art provides support for a host bridge talking to a processor complex through an I/O hub chip over communications links between the host bridge and an I/O hub chip. Redundant communications links are provided to prevent a failure of a single communications link from disrupting communication between a host bridge and I/O hub chip. These communications links can be connected in a ring configuration where multiple host bridge chips and I/O hub chips are connected to the ring. A host bridge is configured to communicate with only one I/O hub chip, however, and must be reconfigured if communications with another I/O hub chip is desired.

[0009] It is desirable for certain system configurations to provide the capability to dynamically communicate with other I/O hub chips from the host bridge chip. This configuration improves system reliability by allowing a second processor complex to access an I/O subsystem in the event of a failure of a first processor complex.

[0010] Various methods have been proposed and implemented to achieve high availability I/O systems. One such system, described in U.S. Pat. No. 5,682,512, couples several processing nodes together using cluster bridges. The processing nodes comprise a microprocessor, memory and I/O interconnected by a system bus, while the cluster bridges comprise address translation logic as well as interfaces to a processor node via the system bus and one or more other cluster bridges via point-to-point communication lines. The I/O bridges may be PCI-based. The address translation logic takes addresses that correspond to a global address map and remaps them to local addresses if such a mapping exists. The system structure at each node contains one or more processors, memory and I/O. This system does not use address translation during DMA operations when moving from an I/O address space to a system memory address, does not dynamically route DMA operations to a desired processing node, and does not dynamically route interrupts to a desired processor by reusing a portion of the address translation mechanism.

[0011] It is an object of the invention to provide an improved I/O system and method.

[0012] It is a further object of the invention to provide a cost-effective way of building high availability I/O systems with a high degree of design reuse.

[0013] It is a further object of the invention to provide a method for using existing packet-based technology for redundant link connections and extending it to support dynamic access to multiple I/O hubs.

[0014] It is an object of the invention to provide access to translation table information residing in one processor complex while transferring data to another processor complex using the translation table information from that other complex.

[0015] It is a further object of the invention to provide subdivided PCI address space to determine from which processor complex to fetch translation table information.

[0016] It is a further object of the invention to provide dynamic routing of PCI interrupts from a particular PCI bus to different processor complexes (sometimes referred to as I/O hubs).

[0017] It is a further object of the invention to provide a system coherency protocol by which coherency is assured for cached translation table information and DMA read data originating from multiple processor complexes.

[0018] In accordance with the invention, a system and a method are provided for dynamically routing data to multiple processor complexes. PCI address space is subdivided among a plurality of processor complexes for the purpose of retrieving translation table information. Translation table entries at each processor complex determine which processor complex is to receive a DMA transfer, thereby enabling routing of DMA data to one I/O hub node while accessing translation table entries at another I/O hub node. Further, interrupt requests may be dynamically routed to multiple processor complexes.

[0019] Other features and advantages of this invention will become apparent from the following detailed description of the presently preferred embodiment of the invention, taken in conjunction with the accompanying drawings.

[0027] Referring to FIG. 1, a PCI host bridge chip 100 may provide a means for translating addresses from a PCI memory 102 address space to a system memory 114 address space. Host bridge chip 100 may also provide a hardware mechanism to fetch table entries from system memory 114 which describe how to map PCI addresses into system memory addresses. For this purpose, host bridge 100 uses a table entry to determine the system memory 114 location to which a DMA operation will be directed.

[0028] In this exemplary embodiment, processors 104 and 106 comprise a symmetric multiprocessor (SMP) within processor complex 107. Processor complex 107 also includes a system memory 114, and an I/O hub and memory controller 116 connected to processors 104 and 106 over processor bus 109, connected to system memory 114, and via interface link 126 to host bridge chip 100. Link 126 (as also link 214 and link 118) is a high speed link (HSL), a high-speed interconnect which utilizes a packetized protocol to communicate between the various endnodes. Host bridge chip 100 includes a plurality of host bridges 103, 105, TCE address registers 184, and configuration register 252. Each host bridge 103, 105 is connected to a PCI bus 110, 112, and includes an MHXIVR register 210, 211 and XIVR register 189, 187. One or more I/O adapters 130, 132, 134, 136 interconnect I/O devices 140, 142 to PCI buses 110 and 112. Host bridge chip 100 is connected by link 118 to I/O node 120, thence to I/O node 122, which is connected via link 214 to hub controller 116.

[0029] DMA requests are routed from a host bridge chip 100 node to an input/output (I/O) hub 116 over bus or link 126. Multiple host bridge chips 100 can connect in daisy-chain fashion to the I/O hub and memory controller 116 using a packet-based connection protocol. Line 118 from host bridge chip 100 shows a connection to another host bridge or I/O hub. I/O nodes 120 and 122 can be either a host bridge chip node 100 or a processor complex node 107. The last I/O node 122 can be connected over link 214 to a second port on I/O hub 116 to form a ring configuration. Such a ring configuration provides a redundant connection for failover scenarios.

[0030] In a prior art configuration, one of I/O nodes 120 or 122 may be another processor complex, but communication from a host bridge chip to one and only one processor complex is allowed, and that is fixed at system configuration time. If a configured communication link to a processor complex is broken, then a reconfiguration is required to establish a new communication path to another complex. Thus, in this prior art configuration, a host bridge chip 100 can be configured to communicate with only one processor complex node 116 even though a physical path may exist to other processor complex nodes, say I/O node 120.

[0031] Packets are routed between the host bridge chip 100 and I/O hub chips 116 using source and destination ID fields contained within the packets. In the prior art, each host bridge chip 100 contains a hub ID register (not shown) which identifies the ID of the I/O hub chip 116. The hub ID register is used to fill in the destination ID portion of the packet for DMA requests sent to the I/O hub 116. Interrupt request packets are also routed in a similar manner.

[0032] In accordance with the present invention, for certain system configurations, the capability is provided for dynamically communicating with other I/O hub chips 116 which may exist at other I/O nodes 120, 122 from the host bridge chip 100. This configuration improves system reliability by allowing a second processor complex 107 to access an I/O subsystem 102 in the event of a failure of a first processor complex without requiring reconfiguration, that is, dynamically.

[0033] An exemplary embodiment of the present invention provides a mechanism for the I/O subsystem 102 underneath a host bridge chip 100 to attach to multiple processor complexes 107 dynamically. For this purpose, the existing host bridge chip 100 ports to link 118, 126 are used to provide access to other I/O nodes 120, 122 (either of which may be a processor complex 107) in a redundant fashion as previously described. Further, traffic may flow simultaneously on both ports (connections to links 126, 118) of a host bridge chip 100 to different processor complexes 107 thereby increasing the bandwidth available to that host bridge chip 100.

[0034] Additionally, an exemplary embodiment of the invention provides for accessing translation table entries from processor complex 107 while routing DMA data to another processor complex, say at I/O node 122. This capability provides a means for processor complex 107 to maintain translation tables in local memory 114 while forwarding critical I/O data to other complexes at nodes 120, 122 to provide for failover scenarios.

[0035] Further in accordance with an embodiment of the invention, interrupt requests may be routed to multiple processor complexes 107 dynamically. This mechanism is useful for rerouting error interrupts from a device 140 from one processor complex 107 to another (at, say, I/O node 120) when a failure is detected in one processor complex 107. Generally, interrupts are configured to be routed to a given complex, say 107. If the processor complex 107 goes down, then routing information in the host bridge chip 100 is dynamically reconfigured so that the interrupts are now reported to another processor complex at, say, I/O node 120.

[0036] FIG. 2 shows an high availability I/O system configuration using the capabilities provided by the invention. In FIG. 1, I/O nodes 120, 122 are entities with either host bridges or processor complexes. In FIG. 2, an exemplary embodiment illustrates processor complex 107 connected via link 173 to I/O node 120, also a processor complex. This figure is simplified to show the key ideas of the invention. Host adapter (HA) 150 is connected to a host 168 and to host bridge chip 100. The host bridge chip 100 is in turn connected redundantly over links 118, 126 to two I/O hub chips 154, 116 which are the access points to processor complexes 120, 107 system memory 166, 114, respectively, and a set of symmetric multiprocessors (SMP) 172, 170, respectively. A device adaptor (DA) 132 is also connected to the host bridge chip 100 and to I/O device 140. Although not shown in FIG. 2, redundant DA 132 and HA 150 connections are supported to prevent host bridge 100, DA 132 and HA 150 components from becoming single points of failure in the system. I/O traffic flows between DA 132 and HA 150 under management of the two processor complexes 107, 120. One complex 107 acts as a master for a portion of I/O devices (such as DASD) in the system while the other complex 120 is the slave for that portion.

[0037] Writes to a device via DA 132 may be done as “forked” operations, i.e. the write data is sent to both processor complexes 107, 120. The ability provided by the invention to direct DMA operations dynamically to different processor complexes 107, 120 allows the forked write operation to occur. A forked write operation occurs when the same data is written to two separate memories 114, 166 at processor complexes 107, 120 in order to preserve write data if one processor complex fails. The flow for a write operation by a host 168 is from HA 150 to system memory 114 and then from system memory 114 to DA 132. In the event of a failure of processor complex 107, processor complex 120 takes over completion of the write operation by moving the data from system memory 166 to DA 132, thus providing high availability.

[0038] This system design prevents a processor complex 107 from being a single point of failure and provides the highly available I/O system, such as the system illustrated in FIG. 2, based on the redundant packet-based ring connection between I/O hubs 116, 154 and host bridge chip 100. Although not shown in the drawing, redundant connections can be made to the host 168 through other host adapters (HA) 150, and redundant connections can also be made to I/O device 140 through another device adapter (not shown) in addition to DA 132. These additional host adapters and device adapters can be attached to a separate host bridge chip 100 anywhere in the ring topology 118, 126, 173.

[0039] Features of host bridge chip 100 supporting such configurations are described below in greater detail in connection with a multihub embodiment of the host bridge chip 100 which is operated in accordance with exemplary embodiments of the method of the invention.

[0040] PCI addresses are translated to system memory addresses through translation control entry (TCE) tables maintained in system memory 114. Referring to FIG. 3, an entry in these tables is a translation control entry (TCE) 180. PCI address space is divided into several regions based on PCI address 182 bits 29:28 in the preferred embodiment. These two address bits are used to choose one of four TCE address registers 184 maintained on the host bridge chip 100; each of these registers 184 contains a hub ID field 181 (as shown in FIG. 5) which has a I/O hub node identifier in it. These TCE address registers 184 were previously associated with a PCI host bridge function, but in the multihub mode of the preferred embodiment of the invention are associated with PCI address ranges. This node ID information is used to route a TCE fetch request to a I/O hub 116, 154. This allows a host bridge node 107, for example, to communicate with up to four nodes 120, 122, . . . for fetching TCE table entries 180. More PCI address 182 bits could be used and TCE address registers 184 added to extend the number of supported hubs 107, 120, 122 for TCE fetches.

[0041] FIG. 3 shows how a TCE table 180 entry is used to translate a PCI address 182 to a system memory address 188. The content 186 of TCE address register 184 is a pointer to the system memory address origin of the TCE table (one entry 180 of which is illustrated in FIG. 3). When operating without using the multi-hub support of the present invention, the high order 20 bits 192 of a PCI address 182 are concatenated to the contents 186 of TCE address register 184 to form a TCE 8 byte fetch address 190. In accordance with multi-hub support, PCI address 182 bits 29:28 are no longer used in the TCE fetch address 190 formation. Instead, bits 31:30 are shifted two positions to the right (becoming TCE fetch address 190 bits 43:44) and TCE fetch address 190 bits 41:42 are set to zeroes, with the result represented in FIG. 3 by the annotation: “multihub support:”00“|31:30|27:12”. A TCE fetch request packet containing this address is sent on link 126 to the appropriate processor complex, say 107, based on a selection using PCI address bits 29 and 28. Bits 29 and 28 select bits bits 0-5 out of one of four TCE address registers 184. These bits identify the appropriate processor complex 107, 120, 122 to which the TCE fetch request is routed.

[0042] A TCE 180 is returned from the target processor complex, say 107, to the originating host bridge 100 in a separate response packet across the link 126. While FIG. 2 illustrates only two processor complexes 107, 120, this exemplary embodiment allows for four such complexes which are dynamically selectable through the PCI address 182 bits 29 and 28.

[0043] Referring further to FIG. 3, a system memory address 188 is formed with the high order address bits coming from the TCE 180 and the low order bits coming from the original PCI address 182. Field 200 of TCE 180 represents bits that are unused from the TCE (the preferred embodiment supports 48 bits of system memory addressability) and field 202 of the TCE 180 represents reserved bits. Field 204, bits 62:63 of the TCE 180, are control bits that provide page protection capability.

[0044] Field 206 which replaces certain bits of TCE 180 shows another modification provided by the invention. Bits 56:61, previously a portion of reserved bits 202 in the TCE 180, are now used as a hub identifier as shown in field 206; the preferred embodiment uses bits 56:61 of the TCE 180 to support a 6 bit hub ID 206, although up to 10 bits are available for other possible embodiments. This hub ID field 206 is used for routing data associated with DMAs routed through the host bridge chip 100 to the appropriate processor complex 107, 120, 122. This hub ID 206 does not have to match the hub ID used to perform the TCE fetch for the DMA operation. The use of a separate hub ID 206 for routing the DMAs as opposed to the TCE fetches allows the TCE tables 180 to reside in a processor complex 107 while the DMA data is routed to a separate processor complex 120. These TCE tables 180 and DMA target memory may reside in either the same or separate system memories 114, 166.

[0045] Referring further to FIG. 2, another aspect of the invention is the routing of interrupt request packets to different processor complexes 107, 120. An exemplary embodiment supports 15 interrupt levels for each PCI host bridge function 103, 105. Each interrupt level is controlled through use of XIVR registers 189, 187 which sets the priority level of the interrupt and provides an interrupt server number. The interrupt architecture conforms to the RISC System/6000 PowerPC System Architecture specification 1.39.

[0046] Referring to FIG. 4 in connection with FIG. 1, this interrupt architecture is extended in the preferred embodiment to add a separate MHXIVR register 210, 211 which is 32 bits in size. There are 2 bits 208 in register 210, 211 for each interrupt level Int0 through IntF, and these 2 bits point to the appropriate TCE address register 184 hub ID field 181 to select the proper hub I/O node 107, 120, 122 for routing an interrupt packet.

[0047] Referring to FIG. 7, the packet-based interface 126 (FIG. 1) between I/O hub 116 and host bridge 100 chips will be described. Similar interfaces exist on links 118 and 214. Link 126 is a high speed link (HSL), a high-speed interconnect which utilizes a packetized protocol to communicate between the various endnodes. The endnodes which inter-communicate across HSL include processor complexes (sometimes referred to as CEC units) as well as system I/O drawers, and can operate in either a switched fabric or a looped topology. The HSL protocol is capable of supporting alternate, redundant data paths between endnodes with automatic hardware switchover between the alternate data paths. There are twenty logical signals associated with a single interface or link 126. There are two byte-wide data interfaces 222, 223, with data flowing in one direction on each data interface 222, 223 so that a full-duplex connection is established. Each data interface has a clock 226, 228 and flag 227, 229 bit, respectively. The clock 226, 228 provides a sampling reference for arriving data and the flag 227, 229 performs a packet framing function. The link 126 is capable, for example, of a peak data transfer rate of 500 megabytes per second with data transferred with each clock phase.

[0048] FIG. 6 shows the generalized format of a packet 220 on interface link 126.

[0049] Command class field 230 identifies the type of packet. Request packets are used to request read (i.e. DMA read) or write (i.e. DMA write) operations. Response packets are used to respond to read request packets with the requested data. Link acknowledgment packets are used to acknowledge reception of all packets at an adjacent node and are used for flow control between adjacent nodes 107, 122. End-to-end (ETE) acknowledgment packets are used to acknowledge receipt of packets 220 at a destination node and are used for flow control between source and destination node IDs on a HSL network comprised of link 126, 214, 118.

[0050] Link sequence count 231 is used for flow control between adjacent nodes; this field is reused as a request link sequence count in a link acknowledgment packet.

[0051] Transaction identifier (ID) 232 is used by the initiator to associate a data request with a response that returns the data. This field is reused for link level control bits in a link acknowledgment packet.

[0052] Destination node ID 233, 234 is used to indicate the destination for routing a packet. This field is reused as a response link sequence count and additional link level control bits in a link acknowledgment packet.

[0053] Source node ID 235, 236 is used to indicate the source of a packet and is used for routing acknowledgment and response packets back to a node.

[0054] Command type 240 is used for further delineating request packet types (i.e. read, write) as well as for indicating status on a response packet. This field is not implemented for link acknowledgment packets.

[0055] End to end (ETE) sequence count 242 is used for flow control between source and destination nodes. This field is not implemented for link acknowledgment packets.

[0056] Length 243 indicates data length for read and write request and response packets.

[0057] Scrambler key 244 is used for maintaining an average optical power level only when implementing an optical link.

[0058] Payload 245 is the data being delivered in the packet and, in this exemplary embodiment, is in multiples of 4 bytes.

[0059] Cyclical redundancy check (CRC) 246-249 provides error checking on the packet 220.

[0060] DMA operations initiated by host bridge chip 100 in multihub mode, for example, involving nodes 107, 120 substitute the appropriate node ID 206 into the destination node ID field 233, 234 of a packet 220 for routing DMA read and DMA write operations. For TCE fetch operations, the appropriate node ID 181 is selected and substituted into the destination node ID field 233, 234 of packet 220 for routing the TCE fetch.

[0061] Referring to FIG. 6 in connection with FIG. 3, a TCE fetch operation assigns the destination node ID 233, 234 based on a selection of one of four hub IDs from the TCE address registers 184. This selection is based on the PCI address 182 bits 29:28 as previously described. The DMA read and write operations assign the destination node ID 233, 234 based on the hub ID field 206 returned by the TCE fetch operation as previously described. Interrupt request packets 220 assign the destination node ID field 233, 234 based on a selection of one of four hub IDs. This selection is based on the interrupt level and the associated 2 bit value 208 in the MHXIVR register 210.

[0062] Referring to FIGS. 4 and 5, the details of the register additions and modifications previously described for multihub mode will be further described. An exemplary embodiment of host bridge chip 100 has four separate domains from which interrupts can originate, three of these are PCI host bridge domains 103, 105, and the other is the host bridge chip 100 itself. Each such domain has a separate MHXIVR register 210, 211 to control routing of each interrupt level to a I/O hub node (such as nodes 107, 120, in FIG. 2.) The host bridge chip 100 domain only implements three interrupt levels (0-2), and so only those bits are implemented in the MHXIVR register 210 for that domain. Each interrupt level has a two bit field 208 which controls selection of the appropriate hub ID value 181 from a TCE address register 184.

[0063] Referring to FIG. 5, the TCE address register 184 format includes a valid bit 178 at bit position 60. This bit 178 allows configuration of how many hub ID nodes 107, 120 are supported.

[0064] Hub ID field 181 is used to determine the destination node ID for DMA and TCE fetch link packets. When not in multihub mode, this field is set to the same value for all four TCE address registers 184 and is used for both TCE fetches and DMA read and write operations. When in multihub mode, this field 181 is used only for TCE fetches.

[0065] #en field 185 controls the number of TCE entries 180 supported, or in other words, the size of the TCE table. In an exemplary embodiment, eight encodings are supporting which allow from 8K to 1024K TCE table 180 entries. If a PCI address 182 is generated which causes the supported TCE table size to be exceeded, a TCE extent error occurs. When multihub support is enabled, the maximum number of TCE table entries supported drops from 1024K to 256K, since bits 29:28 of the PCI address 182 are removed from the TCE fetch address formation. Multihub mode bit is added to configuration register 252 as bit 11. When this bit is set, multihub mode is active.

[0066] In accordance with an exemplary embodiment of the invention, management for buffered TCE fetch and DMA read data is modified for multihub mode. Block dkills from link 126 are used to manage TCE coherency at a system level. A block dkill is a packet which is used to maintain coherency between system memories 114, 166 and buffered TCE entries 180 in a TCE cache (for an explanation of which, refer to copending U.S. patent application Ser. No. 09/569,574). Hub chip 116 tracks the state of all TCE entries cached within the host bridge chips 100 and issues block dkills when a TCE 180 has been updated in system memory 114. Hub 116 manages cached TCEs in 128 byte blocks, and so a block dkill when issued covers a 128 byte section of system memory representing 16 TCEs 180. Refer to the above referenced copending U.S. patent application Ser. No. 09/569,574 for a detailed description of how block dkills work in bridge chip 100, and for a description of the TCE manager and TCE CAM, to which references are made in the following description.

[0067] In accordance with the present invention, the operation of a block dkill is modified in multihub mode as follows: the block dkill address bits 16:40, which is part of the payload 245 of a packet 220 received on link 173, are compared against each of the TCE address registers 184 along with the source ID 235, 236 of the block dkill link packet 220. If any of the TCE address registers 184 match these fields in the block dkill packet 220, a hit indication is generated and the TCE address register 220 that got the hit is encoded into two bits corresponding to PCI address 182 bits 29:28.

[0068] Generated bits 29:28 are compared against the same PCI address bits in all entries in the TCE CAM. Block dkill address bits 43:56 are compared against PCI address 182 bits 31:30 & 27:16 in all entries in the TCE CAM. Any TCE CAM entry that matches on both fields is invalidated.

[0069] Page dkills are another coherency management protocol supported over link 126 for ensuring that any data modification in system memory 114 results in invalidating stale copies of that data in host bridge chips 100. Hub chip 116 tracks the state of all cached DMA read data within the host bridge chips 100 and issues page dkills when that DMA read data has been updated in system memory 114. The hub manages cached DMA read data in 4096 byte blocks, and so a page dkill when issued covers a 4096 byte section of system memory 114. Each read channel in host bridge chip 100 checks the page dkill address bits 16:40 against the system memory address 188 bits 16:40 recorded for each read channel (see the above referenced copending U.S. patent application Ser. No. 09/569,574 for a description of read channels), and if a hit occurs, that read channel is invalidated. This mechanism remains identical for multihub mode with the exception that an optional hub ID compare is added to the read channels as an additional check before an invalidation occurs. The use of the hub ID compare is configurable based on configuration register 252 bit 15.

[0070] It is an advantage of the invention that there is provided an improved I/O system and method.

[0071] It is a further advantage of the invention that there is provided a cost-effective way of building high availability I/O systems with a high degree of design reuse.

[0072] It is a further advantage of the invention that there is provided a method for using existing packet-based technology for redundant link connections and extending it to support dynamic access to multiple I/O hubs.

[0073] It is a further advantage of the invention that there is provided access to translation table information residing in one processor complex while transferring data to another processor complex using the translation table information from that other complex.

[0074] It is a further advantage of the invention that there is provided subdivided PCI address space to determine from which processor complex to fetch translation table information.

[0075] It is a further advantage of the invention that there is provided dynamic routing of PCI interrupts from a particular PCI bus to different processor complexes (sometimes referred to as I/O hubs).

[0076] It is a further advantage of the invention that there is provided a system coherency protocol by which coherency is assured for cached translation table information and DMA read data originating from multiple processor complexes.

[0077] It will be appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without departing from the spirit and scope of the invention. In particular, it is within the scope of the invention to provide a computer program product or program element, or a program storage or memory device such as a solid or fluid transmission medium, magnetic or optical wire, tape or disc, or the like, for storing signals readable by a machine, for controlling the operation of a computer according to the method of the invention and/or to structure its components in accordance with the system of the invention.

[0078] Further, each step of the method may be executed on any general computer, such as an IBM System 390, AS/400, PC or the like and pursuant to one or more, or a part of one or more, program elements, modules or objects generated from any programming language, such as C++, Java, Pl/1, Fortran or the like. And still further, each said step, or a file or object or the like implementing each said step, may be executed by special purpose hardware or a circuit module designed for that purpose.

[0079] The exemplary embodiment heretofore described is in accordance with the PCI specification, “PCI Local Bus Specification” Revision 2.2, Dated Dec. 18, 1998. The present invention is also applicable to a PCI-X host bridge. PCI-X is described in “PCI-X Addendum to the PCI Local Bus Specification” Revision 1.0, Dated Sep. 22, 1999. The actual embodiment is PCI, but subsequent chips using this invention may also implement other host bridges, including the PCI-X in addition to PCI.

[0080] Accordingly, the scope of protection of this invention is limited only by the following claims and their equivalents.