MXPA00007393A - Bus arbiter with reinforced function using variable priority and fairness - Google Patents

Abstract

It is an object of the present invention to change arbitration priority levels by making a bus arbiter include logic in which a fairness system is embedded. When a plurality of devices simultaneously request a bus, this bus arbiter resets all the bits of a fairness register to zero and starts a fairness protocol sequence. The bus arbiter deasserts all currently asserted enabling signals. Then, the bus arbiter asserts an enabling signal to a request source which does not set 1 in a corresponding fairness register bit and has the highest priority. Subsequently, the bus arbiter uses fairness algorithm and asserts an enabling signal to a request source having the highest priority when there is another device to which a request signal is asserted and which sets 1 in a fairness bit.

Description

IMPROVED COLLECTIVE DRIVER ARBITRATOR USING VARIABLE PRIORITY AND EQUITY TECHNICAL FIELD The present invention relates generally to a method and system for data processing in general and, in particular, to a method and system for the arbitration of a collective conductor based on variable priority and equity protocols.

BACKGROUND INFORMATION A computer system typically includes several types of collective drivers, such as the collective driver of the system, local bus drivers and peripheral bus drivers. Various devices and components of electronic circuits are connected to each other via these collective conductors, so that intercommunication can be possible between all those devices and components. In general, a central processing unit (CPU) is connected to a collective conductor of the system on which the CPU communicates directly with a system memory that is also connected to the collective bus of the system. It is intended that a local collective conductor be connected to certain highly integrated peripheral components on the same collective conductor as the CPU. One such local bus driver is referred to as the collective driver of Peripheral Component Interconnect (PCI). Under the standard PCI local collective conductor, the peripheral components can be connected directly to a local PCI collective conductor without the need for a joining logic. In this way, the PCI provides a standard collective conductor over which high-performance peripheral devices, such as graphics devices and hard disk drives, can be coupled to the CPU, thereby allowing these high performance peripheral devices to avoid the general access latency and the bandwidth restrictions that are associated with a peripheral collective conductor. A peripheral collective conductor such as a collective conductor of Standard Architecture in Industry (ISA), serves to connect several peripheral devices to the system of a computer. These peripheral devices typically include input / output (I / O) devices such as a keyboard, floppy disk drives and printers. In general, each collective conductor of the system, local collective conductor, and peripheral collective conductor use an independent set of protocols (or rules) to conduct data transfers between various devices connected to it. Each of these protocols is designated in a collective driver directly and is commonly referred to as the "architecture" of the collective driver. In a data transfer between different collective conductor architectures, the data that is being transferred from the first collective conductor architecture may not be in a form that is useful or intelligible by the second receiver collective conductor architecture. As a result, a mechanism was developed to "translate" the data that needs to be transferred from one collective conductor architecture to another. This translation mechanism is normally contained in a device of the physical computing components in the form of a bridge (or interface) collective conductor to collective conductor through which the two different types of collective conductors are connected. Coincidentally, several bridges of collective conductor to collective conductor have been designed to equal the communication protocol of a collective conductor with the one of another to allow extensive communications of the system between the devices on the different collective conductors. For example, a collective bus to collective driver bridge that connects between a collective bus driver of the system and a local PCI bus driver is referred to as the PCI host bridge. The PCI host bridge contains all logical and physical computing components for translating data communications between the collective bus driver of the system and the local PCI bus driver, and ensures that the data is transferred between these two collective drivers in an intelligible manner. If multiple devices are connected to the different collective conductors, the access gained to the CPU or even to a local collective conductor at the same time, would result in chaos. Chaos is avoided by introducing one or more collective driver masters into the system. A collective driver master controls access to the collective driver. In other words, it initiates and controls all the requests of the collective driver. Deciding which collective conductor device or master will use the next collective conductor is called arbitration. In a collective conductor arbitration scheme, a device (or processor) waits to use the collective conductor that signals a collective conductor request. In response, at a later point in time the referee sends a concession signal to the device. After the award is received, the device can use the collective driver. The device indicates later that the collective driver is no longer required. The arbitrator may then grant the collective conductor to another device.

