U

Lecture 17 Interrupt Driven I/O and DMA

Dr Peter Breuer, School of Computer Science January 2012

University of Birmingham

Interrupt Driven I/O and DMA

Last lecture detailed

isolated and memory mapped addressing for peripherals
memory mapped addressing to I/O ports used nowadays loses memory address space to peripherals

Programmed I/O (PIO)

programmer has to poll for response from peripheral

and we bagan to talk about interrupt-drive I/O

This lecture will move on to

a detailed discussion of interrupt-driven I/O and DMA

University of Birmingham

Recall . . .
Each peripheral has interrupt request line (IRQ)
instead of a program polling peripheral for completion . . . peripheral tells the CPU when it is nished
peripheral raises interrupt on its IRQ line

CPU launches interrupt handler code in response

response initiated by CPU! running program is interrupted CPU state is saved handler runs CPU state is restored previously running program continues IRQs checked at end of each Fetch-Decode-Execute cycle when an instruction execution has just been completed no instruction is interrupted half-way through
1-1 No interrupt can be missed - peripheral IRQ mapping
University of Birmingham

Overview of Programming for Interrupts

Afer starting I/O at A, program executes instructions X,Y,Z meanwhile CPU handles IRQ completion notication with special handler code H Program carries on at instruction B knowing I/O has completed
Do other task X,Y,Z H Interrupt Error

A
Issue read command to I/O controller

Read status from I/O controller

Status = Ready?

Ready

Read data C through I/O Controller

No

Done whole transfer?

Transfer data to memory

Yes Treat next instruction

University of Birmingham

An interrupt handler for MIPS

I had to write an interrupt handler for CPU5: H 29: 30: 31: 32: 0.000000140s: 0.000000143s: 0.000000145s: 0.000000147s: 0x00000004: 0x00000008: 0x0000000c: 0x00000010: sll $zero, $zero, 0 sll $zero, $zero, 0 sll $zero, $zero, 0 rfe

Loaded at addr 0x4, where IRQ handler lives in MIPS

not a very good handler! simply says oh yeah, I see somebody did something really need to ask each I/O unit in turn who raised IRQ
only one interrupt line in MIPS! so good IRQ handler will have to poll for whodunnit many IRQ lines and one I/O unit per line would solve that CAUSE register in MIPS only says soft/hardware IRQ
University of Birmingham

Notes on Interrupts
Interrupt-driven I/O requires special programming style
the programmer writes code that
1 installs a handler (subroutine) for the interrupt (IRQ) 2 initiates I/O (e.g. send write cmd to I/O controller)

program continues other stu; I/O completes, IRQ recvd

1 CPU saves PC and executes handler 2 handler saves regs, does work, acks IRQ, restores regs 3 handler restores PC and jumps back to program

In detail, the CPU plays its part like this:

1 2 3

CPU only alert to interrupts before each new instr fetch

instructions are never left partially completed

CPU jumps to handler, PC saved, registers saved to stack as handler nishes, it restores registers, jumps back to PC
PC saved in special extra EPC register in MIPS execution resumes at fetch of next instr at address in PC
University of Birmingham

Interrupts in the Context of the FDE Cycle

Interrupts handled in modied fetch-decode-execute cycle
after each cycle nishes, interrupts are checked if interrupt has been signalled by peripheral . . .
CPU disables further interrupts CPU saves PC where? stack? elsewhere? it depends on which CPU! PC loaded with addr of handler code (0x4 in MIPS) handler code runs in CPU the handler ends with the rfe instr CPU executing rfe restores PC CPU reenables interrupts

execution continues where it left o with next instr

Things to remember . . .
interrupt checked only after an instruction nishes
University of Birmingham

Interrupts in the Java MIPS Simulation

CPU5 has interrupt mechanism
theres a nal stage to the pipeline nishing instr enters if IRQ variable is set
CPU unsets bit 1 of STATUS register to disable interrupts CPU copies PC to EPC register CPU sets PC to 0x4 CPU ushes pipeline handler at 0x4 runs in CPU with IRQs disabled handler executes rfe CPU running rfe restores PC from EPC register sets bit 1 of STATUS register, ushes pipeline

execution continues where it left o

Note: copy PC not easy . . . reconstructed from instr

PC has changed since instr entered pipeline
University of Birmingham

IRQ Protocol in the Java MIPS Simulation

MIPS has only one interrupt line (intel has 16) Theres a protocol that CPU/peripherals must follow:
peripheral sets IRQ (only if IACK unset see below)
no peripheral may set IRQ while IRQ|IACK already set

