The system in Fig. 16.4.1 is quite misleading. For one thing, it has no input/output devices, without which no computer can do anything useful. Fig. 16.1.1 at the beginning of the chapter shows several I/O controllers plugged into the system bus. These boards are really small special-purpose computers which communicate with the memory and the main CPU through the system bus. In fact, the standard way for many systems is to communicate solely through the main memory.
I/O controllers often act as bus initiators because they need to initiate transfers of data from their attached devices (mice, disk drives, keyboards, tape drives, light pens) to memory, or from memory to various output devices (monitors, printers, motors.)
As soon as there are two bus initiators there are problems, for what happens when both initiators attempt to assert control signals? In order to avoid chaos, only one bus initiator should have control of the bus at any time. One scheme is for there to be a bus busy wire. Any device that acts as a bus initiator sets this wire to 1 as a flag for all other potential bus initiators to see. If any would-be initiator sees that the bus is busy, it defers action until the wire changes to 0.
There are problems with this scheme. One is that it is possible for two bus initiators to assert the busy wire (set it to 1) at the exact same moment, or so close to the same time that it is simultaneous for all purposes. The two bus initiators need to be able to figure out that something strange has happened and arrange to stop and retry again later.
This brings up the fact that there must be rules of behavior in order for all the bus devices to get along without clobbering each other's data. These rules are called a bus protocol. Every bus architecture has a published protocol attendant to it and any device manufacturer must conform to the protocol or else the device cannot be attached to the bus without problems.
An analogy to protocols in buses is standards in electrical wiring and telephone circuitry. There are rules about what kind of wire to use, what shape to make the receptacles, how much current and how high a voltage is used, and so forth. In addition to these static or factual rules, there are dynamic rules which govern sequences of actions. In the world of telephones, the completion of a number dialing results in a signal that causes the other party's phone to ring. If they do not answer within a certain time period, the telephone circuitry may cut it off. Also, if the phone is taken off the hook but no number is dialed within a certain amount of time, the telephone company causes a loud buzz or beep to be heard or plays a message about putting the receiver back on the hook.
The bus contention method presented above is a decentralized control protocol. When multiple would-be bus initiators attempt to gain control, they discover that someone else has interfered and then they back off for a while. It is decentralized because no one circuit is given ultimate decision power -- they all share the power in a polite manner. Such decentralized protocols are often used on local area networks, such as Ethernet.
However, most buses use a centralized control protocol because it is faster and does not deteriorate under heavy use. In one widely used scheme, would-be bus initiators have to request and get permission to use the bus. Each bus initiator has two wires between it and a special circuit called the arbiter. One wire is called bus request and the other bus grant. When a device wants to use the bus, it asserts bus request. If the bus is free and no one else also has their bus request wire asserted, the arbiter automatically grants control to the requester by asserting bus grant to that device. Fig. 16.5.1 shows this process.
Fig. 16.5.2 shows several devices asserting their bus request lines, but only one is given control of the bus.
The devices that attach to the bus and to the arbiter obey the protocol that they do not assert any control signals on the bus until their own bus grant line goes high. If they were to "cheat," the signals on the bus would be hopelessly confused and things would go haywire.
When a would-be bus initiator is denied use of the bus, it must wait until the current bus initiator is finished with its bus transaction, which might consist of several steps, as we saw above in the memory read scenario. The slighted initiator is usually in an electronic state where nothing can happen until the bus grant wire goes high, so it automatically waits (and waits "patiently", if anthropomorphic emotions can be attributed to wires and gates!) until the arbiter gives it control.
It is important to realize that a device may be a bus initiator some of the time and a bus responder at other times. For example, an I/O device may be a responder while the CPU is the initiator in one bus transaction. Later that same I/O device may become the initiator while the memory is a responder. To do input, the CPU transmits a command to the I/O controller, such as "read the next 100 bytes from your tape drive and put it into memory at location XYZ." The I/O controller, after getting the command from the CPU, carries it out by becoming bus initiator and copying the data into main memory.
As an endnote, we might wonder how we could possibly build a "fair circuit," that is, a device which would truly randomly choose between one bus initiator and another. The SR latch discussed in an earlier chapter is one way of doing this. By setting both S and R inputs to 1, something not normally done, the circuit oscillates until both inputs go off, and then it jumps to one of its two stable states, in effect randomly choosing Q or Q' to be 1.