Arbitration schemes usually try to balance two factors in the choice of such a device to grant the collective driver. First, each device has a collective driver priority and the devices with the highest priority will be served first. Second, to ensure that no device, even with low priority, is ever completely blocked, most collective drivers and / or such as PCI also require the arbitrator to implement some kind of equity protocol. The intent of an equity protocol is to ensure that all devices receive their turbo over the collective driver. For example, a conventional equity protocol is a tournament scheme. Under a tournament equity protocol, a device that has recently completed an operation on the collective driver is not granted access to the collective driver for a second operation until all the requesting devices have first been granted access to the collective driver. Even when a collective driver can provide an equity protocol with the arbiters that control access to the collective driver, acceptable access to the collective driver can be effectively denied to a device or devices by other high performance devices. This is an unexpected problem that the equity protocols were trying to avoid.

The problem is that of "pulsation" frequencies that interfere with the access of a device to the collective conductor. The concept of this "pulsation" frequency will be described later. Some collective drivers such as the PCI provide a characteristic operation which is usually referred to as a "recoil" capability that allows a device to disconnect from the collective conductor if it is not capable of handling the request at that time. This capacity in the PCI is known as Retry. If a PCI device is not able to handle a request when the purpose of the request occurs, it can allow a "Retry" which indicates to the master that issued the request on the collective driver to try later. For PCI, the typical platform provides a PCI host bridge to provide the synchronization of the collective conductor between the collective bus system and the collective bus PCI. The platform can also provide a number of PCI to PCI collective conductor bridges to provide additional PCI collective conductor segments. Usually, each PCI collective driver segment will have its own arbitrator (with equity protocols). Each bridge usually has logging buffers to temporarily store collective bus driver transactions when those transactions flow to the bridge in both directions (from the primary side to the secondary side, and from the secondary side to the primary side of a bridge). The way in which a pulse sequence can deny a device effective access to the collective conductor involves the interaction between a set of buffers on a bridge, the bridge arbiter, and the traffic of the collective conductor with the devices on the collective conductor. For example, assume that a collective bus driver under a PCI host bridge or a PCI to PCI bridge has a tournament equity protocol for four devices under the bridge (Device A, Device B, Device C, and Device D). Also assume that the bridge was assigned the highest priority (priority 0), Device A was assigned the next highest priority (priority 1), Device B was assigned the next highest priority (priority 2), Device C was assigned the next highest priority (priority 3), and Device D was assigned the next highest priority (priority 4). If all devices request the collective driver at the same time, the equity protocol will ensure that each device gets the opportunity to try to use the collective driver. >The priority of arbitration, in this example, always determines the order in which the device gets a turn to try to use the collective driver. In this example, when all devices request to use the collective conductor, access is first granted to the bridge, then to Devices A to D in sequence. Under this scheme, both Devices A and B could get a turn on the collective conductor and fill the bridge buffers so that when Device C has access to the collective conductor, Device C gets a retry because the buffers of Bridge are full. Eventually the bridge empties some of the buffers with transactions on the other side of the bridge. Then Devices D, A and B take turns in the collective conductor, again filling the intermediate memories. When Device C gets its turn in the round, in the collective conductor again, it again receives a Retry because the memories of the bridge are full again. A pulse frequency can occur, so that each time a specific device gets a turn on the collective conductor it is rotated with a Retry (or equivalent, depending on the type of collective driver) because other devices keep the buffers full of the bridge. When the number of retries is relatively high, the device may be exceeded or fall short resulting in significant operating losses of programs and programming systems that detect the excess or lack and repeat the operation.

Simply adding more buffers to the bridge only changes the amount of data that Devices A, B, and D need to transfer to produce the "pulse" frequency problem. Adding a very large number of buffers should eliminate the problem but this would be impractical because it is too expensive. What is needed, therefore, is a scheme that changes the priority level of the arbitration, so that the rotation sequence changes to increase the probability that each device will get an equitable turn on the collective conductor without the interference of a pulsation frequency.

