Input Output Management

C R Sarma
Associate Professor, Dept of ECE
G.Narayanamma Institute of Technology and Science

1
Input Output Management
• External Devices
• I/O Modules
• Programmed I/O
• Interrupt-Driven I/O
• Direct Memory Access
• I/O Channels and
Processors
• FireWire
2
Input/Output Problems
• Wide variety of peripherals
(external devices)
– Delivering different amounts of
data
– At different speeds
– In different formats
• All slower than CPU and RAM
• Need I/O modules
3
Generic Model of I/O
Module

4
I/O Module Diagram

5
External Device Block
Diagram

6
External Devices
Sensors: sense the outside
• Human readable devices world (e.g. temperature
sensor, microphone)
– Screen, printer, keyboard
Transducers: Sense or
• Only machine readable devices
affect the outside world
(e.g. furnace control,
– Monitoring and control
speaker, temp sensor)
• Communication
– Modem
– Network Interface Card (NIC)

7
Typical I/O Data Rates

8
Typical I/O Module
Functions
• Control & Timing
• CPU Communication
• Device Communication
• Data Buffering
• Error Detection

9
I/O Steps

• Overview of I/O steps (e.g.

Input):
1. CPU checks I/O module device status
2. I/O module returns status
3. If ready, CPU requests data transfer
4. I/O module gets data from device
5. I/O module transfers data to CPU
• Variations for Output, DMA, etc.
10
I/O Commands
• CPU issues address
– Identifies module (& device if >1 per
module)
• CPU issues command
– Control - telling module what to do
• e.g. spin up disk
– Test - check status
• e.g. power? Error?
– Read/Write
• Module transfers data via buffer from/to
device
11
Addressing I/O Devices

• I/O can seem very much like memory

access (from CPU viewpoint)
• Each device given unique identifier
(address)
• CPU’s I/O commands refer to device
address,

12
I/O Module (design)
Decisions
• Hide or reveal device properties to
CPU?
• Support multiple or single device?
• Control device functions or leave for
CPU?
• Also O/S decisions
– e.g. Unix treats everything it can as a
file
– Might even let programmer address I/O 13
 Input Output Techniques
• Programmed I/O
– CPU asks device for I/O then “polls” device until I/O
complete
– then (e.g. read) CPU transfers new item obtained
from device

• Interrupt driven I/O

– CPU asks device for I/O and then device “interrupts”
CPU when complete
– then (e.g. read) CPU transfers new item obtained
from device

• Direct Memory Access (DMA) I/O

– CPU asks device for I/O
– then (e.g. read) when I/O complete, I/O system
transfers new item into memory itself
14
Programmed I/O

• CPU has direct control over I/O

– Sensing status
– Read/write commands
– Transferring data
• CPU waits for I/O module to complete
operation
• Wastes CPU time (“busy waiting”)

15
Programmed I/O - detail
CPU must “poll” for results
• Programmed I/O sequence:
1. CPU requests I/O operation
2. I/O module performs operation
3. I/O module sets status bits
4. CPU checks status bits periodically
• I/O module does not inform CPU
directly
• I/O module does not interrupt CPU
• CPU may wait or come back later 16
 Programmed I/O
CPU executing Typical Polled
software
instructions Operation
CPU issues I/O command

device performs
CPU reads device status bits operation

no
status = done/ready?
CPU is
yes
“busy waiting”
in polling loop
17
I/O Mapping
• Memory mapped I/O
– Devices and memory share an
address space
– I/O access just like memory read/write
– No special CPU instructions for I/O
• Large selection of memory access
commands
• Isolated I/O
– Separate address spaces
– Need I/O vs. memory select lines on
control bus
– Special CPU instructions for I/O
• Limited access commands 18
Programmable Peripheral
Interface
i8255

19
 I/O Management
by
Operating Systems
• OS’s discourage access to I/O by
address
• OS’s treat I/O devices as FILES
• Files are called Device Drivers
• A Drivers for same type of I/O
peripheral from different
manufacturers – different control and
addresses of registers
• Easy to change if treated as device 20
 I/O Management by Operating
Systems

• Device Driver Files Structure

Create() – to create a new DD for a specific I/O
device
Open() – Opens the device file for operation
Read() – read from Device
Write() – Write to Device
Close() – Closes the open DD
these are almost similar to ordinary disk
files
IOCTL() – This is for IO control and contains the
function pointers and the device register 21
Interrupt Driven I/O
Basic Operation
 CPU issues read command
 I/O module gets data from peripheral
