Attached to each SPD bus are at least two IOBUs. Both the main processor and the device controllers operate as IOBUs. This explains why an SPD bus never has only one IOBU; the main processor is an IOBU, as is each device controller. A maximum of 32 IOBUs can be attached to a single SPD bus. With multiple IOBUs attached to the bus, arbitration is needed if more than one unit wants to use the bus at the same time. A priority arbitration mechanism is used. Each IOBU is assigned a priority, and this priority is used to decide which IOBU can use the bus when two or more are contending for its use.

Before we leave this topic to continue with our I/O discussion, we should note that an IOP can be used for functions other than just device control. It should be obvious that an IOP is a full processor with its own operating system and application programs. It also has direct access to the main memory and, through the I/O bus, to the disk system of the AS/400. An IOP can, therefore, be used to run user applications. In the following chapter, we look at how IOPs are being used as application processors. This capability to run other operating systems and applications on an IOP is being heavily exploited in the AS/400.

SPD I/O Bus Operations

Each SPD I/O card provides a BCU for one SPD bus. The BCU provides the master control over the bus operations. Normally, the BCU handles error recovery and retry. It also handles the arbitration when more than one IOBU tries to use the bus at the same time. Additionally, the BCU initializes the bus at IPL time.

At IPL time, the BCU assigns the logical addresses to the attached IOBUs. Note that this is done at every IPL. This means a new IOBU, possibly with a new device attached, can be plugged into an AS/400; when the system is IPLed, the new IOBU is automatically configured into the AS/400. No user intervention is required. This is analogous to plug-and-play I/O in the PC world.

In addition to assigning logical addresses to the attached IOBUs at IPL time, the BCU assigns bus priority to each unit. It checks out each IOBU’s ability to communicate over the bus and downloads the operational code to the memory of each IOP.

All communications during normal operations are between IOBUs. As stated earlier, the system processors function as IOBUs, as do all the IOPs on the SPD I/O adapter cards. Information is always exchanged between the IOBU that originates the bus operation (called the master) and the IOBU selected by the originator (called the slave). All bus operations are between master and slave.

Information is transferred between IOBUs in the form of fixed-length messages or variable-length direct memory access (DMA) operations. DMA is hardware that is added to many computer systems to allow block transfers of a number of words to or from the main memory without intervention by the processor. With DMA, an IOBU can directly access the main memory without going through the system processor.

We can define a bus operation as a momentary connection between two IOBUs. Each bus operation has two parts:

•  The first part of the bus operation has a master select a slave. The master also determines the type and direction for the data transfer.

•  The second part of the bus operation consists of from 1 to 16 data cycles, during which time the data is transferred. Note that 32 data bits are transferred per cycle on the SPD bus.

Two types of bus operations are supported for the SPD bus: unit operations and storage operations. For a unit operation, a message is transferred from the master to the slave. The message is architected to always be 12 bytes in length. We look at the format of these messages in a later section.

The storage operation enables DMA movement between an IOP memory on an adapter card and the system main memory. The movement is controlled by the master who establishes the connection and the direction of the transfer. The maximum number of bytes transferred during a single storage operation is 64 (16 data cycles, 4 bytes per cycle).

Both the system processor and the IOPs can perform either a master or a slave unit operation. The system processor can perform either a master or a slave storage operation. An IOP can perform only a master storage operation. Because no IOP can perform a slave storage operation, data never can be transferred from one IOP memory to another IOP memory. This means there is no SPD bus peer-to-peer I/O in an AS/400. For example, data cannot be transferred directly from a disk IOP to a tape-drive IOP without going through the system’s main memory, which results in a less flexible total system structure.

The preceding discussion dealt only with the operations across the SPD bus. The PCI IOPs also provide control functions for the PCI adapter cards attached to the PCI bus. However, because the PCI bus is synchronous and the individual PCI adapters do not require their own separate processors, the control and handshaking is much simpler.

I/O Operations on the AS/400

Having examined the hardware I/O structure of the AS/400, we are ready to see how OS/400, SLIC, and the hardware all work together to perform an I/O operation for an application program. We start by looking at the objects that are used to support I/O in the AS/400. Then we look at the layered structure between OS/400, SLIC, and the hardware. Finally, we put it all together by following an I/O operation from OS/400 all the way out to the device and back.

Objects to Support I/O

Separate objects exist in OS/400 and at the MI for I/O, but they are closely related. Three system objects exist at the MI to support I/O; four similar objects exist in OS/400. The easiest way to think about these objects is to picture how a device can be attached to an AS/400.

A device can be attached directly to an I/O adapter card. We need to describe the characteristics of this device to the system, and we would use a system object to accomplish this. Remember that the MI is independent of the underlying hardware, including I/O device hardware; so we would want a logical description of the device rather than a physical description. In other words, we want to know that the particular unit is a printer, but we don’t need to know what the printer datastream looks like for this device. We need to know this information down in the machine, but not at the MI. The system object used to describe a device at the MI is appropriately called a logical unit description (LUD). The equivalent OS/400 object is called a device description (DEVD).