Handshake Protocol – Input Operation Control (14 Marks)

Defines asynchronous handshaking to transfer data from input device to CPU/memory without common clock, ensuring data is not lost when device and CPU speeds differ.

Principle: Two control lines: DATA VALID (source says data ready) and DATA ACCEPTED / ACK (destination says data captured). Both sides interlock.

Destination-Initiated Handshake for Input (CPU reading from device):

This is typical for input – CPU/destination initiates because it knows when it can accept.

Steps with timing:

1. Idle: Data bus invalid, VALID=0, ACCEPT=0, Ready=0
2. Destination (CPU interface) is ready to receive → asserts READY / REQUEST (or ACCEPT high)
3. Input device places data byte on data bus (e.g., keyboard, ADC) and after settling asserts DATA VALID / STROBE
4. Destination latches data into input buffer register on seeing VALID, then asserts DATA ACCEPTED / ACK =1
5. Device sees ACK, deasserts VALID =0 and removes data from bus
6. Destination sees VALID low, deasserts ACK/READY =0, handshake cycle complete, next data can be requested

Sequence diagram:

Device:  ----data valid---->
CPU:     <--- ack --------
Time:  Req↑ → Data→ Valid↑ → Latch → Ack↑ → Valid↓ → Ack↓

Source-Initiated alternative: Device asserts VALID first (if data arrives spontaneously), CPU responds with ACK after reading. Used for interrupts.

Hardware Control:

• Device side: Data register + Valid flip-flop
• CPU side: Buffer register + Ready/Ack logic + Interrupt/DMA request
• Example: 8255 PPI Handshake Input Mode – STB (strobe input, active low from device), IBF (Input Buffer Full to device), INTR to CPU. Device pulses STB after putting data, IBF goes high acknowledging latch, CPU reads port resetting IBF.

Advantages: No clock correlation needed, reliable at any speed, automatic flow control.
Disadvantage: Extra 2-wire overhead and handshake delay lowers max throughput; need 4-phase protocol for reliability.