Home     About

Principles of I/O Hardware

I/O Devices

I/O devices can be roughly divided into two categories: block devices and character devices.

• Block Devices
  It stores information in fixed-size blocks, each one with its own address. Common block sizes range from 512 to 65,536 bytes.
  Examples are hard disks, Blu-ray discs, and USB sticks.
• Character Device
  It delivers or accepts a stream of characters, without regard to any block structure. Not addressable and does not have any seek operation.
  Examples are printers, network interfaces, mice, and most other devices that are not disk-like can be seen as character devices.
• Doesn't Really Fit
  Some devices don't fit into this division: For instance, clocks aren't block addressable, nor do they accept character streams. All they do is cause interrupts... at timed intervals.
  Memory-mapped screens do not fit this division either.

Device Controllers

The electronic component of I/O units is called the device controller or adapter. Operating systems use device drivers to handle all I/O devices. There is a device controller and a device driver for each device to communicate with the operating system. A device controller may be able to handle multiple devices. As an interface its main task is to convert serial bit stream to block of bytes, and perform error correction as necessary.

• Cathode Ray Tube (CRT) Controller
  Older version of monitors that were bulky, power hungry and fragile!! CRT monitors fire a beam of electrons onto a fluorescent screen. Using magnetic fields, the system is able to bend the beam and draw pixels on the screen.
  The first "laptops" weighed about 12 kilos.
• LCD Controller
  This works as a bit serial device at low level. It reads bytes containing the characters to be displayed from memory and generates the signals to modify the polarization of the backlight for the corresponding pixels in order to write them on screen.
  The presence of the controller means that the OS programmer does not need to explicitly program the electrial field of the screen!

Memory-Mapped I/O

The controller has registers (similar to CPU registers, but for the device) and the OS can write these registers to "give orders" to the device (e.g., "shut down" or "accept data") or read its state (e.g., "are you busy tonight?").

CPU interaction with the control registers and device data buffers either through dedicated port allocation or using device memory to map them all. CPU can communicate with the control registers and the device data buffers in three ways.

• Seperate I/O and Memory Space: Each control register is assigned an I/O port number.
  We use special I/O instructions like:
  IN REG, PORT
  OUT PORT, REG
  IN and MOV are quite different instructions!
• Memory Mapped I/O: Same address space is shared by memory and I/O devices. The device is connected directly to certain main memory locations so that I/O device can transfer block of data to/from memory without going through CPU.
• Hybrid: Memory-mapped data buffers and separate I/O ports for the control registers. (Pentium)
• Strengths of MM I/O:
  • Special I/O instructions require the OS to resort to assembly code: IN and OUT cannot be executed in C or C++.
  • Memory-mapped I/O allows C to simply write to memory.
  • Control registers are mapped to memory as well.
• Weaknesses of MM I/O:
  • Memory-caching a device I/O register is disastrous.
    We never detect when the device has changed state!
    To fix this requires selective disabling of caching.
  • All memory modules and all devices must examine each memory reference to see if it is for them.
    If there is a high-speed memory bus (as is typical nowadays) then the I/O devices won't see the memory addresses on the high-speed bus.
    To fix this, we might send all requests to memory and see if they fail, then send them to I/O devices.
    Or, we can "snoop" on memory requests and send appropriate ones to I/O controllers. But they may be slow!
    Or we can assign some range of addresses as "not real" memory. But these would not to be assigned at boot time: no dynamic loading of devices!

Direct Memory Access

To reduce the overhead of interrupts, DMA hardware bypasses CPU to transfer data directly between I/O device and memory. DMA module itself controls exchange of data between main memory and the I/O device. CPU is only involved at the beginning and end of the transfer and interrupted only after entire block has been transferred, rather than a byte at a time.

Direct Memory Access Controller

DMA controller (DMAC) manages the data transfers and arbitrates access to the system bus. It contains several registers that can be written and read by the CPU. These include a memory address register, a byte count register, and one or more control registers.

Working of DMA

• First the CPU programs the DMA controller by setting its registers so it knows what to transfer where
• Alongside, DMAC issues a command to the disk controller telling it to read data from the disk into its internal buffer and verify the checksum. When valid data are in the disk controller's buffer, DMA can begin.
• The DMA controller initiates the transfer by issuing a read request over the bus to the disk controller
• The write to memory is another standard bus cycle
• When the write is complete, the disk controller sends an acknowledgement signal to the DMA controller, also over the bus
• The DMA controller then increments the memory address to use and decrements the byte count. If the byte count is still greater than 0, steps 2 through 4 are repeated until the count reaches 0. At that time, the DMA controller interrupts the CPU to let it know that the transfer is now complete.

DMA controllers vary considerably in their sophistication. The simplest ones handle one transfer at a time, whereas sophisticated DMAC have multiple sets of registers internally, one for each channel. Word transfer may be set up to use a round-robin algorithm, or it may have a priority scheme design to favor some devices over others. Many buses can operate in two modes: word-at-a-time mode and block mode. Some DMA controllers can also operate in either mode. In word-at-a-time mode, the DMA controller requests the transfer of one word and gets it. If the CPU also wants the bus, it has to wait. The mechanism is called cycle stealing because the device controller sneaks in and steals an occasional bus cycle from the CPU once in a while, delaying it slightly. In block mode, the DMA controller tells the device to acquire the bus, issue a series of transfers, then release the bus. This form of operation is called burst mode. It is more efficient than cycle stealing because acquiring the bus takes time and multiple words can be transferred for the price of one bus acquisition. The down side to burst mode is that it can block the CPU and other devices for a substantial period if a long burst is being transferred.

Interrupts Revisited

When an I/O device has finished the work given to it, it causes an interrupt by asserting a signal on a bus line that it has been assigned, signals that are detected by the interrupt controller chip. If no other interrupts pending, the interrupt controller processes the interrupt immediately. If another interrupt is in progress or there is a simultaneous request on a higher-priority interrupt request line which it continues to assert until serviced by the CPU. The controller puts a number on the address lines and asserts a signal that interrupts the CPU. This number is used as an index into a table called the interrupt vector to start a corresponding interrupt service procedure. The service procedure in certain moment acknowledges the interrupt by sending some value to some controller's port which enables the controller to issue other interrupts.

Precise and Imprecise Interrupts

An interrupt that leaves the machine in a well-defined state is called a precise interrupt (Walker and Cragon, 1995). Such an interrupt has four properties:

• The PC (Program Counter) is saved in a known place.
• All instructions before the one pointed to by the PC have completed.
• No instruction beyond the one pointed to by the PC has finished.
• The execution state of the instruction pointed to by the PC is known.

An interrupt that does not meet these requirements is called an imprecise interrupt and makes life most unpleasant for the operating system writer, who now has to figure out what has happened and what still has to happen.

Machines with imprecise interrupts typically vomit a large amount of internal state onto the stack to give the OS a chance to figure out what is up.

Imprecise interrupts allow more of the CPU real estate to be used for cache, etc., but make the OS more complex.