Browse Prior Art Database

Universal Bus Controls

IP.com Disclosure Number: IPCOM000051562D
Original Publication Date: 1981-Feb-01
Included in the Prior Art Database: 2005-Feb-10
Document File: 3 page(s) / 15K

Publishing Venue

IBM

Related People

Krager, KI: AUTHOR

Abstract

Described herein is an arrangement for providing a hardware/software interface between a processor having a new type architecture and I/O controller chips. It will allow a large amount of flexibility and expansion capability. This interface will allow up to 255 unit addresses per control block, permit the I/O controller to be very smart or simple depending on the performance desired, use a minimum of hardware and software on the processor side of the interface, and once implemented would affect only the controller side on any expansion.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 56% of the total text.

Page 1 of 3

Universal Bus Controls

Described herein is an arrangement for providing a hardware/software interface between a processor having a new type architecture and I/O controller chips. It will allow a large amount of flexibility and expansion capability. This interface will allow up to 255 unit addresses per control block, permit the I/O controller to be very smart or simple depending on the performance desired, use a minimum of hardware and software on the processor side of the interface, and once implemented would affect only the controller side on any expansion.

A Summary of the Reguirements for Implementation: On the Processor Side:
1. Requires that the processor assign as permanent storage addresses a block of storage (real) which we will call the I/O control block. 2. Requires a hardware cycle steal mechanism on the processor to allow any of the I/O controllers to directly access data memory. 3. Requires a hardware timer in the processor that can update a count in these I/O control block words. 4. Requires some processor programming to control and test the various flags, and control data of these words. 5. Will require that the processor bus have enough drive to support the maximum number of controllers. On the Controller Side: 1. The controllers must be capable of decoding their address from data on the bus, cycle stealing data to/from the data bus, and forcing interrupt requests.

I/O Control Block Format: This control block must be in real storage starting on a double-word boundary and consist of one 16-byte entry for each desired controller.

Entries would look like - (16 bytes long)

(controllers will fetch this data via

cycle steal)

See Original.

Unit address = 1 byte containing the end I/O unit address. Unit status = 1 byte of interlock and status data as follows: Bit 0 = This block currently in use. If busy, set by the I/O controller.

Bit 1 = I/O error occurred during operation. Sense data stored.

Bit 2 = Normal completion of operation.

Bit 3 = Processor Interlock bit. Set by the processor, and makes the control word busy from the processor side.

Bit 4 = I/O controller available. Set by the controller, and accompanied by an interrupt request to alert the

processor that the controller can accept another

command. (This may not happen if the controller is

a simple one.)

Bit 5 = Timer is active and if count decrements to zero an error should be indicated.

Sense data = 1 byte of sense data from the I/O unit if an error was detected during the operation.

Command = 1 byte allowing 255 commands to the I/O controller. Data Address = 4 bytes allowing maximum real address range if desired.

1

Page 2 of 3

Data Length = 4 bytes allowing maximum real size, if desired. Timer = 2 bytes. A count value set to be used as a timeout, if no device answers within a specified time.

This method of control is similar to the IBM/System 360 selector channel TIO, SIO instructions. No chained commands would be allowed. Each controller could addres...