Rask PZR-660nng nn

JPmoorIbale LagnkKen RothmullerHewlett-Packard

(C__Z stems

Introduction Design Methodology

The advent of low-cost microcomputer chip sets ishaving a dramatic impact on the direction of digitaldesign. Except for very cost-sensitive products, mostnew designs are constiucted utilizing programmablelogic to replace more conventional random logicdesigns. The premise of this new logic form is basedon the cost savings exhibited by solutions consistingof a small number of different LSI parts over thosewith many SSI/MSI parts performing the samefunctions. Low LSI parts costs are achieved by pro-ducing functions (e.g., RAM, ROM, processor, andI/O parts) with general utility so that each chipcan be manufactured in very high volume. Logicfunctions are realized by specifying a set of step-by-step instructions which are executed sequentially bythe processor.This paper will concentrate on applications which

use microcomputers to replace random logic de-signs rather than applications which use microcom-puters as low-cost minicomputer replacements.

January 1976

There is a broad spectrum of programmable logicdesign philosophy which ranges from minimum ex-ternal circuitry with all functions implemented infirmware to extremely intelligent I/O functions anddistributed processing in hardware. This paper willfocus on the former strategy because it accentuatesthe programmable logic design problems, and it isconceivable that microcomputer-based distributedprocessing systems of the future will use this firm-ware-oriented strategy. Supplementary hardwarewould be added to firmware-centered design onlywhen performance specifications cannot be met orwhen additional parts are significantly cheaper thantheir firmware equivalents.

Designing firmware-centered, microcomputer-based products begins with the identification of allunprocessed I/O signals and the minimum hard-ware necessary to bring the signals into and out ofthe microprocessor. In most cases the interfacing

19

hardware consists of level converters, voltage tocurrent converters, signal conditioning and protec-tion, and physical transducers. All other functionsare implemented via firmware.

Many of these firmware functions exhibit the samebasic structure. They are cyclic, event-driven taskswhich are time-independent of one another. Someloose cooperation exists between tasks in the formof a producer/consumer data relationship or eventwaitlevent cause synchronizations. It is no surprisethat the firmware functions exhibit these attributessince they are simulating the hardware functionswhich would be implemented as independent, parallelexecuting subsystems.As the design and implementation progress, more

details will be learned about the performanceparameters of the evolving product. Supplementaryhardware may have to be added to increase perform-ance or to decrease cost of some particular firm-ware function which is exceptionally complicatedand costly compared to its hardware equivalent. Itis possible that some product functions must berevised or eliminated altogether to achieve an afford-able product'.

Benefits of Firmware-Centered Designs

The primary outcome of a firmware-centered designis a minmimum parts count solution with all of thesystem's logic residing in the processor's read-onlymemory. This translates into a very low-cost buthighly complex digital system. Using today's ROMprices, it is possible to simulate the effect of a 1000-gate equivalent random logic circuit for under $5using programmable logic (assuming reduced per-formance is adequate).Because all the logic is present in one form, it is

simpler to make modifications and enhancements toa firmware-centered design (assuming I/O interfacesdo not change). It is possible to make very grosschanges to a system without ever having to lay outa new PC board or backplane.

A manufacturer who must support a wide productline which uses firmware-centered microprocessordesigns will find a large amount of subsystem com-monality between each different product. The pro-cessor and memory elements could be identical.Only the ROMs which are inserted into memoryboards, minimum interfacing logic, and possibly thefront panels need be different.

Finally, there are subtle advantages which resultfrom a low parts count product. Small product sizecan impact a number of cost factors, including fewermetal/plastic enclosures, simpler PC boards, andlower labor content. Power supply requirements,which can be a significant part of the total productcost, can be reduced. Repair and inventory costs canalso be affected by a product's parts count.

Design ProblemsIf there are benefits to be gained, then there must

also be a corresponding set of difficult designproblems to be solved and penalties to be paid forthe firmware-centered design approach. Three po-tential problem areas exist: sequentializing hardwarealgorithms, sharing one processor among severalsemi-independent tasks, and processor load distri-bution. These areas are interrelated and can share acommon solution. But before possible solutions arepresented, a more detailed understanding of theproblems is necessary.

Some hardware functions which are translatedinto firmware can take one or more orders of magni-tude longer to execute when the first-pass algorithmsare tried. Study, refinement, and innovation can oftenturn these first design attempts into tuned solutionswhich exhibit execution times more in line with otherfunctions in the system. This problem may be com-pounded for hardware designers who find it difficultto make the translation between their random,parallel-executed logic designs to more structured,sequentially-executed versions. It' is possible thathardware designers have grown used to the conceptof higher-level building block functions offeredtoday (e.g., multiplexers, comparators, and UARTS)which have no equivalents in programming (otherthan what the programmer creates). In a sense, pro-gramming at the assembly language level is likebuilding a complete large-scale digital system out ofNAND gates!

Although complete hardware subsystems (e.g.,keyboard'scanners, display update and refresh, andtimers) are being brought into firmware, there stillis a need to maintain their independence to preservetheir funcbion. To simulate these functions previouslyimplemented with hardwired logic "processors"which allowed them to execute in total parallelism,a similar structure must be developed in firmware.These semi-independent tasks must execute in "ap-parent" parallelism, integrated over some relativeperiod of time. A processor multiplexing schemewill satisfy this need.

When it is determined that a single processor isbeing overburdened with functions to be performed,a processor load distribution mechanism must beavailable. This mechanism must permit functions tobe moved outside of the processor to hardware or toanother processor, or it must permit the resource de-mands placed on the system to be redistributed overtime to eliminate task bunching.The key to a good load distribution mechanism is

that it should have little or no impact on other partsof the system-which remain intact executing on thesingle processor. Ideally, even those functions whichinterfaced with the distributed task should not beaffected.

All three of the potential problem areas can beattacked using techniques developed in the 1960'sfor constructing multitasking systems on largerscale computing systems.

COMPUTER20

Software Framework forMultitasking Systems

A number of minicomputers (and larger systems)offer multitasking facilities within larger operatingsystem frameworks and some in the form of a self-contained, stand-alone facility. These system func-tions permit several semi-independent tasks to sharea single processor through a multiplexing schemewhich executes each task for a short period of time(or until a wait-synchronization point is reached)in a repetitive first-come, first-serve or priority queuestructure. Over a period of time it appears as if tasksare executing in parallel. These systems have foundwide utilization in process control, monitoring, anddata collection applications over the last 10 years.Larger computer systems have employed even

more complicated structures and algorithms to createmultiprogramming environments where several in-dependent programs are automatically scheduledand share the CPU, again in a multiplexed fashion.Both multitasking and multiprogramming attempt

to maximize the utilization of the CPU so that it isalways kept busy. This is exactly the same require-ment for a firmware-centered microcomputer, but fora slightly different reason: the greater the CPU utili-zation, the more functions which can be performedin firmware (and the less external hardware required).

If multitasking concepts could be applied to micro-processor based systems, several benefits could berealized, including the following:

Simplified Design. Once the framework existsfor sharing the processor and synchronizing taskswith internal and external events, the design andconstruction of each individual task are a simplematter of creating a sequentially executed (gen-erally cyclic) program which presumes it has itsown processor to execute on.

Easy Addition of Tasks. As systems are expanded,new tasks can be added without affecting or modi-fying existing tasks (as long as worst case resourcedemands are still within the processor band-width).

Ability to Distribute Tasks. When the processorbandwidth is surpassed, one or more tasks can beremoved and placed in a separate processor (orin hardware) which would occasionally communi-cate with the first processor for data transfersand synchronization purposes.

These advantages can only be realized if themultitasking structure is strictly adhered to and noshortcuts or pathological connections exist betweentasks. Clean and simple interfaces will lead to amaintainable and modifiable system. If these guide-lines are not followed, single task changes will ripplethroughout the system.Assuming multitasking facilities which exist on

larger computing systems theoretically satisfy theproblems posed in firmware-centered designs, canthey be scaled down and form the framework for a

January 1976

programmable logic system? Although it is diffi-cult to generalize across all microprocessor applica:tions, there appear to be some differences and diffi-culties with multitasking structures in microcom-puter-based systems:

Small Firmware Programs (- 4-6K). By compari-son with the application firmware, a large set offunctions to implement a generalized multitaskingstructure could be prohibitive in ROM costs.

High-Speed Task Cycle Requirements (1 to 20 MS).Task state saving and restoring could severelylimit the number of tasks which can be multiplexedtogether on one processor.

Critical Task Response Requirements. Because ofthe limited external circuitry, it may be necessaryto service external hardware quickly to ensuredata capture.

Unusual Task Phase Relationships. Two or moretasks may be tightly coupled and must be inter-leaved and correctly phased with each other'sexecution.

More Complex, Programmed Device Communi-cation. Servicing a device may require severalactivations of a task at different points in thealgorithm to achieve a complete function, whereasa minicomputer has a more intelligent, hard-wired peripheral interface.

The subsequent sections of this paper will outlinesome practical multitasking techniques using cur-rent microprocessor architectures and suggest somearchitectural modifications to correct the difficultiesand make multitasking a more viable design ap-proach in the future.

Applying Multitasking to Microprocessors

The problems to be overcome in a multitaskingstructure for programmable logic systems can bereduced to three design objectives: small-sized utilityfunctions, high performance (i.e., low overhead com-pared to application task times), incremental taskexecution, and task-in-control processor schedulingpolicy.Small size and high performance multitasking

functions to implement virtual processors for eachtask can reinforce one another. A small set ofsimple, general-purpose utilities which can assumecooperating tasks (thereby minimizing the amountof error checking and reporting) can satisfy thesefirst two objectives.Each task must be permitted to execute incremen-

tally with delays inserted for internal and externalsynchronization messages. In addition, tasks maychoose to pass control to other tasks when they arein non-time-critical sections. This incremental execu-tion of each task is the basis for task interleavingon a single processor.

21

To illustrate these multitasking concepts as theycould apply to programmable logic, a simple frame-work will be illustrated. Each task in the systemwill be in one of three states: WAIT (waiting for aninternal or external event to occur), READY (readyto execute when the processor becomes available),

Receiv (mesaSend (message)WAIT -)

\ vt S~ave task

Recelive (message)/\\A etmessage unavailable task i

\ t ~~~state

Receive (message) A EXECUTE

message available

(1)

(2) Share or

Share (task j)

Notes: (1) Initially, all tasks are placed in the READY state by apower-on utilization routine.

(2) Task is placed at a lower priority than other READYtasks.

Figure 1. State diagram for a single task "i"

or EXECUTE (currently the active task which theprocessor is executing). At any point in time, onlyone task can be in the EXECUTE state, and severaltasks can occupy the WAIT and READY states.Figure 1 illustrates the state diagram for a singletask and the possible state transitions.Once a task enters the EXECUTE state it can

exit only when it invokes a receive [message]function and no message is available, or it relin-quishes contrql via the share mechanism, permittingother tasks in the READY state to gain accessto the processor.The receive function is a synchronization primi-

tive which examines whether or not an internal orexternal event (in the form of a message) has oc-curred. Execution continues if the event has hap-pened; otherwise the task is placed in the WAITstate until an executing task invokes a corres-ponding send function or an external piece of hard-ware signals the event.The share feature allows an active task to grant

processor time to a particular task (share [task j )or to any task in the READY state (share). Ifthere are no tasks in the READY state when shareis invoked, control will immediately pass back to thecurrently active task. With this mechanism, taskscan execute in a co-routine fashion as illustratedin Figure 2.

22

7OPROGRA

Share (B)

Share (B)

ASK AM SEQUENCE

TASK BPROGRAM SEQUENCE

Sh

Sh

iare (A)

iare (A)

Figure 2. Share mechanism for co-routine structures

COMPUTER

This framework is simple and structured, pro-ducing controlled and predictable transitionsbetween states. Most microcomputers have someform of interrupt structure which can significantlycomplicate the nature of multitasking functionsdue to their random and task-uncontrollable attri-butes. Figure 3 illustrates the complicationsintroduced by an interrupt system to the basicstate diagram. By only responding to interruptswhen the multitasking dispatcher is examining theREADY queue, orderly execution can be broughtback to the systems. If it is not possible to use thisapproach because of system response time require-ments, it will be necessary to add mechanisms toservice interrupts and provide system interlocks toprevent common data pools from being improperlyinterpreted or modified. The problems associatedwith interrupts have led some individuals to advo-cate their replacement with more appropriate andsoftware-integrated techniques.The multitasking facilities provided should only

implement the tools for sharing the processor andsynchronizing tasks with internial and externalevents. Processor scheduling policy should be set bythe tasks themselves. Once control passes to a task(i.e., it receives the processor resource), it remainsthere until the task chooses to relinquish it to aspecific task or any task which is waiting for pro-cessor time. This permits individuai tasks to createonly as complex a scheduling strategy as is necessaryfor the application. Several side benefits are associ-ated with this approach of executing a task untilit suspends itself, including task selection at appro-priate points in the algorithm which exhibit a mini-mum amount of state information to be saved;guaranteed processor access, which eliminates theneed for mutual exclusion mechanisms; and rationaltask algorithm execution periods, to reduce statesaving and restoring overhead functions.

A multitasking framework of the complexity de-scribed can be implemented on most microcom-puters in 300 to 400 bytes of firmware. Modifyingcurrent architectures could reduce the amount offirmware required and significantly increase the per-formance.

Future Directions

To enhance and make the firmware-centered pro-grammable-logic concept even more cost effective,there are several potentially fruitful avenues whichcould be explored to improve on today's microcom-puters. Four areas will be considered: low-cost auxil-iary processors, improved inter-processor and pro-cessor/device synchronization mechanisms, hard-wired multitasking primitives, and alternate archi-tectures for random logic replacement applications.

ACTIVE TASK i

Interrupt causes executingtask to move to READY.

WAITING TASK i

,/

restorestate

Interrupt signals a specificwaiting task to move directlyto EXECUTE (bypassing READY).

Figure 3. Interrupt overlay on task state diagram

January 1976 23

Illinois State

WI

IEEE COMPUTER SOCIETY

University, Bloomington, IllinoisJune 14-16, 1976

The primary objective of the workshop is tobring together small college teachers of com-puter science and computer engineering to con-duct working sessions on ways in which theforthcoming model curricula materials can beimplemented and at the same time groundworkfor possible implementations might be laid. Theworkshop is being sponsored by the IEEE Com-puter Society and the Society's Education Com-mittee. Main topics to be covered in the work-shop and the speakers are: Digital Logic, Dr.Michael C. Mulder; Computer Organization,Dr. Oscar Garcia, Dr. Michael C. Mulder; Oper-ating Systems, Dr. David Pessel; Data Manage-ment, Dr. Sakti P. Ghosh; Theory of Computing,Dr. George Davida; Curricula Overviews, Dr.David Rine.

Short papers for presentation are being solicit-ed. Preference will be given to the followingtopics:

1. Computer science and/or computer engineering curriculain undergraduate colleges.

2. Special techniques for implementing computer scienceand/or computer engineering curricula in undergraduatecolleges.

3. Laboratory and projects manuals used in undergraduatecomputer science and/or computer engineering programs.

4. Demonstration of logic and microcomputer laboratorymaterials or equipment.

5. Analyses of curricula materials.6. Special undergraduate teaching techniques of courses

within the following areas:

Programming LanguagesAdvanced ProgrammingOperating SystemsData Base and File HandlingData StructuresData CommunicationComputer Organization

Digital LogicTheory of ComputingMicroprocessorsMicroprogrammingPerformance EvaluationArtificial Intelligence

Those persons wishing to make presentationsshould send two copies of a 3-10 page summary,double-spaced typing to Professor David C.Rine, West Virginia University, Morgantown,West Virginia 26506 before April 1, 1976.

If many systems have bandwidth hogging butshort firmware implemented tasks, a single chipwhich could be dedicated to these tasks and easilycommunicate with other processors would be highlydesirable. To make these solutions economical, thechip would be completely self-contained, incorporat-ing a little of everything (RAM, ROM, or PROM,processor with limited addressing, and I/O parts)to do time consuming, but simple repetitive tasks.

To bring the coupling between an external deviceor processor and internal task tighter together andbypass the time consuming interrupt polling rou-tines, better and more direct synchronizationmechanisms must be developed. It is conceivablethat the classical interrupt mechanism can be re-placed with a common hardware/software signallingprocedure which prepares and activates tasks in amore uniform and controllable manner. Coupledwith this concept, the fundamental multitaskingprimitives which are used to create virtual proces-sors for semi-independent tasks could be hardwired,producing significantly increased performance, andforce the utilization of a common interface.

Finally, it is highly unlikely that we have arrivedat the ideal architecture(s) for microcomputer-based programmable logic systems which are in-tended to replace conventional random logic solu-tions. Most of today's microcomputers mimic thedesigns of their minicomputer relatives which werederived back in the mid-1960's from machines whichwere either scientifically or business oriented. Bothof these original computer applications are farremoved from the needs of logic replacement.Examining the basic building blocks of hardwarelogic designs, one can find several constructs (e.g.,pulse generation, counting, independent bit linecontrols and sensing, continuous comparisons, clock-ing, and frequency generation) which are seldomduplicated in today's microcomputers.A radical departure from conventional minicom-

puter architecture for microprocessors may be thekey to cost-effective, high-performance program-mable logic using present process technologies.-

Ken Rothmuller is a project manager respon-sible for microprocessor support tools atHewlett-Packard's Data Systems division.Previous activities at HP have includedcomputer architecture design, digital logicsicmulation, and software management. Afterhours he has organized and taught severalcourses on computer technology at the Uni-versity of Santa Clara and HP. Over thepast ten years Rothmuller has developed

several dedicated mini and microcomputer based systems forprocess control, analytic instrument monitoring and point-of-sale applications. In 1965 he received a BS in electronicengineering at the California State Polytechnic College, followedby an MSEE from Arizona State University.

COMPUTER

A COMPUTER SOCIETYCURRICULA WORKSHOP

L

24