Browse Prior Art Database

Movable Bus Arbiter And Shared Bus Address

IP.com Disclosure Number: IPCOM000099400D
Original Publication Date: 1990-Jan-01
Included in the Prior Art Database: 2005-Mar-14
Document File: 3 page(s) / 105K

Publishing Venue

IBM

Related People

Johnson, KD: AUTHOR [+3]

Abstract

Described is a method which allows sharing of bus arbitration between two bus devices. This method allows two processors to share the same bus address and arbitration function so the existence of multiple processors is transparent to other I/O devices on the bus. The main concept is to make the system and service processor appear to I/O processors as one processor.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Movable Bus Arbiter And Shared Bus Address

       Described is a method which allows sharing of bus
arbitration between two bus devices.  This method allows two
processors to share the same bus address and arbitration function so
the existence of multiple processors is transparent to other I/O
devices on the bus.  The main concept is to make the system and
service processor appear to I/O processors as one processor.  This
method provides the following features:  1) bus arbitration function
can be moved between two or more processors (address 0 is reserved
for the arbiter), 2) the same bus address can be shared between two
or more processors -- data routing can be controlled by the sharing
processors and switched depending on the needs of the system, and 3)
multiple addresses and/or arbitration function can be used to switch
between redundant processors in a fault tolerant system.

      Fig. 1 shows the AS/400* implementation of this feature.  To
achieve the shared arbitration and bus addresses, some special I/Os
were defined to allow the control of arbitration to be passed.

      However, both processors cannot use the arbitration functions
at the same time.  This will result in both sets of arbitration line
drivers being in contention on the arbitration lines and in too many
I/O processors being granted the bus at the same time.  To control
this, the service processor powers up as the bus arbiter and the
system processor powers up as a non-arbiter.  This allows the service
processor (which has software in ROS) to IPL certain processors on
the bus and search out additional code loads from those processors.
The service processor first finds more code for itself, and then
finds a microcode load for the system processor.

      Both service and system processors logically sharing the same
location means that they have the same logical address on the I/O
bus.  Yet for I/O transfers originating from the other I/O
processors, only one of the two processors may respond.  To handle
this, only the processor with an active arbitration function may
receive these transfers.  Hence, while service processor is seeking
out software loads, I/O transfers flow between...