2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 1 Chapter 7 Input/Output 7.1 External Devices

2007 Oct 18 SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt

1

Chapter 7 Input/Output

7.1 External Devices

7.2 I/O Modules

7.3 Programmed I/O

7.4 Interrupt-Driven I/O

7.5 Direct Memory Access

7.6 I/O Channels and Processors

7.7 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

Human readable devices

• Screen, printer, keyboard

Only machine readable devices

• Monitoring and control

Communication

• Modem

• Network Interface Card (NIC)

Sensors: sense the outside world (e.g. temperature sensor, microphone)Transducers: Sense or affect the outside world (e.g. furnace control, speaker, temp sensor)


7

Typical I/O Data Rates


8

Typical I/O Module Functions

Control & Timing

Bus 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) … BUT … it isn’t the same!

Each device given unique identifier (address)

CPU’s I/O commands refer to device address,


12

I/O Module (design) Decisions

Tradeoffs:

• Hide or reveal device properties to CPU?

• Support multiple or single device?

• Control device functions or leave for CPU?

O/S decisions

• e.g. Unix treats everything it can as a file

I/O Mapping [see next slide]


13

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


14

Input Output Techniques Programmed I/O

• CPU issues I/O command then “polls” device until I/O complete

• then (e.g. read) CPU transfers new item obtained from device

Interrupt driven I/O

• CPU issues I/O command 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 DMA to perform transfer between I/O and memory

• DMA issues I/O command then (e.g. read) when I/O complete, DMA transfers new item into memory


15

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”)


16

Programmed I/O - detail

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

CPU must “poll” for results


17

Programmed I/OTypical Polled Operation

CPU issues I/O command

status = done/ready?

CPU reads device status bits device performs

operation

yes

no

CPU executing software

instructions

CPU is“busy waiting”in polling loop


18

Interrupt Driven I/OBasic Operation

1. CPU issues read command

2. I/O module gets data from peripheral while CPU does other work

3. I/O module interrupts CPU

4. CPU requests data

5. I/O module transfers data


19

Interrupt Driven I/O

Advantage: Overcomes CPU busy waiting loops

• No repeated CPU checking of device

I/O module interrupts when ready

• event-driven!


20

Interrupt Driven I/O CPU Viewpoint

1. Issue Read command

2. Do other work

3. Check for interrupt at end of each instruction cycle

4. If interrupted:

a) Save context (registers)

b) Process interrupt

– Fetch data & store

c) restore saved context and resume

done by CPU hardwareNOT software instructions!

execute ISR(software)


21

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


22

Interrupt Driven I/O Identifying Interrupting Module (1)

Techniques:

1. Different hardware bus interrupt line for each module? (expensive)

2. Software Poll: CPU asks each module in turn (slow)

3. Daisy chain or HW Poll (next slide)

4. Bus Mastering (later slide)


23

Interrupt Driven I/O Daisy Chain or Hardware poll

• Interrupt Acknowledge sent by CPU hardware

• ripples down a chain of connected devices

• Module responsible places vector on bus

• CPU uses vector to identify handler routine

CPU

IntAModule

1Module

iModule

n

daisychainlinks

. . . . . .

vector

vector is a word of data; e.g. address of the I/O module, or other unique id.


24

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


25

Multiple Interrupts

Each interrupt line has a priority

Higher priority lines can interrupt lower priority lines

If bus mastering only current master can interrupt


26

Example - PC Bus

80x86 has one interrupt line (INTR)

8086 based systems use one 8259A interrupt controller

8259A has 8 interrupt lines (IRi)8259A

interrupt signalINTR to CPU

IntA signalfrom CPU

vector to CPU(related to IR #)

I/O module 1

I/O module 8

I/O module i

. . .. . .

IR0

IRi -1

IR7 interrupt signalsfrom module


27

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


28

82C59A InterruptController

Maximum Chaining64 devices

IntAto master

vectorfrom slave

IntAto slave


29

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


30

DMA Function

Additional Module (hardware) on bus

DMA controller takes over from CPU for I/O


31

DMA Module Diagram


32

DMA Operation

CPU tells DMA controller:

• Device address

• Starting address of memory block for data

• Amount of data to be transferred

• Read/Write … Go!

CPU carries on with other work

DMA controller deals with transfer

DMA controller sends interrupt when finished


33

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 a data write

Slows down CPU but not as much as CPU doing transfer

WHY?


34

Aside

What effect does caching memory have on DMA?

Hint: how much are the system buses available?


35

Single Bus, Detached DMA controller

Each transfer uses bus twice

• I/O to DMA then DMA to memory

• CPU is suspended twice

DMA Configurations (1)


36

Single Bus, Integrated DMA controller

Controller may support > 1 device

Each transfer uses bus once

• DMA to memory

• CPU is suspended once



37

Separate I/O Bus

Bus supports all DMA enabled devices

Each transfer uses bus once

• DMA to memory

• CPU is suspended once



38

I/O Channels

I/O devices getting more sophisticated – have a dedicated processor ≈ I/O Channel

• e.g. 3D graphics cards

CPU instructs I/O channel to execute an I/O program

I/O channel handles all transfers

Improves speed

• Takes load off CPU

• Dedicated processor is faster


39

I/O Channel Architecture


40

Interfacing

Connecting devices to computer

• e.g. serial, parallel, ethernet, USB

point-to-point: a dedicated connection (disappearing?)

multipoint: an external “bus”

E.g. FireWire, InfiniBand, USB


41

IEEE 1394 FireWire

High performance serial bus

Fast

Low cost

Easy to implement

Also being used in digital cameras, VCRs and TV


42

FireWire Configuration

Daisy chain

Up to 63 devices on single port

• Really 64 – one is the interface itself

Up to 1022 buses can be connected with bridges

Automatic configuration

No bus terminators

May be tree structure


43

Simple FireWire Configuration

Documents

2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 1 Chapter 7 Input/Output 7.1 External Devices