Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Chapter 4


Published on

Input/ Output

Published in: Engineering
  • Login to see the comments

  • Be the first to like this

Chapter 4

  1. 1. Er. Nawaraj Bhandari Topic 4 Input/ Output Computer Architecture
  2. 2. Input/Output Problems  Wide variety of peripherals  Delivering different amounts of data  At different speeds  In different formats  There are a wide variety of peripherals with various methods of operation. It would be impractical to incorporate the necessary logic within the processor to control a range of devices  The data transfer rate of peripherals is often much slower than that of the memory or processor. Thus, it is impractical to use the high-speed system bus to communicate directly with a peripheral
  3. 3. Input/Output Problems  the data transfer rate of some peripherals is faster than that of the memory or processor. Again, the mismatch would lead to inefficiencies if not managed properly  Peripherals often use different data formats and word lengths than the computer to which they are attached
  4. 4. Input/Output Module  Interface to CPU and Memory  Interface to one or more peripherals  Interface to the processor and memory via the system bus or central switch  Interface to one or more peripheral devices by tailored data links
  5. 5. Generic Model of I/O Module
  6. 6. External Devices  Human readable (human interface)  Monitor, printer, keyboard, mouse  Machine readable  Disk, tape, sensors  Communication  Modem  Network Interface Card (NIC)
  7. 7. External Device Block Diagram
  8. 8. External Device  Control signals determine the function that the device will perform, such as send data to the I/O module (INPUT or READ), accept data from the I/O module (OUTPUT or WRITE), report status, or perform some control function particular to the device (e.g., position a disk head). • Status signals indicate the state of the device. Examples are READY/NOT-READY to show whether the device is ready for data transfer
  9. 9. External Device • Control logic associated with the device controls the device’s operation in response to direction from the I/O module. • The transducer converts data from electrical to other forms of energy during output and from other forms to electrical during input. Typically, a buffer is associated with the transducer to temporarily hold data being transferred between the I/O module and the external environment; a buffer size of 8 to 16 bits is common.
  10. 10. I/O Module Function The major functions or requirements for an I/O module fall into the following categories:  Control & Timing  CPU (Processor) Communication  Device Communication  Data Buffering  Error Detection (e.g., extra parity bit)
  11. 11. I/O Module Function  During any period of time, the processor may communicate with one or more external devices in unpredictable patterns, depending on the program’s need for I/O.  The internal resources, such as main memory and the system bus, must be shared among a number of activities, including data I/O.  Thus, the I/O function includes a control and timing requirement, to coordinate the flow of traffic between internal resources and external devices.  For example, the control of the transfer of data from an external device to the processor might involve the following sequence of steps:
  12. 12. I/O Module Function  The processor interrogates the I/O module to check the status of the attached device.  The I/O module returns the device status.  If the device is operational and ready to transmit, the processor requests the  transfer of data, by means of a command to the I/O module.  The I/O module obtains a unit of data (e.g., 8 or 16 bits) from the external device.  The data are transferred from the I/O module to the processor.
  13. 13. Processor/device Communications  Command decoding: The I/O module accepts commands from the processor, typically sent as signals on the control bus. For example, an I/O module for a disk drive might accept the following commands: READ SECTOR, WRITE SECTOR, SEEK track number, and SCAN record ID  Data: Data are exchanged between the processor and the I/O module over the data bus.
  14. 14. Processor/device Communications  Status reporting: Because peripherals are so slow, it is important to know the status of the I/O module. For example, if an I/O module is asked to send data to the processor (read), it may not be ready to do so because it is still working on the previous I/O command. This fact can be reported with a status signal Common status signals are BUSY and READY. There may also be signals to report various error conditions  Address recognition: Just as each word of memory has an address, so does each I/O device. Thus, an I/O module must recognize one unique address for each peripheral it controls.
  15. 15. Data Buffering:  An essential task of an I/O module is data buffering.  Whereas the transfer rate into and out of main memory or the processor is quite high, the rate is orders of magnitude lower for many peripheral devices and covers a wide range.  Data coming from main memory are sent to an I/O module in a rapid burst. The data are buffered in the I/O module and then sent to the peripheral device at its data rate.  In the opposite direction, data are buffered so as not to tie up the memory in a slow transfer operation. Thus, the I/O module must be able to operate at both device and memory speeds.  Similarly, if the I/O device operates at a rate higher than the memory access rate, then the I/O module performs the needed buffering operation.
  16. 16. Need for Data Buffering: Typical I/O Data Rates
  17. 17. Error detection: • Finally, an I/O module is often responsible for error detection and for subsequently reporting errors to the processor. • One class of errors includes mechanical and electrical malfunctions reported by the device (e.g., paper jam, bad disk track). • Another class consists of unintentional changes to the bit pattern as it is transmitted from device to I/O module. • Some form of error-detecting code is often used to detect transmission errors
  18. 18. I/O Module Diagram
  19. 19. I/O Module Diagram The module connects to the rest of the computer through a set of signal lines (e.g., system bus lines). Data transferred to and from the module are buffered in one or more data registers. There may also be one or more status registers that provide current status information. A status register may also function as a control register, to accept detailed control information from the processor. The logic within the module interacts with the processor via a set of control lines. The processor uses the control lines to issue commands to the I/O module. Some of the control lines may be used by the I/O module (e.g., for arbitration and status signals). The module must also be able to recognize and generate addresses associated with the devices it controls. Each I/O module has a unique address or, if it controls more than one external device, a unique set of addresses.
  20. 20. 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
  21. 21. Input Output Techniques  Programmed  Interrupt driven  Direct Memory Access (DMA)
  22. 22. Input Output Techniques
  23. 23. 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
  24. 24. Programmed I/O
  25. 25. Programmed I/O - detail  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
  26. 26. 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
  27. 27. Addressing I/O Devices  Under programmed I/O data transfer is very like memory access (CPU viewpoint)  Each device given unique identifier  CPU commands contain identifier (address)
  28. 28. 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
  29. 29. I/O Mapping
  30. 30. Interrupt Driven I/O  Overcomes CPU waiting  No repeated CPU checking of device  I/O module interrupts when ready
  31. 31. Interrupt Driven I/O
  32. 32. Interrupt Driven I/O Basic Operation  CPU issues read command  I/O module gets data from peripheral whilst CPU does other work  I/O module interrupts CPU  CPU requests data  I/O module transfers data
  33. 33. CPU Viewpoint  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  See Operating Systems notes
  34. 34. 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
  35. 35. DMA Function  Additional Module (hardware) on bus  DMA controller takes over from CPU for I/O
  36. 36. DMA Module Diagram
  37. 37. 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
  38. 38. 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
  39. 39. I/O Channels  The I/O module is enhanced to become a processor in its own right, with a specialized instruction set tailored for I/O.  The CPU directs the I/O processor to execute an I/O program in memory.  The I/O processor fetches and executes these instructions without CPU intervention.  This allows the CPU to specify a sequence of I/O activities and to be interrupted only when the entire sequence has been performed.  The I/O module has a local memory of its own and is, in fact, a computer in its own right.  With this architecture, a large set of I/O devices can be controlled, with minimal CPU involvement.
  40. 40. I/O Channels  I/O devices getting more sophisticated  e.g. 3D graphics cards  CPU instructs I/O controller to do transfer  I/O controller does entire transfer  Improves speed  Takes load off CPU  Dedicated processor is faster
  41. 41. I/O Channel Architecture
  42. 42. Interfacing  Connecting devices together  Bit of wire?  Dedicated processor/memory/buses?  E.g. FireWire, InfiniBand
  43. 43. IEEE 1394 FireWire  High performance serial bus  Fast  Low cost  Easy to implement  Also being used in digital cameras, VCRs and TV
  44. 44. 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
  45. 45. Simple FireWire Configuration
  46. 46. InfiniBand  I/O specification aimed at high end servers  Merger of Future I/O (Cisco, HP, Compaq, IBM) and Next Generation I/O (Intel)  Version 1 released early 2001  Architecture and spec. for data flow between processor and intelligent I/O devices  Intended to replace PCI in servers  Increased capacity, expandability, flexibility
  47. 47. InfiniBand Architecture  Remote storage, networking and connection between servers  Attach servers, remote storage, network devices to central fabric of switches and links  Greater server density  Scalable data centre  Independent nodes added as required  I/O distance from server up to  17m using copper  300m multimode fibre optic  10km single mode fibre  Up to 30Gbps
  48. 48. ANY QUESTIONS?