while CPU does other work
 I/O module interrupts CPU
 CPU requests data
 I/O module transfers data

22
Interrupt Driven I/O

• Advantage: Overcomes CPU busy

waiting loops
– No repeated CPU checking of device
• I/O module interrupts when ready
– event-driven!

23
Interrupt Driven I/O
CPU Viewpoint
done by CPU hardware
 Issue Read command
NOT software instructions!
 Do other work
 Check for interrupt at end of each
instruction cycle
 If interrupted:
execute ISR
a) Save context (registers) (software)
b) Process interrupt
• Fetch data & store
c) restore saved context and resume 24
Interrupt Driven I/O
Design Issues

• How do you identify the module

issuing the interrupt?
• How do you deal with multiple
interrupts?
– i.e. an interrupt handler being
interrupted

25
Interrupt Driven I/O
Identifying Interrupting
Module (1)
• Techniques:
• Different hardware bus interrupt line
for each module? (expensive)
• Software Poll: CPU asks each module
in turn (slow)
• Daisy chain or HW Poll (next slide)
• Bus Mastering (later slide)

26
Interrupt Driven I/O
• Daisy Chain or Hardware poll
– Interrupt Acknowledge sent by CPU
hardware
– ripples down a chain of connected devices daisy
– Module responsible places vector on bus chain
– CPU uses vector to identify handler routine links
IntA
Module
. . . Module . . . Module
CPU 1 i n

vector
vector is a word of data; e.g. address of the
I/O module, or other unique id.
27
Hardware: Bus Master
Approach
• Bus Mastering (uses bus
arbitration) Approach:
– I/O Module must get control of the bus
before it can raise interrupt
– Then only one interrupt line needed!
– e.g. PCI & SCSI

28
Multiple Interrupts

• Each interrupt line has a priority

• Higher priority lines can interrupt
lower priority lines
• If bus mastering only current master
can interrupt

29
Programmable Interrupt
Controller
i8259

30
 Example - PC Bus
• 80x86 has one interrupt line
• 8086 based systems use one 8259A interrupt
controller
• 8259A has 8 interrupt lines (IR)
I/O module 1
interrupt signal IR0
INTR to CPU

... ...
8259A
IR i I/O module i
IntA signal
-1
from CPU IR7 interrupt signals
from module
vector to CPU I/O module 8
(related to IR #)
31
Sequence of Events

1.8259A accepts interrupts (from

modules)
2.8259A determines priority
3.8259A signals 8086 (raises INTR
line)
4.CPU Acknowledges (IntA)
5.8259A puts correct vector on data
bus
6.CPU processes interrupt 32
 82C59A
Interrupt
Controller

IntA
to master
IntA
to slave
vector
from slave

Maximum Chaining
64 devices
33
Direct Memory Access

• Interrupt driven and programmed I/O

require active CPU intervention
– Transfer rate is limited
– CPU is tied up
• DMA is the answer

34
DMA Function

• Additional Module (hardware) on bus

• DMA controller takes over from CPU
for I/O

35
DMA Module Diagram

36
DMA Operation

• CPU tells DMA controller:

– Read/Write
– Device address
– Starting address of memory block for
data
– Amount of data to be transferred
• CPU carries on with other work
• DMA controller deals with transfer
• DMA controller sends interrupt when 37
DMA Transfer: Cycle
Stealing
• DMA controller takes over bus for a
cycle
• Transfer of one word of data
• Not an interrupt
– CPU does not switch context
• CPU suspended (possibly) just
before it accesses bus
– i.e. before an operand or data fetch or
WHY?
a data write
• Slows down CPU but not as much 38
DMA Controller 8237/i8257

39
 DMA Configurations (1)

• Single Bus, Detached DMA controller

• Each transfer uses bus twice
– I/O to DMA then DMA to memory
– CPU is suspended twice

40
 DMA Configurations (2)

• Single Bus, Integrated DMA

controller
• Controller may support > 1 device
• Each transfer uses bus once
– DMA to memory
– CPU is suspended once 41
 DMA Configurations (3)

• Separate I/O Bus

• Bus supports all DMA enabled
devices
• Each transfer uses bus once
– DMA to memory
– CPU is suspended once
42
I/O Channels

• I/O devices getting more

sophisticated
– e.g. 3D graphics cards
• CPU instructs I/O controller to do
transfer
• I/O controller does entire transfer
• Improves speed
– Takes load off CPU
– Dedicated processor is faster 43