CS计算机代考程序代写 scheme Chapter 1

Chapter 1

Input/Output
CHAPTER 4

SSK3207 Chapter 1
Topics

4.1) I/O Unit/Module

4.2) External Devices

4.3) I/O Techniques

SSK3207 Chapter 1

Input and output operations are very important in a computer system. They enable the user to communicate with the computer.

These operations are performed using peripherals such disk drive, keyboard, mouse, printer, monitor etc.

Why need I/O Unit??
Every peripheral has different operation
The data format and word length in the peripheral also differs with the internals computer system.
The data transfer rate of peripherals is far slower compared to that of the main memory or the CPU.

I/O Unit is needed to coordinate the difference stated above.

*
4.1) Input/Output Unit/Module
SSK3207 Chapter 4

SSK3207 Chapter 4

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

SSK3207 Chapter 4

SSK3207 Chapter 4
SSK3207
*

SSK3207

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

SSK3207 Chapter 4

SSK3207 Chapter 4
SSK3207
*

SSK3207

Generic model of I/O Module

An external device attaches to the computer by a link to an I/O module.
The link is used to exchange control, status and data between the I/O module and the external device.

*
SSK3207 Chapter 4

SSK3207 Chapter 4

*

System bus lines
To buffer data
To accept detailed control information from the CPU
Interface with the device that it controls
I/O Module Diagram
SSK3207 Chapter 4

SSK3207 Chapter 4
SSK3207
*

SSK3207

I/O Modules
Module Function

SSK3207
*
The major functions or requirements for an I/O module fall into the following
categories:

• Control and timing

• Processor communication

• Device communication

• Data buffering

• Error detection

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:

1. The processor interrogates the I/O module to check the status of the attached
device.

2. The I/O module returns the device status.

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

4. The I/O module obtains a unit of data (e.g., 8 or 16 bits) from the external device.

5. The data are transferred from the I/O module to the processor.

If the system employs a bus, then each of the interactions between the processor
and the I/O module involves one or more bus arbitrations.

The preceding simplified scenario also illustrates that the I/O module must
communicate with the processor and with the external device. Processor communication
involves the following:

• 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. The latter two commands
each include a parameter that is sent on the data bus.

• Data: Data are exchanged between the processor and the I/O module over the
data bus.

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

On the other side, the I/O module must be able to perform device communication.
This communication involves commands, status information, and data
(Figure 7.2).

An essential task of an I/O module is data buffering. The need for this function
is apparent from Figure 2.11. 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.

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. A simple example is the use of a parity bit on each
character of data. For example, the IRA character code occupies 7 bits of a byte.
The eighth bit is set so that the total number of 1s in the byte is even (even parity)
or odd (odd parity). When a byte is received, the I/O module checks the parity to
determine whether an error has occurred.

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.

SSK3207 Chapter 4

SSK3207 Chapter 4
SSK3207
*

SSK3207

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

SSK3207 Chapter 4

SSK3207 Chapter 4
SSK3207
*

SSK3207

Connected to the computer system through I/O unit
Can broadly classify into three categories:
Human readable
Suitable for communicating with the computer user
Example: VDT, printer etc.
Machine readable
Suitable for communicating with equipment
Example: disk drive, tape drive, sensor etc.
Communication
Suitable for communicating with remote devices such as terminal, a machine readable device or another computer
Example: modem, NIC etc.

*
4.2) External Devices
SSK3207 Chapter 4

SSK3207 Chapter 4

Based on usage, peripherals can be divided into:
1. Input Device
Devices used to accept input only
Example: keyboard, mouse etc

2. Output Device
Devices used only to provide output
Example: printer, VDT etc

3. Input and Output Devices
Can be used to accept input and provide output
Example: touch screen, disk drive etc

*
SSK3207 Chapter 4

SSK3207 Chapter 4

