22-Elec-A4 Digital Systems and Computers · May 2018
Question 5 of 6: Parallel I/O — CPU communication and handshake protocols
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
National Exams — May 2018 · 16-Elec-A4 Digital Systems & Computers.
Closed book, 3 hours. Six questions, 12 marks each; the rubric requires any five, but all six are solved here as a study resource. Approved Casio/Sharp calculator permitted. A Boolean-identity table and the flip-flop excitation table are supplied with the paper (reproduced where used).
Reference texts. M. M. Mano & M. D. Ciletti, Digital Design (6th ed.) — number systems, Boolean minimization, sequential logic; J. F. Wakerly, Digital Design: Principles and Practices (5th ed.) — counters, registers, PLDs; C. Hamacher, Z. Vranesic, S. Zaky & N. Manjikian, Computer Organization and Embedded Systems (6th ed.) — parallel I/O, handshaking, memory-mapped ports; Motorola M68HC11 Reference Manual — port addressing and instruction set.
Question 5: Parallel I/O — CPU communication and handshake protocols (12 marks)
(a) Two methods for the CPU to communicate with the I/O interface. The two classical schemes are program-controlled (polled / programmed) I/O and interrupt-driven I/O. In polled I/O the CPU repeatedly reads a status bit in the interface and transfers a byte only when the bit signals "ready"; it is simple but wastes CPU cycles busy-waiting. In interrupt-driven I/O the interface asserts the IRQ line (shown in the figure) when it is ready, the CPU finishes its current instruction, vectors to a service routine, transfers the byte, and returns — so the CPU does useful work between transfers. (A third method, direct memory access (DMA), lets the interface move blocks to/from memory without the CPU handling each byte; it is the high-throughput extension of the same idea.)
(b) i. Three parallel data-exchange protocols between the interface and the external device:
Simple / brute-force (unconditional) I/O — no handshake. The interface simply drives or samples the data lines, assuming the device is always ready. Used only when timing is guaranteed (e.g. a set of LEDs or switches).
Strobed (pulsed / one-way) handshake — a single control pulse accompanies the data. The sender asserts one strobe line to say "data is valid now"; the receiver is assumed fast enough to capture it. One line (H1 or H2) is active.
Fully interlocked (two-way / double) handshake — both control lines participate. The sender asserts "data available"; the receiver, when it has taken the data, asserts "data accepted"; only then does the sender remove the data and de-assert, and the receiver follows. Each edge is acknowledged, so the transfer self-paces to the slower party and works with devices of unknown speed.
(b) ii. The handshake lines H1 and H2. From the figure, H1 runs from the interface to the device and H2 from the device to the interface. Their common names are a data-ready / data-valid strobe and a data-accepted / acknowledge line; which one plays which role depends on the transfer direction, because the "sender" changes:
Output protocol (CPU/interface → device): the interface is the sender. It places a byte on the data lines and asserts H1 as "DATA READY / DATA VALID". The device latches the byte and replies on H2 as "DATA ACCEPTED / ACKNOWLEDGE". Seeing H2, the interface knows the byte was taken and may present the next one. In the strobed version only H1 (the ready pulse) is used; in the fully interlocked version H1 and H2 chase each other edge-for-edge.
Input protocol (device → CPU/interface): now the device is the sender. It drives the data lines and asserts H2 as "DATA READY / DATA VALID" (data available from the device). The interface captures the byte and replies on H1 as "DATA ACCEPTED / ACKNOWLEDGE", telling the device it may send the next byte. Thus the same two wires reverse roles between input and output: the current sender uses its outgoing line as the "ready" strobe and reads the incoming line as the "accepted" reply.