BRIEF DESCRIPTION OF THE INVENTION The aforementioned needs are met by the present invention. Accordingly, a computer system having a local bus driver which communicates with a CPU via a collective bus bridge, where the collective bus driver bridge contains a bus driver arbiter is provided in a first form. controlling and prioritizing the collective conductor request signals of a plurality of collective conductor devices connected to the collective conductor. The granting of the collective driver is based on the priority of each device, the previous accesses within a cycle of equity, and the history of retries. Also described is a collective conductor arbiter containing an equity driver to control and prioritize the collective conductor request signals based on a predetermined priority of each collective conductor device and each preceding access of the collective conductor device within a cycle of equity. The arbitrator contains logic to grant the control of the collective conductor to the collective conductor device on the basis of the equity logic. The invention also includes a method for arbitrating a collective conductor in a computer system comprising the steps of receiving collective conductor request signals from various collective conductor devices, initiating an equity cycle, selecting a single collective conductor device of the collective conductor devices based on the higher priority of the collective conductor devices with respect to other devices and if an equity indicator for the collective conductor device was not set. If the indicator was set, then the priority is reduced. The indicators are fixed only if the devices are granted access to the collective driver and do not receive a retry signal. These and other features, and advantages, will be understood more clearly from the following detailed description taken in conjunction with the accompanying drawings. It is important to note that the drawings are not intended to represent the only form of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which: FIGURE 1 is a diagram of a typical computer system having a PCI local bus driver architecture, which may use a preferred embodiment of the present invention; FIGURE 2 is a detailed block diagram of an isolated computer configuration showing separate local PCI bus drivers under a PCI host bridge and a PCI to PCI bridge, which may use a preferred embodiment of the present invention; FIGURE 3 is a functional block diagram of a PCI to PCI bridge, which may use a preferred embodiment of the present invention; and FIGURE 4 is a flow chart describing the logic of the arbitration scheme in an exemplary embodiment of the present invention.

DETAILED DESCRIPTION The principles of the present invention and their advantages are best understood by reference to the illustrated embodiment described in FIGURES 1-4 of the drawings., in which similar numbers designate similar parts. In the following description, well-known elements are presented without detailed description so as not to obscure the present invention with unnecessary details. For the most part, unnecessary details to obtain a complete understanding of the present invention have been obtained as such details are within the knowledge of those skilled in the relevant art. The details regarding the circuit or control mechanism used to control the rotation of the different elements described here were omitted, since such control circuits are within the knowledge of those skilled in the relevant art. The present invention may be applicable to a variety of computers under a number of different operating systems. The computer can, for example, be a personal computer, a minicomputer or a large computer. Referring now to the drawings and in particular to FIGURE 1, there is described a block diagram of a typical computer system having a local PCI collective conductor architecture, which utilizes a preferred embodiment of the present invention. As shown, a processor 112, an immediate memory 113, a memory controller 114 and a Dynamic Random Access Memory (DRAM) 115 are connected to a collective system conductor 128 of a computer system 101. The processor 112, the Immediate memory 113, memory controller 114, and DRAM 115 are also connected to the local collective bus PCI 120 of computer system 101 through a host bridge 111. PCI host bridge 111 provides a low latency path through which processor 112 can directly access the PCI devices plotted anywhere within the collective conductor memory and / or I / O address spaces. Host bridge PCI 111 also provides a high bandwidth path to allow a PCI device to have direct access to DRAM 115. Host bridge PCI 111 may include various functions such as buffering / data logging and arbitration. Other devices such as a local area network (LAN) interface 116 and a collective bus connector 127 interface may also be connected to the local bus host PCI 120. The LAN interface 116 is for connecting the computer system 101 to a network of local area 117 such as Ethernet or Token-Ring. The configuration can also support separate PCI local bus drivers under separate PCI host bridges. For example, the PCI to PCI 118 bridge allows the local PCI 130 to connect to the local PCI 120 conductor. A variety of PCI 131, 132, 133, and 134 devices are connected to the local PCI 130 collective bus. The collective conductor interface of expansion 127 is coupled to any other non-PCI peripheral bus conductor 121 such as an ISA bus driver, EISA bus driver, and / or Microchannel Architecture driver (MC-A) to the local bus driver PCI 120. Typically, several peripheral devices no PCI to perform certain basic I / O functions are connected to one of the peripheral collective conductors, such as the peripheral collective conductor 121. In general, the local collective conductor PCI 120 and the local collective conductor PCI 130 can support up to four connectors of integrated board without requiring any expansion capacity. The audio adapter board 122, the moving video adapter board 123, and the graphics adapter board 124 are examples of some devices that can be connected to the local PCI 120 connective conductor or to a local PCI 130 collective conductor via integrated panel collectors. .

