Desktop version

Home arrow Computer Science

  • Increase font
  • Decrease font

<<   CONTENTS   >>

Interrupt-Driven I/O

The primary disadvantage of PIO is that the CPU is totally involved in the slow I/O operation, and spends most of its time remaining idle called busy waiting. The way to get rid of busy waiting is to have the CPU issue an I/O command to an I/O module as usual to start the I/O device, and tell the I/O module to generate an interrupt when it is done. While the I/O module starts working, the CPU is no longer involved in this activity and would proceed to do its some other useful work. The I/O module will interrupt the CPU at the right time to request service when it is ready to exchange data with the CPU. The CPU would then again get involved, leaving its own ongoing processing, and execute the data transfer as usual, and after then would go back to resume its former processing. This approach known as interrupt-driven I/O can be accomplished by setting the INTERRUPT ENABLE bit in a device register; the software would expect that the hardware will give it a signal when the I/O module would request.

Although interrupt-driven I/O is more efficient, and is a big step forward from PIO due to eliminating needless waiting of the CPU, it is still far from optimal. The problem is that every time an interrupt occurs, it requires the CPU to get involved for every word (character) of data that goes from memory to I/O module or from I/O module to memory, and interrupt processing then becomes expensive. However, the Intel 8259A chip supports interrupt-driven I/O that can handle up to 8 I/O modules, and a cascade arrangement can extend it to handle even up to 64 modules.

A brief detail of interrupt-driven I/O and various forms of interrupt implementations are given in the website:

Interrupt-Driven I/O: Design Issues

In implementing interrupt-driven I/O, two aspects in the design are to be considered.

a. There will almost invariably be multiple I/O modules connected to the system. How the CPU would determine which device (source) issued the interrupt;

b. If multiple interrupts have occurred, how the CPU would decide the order of their processing (priority).

These two aspects are logically linked with each other because multiple interrupts issued by multiple devices may be attached with single I/O module or may be attached with multiple I/O modules. The first task of the interrupt system is to identify the source of the interrupt. There is also a high probability that several sources request interrupt services simultaneously, or while an interrupt routine is running, a second I/O device wants to generate its interrupt. The solutions consist of techniques commonly in use, which fall broadly into four general categories:

i. Multiple interrupt lines (independent requesting);

ii. Software poll;

iii. Daisy Chaining (vectored, hardware poll);

iv. Bus arbitration (vectored). Multiple Interrupt Lines

Providing multiple interrupt lines between the CPU and I/O modules is probably the most straightforward approach towards the solution of this problem. This method also corresponds to independent requesting of interrupts issued from devices. This scheme actually uses separate BUS REQUEST and BUS GRANT lines for each unit sharing the bus. The bus control unit immediately identifies all requesting units individually and is able to respond very rapidly to requests for bus access. Priority is also determined by the bus control unit, and may be programmable. While this method has some distinct advantages, it also suffers from severe drawbacks. The PDP-11 Unibus system has implemented this technique (bus control) by combining this independent requesting with a daisy chaining (hardware) approach (discussed next).

A brief detail of the different design approaches of interrupt-driven I/O is given in the website: Priority and Level: Its Determination

The categories (ii), (iii), and (iv) as mentioned above are significant when several devices (masters and/or slaves) connected to a shared bus (common bus) would simultaneously issue interrupts, requesting access to CPU at the same time. The problem of selecting one I/O device to service, from many such devices that have generated interrupts, bears a strong resemblance to the bus arbitration process for bus control. In fact, these categories belong to essentially different individual-selection mechanisms that determine appropriate selection considering the priority of each individual interrupt being issued, while negotiating such concurrent competing requests. Priority of simultaneous interrupts can be realized by the techniques implemented by software, hardware, or a combination of both. Polling (Software Approach) The software method to identify the highest-priority interrupt is realized by a polling procedure. In this method, there is one common branch address for all interrupts. The program that takes care of interrupts begins at the branch address and polls the interrupt sources in the order of their priority. The highest-priority source is tested first, and if its interrupt signal is on, control branches to a service routine for this source; otherwise, the next-lower-priority source is tested, and so on. The particular serviced routine thus reached belongs to the highest-priority device among all devices that interrupted the computer at that instant. As depicted in Figure 5.3, this method uses a set of lines called poll count lines which are directly connected to all units in parallel on the


