Electrical Engineering of Dictionary of Terms
"A"
"B"
"C",
"D",
"E",
"F",
"G",
"H",
"I",
"J",
"K",
"L",
"M",
"N",
"O",
"P",
"Q",
"R",
"S",
"T",
"U",
"V",
"W",
"X",
"Y",
"Z"
Handshaking Protocol
Hand-Shaking Definition:
Hand-Shaking. The interchange of signals between a 'talker' and a 'listener' to exchange data on a bus. In data communications, a sequence of events governed by hardware or software, requiring mutual agreement of the state of the
operational modes prior to information exchange.
A number of interface buses use HandShaking to communicate; however, the terms or acronyms used to indicate the exchange signals are not always the same. But in all cases the process to exchange data is virtually identical.
The main topic covered here is to address Hardware Handshaking Protocols; however a common software protocol used with computers resides on the COM Port [RS232]. Of course a software protocol [XON/XOFF] still controls a hardware interface, it just depends on what level in the system is being investigated.
The Network Structure has little to due with the handshaking style used. However in a point to point bus handshaking is one to one, while in a multi-drop bus a 'talker' sends out an address and only those 'listeners' corresponding to that address answer.
Hand-Shaking Requirement:
Normally a Handshaking sequence is only required between boards of a different manufacturer or when following an interface standard. A designer would not require a Handshaking routine between ICs on their own board design, the designer would just use a clock to latch in the data. However when communicating off-board to another card, Handshaking is used because there may be no other way to determine how long it will take the far-end board to accept or register the data.
Hand-Shaking Nomenclature:
With the General Purpose Interface Bus, GPIB [IEEE-488] a 'Talker' sends out data onto the bus, while a 'Listener' receives the data. The SCSI bus on the other hand, uses the terms 'initiators' for the device that starts the communication while 'targets' are the one that respond, or receive the data.
In addition to 'Talkers' ['initiators'] or 'Listeners' ['targets'] there also may be Bus Masters that control access to the bus. However normally a Bus Master only grants access to a bus [time slot], and does not normally interfere with communication between devices once access has been granted. Of course if a bus error occurs, communication between devices has timed out, or a data transfer time slot has been exceeded than the Bus Master will regain control; but these conditions have nothing to do with the Handshaking Protocol [other than to remove these devices from the bus].
During a Handshake a listener [slave] indicates ready for data, a talker [master] indicates data ready, the slave then indicates data received.
Handshaking Protocol
GPIB for example sends out a Data Ready signal but does not pass data until it receives a Data Valid signal. Because data on the GPIB bus may be broadcast to a number of devices at the same time, all the devices need to rise their Not Ready For Data [NRFD] lines high indicating Ready For Data. So in this example the slowest device on the bus [to rise the signal] dictates the speed of the bus.
In some way waiting for all the devices to be ready may lower bus overhead [see below], but if there's a node on the bus that's overly slow, then bus throughput can slow to a craw.
Handshaking Waveforms
A more complex Handshaking Protocol is shown in the above diagram, but it still represents two devices passing data. This example requires more over-head in that it requires more signals and additional handshaking, slowing the data transactions on the bus. The more complex the handshaking the slower the data throughput, as every interaction requires some finite amount of time.
Transmission Overhead:
Overhead relates to any required interaction on a bus that does not result in data communication. Any interface bus as some amount of overhead. The higher the overhead, the slower the over-all data throughput from one device to another. The asynchronous transfers shown on this page details an increasing bus overhead by the number of interlocking transfers that occur. Another type of asynchronous transfer may have an increased overhead related to the amount of bits appended to a frame of data [as in Start of Frame, SOF].
A synchronous bus can also have an over-head problem, although the overhead is normally related to the length of time it takes for the node sending the data to gain access to the bus.
Interface Timing:
At any rate it's impossible to tell how fast these interfaces transfer data, there's no timing information provided. Normal asynchronous bus specifications provide data on the minimum pulse width for Data Valid [DAV for example] but the maximum pulse width is usually not given. So the actual through-put rate of bus data is dependent on which two devices are communicating on the bus, while the specification provides the best case through-pit [as in minimum pulse widths plus wait times].
VMEbus Strobe Timing Diagram
The timing diagram above provides a classic example of a timing spec, as far as what timing constraints are provided in a standard. Note that most of the set-up and hold times are given as zero [0nS]. The exception is the data set-up time before the Data Valid pulse.
This waveform is from the VME Bus which uses the acronym 'DS' for Data Strobe, as opposed to 'DAV' [DATA AVAILABLE / DATA VALID].
Designing a handshaking circuit using the Data Valid [DS] strobe and the Data Accepted strobe [DTACK] using the timing diagram above is simple. Just use the Data Valid line as an incoming clock to latch in the data and retransmit that signal as the Data Accepted line. This results in the fastest possible Handshake Circuit, as soon as the sender indicates valid data, it receives the Data Accepted signal [ignoring gate delays and trace delays]. Of course you need to build on that, buffers might be needed, a Schmitt trigger to suppress noise and so on.
MTBF:
Of special note is the set-up time between the data being stable on the bus and the 'DS' line indicating the data is ready [35nS later]. The rational for the delay, or the lengthy wait time is to give the synchronizing flip flop a chance to acquire the data before its clock [by the 'DS' line]. Refer to Logic Metastability.
In many cases the receiving logic will use the DS line as a clock or latch, then the data needs to be valid when the DS lines switches. Once the data has been stored the 'listener' brings DTACK active [low] indicating the data has been acquired. Sometime later or as little as 0ns, the 'talker' will deactivate the Data Strobe [DS] line.
Note that if the 'Talker' really does remove DS after only 0nS then the transfer speed is some what fast. However the 35nS hold time still makes the VME transfer rate relatively slow. Also, in most cases the Talker will take longer than 0nS to respond to the transfer, if for no other reason than the round trip propagation delay between the devices on the bus.