Referring now to FIGURE 2, there is illustrated a detailed view of the PCI configuration showing separate local PCI buses under a host bridge and a PCI to PCI bridge. A PCI host bridge 111 allows communications between collective conductor agents coupled to the collective conductor of the system 128 and connective conductor agents coupled to a local collective conductor PCI 120. In addition, a PCI to PCI bridge 118 allows communications between collective conductor agents coupled to a local collective bus PCI 130 (the local bus driver PCI 130 is a peripheral bus driver) and the memory driver 114 (FIGURE 1). The PCI to PCI bridge 118 also allows communications between the processor 112 and the bus driver agents coupled to the local bus host PCI 130. The LAN interface 116, the peripheral bus driver 121, and the graphics adapter board 124 are the driver's agents Collective buses for communication over the local collective bus PCI 120. In addition, the PCI 111 host bridge and the PCI to PCI bridge 118 are coupled as collective bus drivers for communication over the local PCI 120 collective bus. The PCI 111 host bridge and the PCI to PCI bridge 118, have the ability to be initiators and targets for the access cycles on the local collective bus PCI 120. In a preferred embodiment, the local collective bus PCI 120 comprises a 32 bit memory address and spaces 32-bit I / O address, which has multiplexed addresses and data on the same collective conductor. Collective conductor bridges, such as PCI host bridge 111 and PCI to PCI bridge 118, are typically coupled between a primary collective conductor and a secondary collective conductor. A collective conductor bridge allows an access request to start over the primary collective conductor so that it has a destination over the secondary collective conductor, and allows an access request that starts over the secondary collective conductor to have a destination over the collective driver primary. For example, after receiving a collective bus access request from the system 128, the host bus PCI 111 will initiate an access request on the local bus host PCI 120 to communicate with one or more PCI devices 116, 118, 127 or 124 Or, after receiving an access request from the local collective bus PCI 120, the PCI host bridge will initiate an access request on the collective bus of the system 128 to communicate with the controller of the memory 114. Similarly, after receiving an access request of the local collective bus PCI 130, the PCI to PCI bridge 118 will initiate an access request on the local collective bus PCI 120 to communicate with the PCI 111 host bridge. Or, after receiving a collective bus driver access request local PCI 120, the PCI to PCI bridge 118 will initiate an access request on the local PCI 130 collective bus to communicate with the PCI device 131. In sum, the PCI host bridge 111 allows communications between collective bus drivers coupled to the connective driver of system 28 and collective bus agents coupled to the local collective bus PCI 130. The connection to the local collective bus PCI 130 are PCI devices , such as PCI devices 131 to 134. Referring now to FIGURE 3, there is illustrated a block diagram of a PCI to PCI bridge 118 which can be used as a preferred embodiment of the present invention. As shown, the PCI to PCI bridge 118 has two sides, namely a primary side 302 from which communications travel to and from the primary PCI collective bus or local bus 120 PCI and a secondary side 304, from which communications move to and from the secondary PCI bus driver or PCI 130 local bus. (In the PCI architecture, the term "primary side" is simply used to denote the side of a bridge closest to the CPU and memory and the term "secondary side" refers to the furthest side of the CPU and memory). A series of data buffers 306 are provided for temporarily storing requests, data and instructions for communications ranging from the local collective conductor PCI 120 to the local collective bus PCI 130 (ie, the primary collective conductor to the secondary collective conductor). Similarly, there is also a series of data buffers 308 for temporarily storing requests, data and instructions for communications ranging from the local collective bus PCI 130 to the local collective bus PCI 120 (i.e., the collective bus driver secondary to the bus driver ). The sequence control or sequence control unit of the primary and secondary collective conductor 310 initiates master transactions and responds to target transactions on the primary and secondary interfaces of the PCI to PCI bridge 118 as described in the PCI Local Collective Driver Specification, Revision 2.2, published by the PCI Special Interest Group of Portland, Oregon ("Specification of PCI Collective Driver"). The Sequence Control Unit 310 initiates a request for access to the collective conductor on Secondary Side 304 of the PCI to PCI bridge. Each of the devices (A through D) also has a sequence control unit (not shown) that conforms to the requirements of the PCI collective conductor specification. The sequence control unit controls the sequencing of the respective PCI collective conductor signal once the collective conductor has been granted as a master or has been directed as a target by another master. The Secondary Collective Driver Arbitrator 312 performs the arbitration for the secondary side of the PCI to PCI 304 bridges using the signals REQ # and GNT # (FIGURE 3) and the arbitration requirements of the PCI Collective Driver Specification are satisfied. It also contains the Equity register 314 that is provided for the storage of a plurality of data values. One embodiment of the present invention may have a register containing five information bits corresponding to the PCI configuration of FIGURE 2 having the devices 131-134 on the local collective conductor 130. The interoperation between the Sequence Control Unit 310 and the Secondary Collective Driver Arbiter 312 complies with the requirements of the PCI Collective Driver Specification enhanced by the Equity Register 314 described in this invention. The signals REQ # A / GNT # A through REQ # D / GNT # D supported by the Secondary Collective Driver Arbiter 312 are the request / grant signals used by Devices A through D (In FIGURE 2, devices 131 through 134 respectively) to request access to the PCI 130 bus driver.