*
Determine the function that the device will perform (e.g., send data, accept data)
Indicate the state of the device
Data (in a form of a set of bits) to be sent to or received
controls the device’s operation in response to direction from I/0 module
Converts data from electrical to other forms of energy (output) or from other forms to electrical (input)
Temporarily hold data being transferred between the I/O module and external environment
External Device Block Diagram
SSK3207 Chapter 4

SSK3207 Chapter 4

+

Keyboard/Monitor
Basic unit of exchange is the character
Associated with each character is a code
Each character in this code is represented by a unique 7-bit binary code
128 different characters can be represented
Characters are of two types:
Printable
Alphabetic, numeric, and special characters that can be printed on paper or displayed on a screen
Control
Have to do with controlling the printing or displaying of characters
Example is carriage return
Other control characters are concerned with communications procedures

When the user depresses a key it generates an electronic signal that is interpreted by the transducer in the keyboard and translated into the bit pattern of the corresponding IRA code
This bit pattern is transmitted to the I/O module in the computer
On output, IRA code characters are transmitted to an external device from the I/O module
The transducer interprets the code and sends the required electronic signals to the output device either to display the indicated character or perform the requested control function

International Reference Alphabet (IRA)
Keyboard Codes
Most common means of computer/user interaction
User provides input through the keyboard
The monitor displays data provided by the computer

SSK3207
*
The most common means of computer/user interaction is a keyboard/monitor
arrangement. The user provides input through the keyboard. This input is then
transmitted to the computer and may also be displayed on the monitor. In addition,
the monitor displays data provided by the computer.

The basic unit of exchange is the character. Associated with each character
is a code, typically 7 or 8 bits in length. The most commonly used text code is the
International Reference Alphabet (IRA). Each character in this code is represented
by a unique 7-bit binary code; thus, 128 different characters can be represented.
Characters are of two types: printable and control. Printable characters are
the alphabetic, numeric, and special characters that can be printed on paper or displayed
on a screen. Some of the control characters have to do with controlling the
printing or displaying of characters; an example is carriage return. Other control
characters are concerned with communications procedures. See Appendix F for
details.

For keyboard input, when the user depresses a key, this generates an
electronic signal that is interpreted by the transducer in the keyboard and
translated into the bit pattern of the corresponding IRA code. This bit pattern
is then transmitted to the I/O module in the computer. At the computer, the
text can be stored in the same IRA code. On output, IRA code characters are
transmitted to an external device from the I/O module. The transducer at the
device interprets this code and sends the required electronic signals to the output
device either to display the indicated character or perform the requested
control function.

Typical I/O Data Rates
SSK3207 Chapter 4

SSK3207 Chapter 4

I/O Operations – the operation of inserting or extracting data to/from the computer system
I/O Techniques refers to how I/O operations are executed.
There are 3 ways to perform the I/O operations (I/O Techniques):
Programmed I/O
Interrupt-Driven I/O
Direct Memory Access (DMA)

*
4.3) I/O Techniques
SSK3207 Chapter 4

SSK3207 Chapter 4

+

I/O Techniques

SSK3207
Table 7.1 indicates the relationship among these three techniques. In this section,
we explore programmed I/O. Interrupt I/O and DMA are explored in the following
two sections, respectively.

*

What is INTERRUPT???
In systems programming, an interrupt is a signal to the processor emitted by hardware or software indicating an event that needs immediate attention. An interrupt alerts the processor to a high-priority condition requiring the interruption of the current code the processor is executing (the current thread)
The processor responds by suspending its current activities, saving its state, and executing a small program called an interrupt handler (or interrupt service routine, ISR) to deal with the event. This interruption is temporary, and after the interrupt handler finishes, the processor resumes execution of the previous thread.

+

I/O Commands
There are four types of I/O commands that an I/O module may receive when it is addressed by a processor:

