Question 6 of 6: Parallel I/O — CPU polling versus interrupts, and handshake protocols (12 marks)

Question 6: Parallel I/O — CPU polling versus interrupts, and handshake protocols (12 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

The system has two distinct interfaces, and the question deliberately treats them separately. On the processor side, the CPU and the I/O interface communicate over the data bus, with control signals outbound and an interrupt request inbound. On the device side, the interface and the peripheral exchange data over the data lines, coordinated by the two protocol signals H1 and H2.

(a) Programmed I/O versus interrupt-driven I/O (4 marks)

The two methods by which a program makes the CPU aware that the interface has new data, or is ready to accept data, are polling (programmed I/O) and interrupt-driven I/O.

Under polling, the processor takes the initiative. The interface maintains a status register containing flags such as READY or DATA AVAILABLE, and the program executes a tight loop that repeatedly reads that register and tests the flag. When the flag is finally set, the program falls out of the loop and executes the data-transfer instruction that reads the input register or writes the output register. The transfer itself is performed by ordinary load and store instructions to the memory-mapped interface addresses; nothing is transferred until the CPU asks. The scheme is simple to write, needs no additional hardware beyond the status flag, and gives entirely predictable timing, which is why it is still used in small dedicated controllers and in initialisation code.

Under interrupt-driven I/O, the interface takes the initiative. When the device sets the condition the CPU cares about, the interface asserts the IRQ line shown in the figure. The processor completes the instruction in progress, saves the program counter and status register, and vectors to an interrupt service routine that performs the transfer and clears the interrupt source before returning. Between interrupts the CPU is free to execute unrelated work, so the processor and the device proceed concurrently.

The more efficient method is interrupt-driven I/O, and the reason is the enormous mismatch between processor and peripheral speeds. A peripheral such as a keyboard, a printer or a serial link delivers events on a millisecond timescale, while the processor executes an instruction in microseconds or less. A polling loop therefore spends essentially all of its iterations reading a flag that is still clear: the CPU is fully occupied but performs no useful work, and that wasted time scales with how slow the device is. Interrupt-driven transfer replaces that busy-wait with a single hardware signal, so the only processor time charged to the device is the interrupt latency plus the service routine itself. The gain grows with the number of devices, because one polling loop must interrogate every device in turn whereas interrupts arrive only from the device that actually needs service, already identifying itself through its vector.

The advantage is not unconditional, and a complete answer should say so. Interrupts carry a fixed overhead for saving and restoring context, so for a device that is nearly always ready — or when the CPU has nothing else to do — polling can transfer a block faster and with lower latency. Interrupts also introduce concurrency, and therefore the need for priority arbitration and for care over shared data. For sustained high-rate transfers both methods are eventually displaced by direct memory access, in which a DMA controller moves the block and interrupts the CPU only once at completion.

(b) i. Two parallel I/O protocols (part of 8 marks)

The two protocols used between the I/O interface and the external device are the strobe (one-way, non-interlocked) protocol and the handshake (interlocked) protocol. In the strobe protocol only one of the two signals is used: the sender places data on the lines and issues a single timing pulse to announce it, and simply assumes the receiver keeps up. There is no reply, so the sender learns nothing about whether the data was taken; the scheme is fast and cheap but only safe when the receiver's timing is known in advance. In the handshake protocol both H1 and H2 are used, and each transition of one signal is a response to a transition of the other. This makes the exchange self-timed: it runs at the speed of the slower party and cannot overrun, at the cost of two round trips per byte. The fully interlocked form described below is the one normally meant by "handshake".

(b) ii. Steps for input and for output (remainder of 8 marks)

INPUT of data (device to interface). Here the external device is the source, so it owns the data lines and the VALID DATA signal, while the interface replies. The sequence is:

1. Device places the data. The I/O device drives the data lines with the new byte and allows them to settle.
2. Device asserts H1 — VALID DATA. Once the lines are stable the device asserts H1, which tells the interface that the data on the lines may now be read. H1 is the VALID DATA signal for input.
3. Interface captures and acknowledges with H2. Seeing H1, the interface latches the byte into its input register, sets its DATA AVAILABLE status flag (which is what the CPU later polls or takes an interrupt on), and asserts H2. H2 is the ACKNOWLEDGEMENT of data reception for input.
4. Device releases H1. Having seen the acknowledgement, the device knows the byte has been taken; it de-asserts H1 and may remove the data from the lines.
5. Interface releases H2. Seeing H1 return to its inactive state, the interface de-asserts H2. Both signals are now back to their resting values and the next byte may begin.

OUTPUT of data (interface to device). The direction of the data reverses, and with it the ownership of the two signals — but the roles stay attached to the same signal names, with H1 always driven by the sender of the data and H2 by the receiver:

1. Interface places the data. The CPU has written a byte to the interface's output register; the interface drives it onto the data lines and lets them settle.
2. Interface asserts H1 — DATA READY. With the lines stable the interface asserts H1 to announce valid data to the device. H1 is again the VALID DATA signal.
3. Device takes the data and asserts H2. The device reads the byte and asserts H2 to confirm it has been accepted. H2 is again the ACKNOWLEDGEMENT. For the interface this is also the signal that its output register is free, so it sets the READY flag that the CPU polls or that raises the interrupt for the next byte.
4. Interface releases H1 and may change the data lines.
5. Device releases H2, completing the cycle and returning both lines to rest.

The symmetry is the point worth stating explicitly: in both directions H1 signals VALID DATA and is driven by whichever party is sending, while H2 signals ACKNOWLEDGEMENT and is driven by whichever party is receiving. What changes between input and output is not the meaning of the signals but which side of the interface drives each one. Because every edge in the sequence is caused by the preceding edge, neither party can run ahead of the other, and the transfer rate adapts automatically to the slower device — the property that makes the interlocked handshake safe across a cable of unknown length, where the strobe protocol is not.