CA2171170A1 - Pipelined distributed bus arbitration system - Google Patents
Pipelined distributed bus arbitration systemInfo
- Publication number
- CA2171170A1 CA2171170A1 CA002171170A CA2171170A CA2171170A1 CA 2171170 A1 CA2171170 A1 CA 2171170A1 CA 002171170 A CA002171170 A CA 002171170A CA 2171170 A CA2171170 A CA 2171170A CA 2171170 A1 CA2171170 A1 CA 2171170A1
- Authority
- CA
- Canada
- Prior art keywords
- bus
- sub
- clock cycle
- during
- systems
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 claims abstract description 28
- 238000012546 transfer Methods 0.000 claims description 13
- 230000001360 synchronised effect Effects 0.000 claims description 4
- 241001522296 Erithacus rubecula Species 0.000 claims description 3
- 230000008878 coupling Effects 0.000 claims 1
- 238000010168 coupling process Methods 0.000 claims 1
- 238000005859 coupling reaction Methods 0.000 claims 1
- 230000008859 change Effects 0.000 abstract description 4
- 230000008569 process Effects 0.000 abstract description 3
- 238000005516 engineering process Methods 0.000 abstract description 2
- 238000010586 diagram Methods 0.000 description 16
- 230000008901 benefit Effects 0.000 description 4
- 238000013461 design Methods 0.000 description 4
- GWUSZQUVEVMBPI-UHFFFAOYSA-N nimetazepam Chemical compound N=1CC(=O)N(C)C2=CC=C([N+]([O-])=O)C=C2C=1C1=CC=CC=C1 GWUSZQUVEVMBPI-UHFFFAOYSA-N 0.000 description 4
- YFONKFDEZLYQDH-OPQQBVKSSA-N N-[(1R,2S)-2,6-dimethyindan-1-yl]-6-[(1R)-1-fluoroethyl]-1,3,5-triazine-2,4-diamine Chemical compound C[C@@H](F)C1=NC(N)=NC(N[C@H]2C3=CC(C)=CC=C3C[C@@H]2C)=N1 YFONKFDEZLYQDH-OPQQBVKSSA-N 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- BSFODEXXVBBYOC-UHFFFAOYSA-N 8-[4-(dimethylamino)butan-2-ylamino]quinolin-6-ol Chemical compound C1=CN=C2C(NC(CCN(C)C)C)=CC(O)=CC2=C1 BSFODEXXVBBYOC-UHFFFAOYSA-N 0.000 description 1
- 241000256844 Apis mellifera Species 0.000 description 1
- 241000282320 Panthera leo Species 0.000 description 1
- 102000029797 Prion Human genes 0.000 description 1
- 108091000054 Prion Proteins 0.000 description 1
- 238000007792 addition Methods 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000001427 coherent effect Effects 0.000 description 1
- 244000221110 common millet Species 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
- G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
- G06F13/368—Handling requests for interconnection or transfer for access to common bus or bus system with decentralised access control
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
- G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
- G06F13/368—Handling requests for interconnection or transfer for access to common bus or bus system with decentralised access control
- G06F13/374—Handling requests for interconnection or transfer for access to common bus or bus system with decentralised access control using a self-select method with individual priority code comparator
Abstract
The present invention provides a scalable, modular and pipelined distributed bus arbitration system for efficiently resolving bus contention between sub-systems, e.g., processors, coupled to a common system bus. The arbitration system includes a plurality of distributed bus arbiters which receives the bus requests from the sub-systems and independently determine the next bus master.
The arbitration protocol enables the arbitration process to be eliminated from the critical timing path thereby allowing the system to operate at the maximum system clock frequency possible for a given integrated circuit (IC) technology to reduce overall system clock latencies. Any change among the sub-systems during an arbitration clock cycle is based on any system bus request(s) which are active during a clock cycle immediately preceding the arbitration clock cycle, and is independent of any system bus request(s) asserted during the arbitration clock cycle. In addition, the arbitration protocol treats a current bus master, i.e., the bus master driving the system bus, preferentially. Each arbitration task is completed within a system clock cycle regardless of processor speed. As a result, the arbitration latency for retaining the current bus master is one system clock cycle while the latency for selecting and switching bus masters is two system clock cycles. In this implementation, a last port driver is the only sub-system permitted to assert a bus request in a clock cycle and immediately drive the system bus in the next immediate clock cycle. Conversely, when a second sub-system which is not the last port driver needs to drive an inactive system bus, the second sub-system asserts its bus request line in a first clock cycle, and arbitration occurs within all the respective bus arbiters occurs in a second clock cycle.
The arbitration protocol enables the arbitration process to be eliminated from the critical timing path thereby allowing the system to operate at the maximum system clock frequency possible for a given integrated circuit (IC) technology to reduce overall system clock latencies. Any change among the sub-systems during an arbitration clock cycle is based on any system bus request(s) which are active during a clock cycle immediately preceding the arbitration clock cycle, and is independent of any system bus request(s) asserted during the arbitration clock cycle. In addition, the arbitration protocol treats a current bus master, i.e., the bus master driving the system bus, preferentially. Each arbitration task is completed within a system clock cycle regardless of processor speed. As a result, the arbitration latency for retaining the current bus master is one system clock cycle while the latency for selecting and switching bus masters is two system clock cycles. In this implementation, a last port driver is the only sub-system permitted to assert a bus request in a clock cycle and immediately drive the system bus in the next immediate clock cycle. Conversely, when a second sub-system which is not the last port driver needs to drive an inactive system bus, the second sub-system asserts its bus request line in a first clock cycle, and arbitration occurs within all the respective bus arbiters occurs in a second clock cycle.
Description
- 217117~
Page: 1 R,~cK('JRouNl~ OF THF, INVFNTION
Field of the TnveTltion The present invention relates to the field of computer systems architecture. More particularly, the invention relales to system bus arbitration protocols.
5 n~criDtion of the R~ ted Art In the design of an efficient system architecture with a number of sub-systems, e.g., a multi-processor system, the use of a common system bus shared by the sub-systems is useful for satisfying several important design goals. These goals include minimi~ing the total number and cost of interconnections between the sub-systems, maintaining modularity in the interfaces of sub-systems, 10 and simplifying the integration of interfaces for add-on sub-systems, e.g., expanded memory and peripherals. However, shaling a system bus necessitates the use of a bus arbitration protocol to resolve the inevitable bus contentions from the sub-systems.
Conventional bus arbitration protocols for resolving bus contentions can be divided into two general classes; centralized arbitration and distributed arbitration protocols. In an exemplary conventional centralized arbitration system 110, as shown in Figure lA, system 110 includes processors 111, 112, 113, 114,asystembus 118andacentralizedarbiterll9. Systembus 118,e.g., Address_bus, is coupled to plocesso- ~ 111, 112, 113, 114 and centralized arbiter 119. In addition, each of processors 111, 112, 113,114 is coupled to centralized arbiter 119 by one of bus ~quest lines Req_0, Req_l, Req_2, Req_3, and one of bus grant lines Bus_Grant_0, Bus_Grant_l, 20 Bus_Grant 2, Bus_Grant_3, l~s~li~ely.
Centralized arbiter 119 is the sole bus arbiter and is responsible for arbitrating all bus contentions. When one of processors 111, 112, 113, 114 needs to drive system bus 118, a request is made to centralized arbiter 119 via the appropriate bus request line. If no other processor is contending for system bus 118, centralized arbiter 119 assigns bus 118 to the requesting processor.
25 Conversely, if two or more processors make a bus request within a pre-determined period, centralized arbiter 119 uses a suitable allocation scheme, e.g., a round robin or a predetermined (3/30/95.ks) 21711~`
Page: 2 priority scheme, to decide which processor should be assigned the next bus master. In either case, centralized arbiter 119 co~ ullicates the bus grant to the assigned processor via the appropriate bus grant line. For example, processor 111 makes a request to arbiter 119 via bus request line Req_0 and eventually receives a grant from arbiter 119 via bus grant line Bus_Grant_0.Figure lB is a block diagram of a conventional distributed arbitration system 120 which includes processors 121, 122, 123, 124 and a system bus 128. System bus 128, e.g., Address_bus, is coupled to processors 121, 122, 123,124. In addition, processors 121,122,123,124 are coupled to each other by bus request lines Req_0, Req_l, Req_2, Req_3 and also by bus control lines Bus_Busy_0, Bus_Busy_l, Bus_Busy_2, Bus_Busy_3.
The distributed arbitration protocol dictates that all processors 121, 122, 123, 124 are responsible for 5imul~neously arbitrating bus contentions and assigning the same processor to be thenextbusmaster. Forexample,whenoneofprocessors 121,122,123,124needstodrivesystem bus 128, a request is broadcasted to every other processor coupled to bus 128 via the appropriate bus request line. If no other processor is contending for system bus 128, all the other pr~cessols will independently assign bus 118 to the requesting processor. Conversely, if two or more processors make a bus request within a pre-determined period, then each of processors 121,122,123,124 uses a suitable identical allocation scheme to independently arrive at the same conclusion as to which processor should be the next bus master. In either case, the processor assigned to be the next bus master cap~ules system bus 128 by asserting the a~propliate bus busy line, thereby co"-, n"nic~ting to all the otherprocessors that system bus 128 is now in use. Forexarnple, processor 121 bro~dc~ctc a bus request on bus request line Req_0. When system bus 128 is free and none of the o~her bus request lines Req_l, Req_2 and Req_3 has been asserted by a processor with higher priority, processor 121 proceeds to capture system bus 128 by asserting bus control line Bus_Busy_0.
Appendix A is a specification of one such distributed arbitration scheme, narned the "Futurebus+"
based on the I.E.E.E.Standard 896.2-1991.
(3/30/95.ks - 2171ili~
Page: 3 In most conventional bus arbitration protocols, such as the above mentioned protocols, in order to minimi7e the overall delay arising from bus arbitration, the sequential tasks of sending and receiving a bus request, and assigning the next bus master are completed in the same system clock cycle. While it is expedient to attempt to complete processing of the bus request and the S corresponding bus driver assignment in one system clock cycle, as the system clock speed increases in response to plocesso-s with faster processor clocks, the ability to receive a bus request and complete the arbitration process within a single fast system clock cycle is no longer ~tt~in~ble.
Hence, these conventional bus arbitration protocols are not scalable with respect to faster processors.
A system designer is forced to either slow the system clock speed or to use multiple system clock 10 cycles for resolving bus contentions. As a result, the performance is inhibited by either a slower system clock speed or extra system clock latencies inserted for solely arbitrating bus contentions.
Hence, there is a need for a solution to the bus arbitration problem that is efficient, cost effective, modular and scalable as processor clock speeds increase.
(3/30~5 ks) - 2t 1~ 1 70 Page: 4 SUMMAl~Y OF THF INYFNT~ON
The present invention provides a scalable, modular and pipelined distributed bus arbitration system for efficiently resolving bus contention between sub-systems, e.g., processors, coupled to a common system bus. The arbitration system includes a plurality of distributed bus arbiters which 5 receive the bus requests from the sub-systems and independently determine the next bus master.
In accordance with one embodiment of the invention, three principles provide minim~l system clock latencies associated with the transfers via the syslem bus. First, any change among the sub-systems during an arbitration clock cycle is based on any system bus request(s) which are active during a clock cycle immerli~te.ly preceding the arbitration clock cycle, and is independent 10 of any system bus request(s) asserted during the arbitration clock cycle. Second, the arbitration protocol treats a cuITent bus master, i.e., the bus master driving the system bus, preferentially. Third, output bus signals, e.g., bus request and drive enable signals, on the system bus are generated directly by output registers of the sub-systems without any intervening arbitration logic. Similarly, there is no ~l,il.alion logic coupled between the system bus and input registers of the sub-syster~s for 15 receiving input bus signals, i.e., the input registers are directly coupled to the system bus.
These principles permit the a, biL~dLion process to be elimin~te~ from the critical timing path thereby allowing the system to operate at the maximum system clock frequency possible for a given integrated circuit (IC) technology thereby reducing overall system clock latencies. In addition, each arbitration task is completed within a system clock cycle regardless of processor speed. As a 20 result, the arbitration latency for ret~ining the current bus master is one system clock cycle while the latency for selecting and switching bus masters is two system clock cycles.
The arbitration protocol also allows a "real-parking" mode that further reduces arbitration latencies in a simpler system where there are only two possible bus masters contending for the system bus. In the case of the simpler system, the arbitration latency for retaining the current bus 25 master can be reduced to zero system clock cycles, but increases the latency of switching culrent bus masters to four system clock cycles.
(3/30J95.ks) - 2tl~t.70 Page: 5 In this embodiment, a modified round-robin protocol is used to prioritiæ accesses arnong competing sub-systems to the system bus. Each sub-system occupies a port, i.e., a location, on the system bus and is assigned a unique identification number (ID). Every port keeps track of which port is the last port driver and then sim~ neously (concurrently) determines which port should be 5 assigned, i.e., selected to be, the next bus master based on the identity of the last port driver.
Consequently, whenever a port wins arbitration and becomes the current bus master, the identity of the last port driver stored by every port is updated with the ID of the new current bus master.
For efficiency, the last port driver is treated preferentially during priority assignments. Initially, upon system reset, the arbitration system is synchro~ ed by selecting a sub-system on a predefined 10 port to be the last port driver by every sub-system.
In some embodiments, the arbitration protocol allows a pre-assigned special port to be treated preferentially, i.e., the special port is not required to participate in the round-robin scheme.
Tns~e~r~, the special port is given the highest priority whenever its bus request is asserted. The special port protocol advantageously offers specific flexibility in the design of the higher level 5 system architecture. ~Ience, when the special port wins arbitration, the last port driver identity maintained by all the ports coupled to the system is not updated since the special port does not participate in the round-robin protocol.
In this implement~tion, the last port driver is the only sub-system permitted to assert a bus request in a clock cycle and imme~ sçly drive the system bus in the next immefli~te clock cycle.
20 Upon driving the system bus the first sub-system ~co.,.es the current bus master. Subsequently, the cuIrent bus master is permitted to lldns,~ multiple data packets back to back without any system clock latency by simply holding its bus request line. Although the current bus master may drive zero or more transaction packets before relinquishing the bus, in order to elimin~te the possibility of a system bus deadlock, the current bus master should relinquish the bus within a finite number 25 of clock cycles. In addition, the current bus master should relinquish its bus request line when the current driver has no more requests pending.
(3t30/95 ks) - 2 t 7 1 1 70 Page: 6 Conversely, when a second sub-system which is not the last port driver needs to drive an inactive system bus, the second sub-system asserts its bus request line in a first clock cycle.
Arbitration within all the les~cli~e bus arbiters occurs in the next clock cycle, i.e., the second clock cycle. Assllming that none of the other sub-systems has a higher priority than the second sub-5 system, then the second sub-system can now be assigned the next bus master and permitted to drive the bus in a third system clock cycle. Hence, two latent system clock cycles are needed where the requesting sub-system is not the last port driver and the system bus is inactive.
Advantages of the pipelined bus arbitration syslem include the ability to scale the arbitration system as sub-system clock speeds, e.g., processor clock speeds, increase, accomplished by 10 eliminating the arbitration logic from the critical path. Scalability is advantageous because most digital computers are based on a synchronous system clock and so a high clock speed is important for optimizing pe,rolmance. Hence the ability to scale the arbitration system without increasing arbitration l~tencies pe~nits minimi7~tion of the system clock cycle while m~int~i~ing minim~l overall all,i~alion latçncies. The modularity of the system also makes it easy to expand the system 15 bus and increase the number of sub-systems. Other advantages include minimal latency for the last port driver to become the cu~rent bus master, which is especially important in systerns where the sub-systems occupying the ports generate bursty traffic on the system bus, such as processors.
(3/30~5 ks) - 2171 fi~O
Page: 7 nF~SCR~PrION OF T~F nRAWINGS
The objects, features and advantages of the system of the present invention will be appal~nt from the following description in which:
Figure lA is a block diagram of a conventional system bus having a centralized bus 5 arbitration protocol.
Figure lB is a block diagram of a conventional system bus having a distributed bus arbitration protocol.
Figure 2 is a block diagram of a system bus using a distributed synchronous bus arbitration protocol in accordance with the invention.
Figure 3A is a table showing a round-robin assignment of a last port driver for four ports.
Figure 3B is a tirning diagram showing an arbitration request following a system reset.
Figure 4 is a timing diagram showing the last port driver transforming into a current bus master.
Figure S is a timing diagram illus~ting a change of bus drivers bel~.een the current bus master and a next bus master.
Figure 6 is a timing diagram illustrating another processor becoming the last port driver and the current bus master.
Figure 7 is a tirning diagram showing a special port, a system controller, bccollling the current bus master.
Figure 8 is a timing diagram showing the system controller sending a packet to the last port driver.
Figure 9 is a timing diagram showing a change of bus drivers between the system controller and the last port driver.
(3/30/~5 ks 2 ~ 7 ~
.
Page: 8 NOTATION~ ANn NOMFNCI,ATURF
System controller (SC): a central controller coupled to a system bus for orchestrating the cache coherency, data flow, flow control, and memory operations.
System bus master: a sub-system capable of initiating a data/address transfer on the system 5 bus.
Next bus master: the sub-system permitted to drive the system bus in the next system clock cycle.
Current bus master: the sub-system which is presently p~ ed to drive the system bus.
Last port driver: the sub-system which was last pennined to drove the system bus.
Port: a location or position occupied by a sub-system on the system bus which has a unique port identifier.
Page: 1 R,~cK('JRouNl~ OF THF, INVFNTION
Field of the TnveTltion The present invention relates to the field of computer systems architecture. More particularly, the invention relales to system bus arbitration protocols.
5 n~criDtion of the R~ ted Art In the design of an efficient system architecture with a number of sub-systems, e.g., a multi-processor system, the use of a common system bus shared by the sub-systems is useful for satisfying several important design goals. These goals include minimi~ing the total number and cost of interconnections between the sub-systems, maintaining modularity in the interfaces of sub-systems, 10 and simplifying the integration of interfaces for add-on sub-systems, e.g., expanded memory and peripherals. However, shaling a system bus necessitates the use of a bus arbitration protocol to resolve the inevitable bus contentions from the sub-systems.
Conventional bus arbitration protocols for resolving bus contentions can be divided into two general classes; centralized arbitration and distributed arbitration protocols. In an exemplary conventional centralized arbitration system 110, as shown in Figure lA, system 110 includes processors 111, 112, 113, 114,asystembus 118andacentralizedarbiterll9. Systembus 118,e.g., Address_bus, is coupled to plocesso- ~ 111, 112, 113, 114 and centralized arbiter 119. In addition, each of processors 111, 112, 113,114 is coupled to centralized arbiter 119 by one of bus ~quest lines Req_0, Req_l, Req_2, Req_3, and one of bus grant lines Bus_Grant_0, Bus_Grant_l, 20 Bus_Grant 2, Bus_Grant_3, l~s~li~ely.
Centralized arbiter 119 is the sole bus arbiter and is responsible for arbitrating all bus contentions. When one of processors 111, 112, 113, 114 needs to drive system bus 118, a request is made to centralized arbiter 119 via the appropriate bus request line. If no other processor is contending for system bus 118, centralized arbiter 119 assigns bus 118 to the requesting processor.
25 Conversely, if two or more processors make a bus request within a pre-determined period, centralized arbiter 119 uses a suitable allocation scheme, e.g., a round robin or a predetermined (3/30/95.ks) 21711~`
Page: 2 priority scheme, to decide which processor should be assigned the next bus master. In either case, centralized arbiter 119 co~ ullicates the bus grant to the assigned processor via the appropriate bus grant line. For example, processor 111 makes a request to arbiter 119 via bus request line Req_0 and eventually receives a grant from arbiter 119 via bus grant line Bus_Grant_0.Figure lB is a block diagram of a conventional distributed arbitration system 120 which includes processors 121, 122, 123, 124 and a system bus 128. System bus 128, e.g., Address_bus, is coupled to processors 121, 122, 123,124. In addition, processors 121,122,123,124 are coupled to each other by bus request lines Req_0, Req_l, Req_2, Req_3 and also by bus control lines Bus_Busy_0, Bus_Busy_l, Bus_Busy_2, Bus_Busy_3.
The distributed arbitration protocol dictates that all processors 121, 122, 123, 124 are responsible for 5imul~neously arbitrating bus contentions and assigning the same processor to be thenextbusmaster. Forexample,whenoneofprocessors 121,122,123,124needstodrivesystem bus 128, a request is broadcasted to every other processor coupled to bus 128 via the appropriate bus request line. If no other processor is contending for system bus 128, all the other pr~cessols will independently assign bus 118 to the requesting processor. Conversely, if two or more processors make a bus request within a pre-determined period, then each of processors 121,122,123,124 uses a suitable identical allocation scheme to independently arrive at the same conclusion as to which processor should be the next bus master. In either case, the processor assigned to be the next bus master cap~ules system bus 128 by asserting the a~propliate bus busy line, thereby co"-, n"nic~ting to all the otherprocessors that system bus 128 is now in use. Forexarnple, processor 121 bro~dc~ctc a bus request on bus request line Req_0. When system bus 128 is free and none of the o~her bus request lines Req_l, Req_2 and Req_3 has been asserted by a processor with higher priority, processor 121 proceeds to capture system bus 128 by asserting bus control line Bus_Busy_0.
Appendix A is a specification of one such distributed arbitration scheme, narned the "Futurebus+"
based on the I.E.E.E.Standard 896.2-1991.
(3/30/95.ks - 2171ili~
Page: 3 In most conventional bus arbitration protocols, such as the above mentioned protocols, in order to minimi7e the overall delay arising from bus arbitration, the sequential tasks of sending and receiving a bus request, and assigning the next bus master are completed in the same system clock cycle. While it is expedient to attempt to complete processing of the bus request and the S corresponding bus driver assignment in one system clock cycle, as the system clock speed increases in response to plocesso-s with faster processor clocks, the ability to receive a bus request and complete the arbitration process within a single fast system clock cycle is no longer ~tt~in~ble.
Hence, these conventional bus arbitration protocols are not scalable with respect to faster processors.
A system designer is forced to either slow the system clock speed or to use multiple system clock 10 cycles for resolving bus contentions. As a result, the performance is inhibited by either a slower system clock speed or extra system clock latencies inserted for solely arbitrating bus contentions.
Hence, there is a need for a solution to the bus arbitration problem that is efficient, cost effective, modular and scalable as processor clock speeds increase.
(3/30~5 ks) - 2t 1~ 1 70 Page: 4 SUMMAl~Y OF THF INYFNT~ON
The present invention provides a scalable, modular and pipelined distributed bus arbitration system for efficiently resolving bus contention between sub-systems, e.g., processors, coupled to a common system bus. The arbitration system includes a plurality of distributed bus arbiters which 5 receive the bus requests from the sub-systems and independently determine the next bus master.
In accordance with one embodiment of the invention, three principles provide minim~l system clock latencies associated with the transfers via the syslem bus. First, any change among the sub-systems during an arbitration clock cycle is based on any system bus request(s) which are active during a clock cycle immerli~te.ly preceding the arbitration clock cycle, and is independent 10 of any system bus request(s) asserted during the arbitration clock cycle. Second, the arbitration protocol treats a cuITent bus master, i.e., the bus master driving the system bus, preferentially. Third, output bus signals, e.g., bus request and drive enable signals, on the system bus are generated directly by output registers of the sub-systems without any intervening arbitration logic. Similarly, there is no ~l,il.alion logic coupled between the system bus and input registers of the sub-syster~s for 15 receiving input bus signals, i.e., the input registers are directly coupled to the system bus.
These principles permit the a, biL~dLion process to be elimin~te~ from the critical timing path thereby allowing the system to operate at the maximum system clock frequency possible for a given integrated circuit (IC) technology thereby reducing overall system clock latencies. In addition, each arbitration task is completed within a system clock cycle regardless of processor speed. As a 20 result, the arbitration latency for ret~ining the current bus master is one system clock cycle while the latency for selecting and switching bus masters is two system clock cycles.
The arbitration protocol also allows a "real-parking" mode that further reduces arbitration latencies in a simpler system where there are only two possible bus masters contending for the system bus. In the case of the simpler system, the arbitration latency for retaining the current bus 25 master can be reduced to zero system clock cycles, but increases the latency of switching culrent bus masters to four system clock cycles.
(3/30J95.ks) - 2tl~t.70 Page: 5 In this embodiment, a modified round-robin protocol is used to prioritiæ accesses arnong competing sub-systems to the system bus. Each sub-system occupies a port, i.e., a location, on the system bus and is assigned a unique identification number (ID). Every port keeps track of which port is the last port driver and then sim~ neously (concurrently) determines which port should be 5 assigned, i.e., selected to be, the next bus master based on the identity of the last port driver.
Consequently, whenever a port wins arbitration and becomes the current bus master, the identity of the last port driver stored by every port is updated with the ID of the new current bus master.
For efficiency, the last port driver is treated preferentially during priority assignments. Initially, upon system reset, the arbitration system is synchro~ ed by selecting a sub-system on a predefined 10 port to be the last port driver by every sub-system.
In some embodiments, the arbitration protocol allows a pre-assigned special port to be treated preferentially, i.e., the special port is not required to participate in the round-robin scheme.
Tns~e~r~, the special port is given the highest priority whenever its bus request is asserted. The special port protocol advantageously offers specific flexibility in the design of the higher level 5 system architecture. ~Ience, when the special port wins arbitration, the last port driver identity maintained by all the ports coupled to the system is not updated since the special port does not participate in the round-robin protocol.
In this implement~tion, the last port driver is the only sub-system permitted to assert a bus request in a clock cycle and imme~ sçly drive the system bus in the next immefli~te clock cycle.
20 Upon driving the system bus the first sub-system ~co.,.es the current bus master. Subsequently, the cuIrent bus master is permitted to lldns,~ multiple data packets back to back without any system clock latency by simply holding its bus request line. Although the current bus master may drive zero or more transaction packets before relinquishing the bus, in order to elimin~te the possibility of a system bus deadlock, the current bus master should relinquish the bus within a finite number 25 of clock cycles. In addition, the current bus master should relinquish its bus request line when the current driver has no more requests pending.
(3t30/95 ks) - 2 t 7 1 1 70 Page: 6 Conversely, when a second sub-system which is not the last port driver needs to drive an inactive system bus, the second sub-system asserts its bus request line in a first clock cycle.
Arbitration within all the les~cli~e bus arbiters occurs in the next clock cycle, i.e., the second clock cycle. Assllming that none of the other sub-systems has a higher priority than the second sub-5 system, then the second sub-system can now be assigned the next bus master and permitted to drive the bus in a third system clock cycle. Hence, two latent system clock cycles are needed where the requesting sub-system is not the last port driver and the system bus is inactive.
Advantages of the pipelined bus arbitration syslem include the ability to scale the arbitration system as sub-system clock speeds, e.g., processor clock speeds, increase, accomplished by 10 eliminating the arbitration logic from the critical path. Scalability is advantageous because most digital computers are based on a synchronous system clock and so a high clock speed is important for optimizing pe,rolmance. Hence the ability to scale the arbitration system without increasing arbitration l~tencies pe~nits minimi7~tion of the system clock cycle while m~int~i~ing minim~l overall all,i~alion latçncies. The modularity of the system also makes it easy to expand the system 15 bus and increase the number of sub-systems. Other advantages include minimal latency for the last port driver to become the cu~rent bus master, which is especially important in systerns where the sub-systems occupying the ports generate bursty traffic on the system bus, such as processors.
(3/30~5 ks) - 2171 fi~O
Page: 7 nF~SCR~PrION OF T~F nRAWINGS
The objects, features and advantages of the system of the present invention will be appal~nt from the following description in which:
Figure lA is a block diagram of a conventional system bus having a centralized bus 5 arbitration protocol.
Figure lB is a block diagram of a conventional system bus having a distributed bus arbitration protocol.
Figure 2 is a block diagram of a system bus using a distributed synchronous bus arbitration protocol in accordance with the invention.
Figure 3A is a table showing a round-robin assignment of a last port driver for four ports.
Figure 3B is a tirning diagram showing an arbitration request following a system reset.
Figure 4 is a timing diagram showing the last port driver transforming into a current bus master.
Figure S is a timing diagram illus~ting a change of bus drivers bel~.een the current bus master and a next bus master.
Figure 6 is a timing diagram illustrating another processor becoming the last port driver and the current bus master.
Figure 7 is a tirning diagram showing a special port, a system controller, bccollling the current bus master.
Figure 8 is a timing diagram showing the system controller sending a packet to the last port driver.
Figure 9 is a timing diagram showing a change of bus drivers between the system controller and the last port driver.
(3/30/~5 ks 2 ~ 7 ~
.
Page: 8 NOTATION~ ANn NOMFNCI,ATURF
System controller (SC): a central controller coupled to a system bus for orchestrating the cache coherency, data flow, flow control, and memory operations.
System bus master: a sub-system capable of initiating a data/address transfer on the system 5 bus.
Next bus master: the sub-system permitted to drive the system bus in the next system clock cycle.
Current bus master: the sub-system which is presently p~ ed to drive the system bus.
Last port driver: the sub-system which was last pennined to drove the system bus.
Port: a location or position occupied by a sub-system on the system bus which has a unique port identifier.
3~3n~s.k.
- 2 1 7 t ~ 1~
Page: 9 nF~,CRTPTION OF THF PRFFFRRFD FM~ODIMFNT
In the following description, numerous details provide a thorough understanding of the invention. These details include functional blocks and an exemplary pre-determined arbitration priority scheme to assist a systems designer in implementing an efficient pipelined distributed bus 5 arbitration system. While the bus arbitration system is illustrated by a specific implementation, the invention is applicable to a wide variety of system architectures and environment~. In other in-st~nces, well-known circuits, structures and program code are not described in detail so as not to obscure the invention unne~ess~rily. Accordingly, co-pending patent application, entitled "Packet Switched Cache Coherent Multiprocessor System", our reference number ~i'31, assigned to Sun l0 Microsystems, Inc., herein incorporated by reference in its entirety, provides a detailed specification of the pipelined distributed bus arbitration protocol in accordance with the present invention.
In one embodim~-nt, as illustrated by the block diagram of Figure 2, system 200 includes multiple sub-systems, e.g., processors 210,220,230,240, a system bus 280, and a system controller 290. Each sub-system includes a bus transceiver, a bus requester and a bus arbiter. For example, processor 210 includes a bus transceiver 212, a bus requester 214 and a bus arbiter 216. Similarly, system controller 290 includes a bus transceiver 292, a bus requester 294 and a bus arbiter 296.
Collectively, bus arbiters 216, 226, ... 296 form the distributed arbitration system of the present invention.
In this implemen~tion, system bus 280 is an address bus, thereby advantageously enabling 20 data to be siml-lt~neously transferred over a separate data bus (not shown) while the address bus is busy. Nevertheless, the present invention is equally applicable to other systems where system bus 280 is a de-licated data bus or a combined address/data bus. In addition, although the described sub-systems are all bus masters, the a~ dlion protocol is also applicable to systems where the sub-systems includes both bus master(s) and bus slave(s). Hence, with respect to this embodiment 25 of system 200, a current bus master is also a current bus master.
(3/30~5 .ks) 2t7t~
Page: 10 System bus 280 int~,conn~ls the lcs~Li~e bus transceivers 212, 222, 232, 242 of processors 210, 220, 230, 240 to bus transceiver 292 of system controller 290. Processors 210, 220, 230 and 240 are also coupled to system controller 290 by their respective bus qualifier lines UPA_Addr_Valid_0. UPA_Addr_Valid_1, UPA_Addr_Valid_2 and UPA_Addr_Valid_3.
Bus requesters 214,224,234,244,294 and bus arbiters 216,226,236,246,296 of processors 210, 220, 230, 240 and system controller 290, respectively, are coupled to each other via the following albiLIdLion control lines. A system arbitration reset line Arb_Reset couples system controller 290 to all processors 210, 220, 230, 240. A Req_out_0 line of bus requester 214 is coupled to a Req_0 line of system controller's bus arbiter 296 and to Req_in_2, Req_in_1, Req_in_0 lines of bus arbiters 226,236,246, respectively, and a Req_out_1 line of bus requester 224 is coupled to Req_l, Req_in_0, Req_in_2, Req_in_1 lines of bus arbiters 296, 216, 236, 246, res~ecLi-/ely.
Sirnilarly, a Req_out_2 line of bus requester 234 is coupled to Req_2, Req_in_l, Req_in_0, Req_in_2 lines of bus arbiters 296,216,226,246, respectively, and a Req_out_3 line of bus requester 244 is coupled to Req_3, Req_in_2, Req_in_1, Req_in_0 lines of bus arbiters 226, 236, 246, 15 respectively. Finally, a SC_Req line of system controller's bus requester 294 couples controller 290 to bus arbiters 216, 226, 236, 246 of processors 210, 220, 230, 240, respectively Although counter-intuitive on its face, one underlying technique used in the pipelined distributed bus arbitration system is to divide the arbitration sequence into separate tasks for processing in separate clock cycles. For example, the sensing of outstanding bus request(s) and 20 the assigrlment of a next bus master are completed in separate clock cycles. Another technique is to . . in h i~e the frequency of changeovers of the current bus master. Yet another technique is to minimi7e the total number of clock cycles lost when a changeover of the current bus master is needed. By applying these techniques, each arbitration task is completed within a system clock cycle regardless of processor clock speed and wherever possible, arbitration tasks are elimin~sed 25 from the critical path, thereby reducing the number of system clock cycle l~tencies due to bus arbitration.
~ c ~
2t711 ~
`_ Page: 11 As a result, the following minim~l arbitration latencies are possible in this implement~tion.
A current bus master can transmit data packets back to back without any system clock latency. A
last port driver is permitted to request for and drive the system bus in consecutive system clock cycles, i.e., one system clock latency. When a processor is not the last port driver, then there is a 5 minimllm of two system clock latencies. Finally, a minimum of three latent system clock cycles are needed to displace a different current bus master. These minim~l system clock l~tencies are accomplished by the following rules.
Figure 3A is a table showing an exemplary modified round-robin priority scheme for bus arbiters 216, 226, 236, 246 of processors 210, 220, 230, 240, respectively. The priority scheme is 10 used by the arbitration system to select a next bus master from among the sub-systems competing for system bus 280. Each processor occupies a port (location) on system bus 280 and is assigned a unique identification number (ID). For system synch onizalion, processor 210, with port address 0, is sele~ted to be a last port driver upon reset. Subsequently, every port keeps track of which port isthelastportdriverandtosim~ eo-lçly(concurrently)detelrnineswhichportshouldbe~csigned, 15 i.e., selected to be, the next bus rnaster based on the identity of the last port driver. Consequently, when a port wins arbitration and becomes the current bus master, the identity of the last port driver stored by every processor is updated with the ID of the new current bus master. For efficiency, the last port driver is treated preferentially.
Figures 3B and 4 through 9 are exempl~ry timing diagrams illustrating multi-processor 20 system 200 wherein the width of the addressbus is chosen such that two bus clocks cycles are required to complete an address transfer. Hence, in the following exemplary rliccuscion~ although each data transfer quantum (address information packet size) requires two clock cycles for completion, the notion of a two cycle data and/or address bus is not fund~men~l to this invention.
For example, processor 210 drives a first cycle of address inforrnation onto system bus 280 during 25 one system cycle, and a second cycle of address info.,l~ation during a second system clock cycle.
(3/30/95.ks) 2 1 71 ~ 70 -Page: 12 As is known to one skilled in the art, depending on the implemens~tion, data and/or address packets can be transferred over a system bus in one or more system clock cycles, i.e., other system bus widths are possible. For example, in another embodiment, the address bus width is equal to the width of the system address space. In yet another embodiment, the address bus width is a quarter S of the width of the system address space. Further note that processors 210,220,230,240 are similar and hence a descli~lion of one sub-system, e.g., processor 210 or 220, is applicable to the other sub-systems, i.e., processors 220, 230, 240.
Figure 3B show a reset timing sequence wherein a bus arbitration request may be asserted one clock cycle after a system reset signal UPA_Reset_L. Each of processors 210, 220, 230, 240 has a unique port address, 0,1, 2, 3, respectively. An Arb_Reset signal on Arb_Reset line provides system controller 290 with a mechanism for selectively resetting state machine(s) of one or more sub-systems without reset~ng every state m~rhine of each sub-system. For example, the Arb_Reset signal from system controller 290 enables processors 210, 220, 230, 240 to synchronize the rcs~li./e arbitration state ,..~chines of bus arbiters 216, 226, 236, 246.
Figure 4 is a timing diagram illustrating the transformation of the last port driver into the curTent bus master. ~ssllming that bus arbiters 216, 226, ... 296 have determined that there are no bus request(s) outct~n-ling in a clock cycle preceding a first clock cycle, the last port driver is the only su~system po~ lcd to assert a bus request during the first clock cycle and imm~Ai~tely drive system bus 280 during a second clock cycle. For example, when processor 210 is the last port 20 driver, processor 210 already has the highest priority and can be assigned, i.e., selected to be, the next bus master without the need to poll the bus request lines of the other processors 220, 230, 240 during the first clock cycle. Consequently, bus transceiver 212 is permitted to assert its bus request line Req_out_0 during the first system clock cycle and drive system bus 280 in the next immeAi~te clock cycle, i.e., the second system clock cycle. In this exarnple, processor 210 drives a first half 25 of the address onto address bus 280 in the second system clock cycle and a second half of the address onto address bus 280 in a third system clock cycle.
(3/30/95.ks) Page: 13 Upon driving bus 280 in the second system clock cycle, processor 210 is assigned the status of the current bus master. The current bus master is defined as the sub-system which is culrently driving address bus 280 and also asserting the UPA_Addr_Valid_x qualifier line of its transceiver, e.g., UPA_Addr_Valid_0 of transceiver 212. Being the current bus master, processor 210 can 5 transmit multiple data packets back to back without any system clock latency by simply m~int~ining, i.e., contin~ling to assert, bus request line Req_out_0 of bus requester 214. Although the current bus master, ~ cessor 210, may drive any number of transaction packets (including no packet) before relinquishing system bus 280 in the presence of a bus request from another processor 220, 230,240 or system controller 290, in order to elimin~te the possibility of a deadlock, a well behaved current bus driver should release bus 280 within a finite number of clock cycles. In addition, the current bus master should also release its bus request line when the current bus master has no more request pending.
As shown in Figure 5, when a sub-system, e.g., processor 220, which is not the last port driver,assertsbusrequestlineReq_out_1 of requester224whileanothersub-system,e.g.,plocessor 15 210, is both the last port driver and the current bus master, then there is a latency of at least three system clock cycles before transceiver 222 of processor 220 is able to drive system bus 2~0. There are two reasons why a minimnm of three latent system clock cycles are needed for displacing a current bus master which driving system bus 280. First, even though requester 224 has asserted bus request line Req_out_1 by the first system clock cycle, two system clock cycles are needed to 20 complete the tr~ncmicsion of processor 210's last data packet of address information. Second, the ~ bi~ldlion protocol e-lfol~,es a dead cycle in the third clock cycle.
Hence, ~Csl~ming that no other processors with a higher priority than processor 220 is contending for system bus 280, processor 220 can now be assigned the next bus master and proceed to drive system bus 280 in a fourth system clock cycle. As a result, replacing an active current bus 25 master requires three latent clock cycles.
(3/30195.ks) Page: 14 As ~liscllsse~ above, the arbitration protocol provides an idle or dead cycle on system bus 280 between current bus master changes. The dead cycle eliminates the possibility of the bus driver circuitry of t~vo bus masters, i.e., the current bus master and the next bus master, sim~lt~neously driving system bus 280. One such example is where the turn-off time of the driver circuitry of the 5 first bus master, i.e., processor 210, is longer than the turn-on time of the driver circuitry of the second bus master, i.e., processor 220. Note that when a current bus master asserts its bus request line, the total number of bus cycles ~ ulled to switch the current bus master also depends on factors such as the state of processor 210's current data transfer, i.e., was the bus request from processor 220 asserted during the first or second half of processor 210's data transfer.
10Figure 6 is a timing diagram illustrating a different sub-syslem, e.g., processor 220, becoming the last port driver and eventually the current bus master when system bus 280 is inactive, i.e., not being driven. During the first clock cycle, processor 210, the last port driver, is inactive and is not driving system bus 280. When requester 224 of processor 220 asserts bus request line Req_out_l in the second clock cycle, arbitration occurs in the next clock cycle, i.e., the third clock 15cycle. ~s~lming that no other processors with a higher priority than processor 220 needs bus 280, processor 220 can now be assigned the next bus master and perrnitled to drive bus 280 in a fourth system clock cycle. Hence, where the requesting processor is not Ihe last port driver and system bus 280 is inactive, a total of two latent system clock cycles are needed between the bus request and ownership of bus 280.
20Referring now to Figure 7, system controller 290 makes a bus request and eventually beco,ll~s the cu~Tent bus rnaster. When system controller 290 asserts request line SC_Req of requester 294 duling the second clock cycle while processor 210 is the last port driver but inactive, another system clock cycle, the third cycle, is needed for arbitration. Subsequently, in the fourth clock cycle, system controller 290 is perrnitted to drive address bus 280. Hence, there are two latent 25 system clock cycles which is similar to the instance where one sub-system wants to drive bus 280 while another su~system is an inactive last port driver.
(31301~5 ks Page: 15 In accordance with another aspect of the invention, the arbitration protocol allows a "real-parking" mode which further reduces arbitration latencies where system 200 has only two possible bus drivers, i.e., two bus masters, for example when there are only processors 210,220, coupled to system bus 280. In the case of this reduced system, the arbitration latency for retaining the current 5 bus master can be reduced to zero system clock cycle by simply maintaining the bus request of the current bus master after completion of the data transfer.
In some embo~liments, the arbitration protocol of system 200 allows a pre-assigned special port, e.g., system controller 290, to be treated preferentially, i.e., the special port is not required to participate in the round-robin scheme. In this example, system controller 290 is given the highest l0 priority whenever its bus request is asserted. The special port designation advantageously offers specific flexibility in the design of the higher level architecture of system 200. Hence, whenever system controller 290 wins arbitration, the last port driver identity m~int~ine~ by all the ports coupled to the system, i.e., processors 210, 220, 230, 240, is not updated since system controller 290 does not participate in the modified round-robin protocol.
Bidirectional bus qualifier signals UPA_Addr_Valid_0, UPA_Addr_Valid_1, UPA_Addr_Valid_2 and U~'A_Addr_Valid_3 are exchanged between the special port, system controller 290, and processors 210, 220, 230, 240, respectively, enabling system controller 290 to detect when the cDnt bus master is driving a valid packet. Conversely, when system controlier 290 is the current bus master, the validity signals enable a slave sub-subsystem to know when to receive a data packet from system controller 290. In addition, a validity signal is asserted during the first system clock cycle of each two cycle packet, and deasserted during the second cycle.
Holding arnplifiers of system controller 290 m~in~in the logic level of UPA_Addr_Valid lines whenever there is no active bus driver. Other benefits of using holding amplifiers on system controller 290 include ease of debugging system bus 280.
Figure 8 is a timing diagram illustrating a data packet transfer from the special port, e.g., system controller 290, to processor 210. When syslem controller 290 asserts request line SC_Req (3/30/95 .ksl - 2171 17~
Page: 16 while the transceiver of the current bus master, e.g., transceiver 212 of processor 210, is driving bus 280, processor 210 is permitted to complete the ongoing transfer of the last data packet. Since systemcontroller290isthespecialport,processor210isexpectedtoreleaserequestlineReq_out_0 of requester 214. As discussed above, system controller 290 always has the highest priority relative 5 to the other sub-systems and hence need not be assigned the next bus master. As such, processor 210 can remain the last port driver when transceiver 292 of system controller 290 is driving system bus 280. From the perspective of system controller 290, the completion of the transfer of the last data packet by processor 210 incurs two latent system clock cycles. A third latent clock cycle is needed to prevent system bus fights, i.e., attempts by multiple sub-systems to sim~ neously drive 10system bus 280. Thereafter, system controller 290 becomes the current bus master and is permitted to drive system bus 280. Note that pre-assigning system controller 290 with the highest priority relative to sub-systems 210, 220, 230, 240 is merely an implementational option. The arbitration system of the present invention is also applicable to other systems where system controller 290 has equal or lower priority relative to sub-systems 210, 220, 230, 240.
15As shown in Figure 9, system controller 290 surrenders ownership of system bus 280 in response to a bus request from an inactive sub-system which was the last port driver. When system controller 290 is the current bus master and detects a bus request from an inactive last port driver, e.g., processor 210, system controller 290 completes the transfer of the last data packet in two system clock cycles. A third latent system clock cycle is needed before the last port driver, e.g., 20processor 210 can begin to drive system bus 280 and become the current bus master.
Other modifications and additions are possible without departing from the spirit of the invention. For example, the total number of sub-systems can be smaller or larger. The address bus can be wider or narrower with respect to the system address space. In addition, the sub-systems can include video controllers, cache controllers and mathematical co-processors such as floating 25 point units. Hence, the scope of the invention should be determined by the following claims.
(3f30~5 ks)
- 2 1 7 t ~ 1~
Page: 9 nF~,CRTPTION OF THF PRFFFRRFD FM~ODIMFNT
In the following description, numerous details provide a thorough understanding of the invention. These details include functional blocks and an exemplary pre-determined arbitration priority scheme to assist a systems designer in implementing an efficient pipelined distributed bus 5 arbitration system. While the bus arbitration system is illustrated by a specific implementation, the invention is applicable to a wide variety of system architectures and environment~. In other in-st~nces, well-known circuits, structures and program code are not described in detail so as not to obscure the invention unne~ess~rily. Accordingly, co-pending patent application, entitled "Packet Switched Cache Coherent Multiprocessor System", our reference number ~i'31, assigned to Sun l0 Microsystems, Inc., herein incorporated by reference in its entirety, provides a detailed specification of the pipelined distributed bus arbitration protocol in accordance with the present invention.
In one embodim~-nt, as illustrated by the block diagram of Figure 2, system 200 includes multiple sub-systems, e.g., processors 210,220,230,240, a system bus 280, and a system controller 290. Each sub-system includes a bus transceiver, a bus requester and a bus arbiter. For example, processor 210 includes a bus transceiver 212, a bus requester 214 and a bus arbiter 216. Similarly, system controller 290 includes a bus transceiver 292, a bus requester 294 and a bus arbiter 296.
Collectively, bus arbiters 216, 226, ... 296 form the distributed arbitration system of the present invention.
In this implemen~tion, system bus 280 is an address bus, thereby advantageously enabling 20 data to be siml-lt~neously transferred over a separate data bus (not shown) while the address bus is busy. Nevertheless, the present invention is equally applicable to other systems where system bus 280 is a de-licated data bus or a combined address/data bus. In addition, although the described sub-systems are all bus masters, the a~ dlion protocol is also applicable to systems where the sub-systems includes both bus master(s) and bus slave(s). Hence, with respect to this embodiment 25 of system 200, a current bus master is also a current bus master.
(3/30~5 .ks) 2t7t~
Page: 10 System bus 280 int~,conn~ls the lcs~Li~e bus transceivers 212, 222, 232, 242 of processors 210, 220, 230, 240 to bus transceiver 292 of system controller 290. Processors 210, 220, 230 and 240 are also coupled to system controller 290 by their respective bus qualifier lines UPA_Addr_Valid_0. UPA_Addr_Valid_1, UPA_Addr_Valid_2 and UPA_Addr_Valid_3.
Bus requesters 214,224,234,244,294 and bus arbiters 216,226,236,246,296 of processors 210, 220, 230, 240 and system controller 290, respectively, are coupled to each other via the following albiLIdLion control lines. A system arbitration reset line Arb_Reset couples system controller 290 to all processors 210, 220, 230, 240. A Req_out_0 line of bus requester 214 is coupled to a Req_0 line of system controller's bus arbiter 296 and to Req_in_2, Req_in_1, Req_in_0 lines of bus arbiters 226,236,246, respectively, and a Req_out_1 line of bus requester 224 is coupled to Req_l, Req_in_0, Req_in_2, Req_in_1 lines of bus arbiters 296, 216, 236, 246, res~ecLi-/ely.
Sirnilarly, a Req_out_2 line of bus requester 234 is coupled to Req_2, Req_in_l, Req_in_0, Req_in_2 lines of bus arbiters 296,216,226,246, respectively, and a Req_out_3 line of bus requester 244 is coupled to Req_3, Req_in_2, Req_in_1, Req_in_0 lines of bus arbiters 226, 236, 246, 15 respectively. Finally, a SC_Req line of system controller's bus requester 294 couples controller 290 to bus arbiters 216, 226, 236, 246 of processors 210, 220, 230, 240, respectively Although counter-intuitive on its face, one underlying technique used in the pipelined distributed bus arbitration system is to divide the arbitration sequence into separate tasks for processing in separate clock cycles. For example, the sensing of outstanding bus request(s) and 20 the assigrlment of a next bus master are completed in separate clock cycles. Another technique is to . . in h i~e the frequency of changeovers of the current bus master. Yet another technique is to minimi7e the total number of clock cycles lost when a changeover of the current bus master is needed. By applying these techniques, each arbitration task is completed within a system clock cycle regardless of processor clock speed and wherever possible, arbitration tasks are elimin~sed 25 from the critical path, thereby reducing the number of system clock cycle l~tencies due to bus arbitration.
~ c ~
2t711 ~
`_ Page: 11 As a result, the following minim~l arbitration latencies are possible in this implement~tion.
A current bus master can transmit data packets back to back without any system clock latency. A
last port driver is permitted to request for and drive the system bus in consecutive system clock cycles, i.e., one system clock latency. When a processor is not the last port driver, then there is a 5 minimllm of two system clock latencies. Finally, a minimum of three latent system clock cycles are needed to displace a different current bus master. These minim~l system clock l~tencies are accomplished by the following rules.
Figure 3A is a table showing an exemplary modified round-robin priority scheme for bus arbiters 216, 226, 236, 246 of processors 210, 220, 230, 240, respectively. The priority scheme is 10 used by the arbitration system to select a next bus master from among the sub-systems competing for system bus 280. Each processor occupies a port (location) on system bus 280 and is assigned a unique identification number (ID). For system synch onizalion, processor 210, with port address 0, is sele~ted to be a last port driver upon reset. Subsequently, every port keeps track of which port isthelastportdriverandtosim~ eo-lçly(concurrently)detelrnineswhichportshouldbe~csigned, 15 i.e., selected to be, the next bus rnaster based on the identity of the last port driver. Consequently, when a port wins arbitration and becomes the current bus master, the identity of the last port driver stored by every processor is updated with the ID of the new current bus master. For efficiency, the last port driver is treated preferentially.
Figures 3B and 4 through 9 are exempl~ry timing diagrams illustrating multi-processor 20 system 200 wherein the width of the addressbus is chosen such that two bus clocks cycles are required to complete an address transfer. Hence, in the following exemplary rliccuscion~ although each data transfer quantum (address information packet size) requires two clock cycles for completion, the notion of a two cycle data and/or address bus is not fund~men~l to this invention.
For example, processor 210 drives a first cycle of address inforrnation onto system bus 280 during 25 one system cycle, and a second cycle of address info.,l~ation during a second system clock cycle.
(3/30/95.ks) 2 1 71 ~ 70 -Page: 12 As is known to one skilled in the art, depending on the implemens~tion, data and/or address packets can be transferred over a system bus in one or more system clock cycles, i.e., other system bus widths are possible. For example, in another embodiment, the address bus width is equal to the width of the system address space. In yet another embodiment, the address bus width is a quarter S of the width of the system address space. Further note that processors 210,220,230,240 are similar and hence a descli~lion of one sub-system, e.g., processor 210 or 220, is applicable to the other sub-systems, i.e., processors 220, 230, 240.
Figure 3B show a reset timing sequence wherein a bus arbitration request may be asserted one clock cycle after a system reset signal UPA_Reset_L. Each of processors 210, 220, 230, 240 has a unique port address, 0,1, 2, 3, respectively. An Arb_Reset signal on Arb_Reset line provides system controller 290 with a mechanism for selectively resetting state machine(s) of one or more sub-systems without reset~ng every state m~rhine of each sub-system. For example, the Arb_Reset signal from system controller 290 enables processors 210, 220, 230, 240 to synchronize the rcs~li./e arbitration state ,..~chines of bus arbiters 216, 226, 236, 246.
Figure 4 is a timing diagram illustrating the transformation of the last port driver into the curTent bus master. ~ssllming that bus arbiters 216, 226, ... 296 have determined that there are no bus request(s) outct~n-ling in a clock cycle preceding a first clock cycle, the last port driver is the only su~system po~ lcd to assert a bus request during the first clock cycle and imm~Ai~tely drive system bus 280 during a second clock cycle. For example, when processor 210 is the last port 20 driver, processor 210 already has the highest priority and can be assigned, i.e., selected to be, the next bus master without the need to poll the bus request lines of the other processors 220, 230, 240 during the first clock cycle. Consequently, bus transceiver 212 is permitted to assert its bus request line Req_out_0 during the first system clock cycle and drive system bus 280 in the next immeAi~te clock cycle, i.e., the second system clock cycle. In this exarnple, processor 210 drives a first half 25 of the address onto address bus 280 in the second system clock cycle and a second half of the address onto address bus 280 in a third system clock cycle.
(3/30/95.ks) Page: 13 Upon driving bus 280 in the second system clock cycle, processor 210 is assigned the status of the current bus master. The current bus master is defined as the sub-system which is culrently driving address bus 280 and also asserting the UPA_Addr_Valid_x qualifier line of its transceiver, e.g., UPA_Addr_Valid_0 of transceiver 212. Being the current bus master, processor 210 can 5 transmit multiple data packets back to back without any system clock latency by simply m~int~ining, i.e., contin~ling to assert, bus request line Req_out_0 of bus requester 214. Although the current bus master, ~ cessor 210, may drive any number of transaction packets (including no packet) before relinquishing system bus 280 in the presence of a bus request from another processor 220, 230,240 or system controller 290, in order to elimin~te the possibility of a deadlock, a well behaved current bus driver should release bus 280 within a finite number of clock cycles. In addition, the current bus master should also release its bus request line when the current bus master has no more request pending.
As shown in Figure 5, when a sub-system, e.g., processor 220, which is not the last port driver,assertsbusrequestlineReq_out_1 of requester224whileanothersub-system,e.g.,plocessor 15 210, is both the last port driver and the current bus master, then there is a latency of at least three system clock cycles before transceiver 222 of processor 220 is able to drive system bus 2~0. There are two reasons why a minimnm of three latent system clock cycles are needed for displacing a current bus master which driving system bus 280. First, even though requester 224 has asserted bus request line Req_out_1 by the first system clock cycle, two system clock cycles are needed to 20 complete the tr~ncmicsion of processor 210's last data packet of address information. Second, the ~ bi~ldlion protocol e-lfol~,es a dead cycle in the third clock cycle.
Hence, ~Csl~ming that no other processors with a higher priority than processor 220 is contending for system bus 280, processor 220 can now be assigned the next bus master and proceed to drive system bus 280 in a fourth system clock cycle. As a result, replacing an active current bus 25 master requires three latent clock cycles.
(3/30195.ks) Page: 14 As ~liscllsse~ above, the arbitration protocol provides an idle or dead cycle on system bus 280 between current bus master changes. The dead cycle eliminates the possibility of the bus driver circuitry of t~vo bus masters, i.e., the current bus master and the next bus master, sim~lt~neously driving system bus 280. One such example is where the turn-off time of the driver circuitry of the 5 first bus master, i.e., processor 210, is longer than the turn-on time of the driver circuitry of the second bus master, i.e., processor 220. Note that when a current bus master asserts its bus request line, the total number of bus cycles ~ ulled to switch the current bus master also depends on factors such as the state of processor 210's current data transfer, i.e., was the bus request from processor 220 asserted during the first or second half of processor 210's data transfer.
10Figure 6 is a timing diagram illustrating a different sub-syslem, e.g., processor 220, becoming the last port driver and eventually the current bus master when system bus 280 is inactive, i.e., not being driven. During the first clock cycle, processor 210, the last port driver, is inactive and is not driving system bus 280. When requester 224 of processor 220 asserts bus request line Req_out_l in the second clock cycle, arbitration occurs in the next clock cycle, i.e., the third clock 15cycle. ~s~lming that no other processors with a higher priority than processor 220 needs bus 280, processor 220 can now be assigned the next bus master and perrnitled to drive bus 280 in a fourth system clock cycle. Hence, where the requesting processor is not Ihe last port driver and system bus 280 is inactive, a total of two latent system clock cycles are needed between the bus request and ownership of bus 280.
20Referring now to Figure 7, system controller 290 makes a bus request and eventually beco,ll~s the cu~Tent bus rnaster. When system controller 290 asserts request line SC_Req of requester 294 duling the second clock cycle while processor 210 is the last port driver but inactive, another system clock cycle, the third cycle, is needed for arbitration. Subsequently, in the fourth clock cycle, system controller 290 is perrnitted to drive address bus 280. Hence, there are two latent 25 system clock cycles which is similar to the instance where one sub-system wants to drive bus 280 while another su~system is an inactive last port driver.
(31301~5 ks Page: 15 In accordance with another aspect of the invention, the arbitration protocol allows a "real-parking" mode which further reduces arbitration latencies where system 200 has only two possible bus drivers, i.e., two bus masters, for example when there are only processors 210,220, coupled to system bus 280. In the case of this reduced system, the arbitration latency for retaining the current 5 bus master can be reduced to zero system clock cycle by simply maintaining the bus request of the current bus master after completion of the data transfer.
In some embo~liments, the arbitration protocol of system 200 allows a pre-assigned special port, e.g., system controller 290, to be treated preferentially, i.e., the special port is not required to participate in the round-robin scheme. In this example, system controller 290 is given the highest l0 priority whenever its bus request is asserted. The special port designation advantageously offers specific flexibility in the design of the higher level architecture of system 200. Hence, whenever system controller 290 wins arbitration, the last port driver identity m~int~ine~ by all the ports coupled to the system, i.e., processors 210, 220, 230, 240, is not updated since system controller 290 does not participate in the modified round-robin protocol.
Bidirectional bus qualifier signals UPA_Addr_Valid_0, UPA_Addr_Valid_1, UPA_Addr_Valid_2 and U~'A_Addr_Valid_3 are exchanged between the special port, system controller 290, and processors 210, 220, 230, 240, respectively, enabling system controller 290 to detect when the cDnt bus master is driving a valid packet. Conversely, when system controlier 290 is the current bus master, the validity signals enable a slave sub-subsystem to know when to receive a data packet from system controller 290. In addition, a validity signal is asserted during the first system clock cycle of each two cycle packet, and deasserted during the second cycle.
Holding arnplifiers of system controller 290 m~in~in the logic level of UPA_Addr_Valid lines whenever there is no active bus driver. Other benefits of using holding amplifiers on system controller 290 include ease of debugging system bus 280.
Figure 8 is a timing diagram illustrating a data packet transfer from the special port, e.g., system controller 290, to processor 210. When syslem controller 290 asserts request line SC_Req (3/30/95 .ksl - 2171 17~
Page: 16 while the transceiver of the current bus master, e.g., transceiver 212 of processor 210, is driving bus 280, processor 210 is permitted to complete the ongoing transfer of the last data packet. Since systemcontroller290isthespecialport,processor210isexpectedtoreleaserequestlineReq_out_0 of requester 214. As discussed above, system controller 290 always has the highest priority relative 5 to the other sub-systems and hence need not be assigned the next bus master. As such, processor 210 can remain the last port driver when transceiver 292 of system controller 290 is driving system bus 280. From the perspective of system controller 290, the completion of the transfer of the last data packet by processor 210 incurs two latent system clock cycles. A third latent clock cycle is needed to prevent system bus fights, i.e., attempts by multiple sub-systems to sim~ neously drive 10system bus 280. Thereafter, system controller 290 becomes the current bus master and is permitted to drive system bus 280. Note that pre-assigning system controller 290 with the highest priority relative to sub-systems 210, 220, 230, 240 is merely an implementational option. The arbitration system of the present invention is also applicable to other systems where system controller 290 has equal or lower priority relative to sub-systems 210, 220, 230, 240.
15As shown in Figure 9, system controller 290 surrenders ownership of system bus 280 in response to a bus request from an inactive sub-system which was the last port driver. When system controller 290 is the current bus master and detects a bus request from an inactive last port driver, e.g., processor 210, system controller 290 completes the transfer of the last data packet in two system clock cycles. A third latent system clock cycle is needed before the last port driver, e.g., 20processor 210 can begin to drive system bus 280 and become the current bus master.
Other modifications and additions are possible without departing from the spirit of the invention. For example, the total number of sub-systems can be smaller or larger. The address bus can be wider or narrower with respect to the system address space. In addition, the sub-systems can include video controllers, cache controllers and mathematical co-processors such as floating 25 point units. Hence, the scope of the invention should be determined by the following claims.
(3f30~5 ks)
Claims (25)
1. A method for arbitrating access to a system bus coupled to a plurality of sub-systems, said plurality of sub-systems including at least a first and second sub-system, each said subsystem including a bus arbiter, the method comprising the steps of:
determining that there is no bus request asserted by any of said plurality of sub-systems on said system bus which remain outstanding in a clock cycle preceding a first system clock cycle;
asserting a first bus request for said system bus with said first sub-system during said first system clock cycle, said first sub-system assigned as a last port driver before said first system clock cycle;
selecting said first sub-system to be a next bus master of said system bus during said first system clock cycle with said bus arbiters of said first and second sub-system, said selecting step independent of any bus request asserted by any of said sub-systems during said first system clock cycle; and driving said system bus with said first sub-system during a second system clock cycle.
determining that there is no bus request asserted by any of said plurality of sub-systems on said system bus which remain outstanding in a clock cycle preceding a first system clock cycle;
asserting a first bus request for said system bus with said first sub-system during said first system clock cycle, said first sub-system assigned as a last port driver before said first system clock cycle;
selecting said first sub-system to be a next bus master of said system bus during said first system clock cycle with said bus arbiters of said first and second sub-system, said selecting step independent of any bus request asserted by any of said sub-systems during said first system clock cycle; and driving said system bus with said first sub-system during a second system clock cycle.
2. A method for arbitrating access to a system bus coupled to a plurality of sub-systems, said plurality of sub-systems including at least a first and second sub-system, each said sub-system including a bus arbiter, the method comprising the steps of:
assigning said second sub-system to be a last port driver having a highest priority for driving said system bus with said bus arbiters of said first and second sub-systems, said first priority assigning step occurring before a first system clock cycle;
Page: 18 asserting a bus request with said first sub-system on said system bus which remains outstanding during said first system clock cycle;
assigning said first sub-system to be the last port driver having the highest priority for driving said system bus, said second priority assigning step occurring during said first clock system cycle;
selecting said first sub-system to be a next bus master of said system bus during a second system clock cycle with said bus arbiters of said first and second sub-systems, said next bus master selecting step independent of any bus request asserted by any of said sub-systems during said second system clock cycle; and driving said system bus with said first sub-system during a third system clock cycle.
assigning said second sub-system to be a last port driver having a highest priority for driving said system bus with said bus arbiters of said first and second sub-systems, said first priority assigning step occurring before a first system clock cycle;
Page: 18 asserting a bus request with said first sub-system on said system bus which remains outstanding during said first system clock cycle;
assigning said first sub-system to be the last port driver having the highest priority for driving said system bus, said second priority assigning step occurring during said first clock system cycle;
selecting said first sub-system to be a next bus master of said system bus during a second system clock cycle with said bus arbiters of said first and second sub-systems, said next bus master selecting step independent of any bus request asserted by any of said sub-systems during said second system clock cycle; and driving said system bus with said first sub-system during a third system clock cycle.
3. A method for arbitrating access to a system bus coupled to a plurality of sub-systems, said plurality of sub-systems including at least a first and second sub-system, each said sub-system including a bus arbiter, the method comprising the steps of:
detecting any bus request asserted by said plurality of sub-systems on said system bus which remains outstanding during a first system clock cycle; and selecting one of said plurality of sub-systems to be a next bus master of said system bus during a second system clock cycle with said bus arbiters of said first and second sub-systems, said next bus master selecting step based upon said detecting step and independent of any bus request asserted by any of said sub-systems during said second system clock cycle.
detecting any bus request asserted by said plurality of sub-systems on said system bus which remains outstanding during a first system clock cycle; and selecting one of said plurality of sub-systems to be a next bus master of said system bus during a second system clock cycle with said bus arbiters of said first and second sub-systems, said next bus master selecting step based upon said detecting step and independent of any bus request asserted by any of said sub-systems during said second system clock cycle.
4. The method of claim 3 wherein said first sub-system is assigned a last port driver with a highest priority for driving said system bus, and wherein said detecting step determines that there is no bus request asserted by any of said plurality of sub-systems on said system bus which remain outstanding in said first system clock cycle, and said selecting step selects said first sub-system to be a next bus master, the method further comprising the steps of:
Page: 19 asserting a first bus request for said system bus with said first sub-system during said second system clock cycle; and driving said system bus with said first sub-system during a third system clock cycle.
Page: 19 asserting a first bus request for said system bus with said first sub-system during said second system clock cycle; and driving said system bus with said first sub-system during a third system clock cycle.
5. The method of claim 3 wherein said second sub-system is assigned a last port driver with a highest priority for driving said system bus, and wherein said detecting step determines that there is a bus request asserted by said first sub-system on said system bus which remains oustanding in said first system clock cycle, and said selecting step selects said first sub-system to be a next bus master, the method further comprising the step of:
driving said system bus with said first sub-system during a third system clock cycle.
driving said system bus with said first sub-system during a third system clock cycle.
6. The method of claim 3 wherein said system bus is a synchronous bus.
7. The method of claim 3 wherein said assignment of said last port driver is based on a round robin arbitration protocol.
8. The method of claim 3 further comprising a step of pre-assigning said first sub-system to be said last port driver during a system reset.
9. The method of claim 3 wherein said plurality of subsystems includes only said first and second subsystem, said method further comprising the step of parking said first subsystem by maintaining said bus request of said first sub-system after completion of a data transfer.
10. The method of claim 3 wherein said sub-systems are processors.
Page: 20
Page: 20
11. The method of claim 1 further comprising the steps of:
assigning said first sub-system to be a current bus master of said system bus;
maintaining said first bus request for said system bus with said first subsystemduring said second system clock cycle and a third system clock cycle;
selecting said first subsystem to remain the next bus master with the bus arbiters of said first and second sub-systems during said second system clock cycle; and driving said system bus with said first sub-system during said third system clock cycle.
assigning said first sub-system to be a current bus master of said system bus;
maintaining said first bus request for said system bus with said first subsystemduring said second system clock cycle and a third system clock cycle;
selecting said first subsystem to remain the next bus master with the bus arbiters of said first and second sub-systems during said second system clock cycle; and driving said system bus with said first sub-system during said third system clock cycle.
12. A method for arbitrating a system bus coupling a plurality of sub-systems including at least a first and second sub-system, each said sub-system including a bus arbiter, the method comprising the steps of:
assigning said first sub-system to be a special port driver of said system bus;
assigning said second sub-system to be a last port driver of said system bus with the bus arbiters of said plurality of sub-systems;
asserting a first bus request for said system bus with said first sub-system during a first system clock cycle; and if said second sub-system has not asserted its bus request during a second system clock cycle, then driving said system bus with said first sub-system during a third system clock cycle.
Page: 21
assigning said first sub-system to be a special port driver of said system bus;
assigning said second sub-system to be a last port driver of said system bus with the bus arbiters of said plurality of sub-systems;
asserting a first bus request for said system bus with said first sub-system during a first system clock cycle; and if said second sub-system has not asserted its bus request during a second system clock cycle, then driving said system bus with said first sub-system during a third system clock cycle.
Page: 21
13. A computer system having a system bus coupled to a plurality of sub-systems in-cluding at least a first and second sub-system, said first sub-system assigned as a last port driver, said first sub-system comprising:
a bus arbiter for determining that there is no bus request asserted by any of said plurality of sub-systems on said system bus which remain outstanding in a clock cycle preceding a first clock cycle;
a bus requester for asserting a first bus request during said first system clock cycle, said first bus request causing said bus arbiter to select said first sub-system to be a next bus master of said system bus during said first system clock cycle, said selection of said next bus master independent of any bus request asserted by any of the other sub-systems during said first clock cycle; and a bus transceiver for driving said system bus during a second system clock cycle.
a bus arbiter for determining that there is no bus request asserted by any of said plurality of sub-systems on said system bus which remain outstanding in a clock cycle preceding a first clock cycle;
a bus requester for asserting a first bus request during said first system clock cycle, said first bus request causing said bus arbiter to select said first sub-system to be a next bus master of said system bus during said first system clock cycle, said selection of said next bus master independent of any bus request asserted by any of the other sub-systems during said first clock cycle; and a bus transceiver for driving said system bus during a second system clock cycle.
14. A computer system having a system bus coupled to a plurality of sub-systems in-cluding at least a first and second sub-system, said second sub-system assigned as a last port driver, said first sub-system comprising:
a bus requester for asserting a bus request for said system bus during a first clock cycle;
a bus arbiter for assigning said first sub-system to be the last port driver having the highest priority for driving said system bus, and for selecting said first sub-system to be a next bus master of said system bus during a second system clock cycle, said next bus master selection independent of any bus request asserted by any of said sub-systems during said second system clock cycle; and a bus transceiver for driving said system bus during a third system clock cycle.
Page: 22
a bus requester for asserting a bus request for said system bus during a first clock cycle;
a bus arbiter for assigning said first sub-system to be the last port driver having the highest priority for driving said system bus, and for selecting said first sub-system to be a next bus master of said system bus during a second system clock cycle, said next bus master selection independent of any bus request asserted by any of said sub-systems during said second system clock cycle; and a bus transceiver for driving said system bus during a third system clock cycle.
Page: 22
15. The computer system of claim 13 wherein said bus arbiter assigns said first sub-system to be a current bus master of said system bus, and said bus requester maintains said first bus request for said system bus during said second system clock cycle and causing said bus arbiter to select said first sub-system to remain the next bus master during said second system clock cycle, thereby permitting said bus transceiver to drive said system bus during said third system clock cycle.
16. An arbitration system useful in association with a system bus coupled to a plurality of sub-systems, including at least a first and second sub-system, said arbitration system comprising:
a bus arbiter for detecting any bus request asserted by said plurality of sub-systems on said system bus which remains outstanding during a first system clock cycle, and for selecting one of said plurality of sub-systems to be a next bus master of said system bus during a second system clock cycle, said next bus master selection based upon said any oustanding bus request detected during said first system clock cycle and independent of any bus request asserted by any of said sub-systems during said second system clock cycle.
a bus arbiter for detecting any bus request asserted by said plurality of sub-systems on said system bus which remains outstanding during a first system clock cycle, and for selecting one of said plurality of sub-systems to be a next bus master of said system bus during a second system clock cycle, said next bus master selection based upon said any oustanding bus request detected during said first system clock cycle and independent of any bus request asserted by any of said sub-systems during said second system clock cycle.
17. A computer system including the arbitration system of claim 16, wherein said first sub-system is assigned a last port driver with a highest priority for driving said system bus, and wherein said bus arbiter determines that there is no bus request asserted by any of said plurality of sub-systems on said system bus which remain oustanding in said first system clock cycle, said first sub-system further comprising:
a bus requester for asserting a first bus request during said second system clock cycle, said first bus request causing said bus arbiter to select said first sub-system to be a next bus master of said system bus during said second system clock cycle; and a bus transceiver for driving said system bus during a third system clock cycle.
Page: 23
a bus requester for asserting a first bus request during said second system clock cycle, said first bus request causing said bus arbiter to select said first sub-system to be a next bus master of said system bus during said second system clock cycle; and a bus transceiver for driving said system bus during a third system clock cycle.
Page: 23
18. A computer system including the arbitration system of claim 16, wherein said second sub-system is assigned a last port driver with a highest priority for driving said system bus, said first sub-system further comprising:
a bus requester for asserting a bus request for said system bus which remains out-standing during a first system clock cycle, said bus request detected by said bus arbiter during said first system clock cycle, thereby causing said bus arbiter to select said first sub-system to be a next bus master of said system bus during a second system clock cycle, said next bus master selection independent of any bus request asserted by any of said sub-systems during said second system clock cycle; and bus transceiver for driving said system bus during a third system clock cycle.
a bus requester for asserting a bus request for said system bus which remains out-standing during a first system clock cycle, said bus request detected by said bus arbiter during said first system clock cycle, thereby causing said bus arbiter to select said first sub-system to be a next bus master of said system bus during a second system clock cycle, said next bus master selection independent of any bus request asserted by any of said sub-systems during said second system clock cycle; and bus transceiver for driving said system bus during a third system clock cycle.
19. The arbitration system of claim 16 wherein said system bus is a synchronous bus.
20. The arbitration system of claim 16 wherein said assignment of said last port driver is based on a round robin arbitration protocol.
21. The arbitration system of claim 16 wherein said first subsystem is pre-assigned to be said last port driver during a system reset.
22. The arbitration system of claim 16 wherein said plurality of sub-systems includes only said first and second subsystem, and said first sub-system parks on said system bus by main-taining a bus request after completion of a data transfer.
23. The arbitration system of claim 16 wherein said sub-systems are processors.
Page: 24
Page: 24
24. A computer system having a system bus coupled to a plurality of sub-systems in-cluding at least a first and second sub-system, said first sub-system comprising:
a bus arbiter for assigning said first sub-system to be a special port driver of said system bus and for assigning said second sub-system to be a last port driver of said system bus;
a bus requester for asserting a first bus request for said system bus during a first system clock cycle; and if said second sub-system has not asserted its bus request during a second system clock cycle, then a bus transceiver for driving said system bus during a third system clock cycle.
a bus arbiter for assigning said first sub-system to be a special port driver of said system bus and for assigning said second sub-system to be a last port driver of said system bus;
a bus requester for asserting a first bus request for said system bus during a first system clock cycle; and if said second sub-system has not asserted its bus request during a second system clock cycle, then a bus transceiver for driving said system bus during a third system clock cycle.
25. A method of resetting a computer system having a plurality of sub-systems, each said subsystem including an arbiter, the method comprising the steps of:
sending a first reset signal to a first said sub-system, thereby resetting all the states of said first sub-system; and sending an arbitration reset signal to a second said sub-system, thereby selectively resetting the arbitration states of the arbiter of second sub-system.
sending a first reset signal to a first said sub-system, thereby resetting all the states of said first sub-system; and sending an arbitration reset signal to a second said sub-system, thereby selectively resetting the arbitration states of the arbiter of second sub-system.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/414,559 US5710891A (en) | 1995-03-31 | 1995-03-31 | Pipelined distributed bus arbitration system |
| US08/414,559 | 1995-03-31 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2171170A1 true CA2171170A1 (en) | 1996-10-01 |
Family
ID=23641973
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002171170A Abandoned CA2171170A1 (en) | 1995-03-31 | 1996-03-06 | Pipelined distributed bus arbitration system |
Country Status (5)
| Country | Link |
|---|---|
| US (2) | US5710891A (en) |
| EP (1) | EP0737925B1 (en) |
| JP (1) | JP3899142B2 (en) |
| CA (1) | CA2171170A1 (en) |
| DE (1) | DE69628609T2 (en) |
Families Citing this family (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5845107A (en) * | 1996-07-03 | 1998-12-01 | Intel Corporation | Signaling protocol conversion between a processor and a high-performance system bus |
| US5815674A (en) * | 1996-07-15 | 1998-09-29 | Micron Electronics, Inc. | Method and system for interfacing a plurality of bus requesters with a computer bus |
| US5925118A (en) * | 1996-10-11 | 1999-07-20 | International Business Machines Corporation | Methods and architectures for overlapped read and write operations |
| US5894562A (en) * | 1996-10-28 | 1999-04-13 | Motorola, Inc. | Method and apparatus for controlling bus arbitration in a data processing system |
| US5909558A (en) * | 1997-07-31 | 1999-06-01 | Linzmeier; Daniel | Low power serial arbitration system |
| US6467009B1 (en) * | 1998-10-14 | 2002-10-15 | Triscend Corporation | Configurable processor system unit |
| US6389497B1 (en) | 1999-01-22 | 2002-05-14 | Analog Devices, Inc. | DRAM refresh monitoring and cycle accurate distributed bus arbitration in a multi-processing environment |
| US6654833B1 (en) * | 1999-07-29 | 2003-11-25 | Micron Technology, Inc. | Bus arbitration |
| US6851047B1 (en) | 1999-10-15 | 2005-02-01 | Xilinx, Inc. | Configuration in a configurable system on a chip |
| US6578098B1 (en) * | 1999-11-04 | 2003-06-10 | Koninklijke Philips Electronics N.V. | Predictive mechanism for ASB slave responses |
| US6732210B1 (en) * | 2000-01-03 | 2004-05-04 | Genesis Microchip Inc | Communication bus for a multi-processor system |
| US20020016882A1 (en) * | 2000-04-24 | 2002-02-07 | Hiroshi Matsuuchi | Digital device, data input-output control method, and data input-output control system |
| US6731303B1 (en) * | 2000-06-15 | 2004-05-04 | International Business Machines Corporation | Hardware perspective correction of pixel coordinates and texture coordinates |
| US6721840B1 (en) | 2000-08-18 | 2004-04-13 | Triscend Corporation | Method and system for interfacing an integrated circuit to synchronous dynamic memory and static memory |
| US6518787B1 (en) | 2000-09-21 | 2003-02-11 | Triscend Corporation | Input/output architecture for efficient configuration of programmable input/output cells |
| US6633938B1 (en) * | 2000-10-06 | 2003-10-14 | Broadcom Corporation | Independent reset of arbiters and agents to allow for delayed agent reset |
| US7076586B1 (en) | 2000-10-06 | 2006-07-11 | Broadcom Corporation | Default bus grant to a bus agent |
| US6957290B1 (en) | 2000-10-06 | 2005-10-18 | Broadcom Corporation | Fast arbitration scheme for a bus |
| US6985980B1 (en) | 2000-11-03 | 2006-01-10 | Xilinx, Inc. | Diagnostic scheme for programmable logic in a system on a chip |
| DE10064593A1 (en) * | 2000-12-22 | 2002-08-29 | Siemens Ag | Method and arrangement for data exchange |
| US6877053B2 (en) * | 2001-01-03 | 2005-04-05 | Nec Corporation | High performance communication architecture for circuit designs using probabilistic allocation of resources |
| US6725364B1 (en) | 2001-03-08 | 2004-04-20 | Xilinx, Inc. | Configurable processor system |
| US20030004698A1 (en) * | 2001-06-29 | 2003-01-02 | Osborn Daniel D. | Agent state drive simulation and method for detecting simulated drive fights |
| US7107374B1 (en) | 2001-09-05 | 2006-09-12 | Xilinx, Inc. | Method for bus mastering for devices resident in configurable system logic |
| JP4260720B2 (en) * | 2004-10-27 | 2009-04-30 | 日本テキサス・インスツルメンツ株式会社 | Bus control device |
| JP4455540B2 (en) * | 2006-06-15 | 2010-04-21 | キヤノン株式会社 | Bus system and arbitration method |
| US7809874B2 (en) * | 2006-06-21 | 2010-10-05 | International Business Machines Corporation | Method for resource sharing in a multiple pipeline environment |
| FI122301B (en) * | 2006-08-25 | 2011-11-30 | Atomia Oy | Circuit, procedure and arrangement for realizing simple and reliable decentralized bus arbitration |
| GB2447690B (en) * | 2007-03-22 | 2011-06-08 | Advanced Risc Mach Ltd | A Data processing apparatus and method for performing multi-cycle arbitration |
| TWI355822B (en) * | 2007-12-20 | 2012-01-01 | Realtek Semiconductor Corp | Circuit and method for setting data and their appl |
| US7779189B2 (en) * | 2008-02-21 | 2010-08-17 | International Business Machines Corporation | Method, system, and computer program product for pipeline arbitration |
| US20160127061A1 (en) * | 2014-11-05 | 2016-05-05 | Qualcomm Incorporated | Broadcast interface |
| US10289786B1 (en) * | 2017-06-27 | 2019-05-14 | Xilinx, Inc. | Circuit design transformation for automatic latency reduction |
| CN111478840A (en) * | 2020-04-15 | 2020-07-31 | 联合华芯电子有限公司 | Double-rate arbitration relay device for bus system |
Family Cites Families (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4228503A (en) * | 1978-10-02 | 1980-10-14 | Sperry Corporation | Multiplexed directory for dedicated cache memory system |
| US5111424A (en) * | 1987-05-01 | 1992-05-05 | Digital Equipment Corporation | Lookahead bus arbitration system with override of conditional access grants by bus cycle extensions for multicycle data transfer |
| JPH065524B2 (en) * | 1987-11-18 | 1994-01-19 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Storage device management method |
| US4979099A (en) * | 1988-10-25 | 1990-12-18 | Apollo Computer Inc. | Quasi-fair arbitration scheme with default owner speedup |
| EP0380842A3 (en) * | 1989-02-03 | 1991-06-12 | Digital Equipment Corporation | Method and apparatus for interfacing a system control unit for a multiprocessor system with the central processing units |
| US5168568A (en) * | 1989-02-06 | 1992-12-01 | Compaq Computer Corporation | Delaying arbitration of bus access in digital computers |
| US5036459A (en) * | 1989-03-09 | 1991-07-30 | U.S. Philips Corporation | Multi-processor computer system with distributed memory and an interprocessor communication mechanism, and method for operating such mechanism |
| US5148545A (en) * | 1989-07-21 | 1992-09-15 | Clearpoint Research Corporation | Bus device which performs protocol confidential transactions |
| EP0468831B1 (en) * | 1990-06-29 | 1997-10-15 | Digital Equipment Corporation | Bus protocol for write-back cache processor |
| US5119448A (en) * | 1990-09-21 | 1992-06-02 | Tacan Corporation | Modular micro-optical systems and method of making such systems |
| JPH04318654A (en) * | 1991-02-13 | 1992-11-10 | Hewlett Packard Co <Hp> | Redirection system for interruption to microprocessor |
| JP2703417B2 (en) * | 1991-04-05 | 1998-01-26 | 富士通株式会社 | Receive buffer |
| US5369748A (en) * | 1991-08-23 | 1994-11-29 | Nexgen Microsystems | Bus arbitration in a dual-bus architecture where one bus has relatively high latency |
| DE69230428T2 (en) * | 1991-09-27 | 2000-08-03 | Sun Microsystems Inc | Bus arbitration architecture containing deadlock detection and masking |
| US5430848A (en) * | 1992-08-14 | 1995-07-04 | Loral Fairchild Corporation | Distributed arbitration with programmable priorities |
| US5319753A (en) * | 1992-09-29 | 1994-06-07 | Zilog, Inc. | Queued interrupt mechanism with supplementary command/status/message information |
| US5434993A (en) * | 1992-11-09 | 1995-07-18 | Sun Microsystems, Inc. | Methods and apparatus for creating a pending write-back controller for a cache controller on a packet switched memory bus employing dual directories |
| US5299196A (en) * | 1992-11-12 | 1994-03-29 | International Business Machines Corporation | Distributed address decoding for bus structures |
| CA2116826C (en) * | 1993-03-11 | 1998-11-24 | Timothy J. Sullivan | Data processing system using a non-multiplexed, asynchronous address/data bus system |
| JPH07105031A (en) * | 1993-09-20 | 1995-04-21 | Internatl Business Mach Corp <Ibm> | Method and apparatus for transfer of interrupt information at inside of multiprocessor computer system |
-
1995
- 1995-03-31 US US08/414,559 patent/US5710891A/en not_active Expired - Lifetime
-
1996
- 1996-03-06 CA CA002171170A patent/CA2171170A1/en not_active Abandoned
- 1996-03-15 DE DE69628609T patent/DE69628609T2/en not_active Expired - Lifetime
- 1996-03-15 EP EP96301773A patent/EP0737925B1/en not_active Expired - Lifetime
- 1996-04-01 JP JP10607996A patent/JP3899142B2/en not_active Expired - Lifetime
-
1997
- 1997-06-04 US US08/870,438 patent/US5862356A/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP3899142B2 (en) | 2007-03-28 |
| DE69628609T2 (en) | 2004-05-13 |
| US5710891A (en) | 1998-01-20 |
| US5862356A (en) | 1999-01-19 |
| EP0737925B1 (en) | 2003-06-11 |
| EP0737925A1 (en) | 1996-10-16 |
| JPH0926933A (en) | 1997-01-28 |
| DE69628609D1 (en) | 2003-07-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0737925B1 (en) | Pipelined distributed bus arbitration system | |
| US6393506B1 (en) | Virtual channel bus and system architecture | |
| US4602327A (en) | Bus master capable of relinquishing bus on request and retrying bus cycle | |
| US5168568A (en) | Delaying arbitration of bus access in digital computers | |
| US5621897A (en) | Method and apparatus for arbitrating for a bus to enable split transaction bus protocols | |
| US5619661A (en) | Dynamic arbitration system and method | |
| US6986005B2 (en) | Low latency lock for multiprocessor computer system | |
| US7174403B2 (en) | Plural bus arbitrations per cycle via higher-frequency arbiter | |
| US5901295A (en) | Address and data bus arbiter for pipelined transactions on a split bus | |
| US5313591A (en) | Computer bus arbitration for N processors requiring only N unidirectional signal leads | |
| JP2003281082A (en) | Retry scheme for controlling transaction between two buses | |
| US5649209A (en) | Bus coupling information processing system for multiple access to system bus | |
| EP1187029B1 (en) | Peripheral component interconnect arbiter implementation with dynamic priority scheme | |
| US5931931A (en) | Method for bus arbitration in a multiprocessor system | |
| EP1096387B1 (en) | An arbitration unit for a bus | |
| US5708783A (en) | Data bus arbiter for pipelined transactions on a split bus | |
| JPH0581178A (en) | Pipeline bus | |
| JPH04134551A (en) | Method of informing second agent of necessity of service from first agent in bus for transferring data between a lurality of data processing agents | |
| JPH1125036A (en) | Arbitration system and method for arbitorating access | |
| US5815676A (en) | Address bus arbiter for pipelined transactions on a split bus | |
| KR100243868B1 (en) | Arbiter logic in main computer system | |
| JP4190629B2 (en) | Multiprocessor system | |
| EP0537898B1 (en) | Computer system including video subsystem | |
| JP2002175270A (en) | Exclusive control system of bus | |
| JPH0895905A (en) | Bus interface circuit |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |