Some buses are not tied to a clock but rather use a cause and effect basis to decide which signal gets changed next. These are called asynchronous buses because they have no clock and no fixed time cycles. Protocols need to be followed in order to ensure that data gets transferred correctly.
Fig. 16.7.1 shows an asynchronous bus used to read. There are no fixed time periods, although some events have to happen before others. For purposes of discussion, four times, t1, t2, t3 and t4 have been identified below.
The way this asynchronous read operation works is that the CPU becomes the bus initiator after the arbiter has granted permission to do so. It puts the address on the address wires and sets RD to 1 to request a read. Then it asserts MSYN, which stands for "Master Synchronization," at time t1. This is the electronic form of a phone ringing, waking all the responders up and telling them that there's work to be done. (Note the lamentable use of old terminology, but the acronym is explained to demystify it.)
Exactly which responder does the work is indicated by the address wires. When the right responder (in this case main memory) figures out what to do, it starts to do it, and to finish the job as soon as possible.
When it is done, at the earliest possible moment, t2 in the above diagram, it signals the initiator by setting SSYN (slave synchronization) high. The initiator sees this is high and then latches the data wires into its registers. At t3, the initiator turns off MSYN which is a signal to the responder that the initiator received the value and the responder can (temporarily) go back to an idle state. At t4 all other lines of the bus are cleared in preparation for the next bus transaction, which cannot start until both MSYN and SSYN are both 0 again. This is the signal to the next bus initiator that the bus is now free and ready to use.
In Fig. 16.7.2 we see the same timing diagram for an asynchronous read, except that the causal relationships between the turning off and on of the signals are shown.
Fig. 16.7.2: Time dependencies of events in an asynchronous bus
Each of these events is numbered. e1 is when the initiator turns on MSYN, declaring that all the data and address wires are ready to go and that the main memory should begin its work immediately. e2 is when the memory puts a valid data item on the bus, which is of course caused by the initiator's request. This event, e2, in turn causes SSYN to go to 1, which is used as a signal to say that the data is ready to be read off the data wires. Eventually, the initiator latches the data value and drops MSYN as a signal that it has got it. This is event e4, which causes the responder to know that its work is done, so it drops SSYN, event e5. As long as all the causal relationships are preserved, it doesn't matter how short or how long the stretch of time is between events in an asynchronous bus.
Asynchronous buses could be faster than synchronous buses because devices do not have to wait until a time unit ends to respond to signals. Equipment from diverse manufacturers may be easier to tie together using asynchronous buses, also. On the other hand, synchronous buses are easier to construct and get working. Most asynchronous buses end up waiting for small amounts of time anyway to make sure that signals do not overlaps so there is not a huge savings.
In either case, computer buses, seemingly so simple and secondary compared to the ALU and memory and the control circuitry, turn out to be maddeningly complex and problematical.