Control
– used to activate a peripheral and tell it what to do
Test
– used to test various status conditions associated with an I/O module and its peripherals
Read
– causes the I/O module to obtain an item of data from the peripheral and place it in an internal buffer
Write
– causes the I/O module to take an item of data from the data bus and subsequently transmit that data item to the peripheral

SSK3207
*
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:

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

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

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

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

Three
Techniques
for Input of a
Block of Data

SSK3207
Figure 7.4a gives an example of the use of programmed I/O to read in a block of
data from a peripheral device (e.g., a record from tape) into memory. Data are read
in one word (e.g., 16 bits) at a time. For each word that is read in, the processor must
remain in a status-checking cycle until it determines that the word is available in the
I/O module’s data register. This flowchart highlights the main disadvantage of this
technique: it is a time-consuming process that keeps the processor busy needlessly.
*

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

SSK3207 Chapter 4

SSK3207 Chapter 4
SSK3207
*

SSK3207

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

SSK3207 Chapter 4

SSK3207 Chapter 4
SSK3207
*

SSK3207

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
when CPU issues a command to the I/O module, it must wait until the I/O operation is complete

*
SSK3207 Chapter 4
Programmed I/O

Forward the read instruction to the I/O Module
Read the I/O Module status
Check Status

Read word from I/O Module
Write word to memory
Done ?

CPU

Memory
CPU

I/O
I/O

CPU
I/O

CPU
Not
ready
No
Error Situation
Ready
Yes
Next Instruction

SSK3207 Chapter 4

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

SSK3207 Chapter 4

SSK3207 Chapter 4
SSK3207
*

SSK3207

2. Interrupt Driven I/O
Overcomes CPU waiting
No repeated CPU checking of device
I/O module interrupts when ready

SSK3207 Chapter 4

SSK3207 Chapter 4
SSK3207
*

SSK3207

Interrupt-Driven I/O

SSK3207
*
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.

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.

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.

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

Figure 7.4b shows the use of interrupt I/O for reading in a block of data.
Compare this with Figure 7.4a. Interrupt I/O is more efficient than programmed I/O
because it eliminates needless waiting. However, interrupt I/O still consumes a lot of
processor time, because every word of data that goes from memory to I/O module
or from I/O module to memory must pass through the processor.

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

SSK3207 Chapter 4

SSK3207 Chapter 4
SSK3207
*

SSK3207

Overcomes CPU waiting
No repeated CPU checking of device
I/O module interrupts when ready
The CPU issues an I/O command, continues to execute other instructions, and interrupted by the I/O module when the latter has completed

*
SSK3207 Chapter 4
Interrupt Driven I/O
CPU

Memory
CPU

I/O
I/O

CPU
I/O

CPU

Perform other tasks
Interrupt

Yes
Next Instruction

Forward the read instruction to the I/O Module
Read I/O Module status
Check Status

Read word from I/O Module
Write word into memory
Done ?

No
Error Situation
Ready

SSK3207 Chapter 4

CPU Viewpoint
Issue read command
Do other work
Check for interrupt at the end of each instruction cycle
If interrupted:-
Save context (e.g., program counter, registers) of current program
Process interrupt
Fetch data & store

(See Operating Systems notes)
SSK3207 Chapter 4

SSK3207 Chapter 4
SSK3207
*

SSK3207

Design Issues

SSK3207
*
Two design issues arise in implementing interrupt I/O. First, because there will
almost invariably be multiple I/O modules, how does the processor determine which
device issued the interrupt? And second, if multiple interrupts have occurred, how
does the processor decide which one to process?

+

Intel
82C59A
Interrupt
Controller

SSK3207
*
The Intel 80386 provides a single Interrupt Request (INTR) and a single Interrupt
Acknowledge (INTA) line. To allow the 80386 to handle a variety of devices and priority
structures, it is usually configured with an external interrupt arbiter, the 82C59A.
External devices are connected to the 82C59A, which in turn connects to the 80386.

