Asynchronous communication protocols
 

  • Although bus protocols are finite state machines, traditionally, the steps in the bus protocols are described using timing diagrams:

           

  • In a asynchronous protocol, the protocol steps are "driven" by readiness event indications

    I.e.: the progress/transition in the asynchronous protocol is paced by specific readiness event indications

Illustration of an asynchronous communication protocol

Problem description:

 
  • Pitcher and catcher are deaf, mute and blind
  • The pitcher has perfect aim (despite being blind)
  • The pitcher has an infinite number of balls
  • The catcher can be in the catching position or idle position.
  • The catcher will catch a ball thrown if he is in the catching position

Give a set of rules to allow the pitcher to write a (braile) message on a ball and "send" (= throw) it to the catcher and the catcher will always "receive" (= catch the ball) it reliably.

Illustration of an asynchronous communication protocol
 

Solution:

 

 

Notice: the progress of the steps in the protocol are "driven" by a readiness event

CPU signals used to implement a asynchronous communication protocol

Signal names taken from a blue CPU (M68000):

Note: different CPU manufacturer can assigned different signal names to these signals !!!

CPU signals used to implement a asynchronous communication protocol

Text books that presents a (simpler) asynchronous protocol uses these signal names:

We will first discuss the meaning of the new signals first.

Terminology: the master device
 

Master device = the device that initializes the communication procotol

In computer communication, the CPU is always the master device

Terminology: the slave device
 

Slave device = the device that is targeted in the communication procotol

In computer communication, the memory is always the slave device

The meaning of the Master Synch (MSYNC) signal
 

MSYNC is only asserted when the master device has sent out the Read/Write request

The MSYNC signal asserts that the command/request signals on the system bus is now correct

The meaning of the Slave Synch (SSYNC) signal
 

SSYNC is only asserted when the slave device has processed the Read/Write request

The SSYNC signal asserts that the response signals on the system bus is now correct

The meaning of the Memory Request (MREQ) signal
 

MREQ is only asserted when the memory is targeted (instead of an IO device):

The MREQ signal is used to activate (= enable) the memory circuit

The meaning of the Read/Write (R/W) signal
 

R/W is used to indicate a Read operation or a Write operation on the memory:

We will use R/W=0 to mean Read operation and R/W=1 to mean Write operation

The asynchronous READ protocol

Protocol steps exchanged between the CPU and the memory in a READ operation:

 

The asynchronous READ protocol

The asynchronous protocol will add READINESS signalling to ensure correctness:

 

An actual bus protocol timing diagram

Actual example of a timing diagram (there are 3 operations in this diagram)

The timing diagram of the asynchronous READ protocol

We will now study the timing diagram of the asynchronous READ protocol:

I will explain the timing diagram in a piece meal manner next....

The timing diagram of the asynchronous READ protocol

The signals activated by the CPU and memory when executing the async READ procotol are:

 

The timing diagram of the asynchronous READ protocol

The meaning of the signal transitions in a timing diagram:

 

The timing diagram of the asynchronous READ protocol

The signals at The start of an asynchronous READ protocol are as follows:

The CPU now starts a READ operation and runs the async READ protocol...

The timing diagram of the asynchronous READ protocol

(1) the CPU sends out the address and a READ command:

The memory may start working on the request; but it will usually wait till the next step...

The timing diagram of the asynchronous READ protocol

(2) the CPU asserts the MSYNC sigan to tell the memory that all signals are now valid:

The memory will now fetch the data requested in the READ operation...

The timing diagram of the asynchronous READ protocol

(3) the memory will now process the READ request:

The SSYNC signal will prevent the CPU from reading invalid data on the data bus !!!

The timing diagram of the asynchronous READ protocol

(4) after some processing delay, the memory will send the fetched data on the data bus:

At this moment, the CPU can not tell if the data is valid !!!

The timing diagram of the asynchronous READ protocol

(5) the memory will certify the data correctness by asserting the SSYNC signal:

The SSYNC signal will trigger the CPU to continue with the next step !!!

The timing diagram of the asynchronous READ protocol

(6) the CPU will copy the data on the data bus into its MBR reg at the earliest possible time:

Note that the protocol can guarantee that the data on the data bus is correct !!

The timing diagram of the asynchronous READ protocol

(7) the CPU must remove (withdraw) the READ request from the bus in a safe manner:

Unassert MSYNC first (MREQ and R/W cannot change while MSYNC is asserted)

The timing diagram of the asynchronous READ protocol

(7) the CPU must remove (withdraw) the READ request from the bus in a safe manner:

When MSYNC ("guaranteed correct") is unasserted, CPU can safely change the other signals

The timing diagram of the asynchronous READ protocol

(8) the memory must remove (withdraw) the DATA response from the bus in a safe manner:

Unassert SSYNC first (the data cannot change while SSYNC is asserted)

The timing diagram of the asynchronous READ protocol

(8) the memory must remove (withdraw) the DATA response from the bus in a safe manner:

When SSYNC ("data guaranteed correct") is unasserted, memory can safely remove the data

The timing diagram of the asynchronous READ protocol

Notice that: all signals have returned to their original state !!

Therefore: a new bus cycle can start immediately !!!

Reading the timing diagram of an actual asynchronous bus protocol

Can you now read the READ procotol in the timing diagram of the M68000 processor:

The READ procotol is on the left of the diagram.

(The right side of the diagram contains a asynchronous READ procotol, one on a slower memory)

Another way to view the asynchronous READ protocol

Initially, there are no signals asserted on the bus:

 

Another way to view the asynchronous READ protocol

(1) the CPU sends out address and MREQ and R/W=0:

 

Another way to view the asynchronous READ protocol

(2) the CPU asserts the MSYNC to indicate that the request signals are now valid:

 

Another way to view the asynchronous READ protocol

(3) in response (to MSYNC), the memory fetches the requested data and send it on the databus:

 

Another way to view the asynchronous READ protocol

(4) the memory then asserts SSYNC to tell the CPU that it's OK to read the data now:

 

Another way to view the asynchronous READ protocol

Notice that the protocol guarantees that the CPU receives valid data on data bus:

 

Another way to view the asynchronous READ protocol

(5) the CPU read the data and then:   first de-assert MSYNC:

 

Another way to view the asynchronous READ protocol

(5) the CPU then de-assert the other request signals:

 

Another way to view the asynchronous READ protocol

(6) in response (to MSYNC), will de-assert the SSYNC signal first:

This means: data on data bus is invalid (even though it's still valid, that's OK)

Another way to view the asynchronous READ protocol

(6) and the memory withdraws the data from the databus (shut of tri-state-buffers):

And the computer system is back to the initial state !!!

Pros and Cons of the Asynchronous bus protocol

  • Strength of the Asynchronous bus protocol:

    • Automatically adapt to the speed of the other communication device:

      • Faster devices will send the MSYNC/SSYNC signal sooner

      • Slower devices will send the MSYNC/SSYNC signal later

      • Devices can adapt to each other's speed by synchronizing on the MSYNC/SSYNC signals

  • Weakness of the Asynchronous bus protocol:

    • More complicated than the Synchronous bus protocol

      (We will discuss that next)