The collective bus driver 312 contains equity register 314 which contains an equity bit for each request line 316, 317, 318 and 319 (each device has its own request signal on the collective conductor). The bit assignments in the Equity Register 314 (bit 0 was assigned to bridge 118, bit 1 was assigned to Device A, bit 2 was assigned to Device B, bit 3 was assigned to Device C, and bit 4 was assigned to Device D). The arbitration algorithm used by the Secondary Collective Driver Arbitrator may be any algorithm that satisfies the requirements of the PCI Collective Driver Specification. The algorithm can also be a simple linear priority algorithm when used in conjunction with the equity register 314. The use of the equity register 314 is a necessary addition to the simple linear priority algorithm to enforce the Collective Driver specification. PCI The remainder of this description will discuss a simple linear priority modified by the effect of the equity register 314. The PCI to PCI bridge 118 is given the highest priority. Device A (ie, device 131 of FIGURE 2), which is associated with request signal REQ # A, is given the next highest priority. In this way, Device A will initially have access to the collective driver in favor of the other contending devices that are requesting access at approximately the same time. Device B (i.e., device 132 of FIGURE 2), then Device C (i.e., device 133 of FIGURE 2), and finally Device D (i.e. device 134 of FIGURE 2) ) is the priority sequence for the rest of the devices on the collective bus PCI 130. FIGURES 4A and 4B illustrate the logic scheme for the arbiter 312. When multiple devices request the bus driver at the same time the sequence of the equity protocol begins (step 400). The arbitrator 312 begins the sequence of the equity protocol (step 400) begins by resetting all the bits in the equity register 314 (FIGURE 3) to zero (step 402). The arbiter 312 then checks each of the REQ # signals shown in FIGURE 3 of each of the devices (A to D and the bridge) to determine if a request (REQ #) has been maintained (step 404). If a request (REQ #) has not been sustained, arbitrator 312 determines whether a predetermined time lapse (step 405) has expired by the use of a timer (not shown). The use of the timer limits the idle time on the collective conductor after retry for a predetermined period of time which can be easily fixed or preprogrammed. If one of the devices that has received the retry does not attempt to use the collective conductor when the timer expires, the equity bits for the entire device would reset to zero, allowing a new equity cycle to begin. Such a timer may be as is conventionally present in computer systems and is familiar to those who practice the relevant technique. If there is a request (REQ #), arbitrator 312 ceases to sustain any current grant (GNT #) that is sustained. Arbitrator 312 holds the granting to the higher priority requester (ie the sustained REQ #) whose corresponding priority register bit is not set one (step 406). Referee 312 then waits for the next collective bus transaction to begin (step 408). After the next transaction has been initiated, arbitrator 312 determines whether any other device request is sustained without having its associated Equity Register bit 314 set to one (step 410). If so, arbitrator 312 determines whether the purpose of the request in step 410 responded to a RETURN (step 414). If the determination in step 414 is yes, arbitrator 312 returns to step 404. On the other hand, if the determination in step 414 is no, arbitrator 312 sets the equity bit for this device to one (step 416) and then returns to step 404. If the determination from step 410 is no, the arbiter 312 determines whether the target responded to a retry (step 412). If the determination in step 412 is not the arbitrator 312 returns to step 402 and resets all the bits in the equity register. On the other hand, if the arbiter 312 determines that the target responded with a retry (step 412), the arbiter 312 checks to see if another sustained device request has its equality bit set to one (step 418). If there is no other device with a sustained request and its equity bit set to one, the routine returns to step 402 and all the bits in the equity register are set to zero. If there is another device, however, with a sustained request and its equity bit set to zero, arbitrator 312 stops supporting the current grant and holds a grant to the highest priority applicant (using an equity algorithm) whose registration bit of equity was set at one (step 420). Referee 312 then repeats step 408.

OPERATION The arbitrator's manner of use can be better illustrated by an example. When multiple devices request the collective conductor at the same time (for example, Devices A, B and C), the equity routine begins. Once a device receives a turn on the collective conductor if a Retry (progresses), referee 312 will begin ignoring the Petition Line of that device (Equity Bit set to 1), until the other devices that also had their lines of active requests receive their turn on the collective driver. Table 1 shows the arbitrage level, the request status, if the target responded with a retry, and the equity bit of each device in the first equity determination. In this example, the column marked "Equity Bit before / after" contains the value of the bits in the equity register 314 (FIGURE 3) which were set to 1 in step 416 (FIGURE 4a) and readjusted to 0 in step 402 (FIGURE 4a).

In the example shown in Table 1, device A has priority and did not receive a retry. The only devices that enter the arbitration process are those devices that have their request held (a Yes in the Request column) and whose Equity Bit (the bit shown in the Equity Bit column before / after the table) was fixed in Zero. As a result, Device A was granted access to the collective driver and its equity priority bit was set to "1". In this way, future requests will be ignored. The next device to take its turn is device B as illustrated in Table Two.

Table Two - Second Turn, First Cycle As illustrated in Table Two, although Device A has priority, it does not have a shift on the collective conductor because the equity bit was set to one. In this way, Device B will be given its turn over the collective driver. After Device B has gained access, it is the turn of Device C over the collective conductor. Assume for purposes of illustration, that Device C, however, received a retry of the objective. In this way, your Equity Bit was not set to "1" (as shown in Table 3). That is, from the point of view of equity, it is as if Device C does not receive a shift on the collective driver, and arbitrator 312 will still acknowledge his Request and Device C can continue to have access to the collective driver within the same cycle. equity until it progresses over the collective driver (exchanges information with its objective through the collective driver).

Table Three - Third Shift, First Cycle Once Device C gets a turn on the collective conductor without retry, if other devices also want the collective conductor, the equity bit of Device C is set to "1" and your request will be ignored.

Table Four - Fourth Shift, First Cycle Finally there are conditions (as shown in Table Four) where there are no additional devices on the collective conductor with active request lines that have their Equity Bit = 0. At that point, all equity bits are reset to "0" by arbitrator 312 and the equity cycle can start again as illustrated in Table 5: Note that with this solution, arbitrator 312 would deny access to the collective driver (ignoring the Device Request) to the device that has progressed, while granting extra access to the collective driver during an equity cycle for devices that previously received a Retry. The timer limits the idle time on the collective driver after the Retry. Thus, if one of the devices that has received the Retry does not attempt to use the collective conductor when the timer expires, the equity bit for all devices would be reset to zero, allowing a new equity cycle to begin. In sum, the arbitrator has several substantial advantages over the prior art. With this solution, the arbitrage levels can remain the same and each device that receives a retry in its turn on the collective driver can receive extra shifts on the collective driver during the first cycle of equity until his transactions on the collective driver are managed (have progressed). In this way, the collective driver is not denied access to the device due to the Retry signals. Although the invention has been described with reference to specific embodiments, these descriptions are not intended to constitute a limiting sense. The various modifications of the embodiments described, as well as the alternative embodiments of the invention, will become apparent to those skilled in the art upon reference to the description of the invention. Therefore, it was contemplated that the claims will cover any modifications or modalities that fall within the true scope of the invention. It is noted that in relation to this date, the best method known to the applicant to carry out the aforementioned invention, is that which is clear from the present description of the invention.

