- As we saw in the last webpage:
- Bus protocols contains a rigid set of steps that communicating devices
must perform to complete a data transfer operation
(buses are always use to perform data transfer)
- These steps are pre-planned, i.e., specified a priori.
(You can find analogies of bus protocols in archaic practices
like a visit from
a foreign head of state. The protocol dictates that
the foreign head of state must be received in a certain manner.
One of the steps in the reception is the "inspection of the guards").
- A bus is called "synchronous" if the steps of the bus protocol
is guided by a clock signal
The clock signal that guides the bus protocol is called the "bus clock".
(Do not confuse this clock with the 4-phase clock inside the CPU,
these are 2 different clocks and they have nothing to do
with each other.
There are many clocks inside a computer, each one clock signal
paces its own little subsystem within the computer).
- The steps in an synchronous bus protocol are pre-planned using
the bus clock.
Let's consider the mundane task of "frying an egg".
The steps to successfully fry an egg consist of:
- Turning on the stove
- Putting a pan on the stove
- Poor oil in the pan
- Break the egg and put it in the pan
- Wait until the egg is cooked
- Remove the egg and turn off the stove
- (As any examplary student would do it, we ignore the dish washing step...
To fry an egg successfully, the steps must be followed in a specific order,
e.g., you cannot put the egg in, fry it and then poor the oil
(yes, human knows that, but try telling that to a computer...
you have to spell it out to machines... it's worst than teaching
- Some steps can be do simultaneously but the design will
be more complex (need more hardware), so sometimes, even when steps
can be performed simultaneously, the bus protocol designer
may opt to make the step happen sequentially.
- In a synchronouse protocol, the steps of the protocol are planned to
occur at the moments that the clock signal changes in value
(device can only detect changes in the clock)
The start of a synchronous protocol is always at a rise of the
bus clock signal.
The last event in a synchronous protocol is usually planned
to occur at a fall of the bus clock signal (so that
the next protocol can start at a rising edge).
Here is an example of a planning of the "fry an egg" steps
using a clock:
- At rise of clock: Turning on the stove and putting a pan on the stove
- At fall of clock: Poor oil in the pan
- At rise of clock: Break the egg and put it in the pan
- At fall of clock: If eyes signals that the egg is ready,
remove the egg and turn off the stove
Here is an example of a completion of the synchronous egg frying protocol:
Note that when the protocol finishes, we can start a new protocol
immediately if we wanted to -
if you build this protocol with a finite state automata,
you will get a lean and mean egg-frying machine :-)
- The same principle applies when devices inside a computer communicate
with each other:
- A number of things must happen
- and the things must happen in a particular order
- The steps are preplanned with a clock signal
- The (rigid) steps that must happen in a data transfer
depends on the type of operation performed.
Analogy with the fry egg
(This protocol requires more circuits
but its more reliable)
- Now you may understand why (brainless) devices need a rigid
bus protocol to perform a data transfer operation successfully:
The main reason is to make sure that the devices
know each others' state of affair when they take the next step.
For instance, in the synchronous protocol above assures that:
- The memory will keep sending the data as long as
the MREQ and READ is asserted
(because otherwise, the CPU may read a wrong value).
- CPU will not read data as long as WAIT is asserted WAIT.
- So the data on the data bus during the period that:
is guaranteed to be valid !
- MREQ and READ are asserted
- WAIT is not asserted
- So if you make the CPU perform the read during this period,
you will guarantee that it reads the correct value.
- The bus protocol spells out the steps rigidly that will lead
to this state (and also specify steps to return the system
back to its original state).
- Example of a hardware project with timing diagram
- The project description:
- The timing diagram: