Bit-Slice Design: Controllers and ALUs

Refining the CCU

Last Edit November 2, 1996; May 1, 1999; July 7, 2001

In a microcomputer system there is a need to interface the main or central unit (microprocessor and/or control unit) to one or more external devices such as sensors, displays, control panels, keyboards or external memory. The main objective is to design the interface to minimize the effect of the interface activities on the system throughput or performance. Any contact with any external device will be considered as input/output handling or I/O.

Although there are many schemes for handling I/O requests, interrupts and queuing will be covered very lightly herein, principally as a means of alerting the designer to the existence of the problems. (The subject warrants its own seminar.) Only those schemes relevant to firmware design will be explored in any detail.

There are two very basic methods of I/O handling - status polling and interrupt servicing.

Status Polling

With status polling, the controlling unit must interrogate each peripheral to determine if it needs servicing by testing the status line of each peripheral, one at a time.

This might be by the elementary "Round Robin" approach, where the devices are tested in a set, circular sequence. Where different devices are to be handled on a priority basis, priority is accomplished by assigning high-priority devices to more than one location in the testing sequence. A high-priority device is tested with a higher polling frequency than the low-priority items.

Figure 4-1 Status polling microprogram flowchart

Problems

• One problem with status polling is that a device requesting service must wait for its turn even if all other devices are inactive.
• The controlling unit, a processor or a controller, must waste time testing inactive status lines; this reduces the possible system throughput.
• With the sequence test under microprogram control, a long microroutine is necessary, since each status test requires its own microinstruction.
• In terms of the requesting device, the system response is relatively slow.

When to Use or Not Use

The scheme is suitable if the frequency of service requests for each device is known with some degree of accuracy. This allows the polling frequency to be custom-tailored to the system. The service time, once a request for service is acknowledged, should be long compared to the estimated wait time.

It is not an advisable scheme where interfacing to a human is involved; that is, requests should be primarily I/O to hardware devices. (Human patience tends to decrease with exposure to computers; and has dropped from minutes (way back) to 30 sec (60's) to 1-3 sec. Look at the operating speeds of 1980's PCs (200-250MHz) compared to 16MHz systems, and the forecasted 500MHz systems (1998-9). Even children's game systems are at 64-bit computing speeds and climbing and these children will demand even faster response.

Or, watch someone trying to access the Internet during internet traffic jams. Humans want instant gratification. The normal phone connection came and went in and out of vogue in less than three years because it is not fast enough to keep up with the increasingly more demanding computer user.