1 / 61

William Stallings Computer Organization and Architecture 8 th Edition

William Stallings Computer Organization and Architecture 8 th Edition. Chapter 7 Input/Output. Input/Output Problems. Wide variety of peripherals Delivering different amounts of data At different speeds In different formats All slower than CPU and RAM Need I/O modules.

aimee
Télécharger la présentation

William Stallings Computer Organization and Architecture 8 th Edition

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. William Stallings Computer Organization and Architecture8th Edition Chapter 7 Input/Output

  2. Input/Output Problems • Wide variety of peripherals • Delivering different amounts of data • At different speeds • In different formats • All slower than CPU and RAM • Need I/O modules

  3. Input/Output Module • Interface to CPU and Memory • Interface to one or more peripherals

  4. Generic Model of I/O Module

  5. External Devices • Human readable • Screen, printer, keyboard • Machine readable • Monitoring and control • Communication • Modem • Network Interface Card (NIC)

  6. External Device Block Diagram

  7. I/O Module Function • Control & Timing • CPU Communication • Device Communication • Data Buffering • Error Detection

  8. I/O Steps • 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.

  9. I/O Module Diagram

  10. I/O Module 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

  11. Input Output Techniques • Programmed • Interrupt driven • Direct Memory Access (DMA)

  12. Programmed I/O • With programmed I/O, data are exchanged between the processor and the I/O module. The processor executes a program that gives it direct control of the I/O operation, including sensing device status, sending a read or write command, and transferring the data. When the processor issues a command to the I/O module, it must wait until the I/O operation is complete. If the processor is faster than the I/O module, this is wasteful of processor time.

  13. Programmed I/O - detail • When the processor is executing a program and encounters an instruction relating to I/O, it executes that instruction by issuing a command to the appropriate I/O module. With programmed I/O, the I/O module will perform the requested action and then set the appropriate bits in the I/O status register (Figure 7.3).The I/O module takes no further action to alert the processor. In particular, it does not interrupt the processor.

  14. Programmed I/O - detail • Thus, it is the responsibility of the processor periodically to check the status of the I/O module until it finds that the operation is complete. • To explain the programmed I/O technique, we view it first from the point of view of the I/O commands issued by the processor to the I/O module, and then from the point of view of the I/O instructions executed by the processor.

  15. I/O Commands • To execute an I/O-related instruction, the processor issues an address, specifying the particular I/O module and external device, and an I/O command. There are four types of I/O commands that an I/O module may receive when it is addressed by a processor:

  16. I/O Commands • Control: Used to activate a peripheral and tell it what to do. For example, a magnetic-tape unit may be instructed to rewind or to move forward one record. These commands are tailored to the particular type of peripheral device.

  17. I/O Commands • Test: Used to test various status conditions associated with an I/O module and its peripherals. The processor will want to know that the peripheral of interest is powered on and available for use. It will also want to know if the most recent I/O operation is completed and if any errors occurred.

  18. I/O Commands • Read: Causes the I/O module to obtain an item of data from the peripheral and place it in an internal buffer (depicted as a data register in Figure 7.3).The processor can then obtain the data item by requesting that the I/O module place it on the data bus.

  19. I/O Commands • Write: Causes the I/O module to take an item of data (byte or word) from the data bus and subsequently transmit that data item to the peripheral.

  20. Three Techniques for Input of a Block of Data

  21. Addressing I/O Devices • With programmed I/O, there is a close correspondence between the I/O-related instructions that the processor fetches from memory and the I/O commands that the processor issues to an I/O module to execute the instructions. That is, the instructions are easily mapped into I/O commands, and there is often a simple one-to-one relationship. The form of the instruction depends on the way in which external devices are addressed.

  22. Addressing I/O Devices • Typically, there will be many I/O devices connected through I/O modules to the system. Each device is given a unique identifier or address. When the processor issues an I/O command, the command contains the address of the desired device. Thus, each I/O module must interpret the address lines to determine if the command is for itself. • When the processor, main memory, and I/O share a common bus, two modes of addressing are possible: memory mapped and isolated.

  23. I/O Mapping • Memory mapped I/O • Devices and memory share an address space • I/O looks just like memory read/write • No special commands for I/O • Large selection of memory access commands available • Isolated I/O • Separate address spaces • Need I/O or memory select lines • Special commands for I/O • Limited set

  24. Interrupt Driven I/O • The problem with programmed I/O is that the processor has to wait a long time for the I/O module of concern to be ready for either reception or transmission of data. The processor, while waiting, must repeatedly interrogate the status of the I/O module. As a result, the level of the performance of the entire system is severely degraded.

  25. Interrupt Driven I/O • An alternative is for the processor to issue an I/O command to a module and then go on to do some other useful work.The I/O module will then interrupt the processor to request service when it is ready to exchange data with the processor.The processor then executes the data transfer, as before, and then resumes its former processing.

  26. Interrupt Driven I/O • Let us consider how this works, first from the point of view of the I/O module. • For input, the I/O module receives a READ command from the processor. The I/O module then proceeds to read data in from an associated peripheral. Once the data are in the module’s data register, the module signals an interrupt to the processor over a control line. The module then waits until its data are requested by the processor. When the request is made, the module places its data on the data bus and is then ready for another I/O operation.

  27. Interrupt Driven I/O • From the processor’s point of view, the action for input is as follows. • The processor issues a READ command. It then goes off and does something else (e.g., the processor may be working on several different programs at the same time). At the end of each instruction cycle, the processor checks for interrupts (Figure 3.9). When the interrupt from the I/O module occurs, the processor saves the context (e.g., program counter and processor registers) of the current program and processes the interrupt.

  28. Interrupt Driven I/O • From the processor’s point of view, the action for input is as follows. • In this case, the processor reads the word of data from the I/O module and stores it in memory. It then restores the context of the program it was working on (or some other program) and resumes execution.

  29. Simple InterruptProcessing

  30. Changes in Memory and Registersfor an Interrupt

  31. 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

  32. Identifying Interrupting Module (1) • Different line for each module • PC • Limits number of devices • Software poll • CPU asks each module in turn • Slow

  33. Identifying Interrupting Module (2) • Daisy Chain or Hardware poll • Interrupt Acknowledge sent down a chain • Module responsible places vector on bus • CPU uses vector to identify handler routine • Bus Master • Module must claim the bus before it can raise interrupt • e.g. PCI & SCSI

  34. Multiple Interrupts • Each interrupt line has a priority • Higher priority lines can interrupt lower priority lines • If bus mastering only current master can interrupt

  35. 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

  36. DMA Function • Additional Module (hardware) on bus • DMA controller takes over from CPU for I/O

  37. Typical DMA Module Diagram

  38. 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 finished

  39. DMA TransferCycle 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 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

  40. DMA and Interrupt Breakpoints During an Instruction Cycle

  41. 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

  42. 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

  43. 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

  44. Interfacing • The interface to a peripheral from an I/O module must be tailored to the nature and operation of the peripheral. One major characteristic of the interface is whether it is serial or parallel (Figure 7.16). In a parallel interface, there are multiple lines connecting the I/O module and the peripheral, and multiple bits are transferred simultaneously, just as all of the bits of a word are transferred simultaneously over the data bus.

  45. Interfacing • In a serial interface, there is only one line used to transmit data, and bits must be transmitted one at a time. • A parallel interface has traditionally been used for higher-speed peripherals, such as tape and disk, while the serial interface has traditionally been used for printers and terminals. With a new generation of high-speed serial interfaces, parallel interfaces are becoming much less common.

  46. FireWire • With processor speeds reaching gigahertz range and storage devices holding multiple gigabits, the I/O demands for personal computers, workstations, and servers are formidable. Yet the high-speed I/O channel technologies that have been developed for mainframe and supercomputer systems are too expensive and bulky for use on these smaller systems.

  47. FireWire • Accordingly, there has been great interest in developing a high-speed alternative to Small Computer System Interface (SCSI) and other small system I/O interfaces. The result is the IEEE standard 1394, for a High Performance Serial Bus, commonly known as FireWire.

  48. IEEE 1394 FireWire • High performance serial bus • Fast • Low cost • Easy to implement • Also being used in digital cameras, VCRs and TV

  49. FireWire Configuration • Daisy chain • Up to 63 devices on single port • Really 64 of which one is the interface itself • Up to 1022 buses can be connected with bridges • Automatic configuration • No bus terminators • May be tree structure

  50. Simple FireWire Configuration

More Related