Figure 7.8 shows the use of the 82C59A to connect multiple I/O modules for the
80386. A single 82C59A can handle up to eight modules. If control for more than eight
modules is required, a cascade arrangement can be used to handle up to 64 modules.

The 82C59A’s sole responsibility is the management of interrupts. It accepts
interrupt requests from attached modules, determines which interrupt has the highest
priority, and then signals the processor by raising the INTR line. The processor
acknowledges via the INTA line. This prompts the 82C59A to place the appropriate
vector information on the data bus. The processor can then proceed to process the
interrupt and to communicate directly with the I/O module to read or write data.

The 82C59A is programmable. The 80386 determines the priority scheme to
be used by setting a control word in the 82C59A. The following interrupt modes are
possible:

• Fully nested: The interrupt requests are ordered in priority from 0 (IR0)
through 7 (IR7).

Rotating: In some applications a number of interrupting devices are of equal
priority. In this mode a device, after being serviced, receives the lowest priority
in the group.

• Special mask: This allows the processor to inhibit interrupts from certain devices.

+

Intel 82C55A
Programmable Peripheral Interface

SSK3207
As an example of an I/O module used for programmed I/O and interrupt-driven I/O,
we consider the Intel 82C55A Programmable Peripheral Interface. The 82C55A is
a single-chip, general-purpose I/O module designed for use with the Intel 80386
processor. Figure 7.9 shows a general block diagram plus the pin assignment for the
40-pin package in which it is housed.

The right side of the block diagram is the external interface of the 82C55A.
The 24 I/O lines are programmable by the 80386 by means of the control register.
The 80386 can set the value of the control register to specify a variety of operating
modes and configurations. The 24 lines are divided into three 8-bit groups (A, B, C).
Each group can function as an 8-bit I/O port. In addition, group C is subdivided into
4-bit groups (CA and CB), which may be used in conjunction with the A and B I/O
ports. Configured in this manner, group C lines carry control and status signals.

The left side of the block diagram is the internal interface to the 80386 bus. It
includes an 8-bit bidirectional data bus (D0 through D7), used to transfer data to
and from the I/O ports and to transfer control information to the control register.
The two address lines specify one of the three I/O ports or the control register.
A transfer takes place when the CHIP SELECT line is enabled together with either
the READ or WRITE line. The RESET line is used to initialize the module.

The control register is loaded by the processor to control the mode of operation
and to define signals, if any. In Mode 0 operation, the three groups of eight external
lines function as three 8-bit I/O ports. Each port can be designated as input or
output. Otherwise, groups A and B function as I/O ports, and the lines of group C
serve as control lines for A and B. The control signals serve two principal purposes:
“handshaking” and interrupt request. Handshaking is a simple timing mechanism.
One control line is used by the sender as a DATA READY line, to indicate when
the data are present on the I/O data lines. Another line is used by the receiver as an
ACKNOWLEDGE, indicating that the data have been read and the data lines may
be cleared. Another line may be designated as an INTERRUPT REQUEST line and
tied back to the system bus.
*

+

Keyboard/Display Interfaces to 82C55A

SSK3207
Because the 82C55A is programmable via the control register, it can be used to
control a variety of simple peripheral devices. Figure 7.10 illustrates its use to control
a keyboard/display terminal. The keyboard provides 8 bits of input. Two of these
bits, SHIFT and CONTROL, have special meaning to the keyboard-handling program
executing in the processor. However, this interpretation is transparent to the
82C55A, which simply accepts the 8 bits of data and presents them on the system
data bus. Two handshaking control lines are provided for use with the keyboard.

The display is also linked by an 8-bit data port. Again, two of the bits have special
meanings that are transparent to the 82C55A. In addition to two handshaking
lines, two lines provide additional control functions.
*

+

Drawbacks of Programmed and Interrupt-Driven I/O
Both forms of I/O suffer from two inherent drawbacks:

The I/O transfer rate is limited by the speed with which the processor can test and service a device
The processor is tied up in managing an I/O transfer; a number of instructions must be executed for each I/O transfer

