Browse Prior Art Database

Shared Master/Slave Device

IP.com Disclosure Number: IPCOM000040755D
Original Publication Date: 1987-Dec-01
Included in the Prior Art Database: 2005-Feb-02
Document File: 3 page(s) / 45K

Publishing Venue

IBM

Related People

Duffield, NJ: AUTHOR [+3]

Abstract

The device includes data flow controller 10 having shared data registers 12, flag 14 and control registers 16 and connected between CPU bus interface 18 and I/O bus interface 20. Bus 18 is connected to CPU 22, and I/O bus 20 is connected to various devices, such as arbitration unit 24, service processor 26 and I/O controllers 28. Arbitration unit 24 may control which device is on bus 20; service processor 26 may debug hardware; and I/O controllers 28 may control a connected disk drive, all of these being for example. When designing a master/slave device (a device which both issues and services requests) to interface to an I/O bus, the master and slave operations must be controlled so that they do not interfere with each other. The simplest way to do this is to provide separate Master and Slave facilities.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

Shared Master/Slave Device

The device includes data flow controller 10 having shared data registers 12, flag 14 and control registers 16 and connected between CPU bus interface 18 and I/O bus interface 20. Bus 18 is connected to CPU 22, and I/O bus 20 is connected to various devices, such as arbitration unit 24, service processor 26 and I/O controllers 28. Arbitration unit 24 may control which device is on bus 20; service processor 26 may debug hardware; and I/O controllers 28 may control a connected disk drive, all of these being for example. When designing a master/slave device (a device which both issues and services requests) to interface to an I/O bus, the master and slave operations must be controlled so that they do not interfere with each other.

The simplest way to do this is to provide separate Master and Slave facilities. However, design is often limited by size, causing this to be an unviable option. This shared device outlines rules developed to allow Master and Slave operations to share the same facilities. Management of the data takes place between two interfaces: the I/O bus interface 20 and the CPU bus interface 18.

The I/O bus interface 20 will be used by devices 28, etc. to send data to, or request data from, other bus devices. A device must be prepared to accept slave operations from this bus at any time. The CPU bus 18 is used to read data from, or write data to, the CPU's memory. Flag 14 is used to indicate that shared data registers 12 are empty and waiting for another access, for example. Control registers 16 are used to indicate the type and direction of the operation acting on data registers 12 (i.e., read from CPU 22...). Data flow controller 10 is used in conjunction with the CPU 22 as another device on the I/O bus 20. The controller 10 can act as a master on the I/O bus 20 (a unit initiating an access) or as a slave on the I/O bus 20 (a unit accepting an access). When a device 28, etc., wants to initiate an access on the I/O bus 20, a request is issued.

The arbitration unit 24 on bus 20 will grant the bus 20 to one of the requesting units, and after gaining control of the I/O bus 20, the control, address and data cycles shown in Fig. 2 will take place across the bus 20. To allow for the sharing of various facilities in the controller 10, the following rules were devised to govern the data flow: - If a device (such as controller 28) using the shared bus facilities wants to be master (the control) of the

I/O bus 20, it must request and be granted the bus 20

before loading any shared facility with data for a

ma...