CPU sees IRQ, sets IACK and starts handler

no peripheral may signal IRQ while IACK set

peripheral that set IRQ sees IACK, lowers IRQ

peripherals may set IRQ again only when IACK drops too

CPU nishes handler, sees IRQ unset, unsets IACK

if IRQ still set when handler nishes . . . CPU checks at end of every FDE cycle thereafter . . . and eventually unsets IACK when IRQ goes down meanwhile no peripheral may set IRQ

with IRQ and IACK down, peripherals may assert IRQ anew

If this protocol not followed by every peripheral, chaos!

University of Birmingham

Extra MIPS hardware for Interrupts

The CPU5 Java MIPS simulation has these features too
3 extra MIPS instructions: rfe, mfc0, mtc0
return from exception, move from coprocessor 0, . . .

3 extra (coprocessor) registers: STATUS, CAUSE, EPC

STATUS bit 1 controls IRQ handling: 1=on, 0=o CAUSE indicates interrupt origin: 0 for hardware IRQ EPC is where PC is saved by CPU on starting handler these are coprocessor registers 12, 13, 14 respectively use names $status, $cause, $epc in assembler code mfc0 $1,$status reads from STATUS register to register $1 mtc0 $status,$1 moves data the other way.

2 extra signal lines: IRQ, IACK

IRQ is set by a peripheral wishing to alert the CPU IACK is set by the CPU to indicate it has seen the IRQ

University of Birmingham

Java Simulation Rules that Peripherals must Follow

To ensure peripherals play fair and stick to protocol

use cpu.raiseIRQ() and lowerIRQ() to set/unset IRQ public void raiseIRQ() { while (IRQ || IACK) Clock.waitOn(); // status change? /* !IRQ !IACK */ IRQ = true; /* IRQ !IACK */ Clock.signal(); // status change! }

Peripherals must implement run() method new thread!

other methods (e.g. write) are memory mapped to ports CPU launches handler which will access these methods

University of Birmingham

What is wrong with interrupts?

Interrupt-driven I/O is better than PIO, but . . .

the CPU is still involved in spending a lot of time in I/O
E.g. reading from disk to memory, CPU repeatedly . . . sends (sw) read instruction to disk controller runs handler which saves regs when signalled via IRQ the handler reads (lw) the disk controller buer to mem registers are restored and CPU moves on to next instr thats a lot of work for a few bytes transfer!

One IRQ can block another!

solution: priorities; higher priority IRQ/device can interrupt lower priority IRQ handler while it is running

Better solution is to tell another device to deal with it all

Thats direct memory access (DMA)

University of Birmingham

Direct memory access

DMA means extra unit on system bus: DMA controller

CPU Interupts

Bus

Bus

Main memory

DMA

I/O Controller

I/O Controller

I/O Controller

Disk

Graphics

Network

University of Birmingham

DMA controller
DMA controller is a mini-processor dedicated to I/O
specialises in transferring data between mem locations
includes I/O devices

When the CPU wants to transfer a block of data

it issues a command to the DMA controller containing
address of I/O device starting oset of data block size of block the data transfer direction (read or write)

the DMA unit then does the I/O and raises interrupt when nished meanwhile, the CPU goes on processing DMA controller uses system bus for transfers
exerts control over memory and other I/O devices most useful and ecient in large (block) transfers
University of Birmingham

DMA functions

The DMA controller uses the bus independently of CPU

either it sneaks use of the bus when CPU doesnt use it or it takes the bus from the CPU by force (cycle stealing)

DMA transfers do not involve the CPU

CPU orders DMA controller to do it and leaves it to do it when transfer is nished the DMA controller signals an IRQ
then appropriate handler is run e.g. returns number of bytes got to read system call

DMA is most useful and ecient in large block transfers

e.g. loading large blocks of data to memory from disk

University of Birmingham

Notes on DMA

DMA doesnt tie up CPU; ecient for large transfers But it is dicult to coordinate with cache memory
a copy of memory recently accessed by the CPU is cached and buered in special high-speed memory close to the CPU DMA bypasses this cache:
it is possible that the CPU will have written to memory but the data only have reached cache/buers and not yet reached main memory if DMA reads main memory it will read the old data, not the data the CPU has written conversely, DMA may have written to memory and the CPU may see the old data still in the cache

University of Birmingham

Summary

This lecture has

completed the study of three kinds of I/O mechanisms
programmed I/O interrupt-driven I/O direct memory access

Next lecture will

start a new area
networking!

University of Birmingham