1 / 43

Chapter 7 Input/Output

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. Input/Output Problems. Wide variety of peripherals (external devices)

edric
Download Presentation

Chapter 7 Input/Output

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 SYSC2001* - 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 SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt

  3. Generic Model of I/O Module SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt

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

  5. External Device Block Diagram SYSC2001* - 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) SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt

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

  9. I/O Steps • Overview of I/O steps (e.g. Input): • CPU checks I/O module device status • I/O module returns status • If ready, CPU requests data transfer • I/O module gets data from device • I/O module transfers data to CPU • Variations for Output, DMA, etc. SYSC2001* - 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 SYSC2001* - 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, SYSC2001* - 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] SYSC2001* - 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 SYSC2001* - 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 SYSC2001* - 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”) SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt

  16. Programmed I/O - detail • Programmed I/O sequence: • CPU requests I/O operation • I/O module performs operation • I/O module sets status bits • 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 SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt

  17. CPU executing software instructions Programmed I/OTypical Polled Operation CPU issues I/O command device performs operation CPU reads device status bits status = done/ready? no CPU is “busy waiting” in polling loop yes SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt

  18. Interrupt Driven I/OBasic 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 SYSC2001* - 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! SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt

  20. Interrupt Driven I/O CPU Viewpoint done by CPU hardware NOT software instructions! • Issue Read command • Do other work • Check for interrupt at end of each instruction cycle • If interrupted: • Save context (registers) • Process interrupt • Fetch data & store • restore saved context and resume execute ISR (software) SYSC2001* - 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 SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt

  22. 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) SYSC2001* - 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 daisy chain links CPU IntA Module 1 . . . Module i . . . Module n vector vector is a word of data; e.g. address of the I/O module, or other unique id. SYSC2001* - 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 SYSC2001* - 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 SYSC2001* - 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 (IRi) I/O module 1 8259A interrupt signal INTR to CPU IR0 . . . IRi -1 I/O module i IntA signal from CPU . . . IR7 interrupt signals from module vector to CPU (related to IR #) I/O module 8 SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt

  27. Sequence of Events • 8259A accepts interrupts (from modules) • 8259A determines priority • 8259A signals 8086 (raises INTR line) • CPU Acknowledges (IntA) • 8259A puts correct vector on data bus • CPU processes interrupt SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt

  28. 82C59A InterruptController IntA to master IntA to slave vector from slave Maximum Chaining64 devices SYSC2001* - 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 SYSC2001* - 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 SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt

  31. DMA Module Diagram SYSC2001* - 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 SYSC2001* - 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? SYSC2001* - 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? SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt

  35. 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 SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt

  36. 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 SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt

  37. 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 SYSC2001* - 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 SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt

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

  43. Simple FireWire Configuration SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt

More Related