Hardware Reference
In-Depth Information
The advantage of an asynchronous bus should now be clear, but the fact is that
most buses are synchronous. The reason is that it is easier to build a synchronous
system. The CPU just asserts its signals, and the memory just reacts. There is no
feedback (cause and effect), but if the components have been chosen properly,
everything will work without handshaking. Also, there is a lot of investment in
synchronous bus technology.
Up until now, we have tacitly assumed that there is only one bus master, the
CPU. In reality, I/O chips have to become bus master to read and write memory,
and also to cause interrupts. Coprocessors may also need to become bus master.
The question then arises: ''What happens if two or more devices all want to be-
come bus master at the same time?'' The answer is that some
bus arbitration
mechanism is needed to prevent chaos.
Arbitration mechanisms can be centralized or decentralized. Let us first con-
sider centralized arbitration. One particularly simple form of this is shown in
Fig. 3-40(a). In this scheme, a single bus arbiter determines who goes next. Many
CPUs have the arbiter built into the CPU chip, but sometimes a separate chip is
needed. The bus contains a single wired-OR request line that can be asserted by
one or more devices at any time. There is no way for the arbiter to tell how many
devices have requested the bus. The only categories it can distinguish are some re-
quests and no requests.
When the arbiter sees a bus request, it issues a grant by asserting the bus grant
line. This line is wired through all the I/O devices in series, like a cheap string of
Christmas tree lamps. When the device physically closest to the arbiter sees the
grant, it checks to see if it has made a request. If so, it takes over the bus but does
not propagate the grant further down the line. If it has not made a request, it propa-
gates the grant to the next device in line, which behaves the same way, and so on
until some device accepts the grant and takes the bus. This scheme is called
daisy
chaining
. It has the property that devices are effectively assigned priorities de-
pending on how close to the arbiter they are. The closest device wins.
To get around the implicit priorities based on distance from the arbiter, many
buses have multiple priority levels. For each priority level there is a bus request
line and a bus grant line. The one of Fig. 3-40(b) has two levels, 1 and 2 (real
buses often have 4, 8, or 16 levels). Each device attaches to one of the bus request
levels, with more time-critical devices attaching to the higher-priority ones. In
Fig. 3-40(b) devices, 1, 2, and 4 use priority 1 while devices 3 and 5 use priority 2.
If multiple priority levels are requested at the same time, the arbiter issues a
grant only on the highest-priority one. Among devices of the same priority, daisy
chaining is used. In Fig. 3-40(b), in the event of conflicts, device 2 beats device 4,
which beats 3. Device 5 has the lowest-priority because it is at the end of the low-
est priority daisy chain.