When large volumes of data are to be moved a more efficient technique is direct memory access (DMA)

SSK3207
*
Interrupt-driven I/O, though more efficient than simple programmed I/O, still
requires the active intervention of the processor to transfer data between memory
and an I/O module, and any data transfer must traverse a path through the processor.
Thus, both these forms of I/O suffer from two inherent drawbacks:

1. The I/O transfer rate is limited by the speed with which the processor can test
and service a device.

2. The processor is tied up in managing an I/O transfer; a number of instructions
must be executed for each I/O transfer (e.g., Figure 7.5).

There is somewhat of a trade-off between these two drawbacks. Consider the
transfer of a block of data. Using simple programmed I/O, the processor is dedicated
to the task of I/O and can move data at a rather high rate, at the cost of doing
nothing else. Interrupt I/O frees up the processor to some extent at the expense of
the I/O transfer rate. Nevertheless, both methods have an adverse impact on both
processor activity and I/O transfer rate.

When large volumes of data are to be moved, a more efficient technique is
required: direct memory access (DMA).

3. Direct Memory Access (DMA)
Interrupt driven and programmed I/O require active CPU intervention
Transfer rate is limited
CPU is tied up
DMA is the answer

SSK3207 Chapter 4

SSK3207 Chapter 4
SSK3207
*

SSK3207

DMA Function
Involves an additional module (hardware) on system bus
DMA has ability of mimicking the CPU
DMA controller takes over from CPU for I/O

SSK3207 Chapter 4

SSK3207 Chapter 4
SSK3207
*

SSK3207

DMA Module Diagram
SSK3207 Chapter 4

SSK3207 Chapter 4

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

SSK3207 Chapter 4

SSK3207 Chapter 4
SSK3207
*

SSK3207

Interrupt driven and programmed I/O require active CPU intervention
Transfer rate is limited
CPU is tied up
DMA is the answer …
Additional Module (hardware) on bus
DMA controller takes over from CPU for I/O
The I/O module and main memory exchange data directly, without CPU involvement

*
SSK3207 Chapter 4
Direct Memory Access (DMA)
DMA
CPU

DMA
CPU

Perform other tasks

Interrupt
Forward the read instruction to the I/O Module
Read DMA module status

Next Instruction

SSK3207 Chapter 4

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

SSK3207 Chapter 4

SSK3207 Chapter 4
SSK3207
*

SSK3207

+

DMA Operation
DMA
DMA

SSK3207
*
Figure 7.12 shows where in the instruction cycle the processor may be suspended.
In each case, the processor is suspended just before it needs to use the bus.
The DMA module then transfers one word and returns control to the processor.
Note that this is not an interrupt; the processor does not save a context and do
something else. Rather, the processor pauses for one bus cycle. The overall effect
is to cause the processor to execute more slowly. Nevertheless, for a multiple-word
I/O transfer, DMA is far more efficient than interrupt-driven or programmed I/O.

+

Alternative
DMA
Configurations

SSK3207
*
The DMA mechanism can be configured in a variety of ways. Some possibilities
are shown in Figure 7.13. In the first example, all modules share the same system
bus. The DMA module, acting as a surrogate processor, uses programmed I/O to
exchange data between memory and an I/O module through the DMA module. This
configuration, while it may be inexpensive, is clearly inefficient. As with processor controlled
programmed I/O, each transfer of a word consumes two bus cycles.

The number of required bus cycles can be cut substantially by integrating the
DMA and I/O functions. As Figure 7.13b indicates, this means that there is a path
between the DMA module and one or more I/O modules that does not include the
system bus. The DMA logic may actually be a part of an I/O module, or it may be a
separate module that controls one or more I/O modules. This concept can be taken
one step further by connecting I/O modules to the DMA module using an I/O bus
(Figure 7.13c). This reduces the number of I/O interfaces in the DMA module to one
and provides for an easily expandable configuration. In both of these cases (Figures
7.13b and c), the system bus that the DMA module shares with the processor and
memory is used by the DMA module only to exchange data with memory. The
exchange of data between the DMA and I/O modules takes place off the system
bus.

