1. 2007 Oct 18SYSC2001* - 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.7FireWire

2. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 3 Generic Model of I/O Module

4. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 4 I/O Module Diagram

5. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 5 External Device Block Diagram

6. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 7 Typical I/O Data Rates

8. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 8 Typical I/O Module Functions  Control & Timing  Bus Communication  Device Communication  Data Buffering  Error Detection

9. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 17 Programmed I/O Typical 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 18 Interrupt Driven I/O Basic 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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 hardware NOT software instructions! execute ISR (software)

21. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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 IntA Module 1 Module i Module n daisy chain links... vector vector is a word of data; e.g. address of the I/O module, or other unique id.

24. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 26 Example - PC Bus  80x86 has one interrupt line (INTR)  8086 based systems use one 8259A interrupt controller  8259A has 8 interrupt lines (IR i ) 8259A interrupt signal INTR to CPU IntA signal from CPU vector to CPU (related to IR #) I/O module 1 I/O module 8 I/O module i... IR 0 IR i -1 IR 7 interrupt signals from module

27. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 28 82C59A Interrupt Controller Maximum Chaining 64 devices IntA to master vector from slave IntA to slave

29. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 30 DMA Function  Additional Module (hardware) on bus  DMA controller takes over from CPU for I/O

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

32. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 34 Aside  What effect does caching memory have on DMA?  Hint: how much are the system buses available?

35. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 36  Single Bus, Integrated DMA controller  Controller may support > 1 device  Each transfer uses bus once DMA to memory CPU is suspended once DMA Configurations (2)

37. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 37  Separate I/O Bus  Bus supports all DMA enabled devices  Each transfer uses bus once DMA to memory CPU is suspended once DMA Configurations (3)

38. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 39 I/O Channel Architecture

40. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 41 IEEE 1394 FireWire  High performance serial bus  Fast  Low cost  Easy to implement  Also being used in digital cameras, VCRs and TV

42. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 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. 2007 Oct 18SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt 43 Simple FireWire Configuration