Polling priority interrupt.

bus. When a unit requests access to the bus, it puts a signal on the common BUS REQUEST line. In response to the received signal, the bus controller proceeds to generate a sequence of numbers on the poll count lines. These numbers, which can be thought of as device addresses, are compared by each unit with the unique address already assigned to that unit. When a requesting device Ij finds that its address matches the number on the poll count lines, it activates the BUS BUSY. The bus controller responds bj terminating the polling process and Ij connects to the bus. The priority of a unit, however, is clearly determined by the position of its address in the polling sequence, which can be altered under program control, and hence does not depend on the physical position of the device unit on the bus.


i. The sequence of numbers generated by the bus controller to match the unique unit address is normally programmable (the poll count lines are connected to a programmable register); hence, selection priority can be altered under program control;

ii. A failure in one unit need not affect any of the other units.


i. The cost of more control lines (ะบ poll count lines instead of one BUS GRANT line) to achieve flexibility (independence) over the connected units;

ii. The number of units that can share the bus is limited by the addressing capability of the poll count lines;

iii. If there are many interrupts, the time required to poll them may exceed the time permitted to service the I/O device. In this situation, a hardware-priority-interrupt unit can be used to speed up the operation.

Intel 8259A is one such programmable interrupt controller being used with the respective CPUs that alone manages the interrupts with priorities issued by the numerous devices. Daisy Chaining (Hardware-Serial Connection) The hardware-based priority function can be established by either a serial or a parallel connection of interrupt lines. The serial connection is also known as the daisy chaining method. Under this interrupt system environment, there is a hardware-priority-interrupt unit that functions as an overall manager performing the responsibility of:

i. Accepting interrupt requests from many sources;

ii. Determining which of the incoming requests has the highest priority;

iii. Accordingly issuing an interrupt request to the computer, based on this determination.

As shown in Figure 5.4, all the devices in this system are connected to a common BUS REQUEST line. The unit requesting the bus service issues an interrupt to activate this line by sending a signal to the bus control unit. The bus control unit responds to a BUS REQUEST signal only if BUS BUSY is inactive. This response takes the form of a signal placed on the BUS GRANT line. On receiving the BUS GRANT signal, the requesting unit enables its physical bus connections and activates BUS BUSY for the duration of its new bus activity. Since each interrupt source (device) has its own interrupt vector, it can then directly access its own interrupt service routine. As the BUS GRANT line is connected serially from unit to unit, if two units simultaneously request bus access, the one closest to the bus control unit receives the BUS GRANT signal first and gains access to the bus. Selection priority is therefore completely determined by the order in which the units are linked together (chained) over the BUS GRANT line. The device with the highest priority is placed in the first position (closest to the bus control unit), followed by lower-priority devices up to the device with the lowest priority, which is placed last in the chain.


i. Daisy Chaining is much faster than any software control and requires very few control lines employing a very simple arbitration algorithm;

ii. It can be used essentially with an unlimited number of devices.


Daisy chain priority interrupt.


i. Since priority is wired-in, the priority of each unit cannot be changed under program control, hence offering less flexibility;

ii. If bus requests are generated at a sufficiently high rate, a high-priority device can lock out a low-priority device;

iii. There is a susceptibility to failures involving the BUS GRANT line and its associated circuitry. If the first device is unable to propagate the BUS GRANT signal, then all other devices cannot gain access to the bus. Bus Arbitration Technique This technique makes use of vectored interrupts. With bus arbitration, an I/O module by any means must first gain control of the bus (by raising the interrupt request line) before it can issue the interrupt. Thus, only one module can raise the line at a time. When the CPU detects the interrupt, it can easily identify the source and responds on the interrupt acknowledge line. The requesting module then places its vector (address of the service routine) on the data lines.

A brief detail of the different design approaches of interrupt-driven I/O as discussed is given in the website:

<<   CONTENTS   >>

Related topics