610 likes | 1.43k Views
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)
E N D
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
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
Generic Model of I/O Module SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt
I/O Module Diagram SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt
External Device Block Diagram SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt
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
Typical I/O Data Rates SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
DMA Module Diagram SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt
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
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
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
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
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
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
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
I/O Channel Architecture SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt
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
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
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
Simple FireWire Configuration SYSC2001* - Dept. Systems and Computer Engineering, Carleton University Fall 2007. SYSC2001-Ch7.ppt