Claims (34)

1. CLAIMS Having described the invention as above, the content of the following claims is claimed as property. 1. A computer system, characterized in that it comprises: a microprocessor; a local bus driver coupled to the microprocessor via a collective bus bridge, where the bus driver bridge is configured to accommodate data transfers between the microprocessor and the local bus driver; and a collective conductor arbiter within the collective conductor bridge to control and prioritize the collective bus driver's request signals of a plurality of collective conductor devices coupled to the collective conductor, where the collective conductor's arbitrator contains a logic to control the granting of the collective conductor to a first collective conductor device of the plurality of collective conductor devices based on a predetermined plurality of the first collective conductor device relative to other collective conductor devices and the first prior access of the collective conductor device to the conductor collective within a cycle of equity.
2. 2. The computer system according to claim 1, characterized in that the collective bus driver also contains logic where the control is granted in response to the previous unsuccessful access of the collective conductor device to the collective driver within the equity cycle, and if each The collective driver device is successful within the equity cycle then in response to the predetermined priority of the first collective driver device in relation to other collective driver devices. The computer system according to claim 2, characterized in that priority access is recorded by adjusting at least one indicator when the first collective conductor device receives access to the collective conductor and the first collective conductor device does not receive a signal from retry The computer system according to claim 3, characterized in that the priority of the first device of the collective conductor is reduced below that of other request signals when the equity indicator is set. The computer system according to claim 3, characterized in that each equity indicator comprises a bit in a data recording unit controllable by the arbitrator. 6. The computer system according to claim 4, characterized in that it also comprises a timer coupled to the arbiter of the collective conductor, the timer begins when a retry signal has been sent to a collective conductor device, where after a lapse of one period default as determined by the timer, all equity indicators return to a fixed position. The computer system according to claim 6, characterized in that the predetermined period is programmed. The computer system according to claim 1, characterized in that the equity cycle starts in response to at least one request when the collective conductor is idle and ends when each applicant collective conductor device successfully completes a transfer over the collective driver . 9. A collective conductor arbitrator for a computer system, the computer system has a collective conductor to connect to a plurality of collective conductor devices where each request of the collective conductor device controls the collective conductor by the use of a collective signal. collective driver request, the collective conductor arbitrator is characterized in that it comprises: logic that incorporates an equity scheme to control and prioritize the collective conductor request signals based on a predetermined priority of each collective conductor device and each previous access of the collective driver's device within a cycle of equity, and logical to grant the control of the collective conductor to a collective conductor device based on the prioritization scheme and the equity scheme. 10. The arbiter of the collective conductor according to claim 9, characterized in that the previous access is recorded by adjusting a corresponding indicator when the first collective conductor device receives access to the collective conductor and the first collective conductor device does not receive a retry signal . 11. The arbiter of the collective conductor according to claim 10, characterized in that the priority of a first device of the collective conductor is reduced below that of the other request signals when the equity indicator is set. 12. The arbiter of the collective conductor according to claim 10, characterized in that each indicator comprises a bit in a data recording unit controllable by the arbiter. 13. The arbiter of the collective conductor according to claim 11, characterized in that it also comprises a timer coupled to the arbiter of the collective conductor, the timer starts when a retry signal has been sent to a collective conductor device, when after a lapse of a period default as determined by the timer, all equity indicators return to a non-fixed logical state. 14. The arbiter of the collective conductor according to claim 13, characterized in that the predetermined period is programmable. 15. The arbiter of the collective conductor according to claim 9, characterized in that the equity cycle starts in response to at least one collective conductor request when the collective conductor is idle and ends when each applicant collective conductor device successfully completes a transfer of data about the collective driver. 16. A method for arbitrating a collective driver in a computer system, having a collective driver to connect to a plurality of collective driver's devices, where each collective driver's device requests control of the collective driver by the use of a signal of the collective conductor, the method is characterized in that it comprises the steps of: (a) selecting a first collective conductor device to access the collective conductor from the plurality of collective conductor devices in response to a predetermined priority of collective conductor devices with respect to other devices of the plurality of collective conductor devices and a first logical state of the corresponding indicator, where the indicator operates to set a second logical state in response to a transaction of the corresponding collective conductor that effects an exchange of information through the conductor colec tivo. The method according to claim 16, characterized in that it further comprises the steps of: (b) determining whether the retry signal was received, if the retry signal was not received, setting the corresponding indicator to the second logical state; and (c) repeating steps (a) through (c) until all requests have been processed. 18. The method according to claim 16, characterized in that step (a) further comprises the additional step of starting an equity cycle before the step of selecting the first device of the collective conductor. 19. The method in accordance with the claim 18, characterized in that step (a) further comprises the additional step of setting a plurality of indicators to an initial state after starting the equity cycle. 20. The method of compliance with the claim 16, characterized in that the indicator is a registration bit coupled to an arbitrator of the collective conductor. 21. The method according to the claim 17, characterized in that it further comprises the step of: (d) granting access to the collective conductor based on the selection of the collective conductor device in step (a). 22. The method according to claim 21, characterized in that it also comprises the step of determining whether the predetermined time period has expired but a request has been sustained, if not repeating the steps (b), and if the lapse has expired repeat steps (d), (b), and (c). 23. The method according to claim 22, characterized in that the predetermined time period is determined by a timer coupled to the arbiter of the collective conductor. 24. The method according to claim 23, characterized in that the predetermined period is programmable. 25. The method according to claim 16, characterized in that it further comprises step of: (b) if the corresponding indicators are all in a second logical state a current equity cycle ends and the access to the collective conductor is determined in response to the predetermined priority . 26. The method according to claim 16, characterized in that it also comprises the step of: (b) repeating step (a) until all the indicators corresponding to each device of the plurality of requests for access to the collective conductor are in a second logical state. 27. The method according to claim 23, characterized in that the current equity cycle ends when each device requesting access to the collective driver successfully completes the transfer of data on the collective conductor. 28. A computer program product incorporated in machine readable medium, the program product is executable by the machine to effect a method of arbitrating a plurality of requests of the collective conductor device to control a collective conductor, characterized in that it comprises the steps of: (a) starting a cycle of equity; (b) setting a plurality of indicators in an initial state; (c) selecting a single collective conductor device from the plurality of collective conductor devices based on the highest priority of collective conductor devices with respect to other devices of the plurality of collective conductor devices and when it has not been fixed previously a corresponding indicator; (d) determine if the retry signal was received, if the retry signal was not received, set the corresponding indicator and repeat steps (d) to (e); and (e) repeating steps (c) through (e) until all requests for the equity cycle have been processed. 29. The product of the program according to claim 28, characterized in that step (c) further comprising determining whether a predetermined period of time has expired if a request has not been sustained, if not repeating step (c), if the period has expired repeat steps (b) to (c). 30. The product of the program according to claim 29, characterized in that predetermined period of time is determined by a timer coupled to the arbiter of the collective conductor. 31. The product of the program according to claim 30, characterized in that the predetermined period is programmable. 32. The product of the program according to claim 28, characterized in that the method further comprises, the step of, if all the indicators were set, selecting the access to the collective conductor of a collective conductor device in response to the predetermined priority. 33. The product of the program according to claim 28, characterized in that the method further comprises the step of: (b) repeating step (a) until all the indicators corresponding to each device of the plurality of collective conductor devices that request access to the collective driver be fixed. 34. The product of the program according to claim 28, characterized in that the equity cycle is initiated in response to at least one collective conductor request when the collective conductor is idle and ends when each applicant collective conductor device successfully completes a transfer about the collective driver.