8237 DMA Usage of System Bus

SSK3207
The Intel 8237A DMA controller interfaces to the 80 x 86 family of processors and
to DRAM memory to provide a DMA capability. Figure 7.14 indicates the location
of the DMA module. When the DMA module needs to use the system buses (data,
address, and control) to transfer data, it sends a signal called HOLD to the processor.
The processor responds with the HLDA (hold acknowledge) signal, indicating
that the DMA module can use the buses. For example, if the DMA module is to
transfer a block of data from memory to disk, it will do the following:

1. The peripheral device (such as the disk controller) will request the service of
DMA by pulling DREQ (DMA request) high.

2. The DMA will put a high on its HRQ (hold request), signaling the CPU
through its HOLD pin that it needs to use the buses.

3.The CPU will finish the present bus cycle (not necessarily the present instruction)
and respond to the DMA request by putting high on its HDLA (hold
acknowledge), thus telling the 8237 DMA that it can go ahead and use the
buses to perform its task. HOLD must remain active high as long as DMA is
performing its task.

4. DMA will activate DACK (DMA acknowledge), which tells the peripheral
device that it will start to transfer the data.

5. DMA starts to transfer the data from memory to peripheral by putting the
address of the first byte of the block on the address bus and activating MEMR,
thereby reading the byte from memory into the data bus; it then activates IOW
to write it to the peripheral. Then DMA decrements the counter and increments
the address pointer and repeats this process until the count reaches zero
and the task is finished.

6. After the DMA has finished its job it will deactivate HRQ, signaling the CPU
that it can regain control over its buses.
*

+

Evolution of the I/O Function
The CPU directly controls a peripheral device.
A controller or I/O module is added. The CPU uses programmed I/O without interrupts.
Same configuration as in step 2 is used, but now interrupts are employed. The CPU need not spend time waiting for an I/O operation to be performed, thus increasing efficiency.
The I/O module is given direct access to memory via DMA. It can now move a block of data to or from memory without involving the CPU, except at the beginning and end of the transfer.
The I/O module is enhanced to become a processor in its own right, with a specialized instruction set tailored for I/O
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.

SSK3207
*
As computer systems have evolved, there has been a pattern of increasing complexity
and sophistication of individual components. Nowhere is this more evident than
in the I/O function. We have already seen part of that evolution. The evolutionary
steps can be summarized as follows:

1. The CPU directly controls a peripheral device. This is seen in simple microprocessor-
controlled devices.

2. A controller or I/O module is added. The CPU uses programmed I/O without
interrupts. With this step, the CPU becomes somewhat divorced from the specific
details of external device interfaces.

3. The same configuration as in step 2 is used, but now interrupts are employed.
The CPU need not spend time waiting for an I/O operation to be performed,
thus increasing efficiency.

4. The I/O module is given direct access to memory via DMA. It can now move
a block of data to or from memory without involving the CPU, except at the
beginning and end of the transfer.

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

6. 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. A common use for such an
architecture has been to control communication with interactive terminals.
The I/O processor takes care of most of the tasks involved in controlling the
terminals.

As one proceeds along this evolutionary path, more and more of the I/O
function is performed without CPU involvement. The CPU is increasingly
relieved of I/O-related tasks, improving performance. With the last two steps
(5–6), a major change occurs with the introduction of the concept of an I/O module
capable of executing a program. For step 5, the I/O module is often referred
to as an I/O channel. For step 6, the term I/O processor is often used. However,
both terms are on occasion applied to both situations. In what follows, we will use
the term I/O channel.

+

Parallel
and
Serial
I/O

SSK3207
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. 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.
*