CALIFORNIA STATE UNIVERSITY, NORTHRIDGE
A SYSTEMS APPROACH TO MICROPROCESSOR
SELECTION FOR A CONTROLLER APPLICATION
A thesis submitted in partial satisfaction of the
requirements for the degree of Master of Science in
Engineering
by
Gary Wayne Larison
June, 1978
The Thesis of Gary Wayne Larison is approved:
Dr.
Mendelovicz
Dr. D. M. Schwartz
California State University, Northridge
ii
PREFACE
The topic chosen for this paper was selected with
two purposes in mind:
{1) to create a comprehensive docu-
ment worthy of presentation in partial satisfaction of
the requirements for a Master of Science in Engineering
degree, and (2) to present a sufficient amount of information regarding the system approach to microprocessor
selection so that this paper may be used as an accurate
engineering document.
iii
TABLE OF CONTENTS
LIST OF TABLES .
vi
.
vii
LIST OF FIGURES
viii
LIST OF ILLUSTRATIONS
Section
1.0
Introduction
1
2.0
Detailed Description of the Problem .
3
2 o;l
3.0
Design Alternatives
yPjyC Basics
6
....
12
3.1
Microcomputer Organization
3.2
Microprocessor
14
14
3.3
Word Size .
18
3.4
Memory
3.5
Input/Output (I/O)
19
3.6
Software Programming
21
4.0
Microprocessor Selection
24
5.0
Microprocessor Functional Capability
Review • . . . . . . . .
. . .
25
.
• .
18
.
5.1
CPU Architecture
27
5.2
Support Circuitry .
45
5.3
Software
58
5.4
Hardware/Sof~ware
6.0
Development Aids
76
Cost Effectiveness
99
6.1
Introduction to Utility Theory
6.2
Decision Criteria Analysis
.
. 110
6.3
Detailed Decision Criteria Analysis • .
. 113
6.3.1
I/O Capability
6.3.2
Interrupt Capability
99
114
iv
. 115
Table of Contents (continued)
Section
Page
6.3.3
Hardware/Software Development Aids
6.3.4
Vendor Support
6.3.5
Tolerance Limit Computation
. 122
6.3.6
Power Consumption
. 123
6.3.7
Cost
6.3.8
Develop~ent
Time
. 126
6.3.9
Chip Count
. . .
. 128
6.3.10
Reliability .
6.3.11
Other Decision Criteria . . . . .
7.0
7.1
. . . .
. • . • . • .
. •
Final Expected Utility
Decision
Sensitivity Analysis
9.0
Summary and Conclusion
Bibliography
. 130
. 131
. . . . • . . • . . 146
. 147
. 148
.
. . . . • .
v
. 120
125
. . . . .
8.0
119
• .
. 156
. 158
LIST OF TABLES
Table
5.1-1
CPU Architecture Functions and Features .
6.2-1
Decision
6.3-1
Cost Estimates
6.3-2
Decision Criteria, Thresholds, and
Weightings . . . . . . . . • . . • . . . . 135
7.0-l
Summary of Expected Utility Results • . . . . 146
8.0-1
Combinational Sensitivity Analysis
Expected Utility Results • . . . . . . . . 154
Crit~ria
28
. 110
. . 127
vi
.j
I
LIST OF FIGURES
Figure
2.1
Present Station Configuration .
4
2.2
CAM RFTS Configuration
9
2.3
CAM Functional Diagram
10
3.1
Microcomputer Block Diagram .
13
3.2
Microprocessor Block Diagram
16
5.2-1
Typical I/O Structure .
50
5.2-2
ACIA Block Diagram
53
5.2-3
PIA Block Diagram .
5.4-1
Hardware/Software Development System
80
5.4-2
Software Interrelationships .
87
5.4-3
Software Development Flow Diagram
89
6.1-1
Utility Curve/Decision Criteria Threshold
Relationship . . . . . • . .
. . . .
. 100
Decision Criteria Expected Utility
Representation • . . . . . . . • • .
.
. 104
Expected Utility Computation Partial
Example
. . . . . . •
. • • .
.
6.1-2
6.1-3
.
55
.
107
6.3-1
Flowchart for Polling Eight I/O Devices .
.
. 116
6.3-2
Servicing an Interrupt Flowchart
.
. 118
6.3-3
Tolerance Limit Computation Flow Chart
vii
. 124
LIST OF ILLUSTRATIONS
Graph
Page
1.
I/O Capability . . .
136
2.
Interrupt Capability .
137
3.
Hardware/Software Development Aids .
.
138
4.
Vendor Support .
.
139
5.
Tolerance Limit Computation
140
6.
Power Consumption
141
7.
Cost .
.
142
8.
Development Time .
143
9.
Chip Count . .
144
Reliability
145
10.
.
• .
.
.
. .
.
viii
.
• .
.
.
.
.
ABSTRACT
A SYSTEMS APPROACH TO MICROPROCESSOR
SELECTION FOR A CONTROLLER APPLICATION
by
Gary Wayne Larison
Master of Science in Engineering
This paper presents a systems approach to the
proper selection of a microprocessor CPU {central processing unit) .
This selection process is addressed in the
context of incorporating the microprocessor as the general
purpose, stored program, digital computer element in a
ground support equipment controller.
Addressing the
problem in this manner allows quantitative illustration of
the methodology involved.
However, the basic approach is
applicable wherever it is desired to incorporate microprocessor technology into a controller design.
The approach
tak~n
in this paper consists of two
phases, termed the functional capability review phase, and
the cost effectiveness evaluation phase.
The functional
capability review phase addresses the important functions
and features of the CPU integrated circuit, and the
required support circuitry to enable it to function as a
ix
i
'i
·I
I
r
'
~
digital computer.
Also discussed are the hardware/software
development aids which are required and most often desired,
to develop the microcomputer (CPU plus support circuitry)
hardware and its associated software.
Having gained a detailed understanding of the
functional capabilities and interrelationships of the CPU,
support circuitry, and hardware/software development aids,
the systems designer evaluates this capability in relation
to the design problem requirements through a cost effectiveness evaluation.
The cost effectiveness evaluation,
developed using utility theory and sensitivity analysis,
enhances the knowledge gained from the functional capability review by projecting the impacts of the capabilities
into the probability of success of the system design.
This two-phase approach extends the system
designer's decision making ability by allowing him to
couple the technical intricacies of microprocessor technology with insights into the ultimate cost effectiveness
resulting from the alternative courses of action available
to him for implementing the microprocessor based design.
X
''·
1.0
Introduction
Increasingly, digital system designers are faced
with the realities of utilizing microprocessor technology
in their designs to remain competitive.
This task is being
made continuously more complex by the burgeoning capabilities being built into the microprocessor, or more often
now, the microcomputer.
The availability of so many different types of
microprocessors with a wide spectrum of capabilities makes
the process of selecting one increasingly more difficult.
Although there has been an abundance of material published,
not only about the microprocessors themselves but also
how to evaluate their functional capability, all too often
the final decision is based on using the microprocessor
about which the most has been written or heard.
Although
the selection of that particular processor should typically
result in a satisfactory design, it is not necessarily
guaranteed.
Lack of success with even the industry "de facto"
standard microprocessor can result if the system designer
r!l: ,
~.
.
!:
q,
does not take the time to understand the fundamentals of
1r
microprocessors or understand the implications of implemen-
'lrI
lr
ting one in a particular design.
A systems approach must
be utilized to realize the benefits of microprocessor
based design.
l
ill
I
2
This approach is developed in this paper through
the example of the CPU selection for implementing a
computer-assist-modification (CAM) controller into an
existing manual test station to upgrade it to automatic
test capability.
2.0
Detailed Description of the Problem
An existing manual test station, -which is part of
the Ground Support Equipment for an airborne radar, must
be upgraded to automatic test capability to handle the
anticipated load increase of an additional airborne radar
which has been allocated to this station.
This manual test station is located aboard U.S.
Navy aircraft carriers deployed throughout the world and
at shrire-based maintenance facilities in the continental
United States.
Its present configuration provides for
manual functional test; fault isolation, and alignment of
the units assigned to it by operator initiated actions
detailed in written stap-by-step procedures.
The majority
of these actions are centered around the 3A2 Control Panel
(see Figure 2.1), with peripheral usage and setup of commercial stimuli and measurement instruments located throughout the four bays of the station.
The U.S. Navy has made it known that it would be
highly desirable if the new airborne radar subsystem could
be tested on equipment already available on board the
carriers, thus eliminating the requirement for any new
ground support equipment requiring additional floor space,
facilities cooling, and electrical power, all of which are
limited on board ship.
3
...
>
<
CD
..J
w
..,
>
<
CQ
~
CL.
N
,.,<
..J
0
...a:z
\U
C)u
;!!~
-c:;
t:::>
i..,
0
u
•
---
11
'.I·
)'
5
As presently configured, the test station can
handle the existing load, but the additional load imposed
on it by the new radar units under the manual testing
philosophy would severely jeopardize, not only the availability of the new radar subsystem, but also that of the
existing radar subsystem.
Therefore, a study was conducted
which determined that the addition of a computer subsystem
(consisting of CPU - Central Processing Unit, memory, input/
output circuitry, and associated peripherals, namely the
operator console and mass storage device) to the station,
would reduce its loading to a point such that the additional
radar subsystem can be accommodated.
The computer subsystem (hereafter referred to as
the controller) functions under the automated test concept
would require the controller to interface with a large
number of command and monitor lines to:
A.
Set up specific stimuli required by the unit
under test.
B.
Route the response of the unit under test to
the appropriate measurement instrument.
C.
Set up the measurement instrument via programming control lines or displayed instructions to
the operator for manual setup of the instrument.
D.
Receive the instrument digital results of the
measurement.
6
E.
Compare the results to programmed limits for
pass/fail decisions.
F.
Branch as required to the next step as dictated
by the pass/fail decision.
G.
Interface with the sta·tion operator via the
display, accepting inputs from the operator
via the control keyboard.
H.
Continuously monitor prime functions of the
station and unit under test for fault conditions and operator hazardous conditions,
interrupting the programmed test presently
being executed to notify the operator of such
a condition and take corrective action (i.e.,
unit shutdown, station shutdown, display the
fault, etc.).
I.
Load and execute the programmed test flow from
the mass storage device, branching as dictated
by the test pass/fail results to other test
programs on the same mass storage device.
2.1
Design Alternatives
The U.S. Navy's desire to utilize existing equip-
ment generated secondary constraints which had to be considered in the approach taken for the controller design.
A.
Limited space - In addition to the fact that
there was no room for a new test station on
7
board ship, it was discovered that even one
new bay could not be added easily due to the
other equipment (work benches, storage racks,
etc.} located in close proximity to the
station.
B.
Limited station power - Any circuitry requiring
DC power would have to be supplied by the margin of the existing station DC power supplies.
c~
Limited station retrofit time - Due to the high
utilization rate of the station, the retrofit
of the controller and its associated checkout
would have to be done in a minimal amount of
time to prevent extended periods of reduced
radar system availability.
Four different design alternatives were considered,
with the last being deemed the most feasible, and accordingly, addressed in this study.
The alternatives consisted
of replacing the existing manual test control panel with a
fully automated panel, but was found to be too costly.
The
second alternative of adding a minicomputer, tape-transport,
and CRT/Keyboard' required extensive equipment relocation
within the station, necessitating long station down times
for retrofit of the modification.
The third alternative
was to have added an intelligent terminal containing the
microcomputer, cassette tape, and CRT/Keyboard in one unit
external to the station.
However the quality of parts and
''
i
I
l
,
1
.,.•. ·.
~
J
1.1.1
'·'l
8
workmanship was unacceptable in the military ground support
equipment working environment.
Having found the three previous approaches undesirable for the reasons stated, a fourth approach called CAM
(Computer Assist Modification) was conceived as a result
of the recent advent of microprocessor technology.
The
microprocessor is capable of performing functions requiring
ten times or more discrete integrated circuitry, with
increased flexibility.
This flexibility is obtained by
means of the software programs executed by the microprocessor for performing specific tasks, which is easily
changed for different tasks.
Thus, utilizing microprocessor technology, it was
found that the entire controller (excluding tape transport
and station interconnecting cables) could be packaged small
enough to be mounted external to the station (see Figure
2.2).
No additional power other than that supplied by the
station itself would be required.
The controller could be
easily retrofitted in the field, and yet meet the stringent
requirements of the military environment.
A basic functional diagram df the CAM controller
is shown in Figure 2.3.
As can be seen, the controller is
composed of three basic blocks:
the microcomputer, the
input/output assembly, and operator interface.
The opera-
tor interface and input/output blocks are relatively
independent of the microcomputer block selection in that
Figure 2.2 CAM RFTS Configuratiqn
·----"~---
10
UNIT
ur~OER
TEST
-
-
UIITERFACE
,
I
.,
MULTI·
I
L.XEH~I
S'ELI'.
TEST
CIACIJITFY
I
1'0
INTEf'f,>.Cf
INPUTS
I
L
Figure 2.3 CAM Functional Diagram
.----t.-...,
I
I
I
AFT$
11
the operator interface will consist of a readout device,
some keyboard and control keys for the operator/computer
interaction, and a mass storage device (i.e., cassette
tape) for storage of the computer programs.
Likewise the
input/output block desig·n is dictated much more by the
station interface requirements rather than the microcomputer interface.
This independence gives microcomputers
their flexibility of easily being adapted from task to
task.
Thus, the major cost effectiveness decisions in
this application lie in the proper selection of the CPU
integrated circuit and its associated hardware and software
elements comprising the microcomputer capability.
The
total number of microprocessors presently available on the
market to implement the CPU function of the controller
exceeds 25.
Thus, a practical means of scaling down the
candidates to a manageable number becomes necessary.
3.0
~P/~C
Basics
In order to appreciate the complexities involved
in the proper selection of a microprocessor, a basic
understanding of microprocessor
(~P)
functional relationships between the
elements of the microcomputer
(~C)
functions and the
~P
and the other
is in order.
The microprocessor had its beginning with the
integrated circuit, which appeared a little over a decade
ago.
Today, LSI (Large Scale Integration) offers a com-
plete circuit on a chip as small as 0.1 inch square.
Such
chips can contain more than 1,000 transistors, all prewired and interconnected.
Although microprocessors are the heart of all
microcomputers, there is often confusion between the two
terms.
Microprocessors are
11
central processing units, 11
the equivalent of the CPU in full-scale systems.
They may
be used individually, but are usually part of a group
called a
11
Chip set.
11
A complete microcomputer includes a
microprocessor, memory and necessary interface circuits,
each section consistii1g of one or more chips, as shown in
Figure 3.1.
Microcomputer hardware may be purchased in various
configurations ranging from individual chips up to one or
more printed circuit boards with the chips installed and
completely tested.
Additionally, various software
12
r-----....
_
_.._..,
_.-
i[:TOC'K t.,en.
~
·" I
1~ Memory
·L-~~-------=·~
' Buf-~"
-J '
... er
c
p
u
ADDP..ESS
!
CONTROT1
·- -- -- -- -
register
~
~·
Memory
~
,_
~
I
'--
....__
..J
r--
~
1-1--
~ f!Jemory
m
Address· f-!P Registerf--
~
~
I
I
r-· .1--H----
i· U
•"'---l ~~resh
Circuit
h'L---'
~
I
I
RAM
~"""'~
1--------
I/O Data
Buffer
~"
Register
f
I
I
l
~
,
PROM
-------~-
I
--11--- ~--- --~1- -----.
I/O
Control
..!..
L---~-----
I/0
Address
Decoder ·
-.
·-l
Interrupt
Priority
IJogic
1
I
T
:
------------~
Illput/Output
I
I
I
,
I
I
I
1
ROM
~
I I
l
1...--
1 IY
I
I
I
I
Central
Processing
Unit
I
, - - - . - - - - - ..._ - - ___..- - - - - - - - - - ........
1\."-r:-..~.~
'l''·"d~----,
1"
I nt:..:;~.a.....,
,
Drivers
I
I
,J..
Figure 3.1 MicrC?computer B1ock Diagram
14
packages may be included in the price or purchased separately.
Purchase prices range from less than $100 to
about $250 for chips sets in lots of 100.
Assembled micro-
computers range from about $400 to over $2,000.
Most
companies offer a complete prototyping system that contains
sufficient hardware and software for almost any control
application.
These systems are in the $2,000 to $20,000
range.
3.1
Microcomputer Organization
Understanding the makeup of the microcomputer is
best done by comparing it with larger scale computers.
All digital computers, from the giant large-scale machines
to the smallest
~Cs,
contain three sections:
a central
processing unit (CPU), memory, and input/output (I/0)
section.
In larger-scale units, the I/0 section controls
and receives or stores data on various peripherals keyboards, printers, tapes, and disks.
The microcomputer has the same three elements.
The CPU
(~P)
and
the I/O usually can be contained on a
single circuit board.
In small-capacity units, the memory
may be on the same board.
In larger units, one or two
additional boards may be required for memory.
3.2
Microprocessor
The microprocessor itself consists of onetoseveral
LSI chips contained in dual-in-line packages (DIPs).
It
15
has three basic elements:
an arithmetic and logic unit
(ALU), several accumulators, registers, and stacks, and a
control block, as shown in Figure 3.2.
The ALU uses logic manipulation, such as AND, OR,
Exclusive OR, complement and shifts to perform arithmetic
functions or generate control functions.
Status flags,
unlike those associated with the programmed flags in a
data word, are developed by the ALU.
Accumulators hold data or instructions for further
manipulation.
Normal operation involves use of data from
memory in conjunction with data stored in an accumulator.
All microprocessors have at least one accumulator, and
many have two or more.
programming efficiency.
Additional registers offer greater
One accumulator serves as the
principal working storage, while others may store memoryreference instructions or data.
Registers, like accumulators, provide temporary
storage of instructions and data.
A program counter (PC)
register stores the address of the next instruction to be
executed; general purpose registers (GPR) store data or
intermediate results.
The stacks provide temporary data storage in a
sequential order- usually last-in, first out (LIFO).
Used primarily for register storage during the execution
of an interrupt, or for subroutine linkage, the stacks
eliminate the need to read and write temporary or
Interrupts I
·~
I
H~der&
C1ontrol
I·
To !/0 &JIA....Jl-.1-...1...--...1
"
{\,--:--T"""T-----~"\1
I"
,
I
Stack
....
I
f'!C!Mry
I
I
~..t
.
(LIFO)
Control &
(SP'
Clocking of
CPU Circuits ~~Stack
Pointer
K.•
'X.Rl
nd.ex
A
... n.egistcr K
{ G:!'~~ ~
'
General
Purpose
Registers
"'
.
;..
r
>A.ccumula tor(,
.,
Arithmetic
Lop.;ic
Unit
I
I
I
I
I
l
Ill
til
~
"'
~
(!)
"<! ,...
Statas
Flags
T
ro
+'
ro
p
..-i
(ACC)
(A'LU
r-------
+'
r::
H
T
.
Figure 3.2 Microprocessor Block Diagram
J
To I/O &
Memory
I
I
I
I
I
I
-1
17
intermediate data into an external stack during these
instances.
The control section sequentially decodes the
instructions fetched from memory and generates the signals
necessary to perform the desired operation.
the instruction set comes in.
This is where
Microcomputers have instruc-
tion sets ranging from 22 to 158 commands (called macroinstructions).
The number of instructions is not a good indication
of the power of a microcomputer, since each manufacturer
"counts" differently.
One manufacturer, for example, lists
43 basic instructions.
instructions.
But these could be listed as 152
A register-to-register add, for example is
considered to be one instruction.
When there are four
possible registers, this function could be counted as 12
·instructions.
Instructions initiate microprograms stored in Read
Only Memory (ROM) within the control section.
The micro-
programs consist of a series of basic operations that
cause data transfers and logical operations to occur within
the microprocessor.
Microprograms•are used to fetch and
execute instructions, provide interrupt service, and
initialize the instructions.
Usually, the microprograms
cannot be modified by the user.
However, there are
~P's
which are capable of having their instruction sets and
subsequent decoding defined by the user.
This capability
,. f
'
.,
18
is often referred to as microprogrammability.
3.3
Word Size
Microprocessors are categorized by word size in
bits.
Usually, the larger the word size, the more power-
ful the device.
Some microprocessors are packaged in
more than one DIP to provide a longer word.
A typical
machine, for example, is comprised of four, four-bit
elements interconnected externally to provide 16-bit
capability.
cessor.
This unit is called a bit-slice micropro-
Recently, single-chip, 16-bit microprocessors
have become available.
Choice of word length ultimately
depends on the application.
For the simple control
operations with few computations, a 4-bit microprocessor
may be sufficient; however, the trend in
~P
based design
is towards larger word length.
3.4
Memory
Most microcomputers use a combination of semi-
conductor Random Access Memory {RAM} , Read Only Memory
{ROM}, and Programmable Read Only Memory {PROM}.
read/write memory.
RAM is
On the other hand, the data in ROM is
usually programmed by the semiconductor manufacturer,
according to specifications by the user and is therefore
fixed and cannot be changed.
Unlike ROM, PROM can be
altered by the user with special equipment.
l
.~
~~
'~
;·.~·
I'i
I
19
Basically, the memory contains data and programs.
A combination of PROM and RAM most often serves as the
system memory.
In general, most of the program storage
will be in PROM, while RM1 is used for data.
PROM or ROM also provides permanent storage for
fixed procedures such as start-up or shut-down.
Semi-
conductor RAM is volatile - that is, when power is lost
all data is lost or at least suspect.
ROM data is per-
manent and therefore is used to control data-loading
programs and safe-shutdown procedures.
Like the ROM, PROM is not volatile.
A number of
relatively low-cost devices are available for erasing and
reprogramming them.
The PROM created a new term-
11
Firmware. 11
Hard-
ware, of course, refers to the equipment necessary to
implement a system; software comprises the instructions
to the hardware.
Firmware is generally considered to be
software stored in PROM.
It is a fixed portion of the
system, but can be altered.
3.5
Input/Output (I/O)
The I/O section is the means by which the micro-
processor communicates with a wide variety of devices,
called peripheral equipment.
Input and Output are very
important to the system designer.
Any computer-based
system requires both machine/machine interface and
20
man/machine interface.
Thus, the processor may have to
operate relays, indicator lamps, step servos, Teletypewriters, CRTs, magnetic or paper-tape units, printers,
analog-to-digital (A/D) or digital-to-analog (D/A) converters, card readers, card punches, and modems.
Transferring data between the processor and the
'I
'Il
I
·!,,
)
peripheral requires an I/O interface.
Basic microcomputer
i\
:\
i:~
systems have one input port (or connection) and one output
11
port.
i,,l
A port allows transfer of one data word in and out
under processor control.
More sophisticated units have
(
/i
I
multiple I/O ports, which allow virtually simultaneous
j,
communication with several peripheral devices.
11
A very powerful I/O technique is called Direct
Memory Address (DMA) .
dat~
D~ffi
allows peripherals to transfer
directly into and out of memory, independent of the
control unit and operating program.
Because DMA does not
t
I
I
require data to go through the CPU, data transfer is faster,
with fewer program steps.
Operating peripherals requires a combination of
hardware and software.
These are currently available for
common computer peripherals, such as Teletype (ASR33),
storage disks, paper tape, punch or card readers, printers
and cartridge or cassette recorders.
It is up to the
system designer to adapt or develop his own special
hardware/software combinations for his application oriented
I/0.
'·l
21
As a controller, the microcomputer accepts digital
sensor data directly.
For analog sensors, many low cost
analog-to-digital (A/D) converters are available to provide the necessary conversion of data to a format utilizable by the microcomputer.
3.6
Software Programming
As an aid to the designer, most manufacturers and
many independent organizations offer software application
and programming packages at various technical levels.
Because microcomputer technology is so new, manu-.
facturers have not yet developed a full line of program
software but the available software is rapidly expanding.
Many
~Cs
are still programmed with machine language,
although assembly language is becoming the more prevalent
means of software programming.
Compilers have only
recently become available for higher level languages,
such as BASIC, PL/M, and FORTRAN.
Machine language is the most basic microcomputer
code.
Programming with machine language requires that the
designer direct each step of the operation, using the
instruction set, coding the program in binary (l's andO's).
To make the programming easier, assemblers are
used.
Assemblers accept coded instructions or mnemonics
and convert them into machine codes that can be accepted
by the microcomputer.
Assemblers give designers easier
22
control over the machine, but still require a knowledge
of the hardware configuration.
Cross-assemblers are also frequently available.
This software allows the designer to develop programs on
other computers for his specific
~C.
For example, one
cross-assembler is used to assemble a program on a large
machine such as IBM's 360/370 for subsequent execution on
a microcomputer.
Loaders aid in placing user-written programs in the
proper location in memory.
Debug programs help the
designer find errors in his program while they are running
on the microcomputer.
Editor programs allow him to
replace, insert, or modify instructions in his program.
Most microcomputer software packages have a monitor
program that controls the microprocessor operation during
software generation, checkout, and hardware/software integration.
The monitor may work in conjunction with assem-
bler and editor programs, that translate a symbolic
language program into machine-executable language programs
which are run by the microcomputer.
Compiler programs allow the designer to write
programs in an English-like language that is almost selfdocumenting.
Compilers permit him to express a program
with fewer statements than is possible with an assembler,
and greatly reduce program development time.
However,
each compiler statement generates several machine commands
i.
23
and is therefore less compact, and slower running, than
an assembly language program.
Also, it may be more
difficult to debug in end systems.
Diagnostic programs check various hardware portions
of the system for correct operation.
CPU diagnostics
check the CPU; memory diagnostics check the memory, etc.
Using these various programming software aids,
the designer can develop specific control systems for
virtually any application.
Therein lies the power and
versatility of the microcomputer.
Having some understanding of the basic functional
capabilities of the
~P,
a means of selecting the one most
suitable for the specific application can now be addressed.
4.0
Microprocessor Selection
The actual selection of a
~P
for a system applica-
tion is all too often based on industry acceptance or
previous experience.
A more detailed and rational approach
is needed to assist the systems designer in making his
decision in order to provide the highest probability of
success.
Such an approach is proposed in the following
sections, and consists of two phases, a functional capability review and a cost effectiveness evaluation.
24
5.0
Microprocessor Functional Capability Review
As previously discussed, the complexities and
capabilities of the
~P
are many, and are growing.
such, this makes the appropriate selection of the
As
~P
critical to the overall success of the system design.
This is true not only in the instance where this is a first
~P
attempt at a design utilizing
technology, but also in
succeeding designs where the re-evaluation of a previously
undesirable choice may be more relevant to the new design.
The choice is important not only from the technological point of view, but also in the economics.
For
the choice of the CPU entails not only that particular
integrated circuit selection, but also a family of particular support IC's, software, and hardware/software development aids.
Although many
~P
manufacturers claim
universality of support IC's and development aids, they
typically have developed them to be compatible with only
that particular
~P.
As such, a wrong decision at the
beginning in the choice of the
~P
often is found to be
unacceptable midway ·through the design, thus creating
disaster by continuing with the first choice by making
numerous modifications, or starting over again with
another choice.
25
i
26
There are several ways of evaluating
~P's,
and
their associated support IC's, software, and hardware/
software development aids, ranging from acceptance of
someone else's opinion, to procurement and exercise of a
prototyping system.
Obviously one end of the spectrum is
very inexpensive, but not very factual, while the other
can be extremely expensive in terms of time and capital,
and very factual.
Unfortunately, the time allocated for this critical
choice is typically very short, with little capital or
manpower resources available to aid in making the decision.
Ideally, the system designer would define the system
requirements in detail; survey the available microprocessors in depth to understand all their capabilities and
idiosyncrasies; compare each against the other and the
system requirements to determine the degree of applicability; and finally choose the one which appears most
capable.
Obviously, this can be a time-consuming process,
requiring substantial expenditures of capital and manpower.
It suffers the risk of the system designer becoming
entangled in intricate, non-essential detaiJrs, and may
cause him to become biased toward one candidate because
of one or two unique features, thus losing the overall
perspective required to make a valid decision based on
total capability.
27
In this section and the next, a method is presented
whereby a selection can be made inexpensively and in a
relatively short period of time, while still gaining the
necessary insights into the essential CPU capability,
support IC requirements, software requirements, and
desirable features of hardware/software development aids.
It is assumed at the beginning of this process
that the system designer has defined, to the best of his
ability, the overall system (controller) requirements,
and is attempting to evaluate the various alternatives
available for 11P selection to maximize the probability
of success of the design.
The first phase of this selec-
tion process termed the functional capability review (the
cost effectiveness evaluation will be covered in the next
section), is broken up into four areas:
tecture,
(1) CPU Archi-
(2) Support Circuitry Requirements,
(3) Software
Requirements, and (4) Hardware/Software Development Aids.
5.1
CPU Architecture
Since the CPU is at the heart of the microcomputer
system, identification of its most desirable features and
organizational aspects (architecture) is the first major
step of a functional capability review.
It is to be noted
that the diversity of microprocessors precludes covering
all types and aspects of CPU architectural implementations,
and as such the architecture discussed below is more of a
28
categorization of existing types.
It is intended to serve
only as the basis from which a detailed analysis could
begin.
The functional capability review is primarily
directed towards the class of 8-bit microprocessors, and
the functions to be considered are shown in Table 5.1-1.
Table 5.1-1
CPU Architecture Functions and Features
Bus Structure
Interrupt Capability
Address
Microprogrammability
Data
Internal Timer
Control
Butfered Drive Capability
Internal Registers
Accumulator
I/O
~~emory
Expandability
Internal CPU Controller
General Purpose
Program Counter
Index
Stack Pointer
Status (Condition Code)
Stacks
Internal/External Clock & Drivers
ALU Arithmetic/Logic Capability
Bus Structure
As is shown in Figure 3.1 of section 3.1, the
primary means of communication between the CPU, memory,
and I/0 elements of the microcomputer is via three buses;
address, data, and control.
Although shown as three
i.
29
'•
separate buses, several ways of implementing the bus
structure are used.
The address and data may be multi-
plexed in and out on the same bus, affording a reduced
number of pinouts on the CPU, but sacrificing speed and
overall throughput of the microcomputer.
Additionally,
this time-shared use of the bus leads to complexity
external to the microprocessor for it is then necessary
for external devices to interpret each transmission to
determine the expected function.
Other types of implemen-
tation include multiplexing the MSB's (most significant
bits) and LSB's (least significant bits) of the address
onto the address bus; a bi-directional data bus; and
uni-directional data buses, one IN and one OUT.
However, of all these implementations, the predominant implementation is that of three separate buses:
the address, a bi-directional data bus, and a control bus.
The width of these buses varies, but again a predominance
of certain widths is present.
For the address bus, a width
of 16 bits, allowing a direct memory addressing capability
of 65,536 locations is common, although widths of 8, 12,
24, and 32 can
~e
found.
The data bus is typically 8 bits
wide, facilitating ease of data transmission between the
;~
memory (organized typically in 8 bits per memory location),
internal CPU registers (each 8 bits wide), and I/0 circuits,
typically organized around BCD (binary coded decimal) , or
other 8 bit (or sub-multiples of 8 bits) codes.
':j
30
The control bus is somewhat of a misnomer, in
that it is actually a collection of the discrete input/
output commands associated with the CPU.
The commands
typically include ones similar to the following:
Input to CPU
Initialize, Reset - This command initializes all
internal CPU registers to a predetermined (usually
zero) state, and loads the program counter with the
address of either the lowest or highest location
in memory, which contains a pointer to an initialization program to be executed.
Single Step - Upon command, the CPU executes a
single instruction and then stops.
Interrupt, Interrupt Request - Upon receipt of
this command, the CPU completes the execution of
the present instruction, and then branches to the
interrupt service routine.
Some CPU's interrogate
this input at the end of the execution of each
instruction.
This input may be maskable, that is,
it may be enabled or disabled under software
control.
Tri-State Control - This command is used in conjunction with those CPU's whose address output
lines are driven via tri-state devices, and forces
the address output lines to the high impedance
state at the end of the instruction being executed,
l
31
allowing access to the microcomputer memory by
external processors or peripheral devices via
'~t
\t
~
I
~!
direct memory access (DMA) .
Data Bus Enable - This command is exactly the same
)
as the Tri-State control signal above, except that
it controls the data bus.
For such operations as
DMA, both of these commands might be activated.
DMA Request - This command may be present in lieu
of the Tri-State control and Data Bus Enable
signals above, and when acknowledged by the CPU,
performs the same function of putting the CPU
address and data bus drivers in the high impedance
output state, freeing these buses for external
control.
Halt, Wait - This command stops the execution of
the program by the microprocessor at the end of
the present instruction being executed.
Non-Maskable Interrupt - This interrupt, as opposed
to the above interrupt, cannot be masked, or
ignored, by program control.
As such, it is
typically allocated to those high priority functions which require immediate attention.
Outputs from CPU
Address Latch Strobe, Valid Memory Address, Memory
Request
Although this signal has different nomen-
clatures, it denotes a valid memory address exists
:1
32
on the address bus for access to the designated
memory location.
Program Memory Enable - When set, this output is
used to enable a specific block or blocks of
memory for addressing of memory locations.
Read/Write Strobe - This signal causes data to be
output or input to memory, to or from the data bus.
DMA Acknowledge - Having received a DMA request
from an external device, the CPU would output
this signal to the external device when the CPU
is ready for the DMA transfer to be executed.
Interrupt Acknowledge - Having received an interrupt request from an external device, the CPU
would output this signal to the external device
when the CPU is ready for the interrupt service
routine to begin.
Bus Acknowledge - This signals that the CPU has
disabled its drive of the address, and data buses,
allowing other processors or external devices to
drive the buses.
Halt Acknowledge - In response to the Halt or Wait
input command, this signal goes true when the CPU
has completed its execution of the present instruction, or in some instances, the following instruction.
33
Internal Registers
In addition to the bus structure required to
communicate with the microcomputer elements external to
the microprocessor, the CPU must contain certain internal
registers to provide temporary storage of data, to facilitate data movement, data manipulation, decision and
control, input/output, and memory operations.
These
registers, as previously shown in Figure 3.2, are interconnected so that they can communicate with one another,
and with external devices via the CPU buses.
These
registers should consist of:
Program Counter
Instruction Register
Accumulator(s)
General Purpose Registers
Stacks/Stack Pointer
Index Register
Status Flag Register
Memory Address Register
Memory Data Buffer Register
Program Counter (PC) - All microprocessors must
contain this register, along with the Instruction
register, and at least one Accumulator, in order
to perform the functions associated with the central processing unit.
means
~y
The program counter is the
which the CPU addresses the memory for
34
instructions, and always contains the address of
the next instruction to be executed.
Instruction Register (IR) - This register provides
the temporary storage for the instruction which
has been fetched from memory, and is decoded by
the control section of the CPU for execution of
its associated microprogram.
Memory Address/Data Buffer Registers - In some
microcomputers, it is necessary to buffer the
memory addresses and data going to/from the memory.
This pair of registers provides this capability.
They may be located either inside the CPU, or
externally in the memory element or other support
circuitry.
The presence in the CPU of the following registers,
their number, and their capabilities greatly influence the
CPU capability.
They are typically accessible to the
programmer, and as such give a great deal of flexibility
and capability by means of software manipulation.
Accumulator(s)
(ACC) - One or more accumulators
'
should generally be provided and are used for both
the temporary storage of data and also to provide
a source and destination for operations performed
in the ALU.
The accurnulator(s) are more useful
when they are capable of shift and rotate
I
~
35
operations, being tested for zero, or having
individual bits tested.
General Purpose Registers (GPR) - General purpose
registers internal to the CPU greatly enhance its
throughput capabilities, in that they can provide
temporary storage for data, thus deleting the
memory access time required to retrieve and store
data to and from memory.
These registers can also
be more useful if they can be loaded directly to
and from memory or I/0 without passing the data
through the ACC; if they can be incremented/
decremented directly; and tested for zero to serve
as counters.
There may be an attendant disadvanvate to
the use of multiple general purpose registers, or
accumulators, in that an instruction involving one
of these registers must identify which register
is to be operated upon.
Since instructions are
bit limited, using some of these bits for register
identification adds to the overall program length
and reduces throughput.
Typically however,
overall throughput is increased through the use of
general purpose registers.
36
Stacks - Because it is convenient to organize
programs around subroutines and interrupt handling
routines, the former to modularize the software,
and the latter to sychronize the microprocessor
with external service requirements, a need exists
to interrupt the normal processing sequence,
process a routine, and then return to the point of
interruption.
Storage is needed for the saving
of information which uniquely defines the status
of the interrupted program, so that it can continue
execution once the interruption has been serviced.
In some microprocessors, a fixed set of
registers is provided internal to the CPU for this
function (aided by special instructions for adding
data to the stack and deleting i t later).
In
others, only stack pointer(s) to the stack are
provided internally, with the stack itself maintained in memory external to the CPU.
Maintenance
of the stack wholly within registers internal to
the CPU limits its depth, whereas maintenance in
memory limits its access time.
Index Register - Efficient memory addressing can
be effected through the use of an index register.
By being able to compute an effective address
from the addition of an address within an instruction and the contents of a specified register
37
{index) , different portions of memory can be
accessed without having to change the address
within an instruction.
Status Flag Register - Programs can be simplified
and throughput increased, if certain conditions
are detected during arithmetic operations, register manipulations, or processor control functions.
A flag register provides this capability by having
its individual bits indicate such conditions as:
ACC = 0
ACC overflow
Sign of an arithmetic operation
Result
=
0
Carry
In selecting a microprocessor one has to trade off
the number of dedicated registers available against the
generality and flexibility of general purpose registers
which can be operated upon by any instruction.
The ease of
addressing memory, manipulating addresses, creating long
addresses in short instructions, manipulating index
'registers, manipulating data in input-output registers,
are important considerations.
Although it is usually
possible to implement a function with almost any microprocessor, it does not follow that the same number of
operations or the same amount of memory are required in
different microprocessors to implement the same function.
f;
'
38
Internal/External Clock and Drivers
A clock must be supplied, not only to the CPU,
but sometimes to the memory element or I/O element of the
microcomputer, to provide the basic timing reference to
synchronize internal and external control for proper execution of instructions.
The reference for this clock is
usually supplied via an oscillator or R-C network, which
is amplified and driven, in some cases as a multi-phase
clock, to the using circuitry.
The amplifying, dividing,
shaping, and driving circuitry may be either external or
internal to the microprocessor.
If external, it requires
additional circuitry, adding to the parts count and power
consumption.
However, even when this circuitry is internal
to the microprocessor, external drivers may still be
required as the drivers internal to the microprocessor may
not have enough capability to supply the needs of memory
and I/0 circuitry.
The frequency of the clock may vary from a few
tens of kilohertz to several megahertz.
Note that the
actual throughput of a microcomputer is not only proportional to the operatirig clock frequency, but also depends
on the number of clock cycles required to execute a particular instruction.
A more valid indication of a micro-
processor's throughput capability can be obtained by means
of benchmarking, which accounts for the varying lengths of
39
different instruction execution times, and will be discussed in more detail later.
Decoder and Control
The execution of each instruction is controlled
by a decoder and control section of the CPU.
Again, the
capability may be either external (special integrated
circuits have been designed to fulfill this function) or
internal to the microprocessor itself.
In either imple-
mentation, it decodes the instruction placed in the
instruction register, commonly termed the "macroinstruction," and executes a series of "microinstructions."
A microinstruction consists of a sequence of discrete
timing and control signals (commonly termed
microoperation~
to individual registers within the microprocessor, memory,
and I/0 elements.
Thus, the instruction set of the micro-
processor is implemented as a stored set of "microinstruction" sequences, which is programmed in ROM by the microprocessor manufacturer, or by the user in microprogrammable
microprocessors.
Microprogrammability
With some microprocessors, it is possible for the
user to create his own instruction set geared towards a
specific application.
This capability, termed micro-
programmability allows the user to define the microinstruction sequences himself, by defining a control ROM, unique
40
to his application.
By being able to determine the
specific sequence o£ microinstructions to be executed for
the user defined macroinstruction, the microprocessor
throughput can be increased due to the more detailed level
of control over the internal microprocessor circuits.
Additionally, because each macroinstruction uses the CPU
more efficiently, application programs require less memory.
Microprogrammable microprocessors are well suited
for emulating other microprocessors.
Because of the often
large investment in software, when it is desirable to
upgrade a system in terms of speed or power while keeping
the same applications software, a microprogrammable
microprocessor can fulfill these new requirements.
Note, however, that microprogramming requires much
greater software effort.
Additionally, defining a unique
microprocessor instruction set may negate all the benefits
afforded by the available software development aids for
fixed instruction sets, such as the assembler, editor,
monitor, and debug programs.
ALU Arithmetic/Logic Capability
Another section which all microprocessors contain
is that of the arithmetic/logic unit (ALU).
The ALU
performs all arithmetic and logical operations required
in the microprocessor.
These typically include the
arithmetic operations of ADD, SUBTRACT, MULTIPLY and
41
DIVIDE (usually implemented in software), COMPLEMENT a
number, INCREMENT, DECREMENT, ROTATE left or right,
COMPARE, and DECIMAL ADJUST.
Most ALU arithmetic opera-
tions are performed in binary fixed point.
However, those
which are capable of operating in floating point and BCD
are desirable where large amounts of "number crunching"
is required for data and interfaces implemented in these
formats.
The logical operations the ALU performs should
include AND, OR, and EXCLUSIVE OR.
These operations can always be performed on the
ACC, but the capability to perform them on other registers
within the CPU and to memory locations, can increase the
throughput by not requiring the movement of the data to
and from the CPU ACC for the operations.
Internal Timer
During many application programs, it is desirable
to use delays or count a number of events.
This can be
done in software by determining the time to execute a
specific instruction a certain number of times or incrementing a register each time an event is detected.
However, software implementation takes microprocessor time
which could be utilized more effectively.
An internal
(or external) timer which is programmable and operates
independently of the microprocessor is most desirable.
Also the timer (or event counter) should indicate an
42
overflow by means of an interrupt to the microprocessor.
Its resolution and maximum count (duration) are major
considerations.
Buffered Drive Capability
Another consideration in evaluating the microprocessor is its internal drive capability for the address,
data, and control buses.
Most microprocessors can only
drive one standard TTL load.
As such, this may necessitate
external driver circuitry to interface with memory and I/0.
Additional considerations are the type of interface, i.e.,
TTL, CMOS, tri-state, and whether level shifters are
required to interface with the other elements of the
microcomputer.
Interrupts
Interrupts provide the primary means for external
devices to communicate with the microcomputer on an
required .. basis.
11
as
Thus the capability of the microprocessor
to accept or ignore these interrupts, prioritize them,
easily denote the point at which the main program was
interrupt~d
by saving the contents of key registers (such
as the ACC, PC, PSW, SP, and GPR's), and the time required
before the interrupt service routine is fetched and
executed, is of prime importance.
There are several different prevalent ways in
which microprocessors implement this interrupt capability.
I .
43
In a single level interrupt system, the control unit of
the microprocessor scans the interrupt line{s) at the
conclusion of each instruction execution, and if an
interrupt is waiting {latched into an internal or external
flip flop)
it saves the key registers and branches to the
interrupt service routine.
With this implementation, no
priority amoungst interrupts is afforded, and they are
serviced on a
11
first come, first serve 11 basis.
A multilevel interrupt system assigns priorities
to the various interrupt sources which are polled to
determine the source of the interrupt.
Another type of
interrupt scheme is termed vectored interrupts.
This
hardware implementation affords more rapid response to
interrupts, in that each interrupt forces the address of
its particular service routine onto the address bus once
the CPU has acknowledged the interrupt.
Thus, no polling
of the external devices is required to determine which one
caused the interrupt, hence saving processor time.
Another highly desirable capability is for the
CPU, by program instruction command, to be able to
11
maskout 11 or ignore interrupt's during execution of the
main program when interrupts cannot be permitted.
I/0, Memory Expandability
Often, the system requirement may change due to
underestimation of the task, or the addition of functions
44
to the system.
The ease of expansion of the memory and
I/0, requiring a minimum of added circuitry and software,
should therefore be considered in the microprocessor
selection.
Microcomputers
Up to this point, the term microcomputer has been
used to describe a basic general purpose/stored program/
digital computer system composed of the microprocessor the CPU element, and the memory and I/O elements, and
miscellaneous support circuitry.
Presently, however, this
term is changing its meaning to that of a single integrated
circuit containing not only the CPU functions, but also
some minimal (and this amount is constantly increasing)
memory capability (RAM up to lKbytes, ROM up to 2kbytes,
and even PROM up to lKbytes), and I/O capability.
Addi-
tionally, extra functions such as internal timers and
digital-to-analog conversion is available "on board" the
microcomputer.
These single chip computers may often be considered
for small program applications, as the capability of the
CPU itself is generally equal to or superior to that of
its single IC CPU counterpart, and generally is software
upwards compatible.
However, with the single IC micro-
computer, certain features should be thoroughly evaluated.
These include the size of the on-board memory, its speed
'
J
45
and ease of expandability; the size of the I/O parts, the
number of ports, whether they are serial or parallel, and
their expandability; bus expansion capability; and the
availability of existing or easily modified hardware/
software development aids are all to be considered.
5.2
Support Circuitry
The number and types of support circuitry external
to the microprocessor must also be factored into the CPU
selection.
Often, the cost, power consumption, and proto-
typing/production time associated with the support
circuitry far exceeds that of the CPU.
As such, a firm
understanding is needed of the support circuitry functions
that are necessary and desirable.
Typically, from 10 to 50 integrated circuits may
be required for support functions.
Generally the various
kinds of chips are grouped into families that are compatible with particular microprocessors.
The families will
include a series of RAM, ROM, and PROM chips to create a
memory system; a series of interface chips capable of
handling both parallel and serial input-output functions;
and miscellaneous chips to enhance system capabilities,
such as controllers for interrupts and DMA operations.
Clock Generators and Drivers
As previously discussed, the clock generator and
driver circuitry may be internal to the microprocessor
I
J
46
chip, in which case only an external R-C combination or
crystal oscillator is required to supply the basic timing
reference.
Or for those microprocessors which require
this circuitry externally, the family of support ICs
usually contains a chip for this function, or it may be
built up from several discrete integrated circuits.
In
this latter instance, not only the frequency and stability
of the clock should be considered, but also the number of
phases, required interface levels, and total drive capability should be known.
Additionally, clock circuits
often recommended in the vendor literature may violate
their own timing specifications.
Therefore, the designer
should understand the timing requirements thoroughly, and
then use the vendor literature as a guide.
Bus Buffering
Microprocessor chips typically provide only limited
bus (address, data, and control) buffering on board, and
as such require external support circuitry to provide
this function.
Logic levels, dynamic loading, and whether
tri-state devices are to be utilized should be considered.
Also, any impact regarding time delays and proper maintenance of signal characteristics (risetime, falltime,
ringing) must be reviewed, and allowance for future
expansion included.
47
Memory
The CPU, being the central element of the microcomputer, is generally given the most consideration during
system design.
The next most important element, whose
evaluation is usually least understood from the systems
design aspect, is the memory system.
It is herein
referred to as a system because it encompasses much more
than the devices used for program and data storage.
The microprocessor technology progression has been
closely followed by the increasing use of solid state semiconductor memories, whose ever increasing storage densities, decreased size and power consumption, and higher
operating speeds, in many instances, surpasses the advances
of the microprocessor capability itself.
These semi-
conductor memories can be categorized into three basic
types:
1.
Read/write, or more commonly known as RAM
(Random Access Memory),
2.
Read only memory (ROM), and
3.
Programmable ROM (PROM).
RAM memory, as mentioned in section 3.4, is
typically used for operational storage, or temporary
storage of data during program execution.
However, it may
just as easily be used for program storage if the volatility (loss of information during power interruption) is
circumvented by means of a backup power source.
RAM's may
48
again be broken down into two basic groups, static and
dynamic.
The individual storage elements of static RAM's
may be thought of as flip-flops, while the storage in
dynamic RM1's is composed of capacitive elements, whose
charge must be periodically refreshed due to leakage of
the charge within the storage element.
Although static
RAM's offer higher speeds and require no refresh function,
they typically consume more power (in some cases greater
than 50% more), and are less dense (now 4Kbits per chip
compared to 16Kbits and more for dynamic RAM's).
ROM memory, as discussed in section 3.4, is
generally used for application program storage and is nonvolatile.
ROM is generally faster than RAM, and provides
higher bit densities per device.
The main drawback is
that the program must be masked into the ROM by the memory
manufacturer, and any changes require a new mask.
Thus
before a program is committed to ROM, it should be debugged
as completely as possible, and time should be scheduled
within the program plan to allow for the manufacturing
time.
Also, any cost and schedule impacts of having to
re-program the ROM should be determined, and evaluated
before committing to this approach.
The third type of memory, programmable ROM, overcomes the negative features of ROM, and reprogrammable ROM
is even more flexible.
PROM, as the name implies, allows
programming the ROM memory without requiring the
I
i
49
manufacturer's masking process.
Rather, this can be done
using a specific piece of equipment (termed a PROM programmer, to be discussed in section 5.4) which "burns"
the program into the ROM by opening fusible links within
the ROM.
This is accomplished by means of applying a
high current pulse or in some cases, a hair-thin laser
beam.
This process saves cost and turn-around time
associated with ROM programming.
PROM's, however, have an inherent disadvantage in
that a "1"
(fusible link open) cannot be transformed back
to a "0" directly.
This disadvantage has been overcome
through the use of reprogrammable ROM's which are capable
of being completely erased (returned to the all "0" states)
and programmed again repeatedly.
Two types are prevalent,
the electrically alterable ROM (EAROM), and the erasable
PROM (EPROM) .
The EAROM is erased by the application of
a voltage for a particular period of time, and they may
be reprogrammed.
The EPROM is erased by subjecting the
IC to ultraviolet light through a transparent covering
encapsulated on the IC itself.
Although these erasable/
reprogramrnable PROM's have overcome the disadvantages of
ROM and PROM, they are typically slower.
Input/Output (I/0)
The input/output interface of a microcomputer
system is generally implemented via I/0 ports, as shown
50
in Figure 5.2-1, for interfacing devices such as keyboards,
CRT
terminals, printers, di.sc memories, tape units,
instruments, control switches, indicators, and many other
types of data transducers.
CPU
nata "'ms
"Hi-Direction.
"t\us
l>rivers
Control/Status
Si11J1als
Address Bus
l
"q-<lffers
"""'.;:-]
Deco~ers
...
I/0
~
.
Port
Ho
~
tO
~
Ill
Ol
i
~
~
~
"' '-------
-+'
rr,
OJ
r-i
..,
,_
0
I/O
.,
8!.
-~
_:
~--------./
1-<
~L
J-4
-+'
~
0
0
Port
# 1
__--"
I/O
,------:-:-r Port
:
--
w
II 2
~
r
I/O
Port
K=
f--·----(
# N
·r-----,1
'-·
~~
w
l--
Fig. 5.2-1 Typical I/O Structure
In this generalized I/O scheme, the I/O data bus
is isolated from the CPU data bus by a bi-directional bus
driver.
When properly addressed and enabled, any of the
I/O ports may be used to route data to and from the CPU.
51
In the past, implementation of these I/O ports was
done utilizing discrete, general purpose circuits (AND,
OR gates, latches, multiplexers).
However, more recently,
I/O interface circuitry, both general and dedicated purpose, is being developed in LSI to unburden the CPU from
performing time consuming I/0 tasks.
These LSI devices
can operate almost independently of the CPU in some cases,
enhancing the overall microcomputer capability and throughput.
In many instances, the complexity of these LSI
devices exceeds that of many CPU's, e.g., floppy disc
i'Bi
~
1·'1
~·
,
'
controllers.
Although many of these devices may be used with
several different types of CPU's, some of the more powerful
ones are designed to work with only one family of chips.
Thus, understanding the types of I/0 support circuitry
available for a particular microprocessor can weigh heavily
in the final CPU selection decision.
The I/O LSI support devices can be classified
either as general purpose or dedicated.
The t,.;o most
common types of general purpose devices are for the serial
and parallel interfacing of I/0.
When defining serial
I/0 interfaces, several considerations are necessary.
A.
Is the interface synchronous or asynchronous?
B.
What is the band rate?
C.
What is the required status information to
and from the particular I/0 device?
52
D.
Is parity generation/check required?
E.
What is the format of the serial word?
F.
Is additional drive/receive, level shifting
or word reformatting circuitry required?
G.
Is temporary storage of the data required?
H.
What are the timing relationships?
Many serial interface LSI devices exist which have
extensive capabilities.
They are known by many names
(UART - Universal Asychronous Receiver Transmitter; ACIA Asychronous Communications Interface Adapter; SRT Synchronous Receiver Transmitter).
They all have certain
basic features which should be present to fulfill its
usage as a general purpose serial interface, as shown in
Figure 5. 2-2.
Serial data flows from the serial I/0 element into
a shift register in the ACIA (this term will be used for
convenience) Receive data register.
Here incoming bits
are assembled into bytes, to be sent to the microprocessor
on the system data bus.
Outgoing data moves from the sys-
tem data bus to the Transmit Data register, where it is
shifted out as a stream of bits with the necessary parity,
start and stop bits, etc.
53
I
Statue
Re~~:ister}-
_.Interrupt
I
Control
& Select
,
Logic
Control
SiFmals
-rra."Ta
To/From
I/0
Control
Register
~PIJ
Data
Control Sip:nall'l
I
'l'o/Vro
¢::
'transmit
Data
--1 Register
~
~
Receive
Data
Register
Data
~a
Fig. 5.2-2
ACIA Block Diagram
Operation of the interface is set up by software,
in the form of a single byte of control information stored
in the control register.
Among the parameters controlled
by the contents of this register are the \vord length,
parity (even or odd), clock rate for synchronization, stop
bits for each t.ransmitted or received character, whether
or not an interrupt will be generated when the receive
data register is ready to communicate with the microprocesser, and enabling or disabling the ready-to-transmit
interrupt to the microprocessor.
54
The status register stores the flags that notify
the microprocessor of important conditions at the interface, such as if data has been received from the serial
I/0; that the transmitter is ready for data to be sent
from the microprocessor; error indications such as overrun
(data is coming in faster than is being read) , I/O device
not ready, and parity error.
The ACIA can be operated in a synchronous data
transfer mode, in which case the microcomputer program
checks status flags and initiates all transfers of data to
and from the interface.
It can also be operated on an
interrupt basis, whereby the ACIA interrupts the microcomputer when certain conditions or combinations of
conditions are sensed.
Similarly, the same basic considerations that are
listed for serial interface, apply for parallel interface,
and again a host of parallel I/0 interface circuits exist.
The basic functions desirable in a parallel interface
circuit (or PIA) is shown in Figure 5.2-3.
Data from the microprocessor reaches the I/O
through either of two Parallel Interface Registers that
contain the necessary latches.
Data from the I/0 to the
processor is gated directly onto the system data bus.
'
55
Control
Linew
Control:
Register
A
Data
Direction
Rep;.l.ster
A
-A
.
Data
>
I"
•
I nterrupts
_p.<!
A1
'Parallel
Interface
Rep;ister
. A
·-;rChip
C'peration
_J,.
}
Contra~
Sil~nals
!o/Frora
I/0
I.op;ic
f-
Control Bus
~
Control
Lines
'flo/From
CPU
Control
RefZiater
'll
Data flUs
T
u
Fig. 5.2-3
Data
Directio
Register
~~
Par.allel
Interface .
RefZister
B
B1
B2
a,a
..
;
PIA Block Diagram
The processor selects the parallel interface device
it wishes to talk to by sending chip select control signals
to the PIA Control and Select Logic.
face device
~n
Each
par~llel
inter-
the system is selectively wired so that
these signals will activate only -the selected interface.
The PIA must be initialized through soft<.·Jare by loading
appropriate control bits in its Control and D::tta direc.."'tion
:registers.
These registers are each set up by a single
control byte, sent from the processor on the system data
56
bus.
Separate control signals to the Chip operation logic
specify which register will receive the control byte.
When
such a byte is received, its bits set the registers for
the kind of parallel interface operation desired.
The
Data direction register control bits specify which bits
of the Parallel Interface register are inputs or outputs.
The Control Register bits are used to establish when data
is sent or received, and when interrupts are to be generated to the processor.
These two basic general purpose I/0 interface
devices are programmable and can perform many common serial
and parallel I/O functions.
There are, however, many
instances where the complexity of the interface would
require too much software, hardware and CPU time if these
relatively simple serial and parallel I/0 devices were
used.
Thus, a whole new category of dedicated, intelligent
I/0 support circuitry is evolving to handle these interfaces.
Most of these dedicated interface circuits are
termed controllers.
They function almost independently of
the microprocessor to interface w1th the particular I/O
function.
The majority of these controllers are designed
to handle the interfacing of peripheral equipment, such
as discs (both floppy and hard), printers, high speed
paper tapes, magnetic tape.drivers,
keyboards.
CRT's, and display/
As the interfaces to these peripherals become
57
more standardized, the matching of controller capability
to peripheral requirements will become easier.
At the
present time, however, the diversity of these interfaces
for any one category of peripheral equipment is great,
and careful review must be made of the peripheral interface
requirements for timing, status monitoring and decision,
word formatting, and logic interface levels.
Additionally, controllers for common functions
utilized in microcomputer system are available in abundance.
Interrupt controllers which establish priorities,
control the interrupt request/acknowledge interface to the
CPU, provide vectored addresses for the interrupt service
routine, and employ selective interrupt masking, are
available.
Also, controllers are available to implement
the DMA (Direct Memory Access) function.
Although these general purpose and dedicated I/0
interface circuits can significantly reduce the overall
chip count of the microcomputer system and increase its
throughput and reliability, they do present some problems
of which the system designer should be aware.
Because of
the specialized design of many of these circuits, no second
sources are available.
This situation, although slowly
improving, will continue until a good deal of interface
standardization takes place.
Also, these circuits impede
benchmarking microprocessors for comparison since the
actual throughput of the microcomputer system is no longer
58
dependent on the microprocessor CPU capability alone.
Lastly, when considering these I/0 interface circuits, it
should be ascertained whether additional buffering, or
level shifting circuitry is required, and whether any
additional voltages are required.
As discussed in this section, the support circuitry
required to implement a microcomputer system, can greatly
influence the decision as to which
~P
to select.
The
types of circuits readily available to implement the
support requirements, their reliability, power consumption,
and ease of interfacing can mean the success or failure
of the system design.
5.3
Software
Although, as previously discussed in sections 5.1
and 5.2, the hardware capability of a microcomputer system
must be thoroughly understood to effect a successful
design, it is equally important that the software capability of the microprocessor and the means by which it is
transcribed into useful programs, be understood.
In this
section and the next, these software requirements will be
discussed.
Software in this context is not intended to mean
those application or operating system programs a microcomputer system executes, but, rather, documentation
available to support the development of the application
59
and operating system programs, the languages which can be
used, and the capability of the microprocessor instruction
set.
Documentation
Presently, one of the biggest problem areas in
microcomputer system design is lack of adequate documentation from the microprocessor manufacturers.
Although an
abundance of material may be available from a particular
vendor, the information contained in these manuals, and
the depth of coverage is often inadequate to guide the
designer through the hardware and software design, development, and production phases of the microcomputer system
design.
Typically, this information is provided in the
forms of a hardware design manual, software design manual,
and a programmers manual.
An evaluation of the documenta-
. tion should reveal that it possesses the following categories of coverage to insure its usefulness.
A.
Detailed information regarding the CPU
architecture, covering those aspects discussed
in section 5.1.
B.
Complete definition of the microprocessor's
instruction set, regarding data movement
between the CPU, memory and I/O; data manipulation (logical, testing, arithmetic) within
60
the CPU; and decision and control based upon
instruction execution.
C.
Extensive timing diagrams for memory, I/0, and
CPU interaction.
D.
Support circuitry available and required for
typical microcomputer system applications.
E.
Memory and I/O design and interfacing
information.
F.
Many examples of memory and I/O subsystem
implementation.
G.
Detailed specifications for individual memory
and I/0 integrated circuits, especially for
the larger controller types of I/O circuits.
H.
Programmers manual, including examples of
common subroutines and operating system blocks
found in many applications.
I.
Complete listings of the assembler, editor,
debut, and monitor programs available with the
hardware/software development aids packages.
J.
Sample test programs for verifying proper
op'eration of the CPU, memory, and I/0 elements.
Even though this documentation may exist, the
system designer should be aware of many potential problems
with it.
Many of the specifications quoted in the docu-
mentation can be misleading by themselves unless thoroughly
evaluated.
Typical of these specification pitfalls are the
61
number of instructions in the instruction set, clock rate,
cycle times, and interfacing.
Quoting the number of
instructions in an instruction set may be misleading.
The
number depends on whether it counts as distinct instructions the number of addressing modes available during data
movement, the number of registers available for register
transfers, or the number of conditions upon which a branch
instruction may be executed.
Such a count can increase the
total number by a factor of two, three, or more.
More
important in the evaluation of instructions sets are the
instructions available in the categories of data movement,
data manipulation, decision and control and I/0 operation.
This can be accomplished via benchmarking and will be
addressed in more detail later.
The clock rate and cycle time are often misinterpreted.
Although a microprocessor's clock rate may be
very fast, and its cycle times extremely short, the
inefficiency of its instruction set in terms of the number
of cycle times required per instruction, and the slow
access times of its memory, may cause its overall execution
time to be longer and its throughput lower than that of
another microprocessor with a slower clock rate, longer
cycle timing, but a more efficient instruction set.
Similarly with interfacing, claims of "TTL drive
compatability" and "reduced interface circuit" count, in
actuality may mean a single TTL load driving capability,
62
or a minimal system configuration for the chip count.
Additional drive capability, interface level shifting,
decoders, refresh circuitry, interrupt and DMA control,
and I/O circuitry often rapidly exceeds the quoted number.
Also, suggested examples for implementing clock, memory
and I/O interfacing, and memory refresh circuitry may
violate the vendor's own specifications.
Illustrations
and listings of software programs are sometimes laden with
errors and are poor examples of efficient programming.
They should be carefully studied and understood before
utilizing them directly in an application program or as a
guide for programming.
Thus, the full realization of the value of the
available documentation is possible only if the requirements of the microcomputer system-are concisely stated
and understood; the documentation is complete as previously
described; the pitfalls are identified; and benchmarking
is employed to estimate the efficiency of the hardware and
software elements of the microcomputer system in the
context of the desired application.
Languages
The software language which is used to program a
microcomputer system is dependent on several factors:
(1) the expected size of the completed application program,
(2) the number of systems to be produced,
{3) the time
63
available for the software programming, integration and
checkout phases,
(4} the expertise of the programmer,
(5} the computer and economic resource availability for
utilizing high level languages, and (6) the likelihood of
future changes.
For the purposes of discussion, the software
languages are broken up into three levels:
Machine
Assembly
Higher Level
Machine Language
Machine language programming, or programming in
the 0/1 binary patterns associated with the microprocessor
instruction set rnneumonic codes, can be considered when
the size of the application program is relatively small
(less than 100 orders) or the comp.uter facilities are not
available or do not have higher level languages.
Machine
language programming affords an inexpensive and rapid
means of programming the system because it does not
require additional equipment and the programmer is most
often the hardware designer who is intimately familiar
with the way in which the hardware and software should
interplay.
The disadvantages are reflected in the pro-
grammer's need to keep track of all memory addresses for
cross referencing within the program, which is only
64
realistic for small programs.
Proportionately, as the
program size grows and with the addition of subroutines,
translational errors of generating the correct machine code
increase.
Also, small changes in a program may require
modifying the entire program.
Assembly Languages
Assembly language, or programming using the codes
of the specific microprocessor instruction set, is the
predominant level of software programming presently
utilized for microcomputer systems, because it does not
have the disadvantages of machine language programming.
Additionally, it aids the designer in functionally understanding the overall microcomputer system, without being
specific about the meaning of each bit pattern.
This
allows programming longer programs more efficiently and
quickly, and easily implementing program changes.
Programming in assembly language, though, requires
external translational capability by an assembler, which
is a program residing in either the hardware/software
development equipment, or in some other computer.
This
capability requires capital expenditure, which can be
quite large for long programs or for ones requiring
multiple iterations before the final program has been
developed.
On this latter point, off-line computer capa-
bility as opposed to the hardware/soft development
65
equipment, which can be co-located with the mircocomputer
system hardware, carries with it the expense and long
turn-around times associated with most time share services
utilized to develop software programs.
Higher Level Languages
Higher level languages, such as FORTRAN and BASIC,
used on many full size computer systems, are slowly being
adapted for use with microprocessors, along with higher
level languages developed for microprocessors, such as
PL/M.
These higher level languages allow programming in
English and mathematical like statements, which are
easier to understand than their assembly language counterparts.
This capability makes the microcomputer system
hardware transparent to the programmer in that it is not
necessary for him to understand the
~nternal
operations
performed for each instruction execution, and allows
program generation to begin earlier and can, in most
instances, begin simultaneously with the hardware development, provided the system requirements have been thoroughly
defined.
This provides for a logical separation of the
tasks of hardware and software design, affording the most
efficient usage of the expertise available from both areas.
However, there are some definite disadvantages to
the use of higher level languages.
The translation from
the high level language to machine code is done via a
66
compiler, which inserts many lines of machine code for each
language statement.
No concentrated attempt is made to
minimize the number of lines of machine code, and thus the
compiled programs tend to be longer than if written in
machine code or assembly language.
This drawback is
somewhat offset by the increasing densities and falling
costs of memory chips, and expanding memory addressing
capability of the CPU's.
Another disadvantage is that
during the integration and checkout phase it is extremely
difficult to trouble shoot a software problem by trying
to correlate from the failure in machine code back to the
higher level language statement.
Although each language has its own advantages and
disadvantages, regardless of which language is chosen, the
key to programming is clearly that of specifying the
application program requirements and thoroughly documenting
the programming effort to aid in all phases of the microcomputer system design.
Instruction Set Evaluation
As previously stated, evaluating the capability
of an instruction set by counting the number of instructions is misleading.
Rather the particular microprocessor
instruction set instructions should be categorized and
evaluated in terms of data movement, data manipulation,
decision and control and I/0.
i
67
Most microcomputer applications are dedicated
towards sensing and control of external devices or equipment.
As such, the efficiency with which data (represen-
ting sensed parameters, program steps, and commands) is
moved between locations, affects the overall capability of
the microcomputer system.
This class of instructions
termed data movement which route the data from one point
in the microcomputer system or internal CPU to another
without altering the data, should consist of the following
subclasses.
Each of these instructions should specify the
source of the data, the direction of movement and the
destination of the data.
Load - These instructions move data from memory
to CPU, and in those instances where I/O is
handled like memory, from the I/0 to the CPU.
This subclass is implemented via the LOAD or
MOVE instructions.
Store - This subclass moves data in the opposite
direction from the Load subclass, i.e., from the
CPU to memory or I/0, using the instructions
of STORE or MOVE.
Register Transfer - Movement of data between
registers internal to the CPU should be possible
through the instructions of LOAD, EXCH (Exchange),
and XFER (Transfer) .
68
Stack and Stack Pointer - Important during subroutine and interrupt handling, instructions to
move data into and out of a register stack, be it
internal to the CPU or in external memory, are
PUSH, POP, or PULL.
I/0 - For those microprocessors which treat I/O
separately from memory, separate instructions
of IN and OUT move data to and from the CPU or
memory to the addressed I/O device.
To facilitate those instructions which move data
in and out of memory, multiple addressing modes prove
useful.
Among the many types of addressing modes available
for different microprocessors, the following are considered to be the basic ones which should be present in a
microprocessor.
Direct Addressing - Often termed "page zero"
addressing, this is typically a two byte
instruction:
the first contains the op code of
the subclass instruction and the second byte
contains the memory address of the data which
is located in the first 256 memory locations.
Indirect Addressing - In this mode, the memory
location accessed contains the address of the data
rather than the data itself.
69
Indexed Addressing - This mode utilizes the index
register of the CPU by adding the second byte of
the instruction to the index register to form the
effective address which points to the data
memory location.
Relative Addressing - Utilizing the program counter
(PC) of the CPU for an eight bit machine, access
to ·locations within plus or minus 128 locations
from where the PC presently points are made
possible by adding the complement of the second
byte of the instruction.
Immediate
Typically for eight bit microprocessors,
this is a two byte instruction, with the first
byte being the op code of the subclass instruction,
and the second byte being the operand.
Although
this addressing mode is not used to address a
memory location, it is essential for loading data
into CPU registers.
The second category of instructions includes those
which modify the data according to arithmetic or logical
operations, and are termed data manipulation.
All of
these instructions should apply within the CPU not only
to the ACC, but also other registers.
Also the ability
to utilize them to manipulate data within memory without
moving it to the CPU, greatly enhances the overall
70
capability of the microcomputer system.
Each instruction
should specify the source of the data (which in many
instances is implied, particularly when the operation is
performed on data contained in the ACC) the operation to
be performed, and the destination of the data (again,
implied in many instructions, as such arithmetic, to be
the ACC).
These instructions should include:
ADD
INCREMENT
SUBTRACT
DECREMENT
COMPLEMENT
COMPARE
CLEAR
DECIMAL ADJUST
SHIFT (Left or right)
AND
ROTATE (Left or right)
OR
EXCLUSIVE OR
Most of these functions are self-explanatory,
with the exception of DECIMAL ADJUST.
This instruction
allows the conversion between BCD and binary data and
facilitates the interface with the ever-increasing number
of BCD I/0 formatted devices (digital panel meters,
indicators, instruments, etc.).
The third category of instructions, for decision
and control, enables the user to alter the normal sequential flow of instruction execution.
Again, there are
many variations on the instructions within this category,
but they resolve into four subclasses.
71
Test - These instructions alter flags according
to relationships of operands, states of input
pins, on bit(s) within a register, and are
implemented via the BIT TEST or COMPARE
instructions.
Branch/Jump - The change of the sequential program
execution occurs under these instructions either
unconditionally, or conditionally based upon states
of bits in a program status word (PSW) register,
or results of arithmetic and logical operations.
These include the JUMP, SKIP, BRANCH, CLEAR FLAG,
and SET FLAG instructions.
Subroutine - This subclass of decision and control
instructions allows the programmer to use a
specific set of program instructions repeatedly
without having to insert this set in the main
program each time he wishes to use it.
Rather,
JUMP to or CALL subroutine instructions direct
program flow to execute the subroutine, with a
RETURN from subroutine directing the flow back
to the main program.
Interrupts - These instructions provide the
control over the interrupts of the system, and
should include WAIT FOR INTERRUPT, HALT, and
ENABLE DISABLE INTERRUPTS for those which are
maskable.
72
Finally, the fourth category of instructions
should be
pres~nt
for those microprocessors which do not
treat I/0 as memory.
There is basically just an INPUT or
OUTPUT instruction which provides communication with the
addressed I/0 device.
A review of the instruction sets for the many
different microprocessors available reveals many derivatives of these basic instructions, with slightly different
mneumonics and hardware implementations.
However, if
the instruction set contains these basics, it should be
capable of being readily configured and programmed for
the vast majority of present and foreseeable microprocessors applications.
Benchmarking
Briefly stated, benchmarking is the writing of
software programs to implement a task or tasks involved
in a particular application, utilizing the instruction set
and instruction execution times of each microprocessor in
comparison with other microprocessors.
This comparison is
done by counting the number of instructions to see which
microprocessor required the fewest lines of code, and adding the instruction execution times to determine which
microprocessor executed the program the fasters.
Benchmarking has been recommended as the most useful tool for projecting microprocessor capability into
73
the end item application.
It not only affords a means of
determining program memory size requirements and execution
speeds, but also gives an indication of the difficulty of
the actual programming effort associated with the microprocessor dedicated instruction set.
Additionally, it
provides a rough estimate of the programming time required,
and the best estimate available of the microprocessor
capability without large capital outlays to purchase two
or more microprocessors systems so that the programs can
be actually run on the hardware for comparison.
Benchmark programs should be keyed towards tasks
associated with a particular application.
However, to
properly evaluate the microprocessor capability as
thoroughly as possible, these benchmarks should include
the following types of operations:
1)
Moving data between CPU and memory; CPU and
I/O; and memory and I/0.
2)
Manipulating data (internal to CPU and in
memory).
3)
Handling interrupts.
4•)
Memory search (or peripheral I/0 memory device,
like a disc or tape storage device).
5)
Programs including subroutine branches and
loops.
Since the microprocessor executes tasks serially
(one step at a time), the ease with which it routes data
74
and controls its movements is directly proportional to its
throughput capability.
Similarly, in controller operations, the ease with
which data can be manipulated, i.e., tested for states,
branching based on test results, modification of data,
allows closer real time operation with the external
environment it is controlling.
This also applies in the
area of interrupt handling, because many real time applications are predicated on timely servicing of devices
which may interrupt normal program execution flow.
The
capability to rapidly recognize or ignore the interrupt,
as desired, store present program execution status, and
begin executing the interrupt service routine, allows many
asynchronous, random requirements on the microprocessors
time to be handled.
In many data processing, or testing applications,
the ability of the microprocessor to perform rapid searching in memory, be it internal to the microcomputer system,
or external on a mass storage device, dictates the throughput.
This capability should be thoroughly exercised in
the benchmarking process.
Its capability to do subroutines,
nesting of subroutines, different types of branching, and
looping show up in almost all microprocessor applications.
Although benchmarking would appear to be the
panacea for microprocessor selection, it has several major
drawbacks.
The need for benchmarking obviously exists at
75
the beginning of the design process.
As such, the
familiarity and experience with the candidate microprocessor instruction sets directly reflects the number
of lines of code written to implement a task.
time allowed for
~P
The limited
selection under most design schedules,
often precludes optimization of the task programs.
One
possible way of alleviating this situation is to have
someone else more familiar with the microprocessor instruction sets write or review the program codes.
However,
almost no program is written error free the first time and
multiple iterations are usually required, even by experts,
before the program can be considered roughly optimized.
Vendor examples of benchmarks are misleading if
used for comparison in that they tend to address tasks
which show their particular microprocessor in its best
light.
Another factor influencing execution times is
memory speed, and often forgotten delays inherent with
memory interface support circuitry.
Lastly, the prolifera-
tion of complex support circuits, handling many tasks
almost independent of the microprocessor, make it difficult to assess the microcomputer system's true throug'hput.
Thus, when benchmarks can be devised for a specific
application task, the usefulness may be ambiguous unless
the program is directly related to the end item application, detailed attention is paid to the programming, and
external factors are taken into consideration.
76
5.4
Hardware/Software Development Aids
With the decreasing number and cost of the inte-
grated circuits which make up a microcomputer system and
the reduced time required to interconnect them, the time
and cost associated with software generation, software
checkout, and hardware/software integration has become the
predominant factor in the overall system cost.
Fortun-
ately, hardware/software development aids have been
designed to simplify and expedite these costly design
areas.
The developmental aids are becoming a necessity
where longer application programs are required, where
multiple product applications are centered around one
particular microprocessor, and where the size of the task
requires a separation of hardware and software design
personnel.
Presently, however, the development aids are
designed to work with only one or two microprocessors,
they require a high initial purchase investment ($10,000
and up), and the capabilities vary considerably.
Thus it
becomes important that the development aids and their
capabilities for the alternative microprocessors should
be included in the
~P
evaluation process.
During the initial stages of development, the
development system hardware is used in conjunction with
special purpose software programs to enter the source
application programs into the development system memory
l
'
77
and edit them.
When completed, these source programs are
translated into executable machine language object
programs.
These object programs can then be run either
on the development system computer simulator, or, if the
hardware/software development system possesses an incircuit emulation capability, the object program can be
run on the actual user prototype hardware.
In either case,
other special purpose software programs allow the user
to monitor the execution of the object programs, and
interrupt, interrogate, and modify results obtained during
the run.
The hardware/software development aids may exist
in either "off-line" or "on-line" implementations.
Off-
line development aids generally consist of special purpose
software programs, such as editors, assemblers or compilers, simulators, and monitor/debug, which are run on
computer systems which may be large, such as time sharing
systems, or on smaller dedicated systems, such as minicomputers.
Although this off-line development aid capa-
bility is typically more powerful in terms of application
program manipulation, coding, and debugging, and allows
independent development of the application programs while
the prototype microcomputer system hardware is being
developed, it has several disadvantages which have caused
. on-line hardware/software development aids to become the
more prevalent implementation.
Time sharing services,
78
although faster, are generally more expensive when large
application programs are required, or multiple iterations
are required to generate a correct program.
Also,
although many software simulators are available to emulate
the prototype microcomputer operation, they always possess
some peculiarities different from the user microcomputer,
particularly in the area of program execution timing.
Thus, even though a program has been developed and
simulated properly on the off-line computer system, it
still may require modification to run correctly in the user
microcomputer system.
Lastly, the cost of these off-line
development aids recurs at each use, whereas the total
cost of on-line aids is only of the initial capital
investment.
For these reasons, the evaluation of hardware/
software development aids will be centered around those
which are on-line.
On-line hardware/software development aids are
usually co-located with the prototype microcomputer system
hardware, offering parallel development of the microcomputer system hardware and software, and facilitating
rapid and efficient detection,' modification, and correction
of problems associated with either.
The on-line hardware/software development aids are
actually composed of a microcomputer hardware system
(usually termed the development system which may use the
same CPU as that of the user prototype) ; associated
I
i
79
peripherals for man/machine interface and program storage;
and a set of special purpose software, generally consisting
of an editor, assembler, and monitor/debug programs.
The
major considerations for an evaluation of a development
system is its hardware capabilities and the basic features
available in each of the special purpose software programs.
Development System Hardware
The development system hardware configurations
vary widely, but the basic system should consist of the
elements shown in Figure 5.4-1.
The development system,
being essentially a microcomputer system itself, is configured in the same manner.
Each of the elements inter-
face with the other over a system bus, consisting of the
address, data, and control buses.
The development system
should operate in a monitor and a user mode.
In the
monitor mode, the system performs as a standalone development tool, allowing software programs to be entered into
the system memory, edited, assembled, filed on external
storage for future use, and loaded for execution.
This
entire process is performed through simple commands through
the system I/0 to the user terminal.
In the User mode,
the system's memory and peripherals may be dedicated to
the user's own prototype system, and the performance of
that system controlled and monitored via in-circuit
emulation.
Both of these modes are controlled by the CPU
i
(Ext~rnal
sj·orage)
Ta-pe
Disc
Drives
· CRT Dis-play/
Keyboard
IFron t Panel
Controls
~
Cabl~
! "
\.7
l.n-Circuit
I
~7
System
Peripheral
System
Memory
Controllers
Monitor
To User
Prototy-pe
Hardware
Emulation
&
Trace
I)
~
SYSTEM BUS
,l
I
\I
v
Processor
&Dedicated
Memory
System
Ta-p
Read.er
j
Gen!!!ral
Purpose
I/O
\
71
Tape
Punch
Line
Printer
"F'i~re.
1/0
General
Pur-pose
DMA
Ports
PROM
I
P~ogrammer
Tel~type
·
User
Devices
User
Devices
5. 4-1 Hardware/Soft-w·are Development System
CD
0
81
processor and its associated dedicated memory.
The processor and dedicated memory element contain
the CPU and some combination of RAM and ROM memory.
The
memory may vary in size from less than 256 bytes, upwards
to 4K to 8K bytes.
This memory should contain at least
a bootstrap loader capable of loading the development
system operating system software from external storage
into the system memory.
The operating system should
contain the programs necessary to interface with all user
accessible system peripherals, and may also contain the
basic monitor and debug functions which will be discussed
later.
The CPU processor is typically the same one which
will be used in the end item hardware so that the performance during the execution of software programs is
identical.
However, they need not be the same if the
development system CPU can accurately simulate the user
CPU.
In those development systems which possess in-circuit
emulation capability, it is becoming more prevalent for
the CPU resident in the in-circuit emulation element to
be the same as the user CPU, and for the development system
CPU to be entirely different.
The system I/O element provides dedicated serial
and/or parallel interface to the peripherals of the hardware/software development system.
The peripherals accessed
through this I/O could include a paper tape/punch
{preferably high speed) and a teletype.
Both of these are
i
82
rapidly being replaced by CRT display/keyboards, and
magnetic tape or disc storage.
These peripherals provide
a larger viewing window and higher speed, more dense
program storage mediums.
Also, a line printer can be
invaluable during all phases of the development by providing hard copy printouts of the software, which may be
studied and corrected off-line from the development system.
It also provides accurate documentation of the end item
programs.
Similarly, PROM programming capability allows
on-line transfer of the application programs in the system
memory (which have been checked out) , directly to PROM,
which will be inserted in the user's end item hardware.
A general purpose I/0 element should be present
which provides several I/0 ports (generally two to four,
8-bit input and output), for connection to the user prototype hardware.
These may be used to substitute for I/O
hardware yet undeveloped or fabricated, or to simulate
external hardware to which the microcomputer system will
eventually connect.
Also available in some developmental systems, is
a general purpose DMA element.
This element facilitates
high speed data transfer between the development system
memory and user I/0 devices or peripherals associated with
the end item hardware.
The system memory is composed of RAM circuits,
typically configured in 4K byte increments, up to a total
83
of 64K bytes.
A minimum system memory size is dictated by
the size of the editor, assembly, debug and monitor programs, and peripheral control programs if these are not
resident in the dedicated memory.
Generally, this would
amount to between 16K bytes and 24K bytes.
However, if
the system memory is to be used to store large application
programs during the user mode, a full 64K byte memory may
be required.
Most hardware/software development systems are
presently implemented with discs (primarily floppy discs
because they are less expensive) as the external storage
medium, and CRT display/keyboards as the primary man/
machine interface terminal.
Because of the complexity
of these peripherals and their associated interfaces,
peripheral controller elements are resident in the development system to provide reduced loading on the processor,
so that the processor time can be more efficiently utilized
for software generation and hardware/software checkout.
The system monitor element varies in size and
function between the different hardware/software development systems, due primarily to the degree of front panel
control capability.
Many development systems provide
front panel displays and controls to monitor the address,
data, and control buses; interrogate and modify the
contents of memory and internal CPU registers; and switch
between the various modes of operation.
However, the
84
trend in development systems is more towards a
11
turn-key 11
type, where all control, display, and monitoring is done
through the system associated peripherals, with only
bootstrap loader initiate and reset control switches on
the front panel.
Those development systems, with expanded
front panel displays and controls are now becoming scaled
down versions of full development systems, and are utilized
for field servicing of microcomputer systems.
One of the most recent and useful tools of the
development system, and probably the most preferred
capability, is that of in-circuit emulation.
Prior to
in-circuit emulation, software and hardware were developed
independently, and then integrated at the point at which
it was felt both functioned correctly as independent items.
Invariably, misinterpretation or complete lack of understanding of the requirements for each led to incompatibilities which required tedious and time-consuming tracing
and debugging of software errors because the development
system could not directly interface its powerful special
purpose software and hardware capabilities into the user
prototype hardware.
In-circuit emulation allows a direct
hardware connection into the user prototype hardware, by
inserting a connector in place of the user CPU IC.
It
thus makes available all the development system capability
for the execution, monitoring, debugging and modifying
the application software run on the user system, and
85
detecting hardware/software incompatibilities.
In the
user mode, the in-circuit emulation element allows the
user to monitor the execution of the application software
in real time, and set breakpoints to stop program execution
on any address, data or control bit patterns.
Once
stopped, the system returns to the monitor mode, where the
monitor/debug software program can be utilized to perform
the functions discussed later.
Additionally, a capability sometimes termed trace,
or real time debug, may be coupled with the in-circuit
emulation.
This capability allows the user to create a
window about a specific hardware or software event, in
which the events leading up to and/or following may be
stored and viewed to analyze the cause of a program
execution problem.
The window is started based upon user
specified conditions, which can include specific bit
pattern combinations on the address, data, and control
buses, or upon some specific event occurrence within the
user hardware.
At that point, storage of the monitored
bus or event data is initiated in a limited space memory
(between 32 and 256 bytes) , which can then be printed out
on the user terminal for analyzing the problem.
The
specification of these event conditions is done via the
monitor/debut software programs.
86
Development System Software
The special purpose software programs available
with the hardware/software development system vary in
capability as much, if not more, than the different hardware configurations.
Although almost all of these program
sets consist of an editor, asserrbler, and monitor/debug
programs, an understanding of the basic desirable capabilities is essential in assessing their usefulness as a
hardware/software development aid.
The interrelationships between the operating
system, editor, assembler, debug/monitor programs in the
monitor and user modes is shown in Figure 5.4-2.
Upon
development system power up, the bootstrap loader is
initiated, loading in the operating system from external
storage, or branching to i t if it is resident in the
development system.
The operating system initializes
the development system and notifies the user via the
terminal and peripheral control.
In the monitor mode, the
user may request that the assemble, edit, or debug/monitor
functions be initiated.
The operating system fetches
the appropriate program and notifies the user of such.
Most often, these programs are stored externally on
cassette tapes or discs, and are loaded into the system
memory for use.
The user can thus jump back and forth
during the software generation phase to produce the
software application programs.
,
,
'
Power
01~
Loader
eripheral
User
_ _ _,.. Controlle .___.... Terminal
_,
r
I
l
'Debug/
Assembler
Monitor
I
L..-
---- -
____
,_-
Editor
I
I
l
File
_
_.:--
--
User
Mode
~--------_.Breakpoint
Figure 5.~-2 Software Interrelationships
_
_.!I
Monitor
Mode
88
Having generated the application programs, the
user requests, via the operating system, that the user
mode be entered and program execution initiated.
From
here, it becomes an iterative process, of detecting errors,
branching back to the debug/monitor program, and correcting
the errors through the assembler, editor, and debug/monitor
programs.
A flow diagram of this iterative process is
shown in Figure 5.4-3.
The basic capabilities required in these special
purpose software programs to effectively implement the
above described software development flow, are as follows.
The editor program must take the source program,
written by the programmer in assembly or higher level
language, which is entered through a keyboard or paper
tape, and transfer it to a "file" in the development system
memory.
The editor acts on special commands from the user
to add, delete or change portions of the source program.
Editors can vary significantly in the ease with which they
permit a user to make changes in the program.
For example,
some editors can operate only on entire lines in a program,
whereas others can add, delete or replace arbitrary
character strings in the program.
Although the mneumonics
associated with these commands vary, the set should include
the following.
89
Enter
!
Source
Prop:ram
--.
Text
Editor
~
Source
Program
Text
NO
Pro~am
Assembly
utp
Listing
OK ?
Assembler
'
YES
-
- - -
Object
Program
-
-
~
-
- - - - - ---- -
Debug
Trace
&
~
+
~~
!'ron-am
T.le 'bup: and
Reassembly
tetected
Program
Errors
NO
Text
Editor
-
+
~·- - - -- - -----Undated
Source
Program
Reasseinbl
s
Object
Prop:ram
.
f---+
Run on
~ulation
~Prototype
Hardware
9
Detected
ErrorsDebug
Real-'l'ime
~ulation
With
Prototype
Fardware
•
NO
'iext
Editor
,
Correct
?
Comnleted
Program ~rne1
Into PROM
~igure
~
Reassemble
.6
Updated
Source
~-ogram
- ,- - - - - - -- - - - Completed
Object . __. PROH
-• Program
Programmer
Program
....___
_____
YES
5.4-3 Software Development Flow Diagram
90
Insert - Inserts new text from the terminal into
the current text file of the system memory.
Next
- Moves forward in the file text by the
specified number of lines.
Back
- Moves backward in the file text by the
specified number of lines.
Go To
- Goes to a specified line in the file text.
Bottom - Moves to the bottom or last line of the
file text.
Change - Change a specified line or character
string in the file text to the entered
text.
Delete - Erase the entire current line or specified
character string.
Save
- Outputs the entire file text from system
memory to external storage.
Put
- Outputs a specified block of file text to
external storage.
Get
- Inserts a specified block of text from
external storage into the current file
text at the specified location.
Print
- Outputs a specified number of lines to
the user terminal starting at the current
file text line.
Quit
Return control to the operating system.
I
,(
91
Assembler
The Assembler program translates the edited source
program written in assembly language into machine code
(object program) executable by the microcomputer system.
Characteristics of the assembler program to be considered
during an evaluation of its capabilities is whether it is
a single or multiple pass; whether it is a native or cross
assembler; is it resident or non-resident; if it has
macroinstruction capability; does it have a flexible
format; and does it provide error messages.
r.iost assemblers work on a multiple pass (usually
two) basis where the source program is read through
several times to generate the final object program.
How-
ever, single pass assemblers are available which run
somewhat faster than multiple pass ones, but limit the
size of the source program being assembled in that they
must both be located in the system memory at the same time.
A native assembler is one which is run on the "online" development system.
Cross assemblers operate on
"off-line," generally larger and different computers to
generate the object program.
·These cross assemblers may
be written in higher level languages, such as FORTRAN or
BASIC, which is not to say that they will translate source
program written in FORTRAN or BASIC to object program code.
Rather a FORTRAN assembler is an assembler program written
92
in FORTRAN to translate assembly language source programs
to object code.
Resident assemblers exist in ROM memory within the
development system, which is available upon power up.
The
non-resident assembler exists on external storage and must
be loaded into the development system each time its use is
required.
If the read-in peripheral is slow, this can
waste time. However, the introduction of floppy discs has
greatly facilitated non-resident software program usage.
The macroinstruction capability allows the programmer to define a series of instructions by a name, and
at any location throughout the source program where the
name is found, the assembler will automatically insert the
series of instructions.
This capability proves most useful
for inserting common instruction sequences into many
different subroutines, e.g., interrupt service routines
where it is desired to store the contents of CPU registers
at the moment of interruption prior to beginning the
service routine.
A flexible format and the availability of error
messages are very important to the usage of assemblers.
Assemblers require that certain syntax rules be followed
when writing the source program.
As such, the more
restrictions imposed by these rules as to format or symbol
usage, the more errors that are likely to be generated
because of the programmer's inability to remember many
I
•
93
detailed rules.
Thus, a format which allows many different
symbols and is not critical with regard to the entered
source program line format (such as which column certain
fields begin in) allows faster and freer, more creative
generation of the source program.
However, even with a
flexible format, errors will be encountered.
Thus the
capability of the assembler to recognize such errors and
generate messages clearly defining the error and where it
occurred, can save the programmer hours of looking for
missing commas, illegal characters, or missing labels.
Monitor/Debug
The Monitor/Debug special purpose software program
facilitates the testing of the object program on the
development system or the user's microcomputer system
during in-circuit emulation.
The monitor/debug program
accepts commands from the user to perform such functions
as displaying or printing out contents of the microcomputer
memory, or the contents of the registers in the CPU,
modifying RAM memory contents, starting execution of the
object program from a specific memory location, and setting
a breakpoint.
Execution of the program stops when the
breakpoint instruction is reached at a specific memory
location, or whenever a given hardware condition is met.
The Monitor/Debug program should possess at least
the following basic command functions:
94
Load
- This command loads the designated
user program from external storage
into the system memory.
Execute
- This command instructs the development system to begin executing the
user program at a specified location.
Display
- The display command requests that a
specified location in memory or CPU
register contents be printed out or
displayed.
It should also display
locations ahead of and behind that
memory location, or the contents of
all (or some of the more important)
registers in the CPU.
CRT displays
offer a decided advantage over teletypes in that the outputting of data
under this command is faster and can
offer a wider simultaneous display
window.
Store
- This command allows changes to be
patched into specified memory locations or CPU registers, to overcome
any programming errors, or overlooked
program steps.
This prevents having
I
'
95
to load in the editor and assembler
programs to make a program change.
Move
- When it is desired to transfer a
block of memory within the system
memory to another location, this
command is exercised.
Save
- This command outputs the specified
user program in the development system internal memory to external
storage.
Quit
- This command forces control of the
development system back to the
operating system program.
Three other commands, which give the Monitor/Debug
program the majority of its debugging capability are:
Set
Breakpoint
This command should allow hardware or
software breakpoints to be established.
If hardware, specified combinations
of address, data, and/or control bit
patterns can be stored in the trace
element of the development system,
and will cause a program halt when
these conditions are sensed during the
user program execution.
When a break-
point is reached it is desirable to
96
print out the contents of the CPU
registers not only at that points,
but during execution of instructions
leading up to that point.
This
information is stored in a memory
stack in the trace element, and
typically the more data stored under
any one instruction, and the more
instructions stored, the better.
Trace
- This command is similar in operation
to the Set Breakpoint, except that no
program halts are generated.
Rather
it continues its normal execution
while the address, data, and control
bit patterns are sensed and stored.
This allows trouble shooting while the
development system executes the user
program in real time.
Single Step- This command affords detailed trouble
shooting of a program bug by singlestepping one instruction at a time,
through the program problem area.
At
each step, the contents of the CPU
registers should be outputted, and the
other commands of the Monitor/Editor
program may be used to examine memory,
97
and modify memory or CPU register
contents.
As has been discussed in this section, the Hardware/Software Development aids can greatly reduce the
time, effort, and cost required for application program
generation, checkout, and hardware/software integration
and thus are a key ingredient in choosing a CPU.
If not
available, or if lacking in capability, they can jeopardize
the overall success of a microcomputer system design.
Conclusion on the Functional Capability Review
The functional capability review provides an
in-depth look at the basic desirable CPU, support circuitry,
and development aids aspects.
Although a functional
capability review considering the factors heretofore
presented would reveal superior or inferior capabilities
for any one candidate microprocessor versus the other
candidates, typically the overall capability for any one
versus another would be essentially equivalent.
It is at
this point most systems designers make a decision, primarily because they know of no other means by which to
further evaluate the choices.
Further evaluation can be achieved through the use
of cost effectiveness, resulting in a more definitive
decision as to whether the choices are indeed equal, or
that one is superior to the others.
For the purposes of
98
the cost effectiveness evaluation, it is assumed that the
functional capability review has narrowed the choices for
the controller application to two, which will be labeled
processor A and processor B.
6.0
Cost Effectiveness
Cost effectiveness has, as its basis, the premise
that major decisions concerning the solution of complex
problems could be improved if the factors which influence
these decisions are made visible and quantitative.
These
factors include not only objective factors such as the
number of internal registers in a CPU, but also judgmental
factors such as customer values and uncertainty.
As illustrated in the previous section, many of
the objective factors can be analyzed quite readily in
terms understandable to the systems designer.
This type
of analysis though, to be useful in making the final
decision, must be carried further to ascertain the value
of these elements to the overall system.
The values are
expressed in terms of the desired functions, e.g., I/0
capability, interrupt capability, which are quantifiable,
and those elements which have a definite bearing on the
decision, but which are not so easily quantified, e.g.,
vendor support, hardware/software development aids, etc.
Utility theory provides the means for evaluating further
all these elements of the decision.
6.1
Introduction to Utility Theory
Utility theory basically states that the worth or
utility (U) of a design alternative is a function of the
99
100
decision criteria (Y j) upon \>lhich the decision is to be
based.
Each decision criterion has associated with it a predetermined threshold or aspiration level, which it should
meet in order to satisfy the systems requirements.
As
such, exceeding this threshold provides increased worth
or utility of that particular criterion, and vice versa,
falling short of the threshold causes decreased utility.
This is illustrated in Figure 6.1-1, where the transition
from below the threshold to above it causes a rapidly
increasing utility in close proximity to the threshold
value.
Threshold
Desirable
Region
Utility
Utility
~agnitude
.
.
YT"~,,
of Criterion
a}
Fig. 6.1-1
Utility Curve/Decision Criteria Threshold
Relatio~ship
101
This rapid transition about the threshold level
can be approximated by a utility level shift at the
threshold as shown in Fig. 6.1-1.
This curve thus repre-
sents a utility function for a particular decision
criterion.
If the uncertainty of achieving exactly each
decision criterion threshold were zero, i.e., if it was
known that the threshold would not be exceeded or underachieved, the CPU choice would be simple.
However, in
reality there is a certain probability associated with
each processor of achieving the particular decision
criterion threshold, and must be included in the utility
derivation.
Also, associated with each decision criterion
is the relative importance or weighting of that criterion
compared to all others in making the final decision.
Lastly, there are certain elements in the final decision
over which the system designer has no control, termed the
states of nature.
For the controller application, the
number of stations the customer retrofits is purely up to
them.
As such, the system designer can only predict with
some probability, which decision will be made.
Obviously there are judgmental decisions being
made throughout the derivation of the total utility function.
These include the selection of the decision crite-
rion; the probability of meeting that threshold f,or a
particular alternative; and the probability of the states
102
of nature in influencing the decision.
The engineering
expertise of the system designer must now be brought into
the decision process by quantifying these previously
unquantified (or unquantifiable) elements in the decision.
There are various methods by which realistic
quantifying estimates can be made for each of the previously mentioned judgmental factors.
Certainly one is for the
system designer to make his own best estimate, particularly
since he should have the best overall knowledge of the
system.
However, this introduces errors due to his own
fixed biases, consciously or unconsciously, and his
expertise is most likely not evenly distributed over all
the factors involved in the decision.
Other methods which are widely used are engineering
meetings or "brain-storming" sessions, which provide a
means of injecting additional expertise into the estimation
by providing open discussion of each of the factors.
How-
ever, while providing these desirable exchanges of information and opinion, these types of sessions have important
undesirable aspects;
1).
A senior member of the group or a dominant
personality can sway opinions in a manner which
causes the group to reach a conclusion inconsistent with the information provided.
2)
People are typically unwilling to change
opinions expressed publicly.
103
3}
It is difficult to maintain an opinion when a
majority is of a different opinion (the
"bandwagon effect"} .
The disadvantages inherent in each of the above
two approaches has given rise to a new technique, termed
the Delphi method.
This method elicits the independent
opinions of experts concerning the decision criteria
parameters and the reasoning behind their opinions.
The process begins with the system designer making
his best estimates of the decision criteria parameters in
the form of a questionnaire.
The questionnaire is dis-
tributed to each expert and he is asked if he would add
to, subtract from, or modify any of the system designer's
estimates of the decision criteria, utility curves,
thresholds, weightings, probabilities, and states of
nature, and the rationale for the experts' estimates.
Having received this feedback, the system designer modifies
the overall opinions according to the group opinion and
redistributes them to the experts.
This process continues
until no significant opinion changes are received.
This
technique thus provides additional expertise in the
decision process, while maintaining the individuality of
the experts'opinions and reasoning.
Having obtained the estimates, the results can be
graphically represented for each decision criterion as
shown in Figure 6.1-2.
The utility curve (Uj} reflects the
104
Yj .=Decision Criteria
(utility) u-4
100
"
Threshold
(Weighting) wj
Utility Curve
YTj
Magnitude of Decision Criteria
(Probability) fll(
Al terna ti ve
c;<
= Mean Value
j
Probability distribution
functions for Alternative 1
under States of Nature s 1 &
s2
1
-$ •2 -1 0 +I #.Z. #3
II
IIIIi
-3 -:l _, 0 ., #.2 •1
. 'l:.:_o-
= SV=mdard
Deviation
Probability distribution
functions for Alternative 2
States cf Natu.re s 1 &
Alternative "'2
1!11111
-.z •I D H ".% #l
-l
L-a-
Figure 6.1-2
Decision Criteria Expected Utility Representation
105
consolidated expert opinions as to how the utility of the
particular decision criterion (Y.) varies as a function of
J
its magnitude.
The desirable threshold (YT.) which should
J
be met in order to achieve the overall design results, and
the weighting (wj) which reflects the particular decision
criterion importance in the end result relative to all the
other decision criteria, are noted on the graph.
The lower graphs represent the experts' concensus
as to the probability of achieving the decision criterion
threshold under each of the states of nature for the
alternatives (a.)
1
The means
(~)
(or candidates) under consideration.
of these probability distribution functions
(fai> are aligned with that value of the decision criterion magnitude which alternative a.1 is felt most likely
to achieve, with the deviation (cr) reflecting the confidence in the mean value estimate.
Since the graphs represent estimates of expected
performance in light of the uncertainties involved, the
utility associated with any one decision criterion is
termed "expected utility."
It is derived by integrating
'
the area under the probability distribution
curve times
the decision criterion utility curve.
several ways.
This may be done in
By knowing the equations for the utility
curve (which can be found by using curve fitting for complex
functions) and the probability distribution functions, they
can be multiplied and integrated over the decision criterion
106
magnitude range.
However, a simpler and quicker technique
which gives a good first order approximation, is to use
best straight line fits
(linear segments) for the utility
curve and divide the probability distribution curve into
"x" sections.
Then, the area under any one section of the
probability curve can be looked up in a table for the
cumulative distribution function (in this case a normal
distribution) and multiplied times the utility corresponding to the midpoint of that section.
in Figure 6.1-3.
This is illustrated
The sum of these results gives the
expected utility for that particular decision criterion.
These decision criteria expected utilities can
be summed for each alternative, and multiplied by the
states of nature probabilities to give the final expected
utility, upon which a decision can be formulated.
In summary, the steps involved in performing a
cost effectiveness evaluation using utility theory are
as follows:
(a)
The system designer explicitly defines the
system requirements based upon his understanding of the design problem and the user's
desires and wants.
(b)
A group of alternative solutions (ai) to the
problem are formulated using a functional
evaluation, as discussed in section 5.
107
(Utility) Uj
idpoint of utility curve
corresponding to the
Probability Distribution
curve sectional area.
yT
Decision "riterion Hagnitude
j
Threshold
fD(
j
J1
"X". sections == ·6
in this paper. It
may be increased as
required to provide
increased resolution
in the Expected Utility
result.
Area under
this section
obtained from
Cumulative "Distribution table
for a Normal
'Distribution.
-3
-1
0
+1
+2
+3
'-c.. <r
Probability Distribution Curye
Figure 6.1-3
Expected Utility Computation Partial Example
108
(c)
A set of decision criteria (Y.) are defined
J
to use in judging each alternative in relation to its ability to satisfy the requirements of step (a).
(d)
A threshold value (YT.) is estimated for
l
each decision criterion, which specifies a
design goal to be met, necessary for
achieving an overall successful design.
(e)
A measure of the utility (Uj) associated with
each decision criterion is estimated reflecting its worth in achieving the design goals.
(f)
The relative importance of the decision
criterion compared to all other criteria in
the final decision is assigned, termed a
weighting value (W.).
J
(g)
A probability distribution (fa.) is defined
l
to reflect the projected likelihood of
achieving the established threshold for each
alternative and each state of nature (Sk).
(h)
The estimates of steps (c) through (g) are
further refined and solidified by review and
modification based on other experts' opinions
(the Delphi method).
(i)
These results are plotted and expected
utility for each decision criteria calculated.
109
(j)
A final expected utility (E(Ua.>> for each
.
1
alternative (ai) is determined as follows:
E(Ua.>
=
1
where E(U
sk
)
=
LE
sk
(U.)
J
P
is the probability of occurrence of the kth
sk
state of nature.
The cost effectiveness evaluation phase of the
CPU selection is presented in the following sections.
110
6.2
Decision Criteria Analysis
The decision criteria considered under this cost
effectiveness study are listed in Table 6.2-1.
Table 6.2-1
Decision Criteria
I/0 Capability
Interrupt Capability
Hardware/Software Development Aids
Vendor Support
Tolerance Limit Computations
Power Consumption
Cost
Development Time
Chip Count
Reliability
Instruction Set
Higher Level Languages
Addressing Modes
Microprogrammable
Memory Choice
Direct Memory Access
Clock Rate
Instruction Cycle Time
'Vleight
111
The decision criterion should be selected to be
independent so that changes in the utility curve or
probability distribution function of one criterion will
not affect those of another criterion, resulting in an
additive effect on the final expected utility.
Before the details of the rationale for selection
of the prime decision criteria are presented, a brief
description of the derivation of the associated weightings,
thresholds, utility curves, and probability curves is in
order.
The approach consisted of four phases:
(1)
because of the limited exposure of the five sources (four
associates involved in the controller project, and one
outside microcomputer system expert) to cost effectiveness
studies and the associated semantic jargon, a group
meeting was held explaining the basics of the study and
the approach being taken,
(2) the criteria presented in
Table 6-1 were each considered by the group for inclusion
as a primary or secondary criteria (high or low weighting)
or complete exclusion because of irrelevance to the final
decision, and group weightings, thresholds, utility curves,
and probability mean and standard deviations were assigned,
(3) copies of the results were distributed in the meeting
to each member, requesting that he consider them for three
days as to possible modification, and (4) after three days,
a second meeting was held to discuss any desired changes,
with new values inserted as agreed upon.
112
The weightings were scaled from 0 to 100, in
increments of five, unless increased resolution was
required.
The thresholds were determined in several ways,
depending upon the decision criteria under consideration,
and are explained later in this section.
The utility
curves were determined to consist of several linear function segments, as shown in the graphs of this section.
In all cases, a normal probability distribution was
assumed with the mean and standard deviation estimates
reflecting the overall group confidence and familiarity
with the criteria under consideration and the probability
of realization of the criteria threshold value.
Although it is certainly acknowledged that this
approach has some of the aforementioned disadvantages of
brain-storming sessions, and group opinions, it was done
primarily due to limited sampling time available in lieu of
the increased time involved in the multiple iteration
Delphi technique.
The negative aspects of this approach
were lessened in that the sources involved were on the
same supervisory level (engineering staff members) , the
exuent of the outside source member's knowledge was unknown
to the other four members of the group, and the four work
associates were intimately familiar with the proposed
controller approach.
The States of Nature considered in this study were
basically two:
(1) the Navy decision to retrofit the 10
113
stations based on board the aircraft carriers, where the
work load is the heaviest and radar system availability
is crucial, and (2) Navy retrofit of all 30 stations, on
both ship and shore-based facilities, to maintain common
configuration.
Because of the lower utilization of the
shore-based stations due to the fewer number of radar
systems required to be maintained, the need to retrofit
these stations to handle the additional load of the new
radar system is not as critical as that of the ship-based
stations.
On board ship, the stations must be available
and operational a large percentage of the time to maintain
the existing radar system.
The added system will overload
these stations without the retrofit.
Thus the probability
associated with each of the states of nature of retrofit
was felt to be:
State of Nature
6.3
Probability
Retrofit 10 stations
0.75
Retrofit 30 stations
0.25
Detailed Decision Criteria Analysis
The rationale behind the selection of each of the
decision criteria, their associated weightings, thresholds,
utility curves, probability curves, and the impact on
these based upon the states of nature are presented in
this section, followed by the graphical representation of
these decision criterion parameters.
114
6.3.1
I/0 Capability (see Graph 1)
As previously discussed in section 2.0, one
of the main functions required of the controller is
to interface with a large number (700 to 1,000) of
I/O lines.
Thus, the efficiency with which the CPU
can manipulate and communicate with these I/0 lines
directly affects the throughput, i.e., unit test
times.
A measure of pure time ( in
~sees.)
though,
is not necessarily a true indication of the CPU's
I/O capability.
Although one processor may execute
an I/0 subroutine rather fast, it may utilize a
large number of memory bytes to accomplish this
task.
In some instances overflowing of the avail-
able microcomputer main memory size, requires the
loading of additional data from the mass storage
device, which is extremely time consuming.
Thus
a more indicative measure of I/0 capability is the
number of memory bytes required, multiplied by the
total execution time.
Weighting - Because of the importance of this
function, i t is weighted as 100.
Threshold - The threshold for this decision criterion was obtained by having several sources from
the expert group write a first iteration program
for a sample I/0 block, composed of polling eight
115
I/0 ports to determine if they contain data or not,
and to input and output data from specific memory
files.
A flow chart of this program is shown in
Fig. 6.3-1.
The established threshold (shown in
Table 6.3-2 of section 6.3.11) represents the group
consensus ori what was felt to be the "tolerable"
limit, beyond which test times become appreciably
long.
Utility Curve - The curve reflects decreasing
utility as the I/0 subroutine takes longer, with
limits on the criterion axis fairly well defined
because of the finite range of program steps
required to implement the sample I/O function
based upon the familiarity of the programmers with
the microprocessor instruction set.
States of Nature - The number of. stations retrofitted has no impact on the weightings, threshold
value, utility curve, or probability curves.
6.3.2
Interrupt Capability (see Graph 2)
The controller must be capable of recognizing
these interrupts during a normal testing sequence,
and take appropriate steps to service the interrupt
generating device.
116
~~
POLL
DEVICE
GET
POINTER ~...
YES
ACTIVE?
NO
NEXT
..... DEVICE
n
STORE
DATA
,,
UPDATE
POINTER
Fig. 6. 3-1
Flm·,;rchart for Polling Eight I/0 Devices
Again, similar to the units of measure for
I/O capability, pure time is insufficient for the
measurement of interrupt capability.
Rather the
number of bytes required to implement the interrupt
routine, times the total execution speed is a more
realistic measure.
Weighting - This function can also significantly
impact overall unit test times, and as such was
117
rated as 90, and is independent of the states of
nature.
Threshold - The threshold level was obtained in the
same fashion as I/O capability.
A sample program
was written for each of the processors for an interrupt routine which services an operator keyboard
action and includes the interrupt overhead (saving
of pertinent information of the test sequence
interrupted, so that it can be continued after the
service routine is completed) .(see flow chart of
Figure 6.3-2).
The established threshold is shown
in Table 6.3-2, which represents the group opinion
of acceptable performance.
Utility Curve - Similar to I/O capability, the
longer the time required for service routine execution, the less desirable because of increased unit
test times.
The utility curve function was also
felt to be independent of the states of nature.
Probability Curve - Because of the internal structure of Processor B for interrupt handling, its
execution time was considerably lower than Processor
A.
Thus its mean reflects this fact, with equal
likelihoods of variation (standard deviation) for
both processors due to the single iteration in
writing of the sample interrupt program.
118
...
INTERRUPT
DISABLE
INTERRUPT
STORE 2
REGISTERS
,,
STORE
STATUS
,,
INTERRUPT
ROUTINE
RESTORE
REGISTERS
RESTORE
STATUS
RETURN TO
PROGRAM
.......
ENABLE
INTERRUPT
Figure 6.3-2 Servicing an Interrupt Flowchart
119
6.3.3
Hardware/Software Development Aids (see Graph 3)
Because of the LSI (large scale integration)
packaging utilized in microprocessor technology,
the actual hardware design effort has been significantly reduced.
Therefore, development of the
test program software and integration and checkout of the hardware with the software occupies a
much larger percentage of the overall task.
One of the main advantages of these aids is
the real time (while the program is executing) debug
capability they afford.
When problems are encoun-
tered in the checkout of software on the actual
controller hardware, these aids allow step-by-step
interrogation of prime functions within the controller to ascertain the cause of the problem.
Additionally, test program software can be
assembled (translated from mnemonic code to computer
code) directly on these aids.
The alternative to
this is to utilize time sharing computer facilities,
whose accumulated cost for large programs can
quickly exceed the cost of the hardware/software
development aids.
Weighting - The group feeling that this criterion
was important to the overall success of the project
resulted in the weighting assignment of 90, independent of the states of nature.
. f
120
Utility Curve -
It was felt that if the hardware/
software development aids could not save at least
two man-months, they would not be worth purchasing,
but would most likely result in somewhere around
eight man-months saved under the ten station retrofit state of nature.
However, if the 30 station
retrofit state of nature occurred, i t was believed
that possibly even more man-months could be saved
due to the increased utilization of the aids in
debugging production problems.
Probability Curves - The probability curves were
based upon review of the development aids available
from each processor vendor and the group estimates
of time savings.
6.3.4
Vendor Support (see Graph 4)
The availability and technical accuracy of
the processor vendor support in terms of written
application material and engineering backup can
greatly reduce the engineering, development, and
checkout tasks associated with a microprocessor
design.
It can make available the past experience
of other designers and prevent "reinventing the
wheel" design for I/0, interrupt, memory, refresh,
and other hardware elements.
Additionally, i t
121
provides a ready reference library of shortcuts to
common software programming tasks.
Weighting - The weighting assigned to this criterion
was felt to be 85 in the first state of nature, and
increased to 90 in the second state of nature.
Immediate support from the vendor could result in
keeping production on schedule, thus preventing
costly delays due to previously encountered problems
to which a ready solution is known.
Threshold- It was felt that probably 3.5 man-months,
if saved due to good vendor support, would be a
realistic figure based upon previous vendor support
interface.
Utility Curves - This criterion is most important
in the design and development and checkout phases,
with somewhat less imp9rtance in the production
phase due to the availability of internal support
based on the experience gained in the previous
phases.
The steeper utility curve under the second
state of nature reflects the fact that because more
stations must be retrofitted, the production phase
would begin sooner.
This would require more
expeditious answers to problems encountered in the
development phase and the likelihood of more
problems being found during increased production.
122
Probability Curves - Because of the somewhat unpredictable nature of the usefulness and availability
of vendor support when needed, and the user/vendor
semantics learning curve (talking on the same level
of a problem) , the standard deviations are fairly
large.
The mean values reflect the more abundant
supply of applications data, large support engineering staff, and more knowledgeable distributors for
Processor A.
6.3.5
Tolerance Limit Computation (see Graph 5)
Output parameters of various radar units must
be measured, quantized, and compared to correct
operational pass/fail tolerance limits.
This
tolerance limit computation is performed repeatedly
throughout a unit test and thus the efficiency with
which the microcomputer performs this task directly
effects units test times.
The most valid measure-
ment of this efficiency is the number of bytes of
program,times the execution time of the program,
similar to the criterion used for I/O and interrupt
I
capabilities.
Weighting - Because this function is often used
throughout the unit test program, it was determined
to warrant a weighting of 85, which is independent
123
of the states of nature because once derived it is
simply repeated as needed.
Threshold - The threshold for this criteria was
derived by generating a sample program shown in
the flow chart of Figure 6.3-3, and listed in
Table 6.3-2.
Utility Curve - Based upon the sample program, it
was felt that both processors could easily implement
this function, with processor B doing it somewhat
more efficiently than A due to the structure of its
instruction set.
Probability Curves - The curve reflects the inherent
better capability of processor B.
6.3.6
Power Consumption (see Graph 6)
Because of the limited power supply margin of
CAr~
the station and the lack of space in the
console
for additional power supplies, power consumption,
which is usually of lesser importance in microprocessor deisng, is quite important in this
controller design.
Also, there is limited cooling
l
available (convection cooling being utilized) for
any hot spots.
Weighting - Because of these limitations, the
weighting associated with power consumption is 80,
and is constant regardless of the states of nature.
;'1··1
.1
124
Enter
Load Upper
Limit into
Re • 1
Load Lower
Limit into
Re • 2
Load Meas.
Result into
Re • 3
Subtract
Reg. 3 from
Re • 1
Subtract
Reg.2 from
NO
Figure 6.3-3 Tolerance Limit Computation
Flow Chart
Ll ~
125
Threshold - The threshold was based upon what the
station power supply margin is, leaving some spare
capability, which is shown in Table 6.3-2.
Utility Curve - The utility curve represents the
desirability of keeping the power consumption of
the microcomputer within the predetermined station
capability.
Probability Curves - Although both processors use
the same power forms, processor B draws more heavily
upon the +5VDC power which is the most crucial in
terms of spare capability.
Also processor B's LSI
packaging is not as "power efficient" as processor
A's.
6.3.7
Cost (see Graph 7)
In order to achieve a life cycle cost realization under this automated test concept, the unit
cost of the retrofit must be kept at a minimum.
Weighting - As such, under state of nature one, the
weighting was felt to be 85, increasing to 90 under
the higher quantity station retrofit to pass on to
the customer some discount for quantity, while still
maintaining the company profit margin.
Utility Curves - These curves reflect the desire to
keep the cost down, especially under the second
126
state of nature where above threshold cost has a
rapidly decreasing utility.
Threshold - The threshold for per unit cost was
derived from interim requests for bids from manufacturing, field service and support, and system
engineering, and is shown in Table 6.3-1.
Probability Curves - It was felt that processor A's
potential for achieving the desired per unit cost
is better than processor B because of the anticipated shorter development time, realization of
hardware/software development aids savings, and
lower integrated circuit costs.
6.3.8
Development Time (see Graph 8)
The amount of time it takes to develop the
controller is a function of the overall microcomputer elements, CPU capability, and hardware/
software development aids.
As such, if development
time can be reduced, production can start earlier,
thus enabling realization of early delivery
compensation
($).
,
If development time runs long,
it extends into production time, necessitating
support of the production effort with development
engineering staff.
In addition there is the possi-
bility of added costs incurred in incorporating
changes found in the continuing development effort
Table 6.3-1
Cost Estimates
Bid Area*
Number of
Stations
Retrofitted
Processor A
10
30
Processor B
10
30
Manufacturing
$42.75K
$35.75K
$47.25K
$40.25K
Field Service and Support
$19K
$16K
$19K
$16K
System Engineering
$33.25K
$33.25K
$38.75K
$38.75K
$95K
$85K
. $105K
$95K
*Manufacturing.includes the cost of materials, assembly, test, and quality
control.
Field Service and Support includes the cost of maintenance manuals, field
liaison, modification kit trial, and spares.
System Engineering includes the cost of prototype engineering, generation of
specifications and test requirements, and manufacturing support.
128
into units already produced and yet to be
produced.
Weighting - The startup time for production allows
for some overrun of the development phase, thus
lowering the importance of this criterion to 75,
which is independent of the states of nature because
the development of the controller is the same
regardless of the number of stations retrofitted.
Threshold - The threshold is based upon the outside
experts'· opinion for the size of this task compared
to similar past designs.
Utility Curve - The utility curve chosen represents
the decreasing utility of longer development times,
with development beyond 40 man-months (the beginning
of projected production) being highly undesirable.
Probability Curves - The probability curves reflect
the confidence of the group members that the vendor
support and hardware/software development aids
associated with processor A will prove more beneficial than processor B's.
6.3.9
Chip Count (see Graph 9)
The number of integrated circuits
(chips)
which can be structured to implement the microcomputer function of the controller is limited by
the physical space available within the CAM assembly.
129
The I/0 circuitry utilizes at least 90% of the
available space.
Also, increased chip count leads
to increased power consumption and reduced reliability.
Weighting - Because preliminary design of the
microcomputer circuitry of the controller seems
to indicate that it will fit in the available
space, the weighting associated with this criteria
is 70, and is independent of the number of stations
retrofitted.
Threshold - The threshold is based upon the space
available and the preliminary microcomputer design
chip count.
Utility Curve - The curve directly reflects the
space limitations and the desire to leave some
margin for future growth.
Exceeding 36 chip
locations would deplete this margin; exceeding
40 would require some rearrangement of the I/0
circuitry; more than 44 chip locations would
require major redesign of the I/0.
However it is
felt that exceeding the 44 chip limit is somewhat
unlikely given the constant influx of more dense
(in terms of functions implemented on any one
chip) packaging.
Probability Curves - The probability curves reflect
the more general nature of processor B's chip set,
130
allowing it to be software programmed for specific
applications, and processor A's need for more
hardware design, plus the fact that A tends to
introduce more new chips per year than B.
6.3.10 Reliability (see Graph 10)
The fact that the controller is the basis of
the automated test concept and the microcomputer
is the heart of the controller, its reliability
must be exceptional to meet the requirements of
the high station utilization rate in supporting
two radar subsystems.
Any controller downtime
resulting in usage of the manual backup capability
can only be done for a limited time before the
workload overtakes the total station available
hours.
Weighting - Because this decision criterion is
critical, it is assigned a weighting of 100 for
both states of nature.
Threshold - The threshold is based upon the total
number of aircraft supported by one station, the
radar subsystem MTBF (Mean Time Between Failure),
the station MEMT (Mean Elapsed Maintenance Time),
unit No-Fault Rate, and number of station hours
available for maintenance.
131
Utility Curve - There is only one utility curve
shown reflecting the fact that even though there
are more stations susceptible to failure at any
one given time under state of nature two, this
is offset by the fact that the 10 stations on
board the carriers can always be given higher
priority for repair than the 20 shore based
stations due to their lower utilization.
Even
if the threshold reliability is exceeded, a minimal field engineering support staff will be
required, which is reflected in the decreased
slope beyond lOxlO
3
hours.
Probability Curves·- The probability curves reflect
the additional years
(2) which processor A has
been in use beyond B, providing a truer indication
of its mean value.
However, the wide standard
deviations for both reflect the fact that neither
has been subjected to this type of environment
and design requirements.
6.3.11 Other Decision Criteria
The following decision criteria were discussed by the group, but were determined to have
insignificant impact, or were included as aspects
of the primary decision criteria.
·~jl!·'· .r
~''
132
Instruction Set - The number and types of instructions available to the programmer determine the
~P's
overall capability.
In this application,
this criterion was reflected in the I/O capability,
interrupt capability, and tolerance computations,
which comprise the majority of the controller
tasks.
High Level Languages - More
11
English like 11 computer
programming languages, although saving initial
program writing time, require large machines to
compile into computer code.
They also complicate
real time checkout due to the multiple instructions
generated in computer code for every high level
language instruction, making a one for one correlation extremely difficult.
Because the programming
task involved in this controller design is small,
the assembly mnemonics of the microprocessor
instruction sets are satisfactory for program
generation.
Addressing Modes - Although the addressing modes
are a measure of microprocessor power, they are
reflected in the I/0, interrupt, and tolerance
capabilities.
Microprogrammability - This provides the capability
to predefine custom instructions for specialized
,
133
usage.
Although it would be somewhat advantageous
in this application, the incurred increase in
development time, chip count and checkout times,
plus the adequacy of the existing instruction sets,
did not warrant this capability.
Memory Choice - Numerous types are available and
are advertised to be functional with most processors.
Typically, however, the memory designed
by the CPU vendor plays best with its own microprocessor, thus predetermining memory choice.
Direct Memory Access - This provides for a very
high speed data transfer capability, which in
this controller application was not necessary.
Clock Rate - As stated in the I/O and interrupt
decision criteria discussions, it is not completely
indicative of microprocessor operating speeds.
Instruction Cycle Time - Defined as the time
necessary to execute a specific instruction.
Although often quoted in vendor sales literature,
it is not necessarily indicative of the true microprocessor performance.
Weight - The weight of the microprocessor chips
is insignificant compared to the overall CAM
assembly.
134
A compilation of these previously discussed
decision criteria is presented in Table 6.3-2, with the
interrelationships of the utility curves, thresholds, and
probability curves shown in the following graphs 1 through
10.
t'
Table 6.3-2
necision Criteria, Thresholds, & Weightings
..---------
~~-r------~--------~-------------r----~~~~-Weightings (w j)
'Decision Criteria (Yj)
j
Threahol(\ (yT )
j
States of Nature~ Navy decision to
retrofit 10 stations(s 1 ) or 30(S )
2
s 1 - 10, P a 0.75 s2 • 30, P8 • 0.25
__
r---r-------------------~------------------t-------· s~1----+-------~2L-----1
1
2
T/0 r.apabili ty
20 x 103 by:tcs-usecs.
.
2 .
24 x 10 bytes-usecs.
8 man-months
Interrupt Capability
3 l!arrlwa:re/Software
Development Aids
;. 5 man-mon tr1s
4 Vendor Support
5 Tolerance J,lmi t Computat' on 1.0 x 10 3 bytes-usecs.
6 !'ower Consumption
10 \'latta
7 f!ont
$100K
B Development ~i~e
32 man-months
C1 r.h i p Count
;6 Integrated Circuits
10 Reliability
10 x 10 3 MTBF hours
I
-- - --- -
I
I
I
I
-
--- -
11 Instruction Set
1? Higher tevel Language
1; Addressin~ Modes
14 1·1 icropror-;rammable
15 ~emory Choice
16 Direct ~emory Access
17 r.lock Rate
"1R Instruction Cycle Time
~
-
-
-
·- -- - - -
*
*
*
*
*
*
*
*
100
90
90
100
90
85
85
90
90
85
eo
80
90
85
75
75
70
100
70
100
...,._, - - -
**
*
*
*
*
*
*
-
-r- ........ -
-
*
*
*
*
*
*
*
*
_... .... -
1G 1vei~h~t____________________J_______~*~----------~--------~*~------~------~*~------~
*- 0ther decision criteria considered, but not in.cluded in E(U) calculations
due to insignificant weighting impact.
136
Y
1
I
110 -
w'
Criteria: I/0 Capability
\ 'J
" ~ : ...
( o.l
.._"\,,.}
I
<.
-4
I
HO
==~:-=~--::-::~,j
100
fox·
90.-
c \-~<'(U
''l
( .:>,~ ·1 '"'2
J _,
1 '.f A1 ) --~ \'
I x .f A1 )
102.9(0.02275) .j. "!G;~. ·;(b. 1;:.5)
101.2(0.341)
+
+
10J.4(0.341)
+ 88.7(0.136) + 36.,(0,G2275)
=,· 2~-~-.:}~!
f.lt1
Au
o- =
21
1
1
1
(s ,s?)E(U,,f~ ) = 101.2(o.o~275) +
-
I
·'
100.~(0.136) +
38.7(0.341) •
86.3(0.31,1) + H3.7(0.136) +
fJi-2(0,02275)
"" 88.86
Graph
137
Y Criteria: Interrupt Capability
2
(s ,s )U 0 a -O.By 2 + 109.2
1 2- '. for 20fy f24
2
"·-1.G7y~ + ·125
·for
24.01t,~r?~30
'-
----------
------.
{bytes-usecs
x 10 2)
(S 1 ,s 2 )E(U 2 ,fA 2 ) "'84-.~(0.02275) +
82.4(0.136) + 80.1{0.341) +
79.1(0.341) + 77.4(0.136) +
75.7 (Q, 0227'~)
(S ,s )E(U 2 ,fB2 )
1 2
92.0(0.02275) +
91.2(0.136} + 90.4(0.341) +
84.1(0.341) + 82.4(0.136) +
80.1(0.02275)
Graph 2
138
Y"i Crt teria: Hardl~are/Software
'
Development Aida
(s 1,s 2 )U./
-
:~1
u ::: 8
o· = 1
8
12.5y .. +
20
' for 2~y f8
:;
3
2
10
3 = 58.7(0,02275)
(s )E(U~9fA )
1
+
~1.3(0.136) + 83.7(0.341) +
1
98.1(0. 3·i1) + 104.4(0.136) +
"110.
=:
(<'
\ J
6(0 .. 02275)
f?.2!..l?..
t' 3 \I -- g-:.;
7tn 0""..,5'I .'
2 )viu
., \ J 3' -A
- ... \ ' J . . c. c.. ;
~8.1(0.136) + 104.4(0.341) +
110.6(0.341) + 116.9{0.136)
123.1(0.022?5)
107.25
S
_1
u
~-
=6 7
(J~ :::
1
-3 -2 -1 0 +1 +2+3
>)2
(Si)E(U 3 ,.rB 3 ) "'33.7(0.02275) +
46.2(0.136) + 58.7(0.341) +
71.3(0.341) + 83.7{0.136) +
98.1(0.02275)
.§.1.99
(S~)E(U ,fB7) = 46.2(0.02275) +
3
t:
~
- J
58.7(0.136) + 71.3(0.341) +
83.7(0.341) + 98.1(0.136) +
104. Ho. o:~275)
11~
Graph 3
+
1.~!
-~
139
Y Criter.ta: Vondor Support
4
(S 1 )U = 14,0yA + 36
4
't for 1,fy ,<,3, 5
.
"' 4.0y
(s )u :
2 4
4
71
-1-
4
4 for 3.51Gy ~6
16.0y
+
34
4 for 1~y {•3. 5
--u•'J4~'
p
0" ~- 62
for 3. 51:~y t1 ~6
.-
(S1)E(U4,fA4) a 57.0(0.02275) +
71.0(0.136) + 83.0(0.341)
89.o(o. ;,;n ~ 93.o{o. •':>6)
97.0(0.022'75)
I .
/~~(s
1 ,:: 2 )
1
1
l
L
(s):F(u 4 ,fAA)
/
/
-~
---~---+--P'------~ ~
-----+---1-
-3
-2
-1 .
0
+1
+2
"'5B.o(n.0227~i)
+
+
+
74.0(0.136) + 90.0(0,;41) +
98 . 0(0.341) -t '106.0(0.136) +
114.0(0.02275)
92_. 5~,
+3
(s 1)E(U 4 ,fB4 ) ~ 43.0(0.02275) +
57.0(0.136) + 71.0(0.341) +
85.0(0.341) + 89.0(0.136) +
93.0(0.02275)
r.
2
76 •.11.
4 = 42.0(0.02275)
(s )E(U,~,f3 )
+
58.0(0.136) + 74.0(0.341) +
90.0(0.341) + 98.0{0.136) +
106.0(0.02275)
Graph 4
:,
!
.l·
140
Y Criteria: Tolerance Computation
5
(s ,s )u~ = -16.66yr + 101.66
1 2 ?
? for 0.4~Yr.~1
u5
100
1-
r-·-
)
= -12.5y5
90
-··-------_
w5 ·----------
+
87.5
for
1.01~y ~c.4
5
no -'TO t·
I
60
---
.
t.
5~1--+--J--1----+----f...
0.4
0,6
0.8
1.0
YT
1.2
1.4
5
(S 1 ,s 2 )E(U ,fA 5 ) = 89.2(0.02275) +
5
87.5(0.136) + 85.8(0.341)
u,.,1.0
1a- :: o.
I
1
I
~
I
71.9(0,02275)
r~<s,
= 80.!..1..4.
·"2)
l__LJ~~
-3 ~2 -1 0 ~1 +2 •3
4u
1()y
==
0,8
=
o. ,
! ;
'I
(s 1 ,s 2 )E(U 5 ,tB5 ) = 92.5(0,02275}
+
90.8(0.136) + 89.2(0.311) +
87.5(0.341) + 85.8(0.136) +
74.4(0.02275)
=
§§!.Ql
Graph 5
141
Y6 Criteria: Power Consumption
(s 1 ,s 2 )u
~
6
-1.67y 6
ih--1o--1t-14
~4
96.7
6
"' - 5 • Oy
5
+
) for 4fy f;10
6
+ 12 0
:for 10.oh;y ,.;14
6
y (•tfatts)
6
YT6
(s ,s )E(U ~fA
1 2
Au ,.. 8
tr = 1
l
I
6 6 ) ~ 87.5(0.02275) +
85.8(0.136) + 84.2(0.341) +
82.5(0.341)
-
+
80.8{0.136) +
67.5(0,02275)
:: ?)_._04-
i
I
lL.-++~---3 -2 -1 0+1 +2 +3
u = 10
t
~"'
1, 25
(S ,s 2 )E(U 6 ,fB 6 ) • 85.2(0.02275) +
1
83.1(0.136) + 81.0(0.341) +
66.9(0.341) + 60.6(0.136) +
54.4(0.02275)
:;%
---r--t-f----~-3 -2 -1
0
+1 t2 +3
12..J2.
Graph 6
142
Y Criteria: Cost
7
(S )U == -0. 33y + i·JB
7 £or 70fy ~100
· 1' 7
7
"' ~-1. 5y + 173
7 fo:r" 100.016:~>'{'120
= -0.83)y.., + 210
1
=' -2.0y,
I
u "' 95
a~==
for 7tJ-£y t:·IOO
7
+
250
foi' 100, 01~y; .f.120
7
(S 1 )E(U 7 ,fA?? = 90.5(0.02275)
+
89.9(0.136) + 87.2(0.341) +
5
48.7(0.02275)
"'?J:l11
1
(S?)~(U~,f 1 " ) ~
f,,.,
'-
h/
I
.).
104.3(0.02275) +
100.1(0. 1)6) + 95.9(0.34-1)
91.8(0.341)
+
45.0(0.136)
-1-
+
J5oO(Q,02275)
= !36~
==----t---t-,--!---l~t-­
-3 -2 -1 0 +1+2 +3
lI
·u == 105
(S )E(U ,fB7) = 87.2(0.022?5) +
1
7
85.5(0,136)
<rc'j
+
56.3(0.341) +
".8.7(0.341) + !;.1.3(0.136) +
33.7(0,02275)
~
.5..2JU
(s )E(U ,:rB'/) == 95.9(0.022'15) +
2
7
91.3(0.136)
+
35.0(0.341)
+
45.0(0.341) +
25.0(0.136) +
~5.0(0.02275)
· Gra-ph 7
143
~B
Criteria: Development
(s ,s 2 )u 8
a
1
100-
'rim~
-3.125y 8 + 175
for
24.fy 0 ~32
0
"' --•L 37Sy8 + 215
for
-~~
= -10.0y8
+
440
for
32.01~y
8 G40
40.01.r,y
8 C:~-4
(s 1 ,s 2 }E(U8 ,fA8 ) = 90.E(0,02275)
=
·t
~
f "R8
u .,, 36
o- = 2
(S
1
,s 2 )E(U8 ,f113 ) = 78.1(0.02275)
l---{~-1-·~
-3 -2 -1 0 +1 +2 +3
-l-
70.6(0.136) + 61.9(0.341) +
53.1(0.34-1) + 50.0(0,136) +
=
I
+
84.4(0.135) + 78.1(0.341)
?O;G(0.341) ~ 61.9(0,156)
53.1(0,02275)
73..!.!}7
30.0(0.02275)
58.08
Graph 8
+
+
144
Yg Criteria: Chip Count
y 0 (# Of Inte.grated Circuits)
J
(s 1 ,s 2 )B(U 9 tfAg) = 75.8(0.02275)
a ::.: 36
&·,
1
+
72.5(0.136) + 70.8(0.341)
65.0(0.341) + 55.0(0.136)
47.5(0.02275)
2
+
+
- 66._42
I
(S 1 ,s 2 )E(U ,fB9 ) = 72.1(0,02275) +
9
71.3(0.136) + 70.4(0.341) +
67.5(0.341) + 62.5(0.136) +
57.5(0,02275)
§§.:.J.~
)
L------.-..-l.l--j:-1--t--1-
Graph 9
--···11><-
-3 ·-1 +1 +3
-2 0 +2
145
Y
10
Criteria: Rollab1li
~y
(s ,s 2 )u = 4y 10 + 60
1
9
· for 2.56y 10 ~10
"' 2y 10 + no
for 10,016y ~15
10
(s 1 ,s 2 )E(U 10 ,rA 10 )
= 80.0(0,02275) +
88.0(0.136) + 96.0(0.341) ~
fu="IO
/.t"<"2
102.0(0.341) + 106.0(0.136)
ihJ.0(0.02275)
tl ("
,. . '
01 ~.:>2;
.~---~-~---l---t----1-~
-·3
-2 -1
u = 7.5
1
&=2
0
-1·1
i·l
+3
(s 1 ,s 2 )E(U 10 ,fBiO)= 70.0(0.02275) +
78.0(0.136) + 86.0(0.341) +
94.0(0.341) + 101.0(0.136) ~
105,0(0.02275}
,.
~-'~:J.:L
Graph 10
~
7.0
Final Expected Utility
A summary of the results of the individual decision
criteria expected utilities are shown in Table
7.0~1.
Table 7.0-1
Summary of Expected Utility Results
Alternative 1 (a )
1
(Processor A)
Alternative 2 (a 2 )
(Processor B)
Criterion
s·
1
(Y.)
J
82
sl
82
1
98.99
98.99
88.86
88.86
2
79.63
79.63
87.03
87.03
3
89.75
107.25
64.99
77.60
4
85.15
92.54
76.14
80.51
5
80.14
80.14
88.03
88.03
6
83.04
83.04
73.15
73.15
7
81.81
86.90
55.81
45.69
8
73.87
73.87
58.08
58.08
9
66.45
66.45
68.18
68.18
10
98.22
98.22
89.71
89.71
837.05
867.03
749.98
756.84
Total
The final expected utility must take into account
the probabilities associated with the previously two
presupposed states of nature, the Navy's likelihood of
retrofitting only 10 (75% probability) or all 30 (25%
probability) stations.
This calculation is shown below.
146
147
E{U ) = E{Us ) x Ps + E{U ) X P
a
1
1
s2
s2
E{U
E(U
al
a2
0.75 + 867.03
)
=
837.05
)
=
749.98 X 0.75 + 756.84 X 0.25
X
X
0.25
=
844.55
=
751.70
From the final expected utility calcuations, the
alternative which yields the largest result would be deemed
the choice most likely to result in a successful design.
In this case, the fact that processor A's utility is
larger by more than 10 percent than processor B's final
expected utility, clearly indicates processor A's superior
capability for this controller application.
Roughly
equivalent results would have indicated either processor
was equally suited to perform the controller task.
7.1
Decision
The cost effectiveness evaluation has provided the
means to differentiate between the two processors, and
forced a more detailed evaluation of just what features of
the CPU and its functions within the microcomputer CAM
controller, were really applicable and worthwhile.
Thus,
the decision as to which processor to use, is based on the
maximum expected utility realizable for the alternatives
under consideration over all the decision criteria and
states of nature, and should be Processor A.
8.0
Sensitivity Analysis
Certainly at this point, an argument can be made
that the decision was arrived at through many engineering
judgments in the attempts to quantify the decision
criteria utility functions, weightings, and probabilities
of. threshold achievement, and as such leaves some question
as to the validity of the decision.
This is indeed true,
and because of the possible errors introduced during
these estimations, the cost effectiveness evaluation
requires an additional step to give added confidence in
the decision.
This can be accomplished through a sensi-
tivity analysis.
The sensitivity analysis affords a means of altering, in direction and amount, those decision criteria
utility curves, and probabilities of achieving the desired
threshold, which have the least credibility associated
with the estimates.
This can be done either on an indi-
vidual basis, or in combinations deemed most likely to
occur, as long as they are within the realm of possibility,
and even exceeding that limit if it is desirable to
ascertain just how much margin the decision actually
possesses.
148
j
149
Criteria
Y I/O Capability
1
Sensitivity
This criteria can be considered
somewhat soft in that the probability curves mean values are based
upon a single programming iteration
for the sample I/0 program.
Real-
izing that no computer program is
written 100% correct, or minimal
the first time, conceivably the
mean values for fAl and fBl could
approach one another, but most
likely both would get smaller, with
fBl never getting smaller than fAl"
Also, no drastic change of the
utility curve is conceived which
would cause E(U 1 , fBl)
exceed E(U , fA ).
1
1
to equal or
Thus no impact
on this criteria's expected utility
is contemplated.
Y2 InterruptCapability
Similar to Y , except processor
1
A's program would most likely not
decrease beyond B's, which if it
did would only weigh the decision
more favorably for processor A.
150
Sensitivity
Criteria
Y3 Hardware/Software
Development Aids
Somewhat soft in that the number
and complexity of the problems
encountered and how useful each
processor's hardware/software
development aids will be is rather
unpredictable.
However, the group
consensus was in favor of processor
A.
The mean value of fB 3 8
' 1' 8 2
would have to shift to
~'s
2
= ·10
~
81 = 9, and
before impacting this
criteria and still would not
dramatically affect the final
expected utility.
Y4 Vendor Support
Again, somewhat soft in that the
derivation of the probability mean
values was predicated on past
experience with vendor support,
and shifts of 2 months less for
processor A, or 2 months more for
processor B, could cause an appreciable change in this criterion
expected utility, but would not by
itself be enough to change the
final decision.
151
Sensitivity
Criteria
Y5 Tolerance Limit
Computations
Similar to Y and Y2 , with the most
1
likely end result to be an increase
in processor A's expected utility
for this criterion.
Y6 Power Consumption
Fairly solid, and even if processor
B's a were smaller (=1), no significant impact.
Fairly soft for both, because of
continuing price cut announcements
for not only the CPU, but also
support hardware.
However, this
is also in processor A's favor in
that they have captured roughly
2 to 3 times the amount of the
market that processor B has, and
can offer higher, low quantity
discounts.
Y8 Development Time
Processor B's development time,
even if every aspect fell into
place with minimal problems, could
still not be expected to be reduced
much more than 4 to 6 months,
simply because of the constant of
programming time and checkout.
152
Criteria
Sensitivity
Processor A's count is more likely
Y Chip Count
9
to be reduced due to their continual introduction of more general
purpose chips, while processor B
has good general purpose chips out
now and is not expected to change
in the near future.
Y
Reliability
10
Unlikely to change due to processor
A's market maturity affording more
user hour data, providing feedback
about potential problems so they
can identify weak spots sooner.
Various combinations of changes to the decision
criteria can also be theorized which may affect the final
expected utility.
Although various aspects of the decision
criteria utility curve, such as its shape and scaling,
could be adjusted for possible errors in the original
estimations, they typically result in modifying the
alternatives expected utilities by equal amounts.
'
Thus,
little if any change is effected in the relative difference in the alternatives final expected utilities.
Likewise, changes in the probability distribution function
standard deviations, although causing some change in the
expected utilities, again have minimal impact.
153
The greatest change in the expected utilities is
caused by shifting of the probability distribution function
mean values.
Given this, the combination of changes
which seems most realistic and would favor processor B
most, in order to determine whether processor A is indeed
the more viable alternative, is as follows.
The changes likely to occur to the decision
criteria expected utilities in favor of processor B are
in the areas of I/0 Capability (Y ) where the probability
1
of B achieving the threshold would be equal to that of A.
Similarly, it is conceivable that the time saved due to
Vendor Support (Y ) could increase by 1 man-month, and
4
that B's Power Consumption (Y 6 ) might decrease by two
watts, maximum.
Lastly, one could optimistically assume
an additional Development Time (Y 8 ) savings of another 6
man-months.
These changes to processor B would be offset somewhat by possible changes to processor A's expected
utilities.
Primarily, these could occur in the area of
its Interrupt Capability (Y ) with the number of bytes2
~secs
decreasing by two; one additional man-month could
conceivably be saved due to Vendor Support (Y 4 ) ; due to
the fact that processor A has a larger market volume, its
Cost (Y 7 ) relative to B's could be expected to decrease
by $5K; and lastly, continual increases in the number of
functions contained per IC, which A is pursuing more
'
l.
154
aggressively than B, could result in a Chip Count (Y )
9
reduction of possibly 4 chips.
As a result of these possible changes, the expected
utility results shown in Table 7.0-1, would be changed to
those of Table 8.0-1.
Table 8.0-1
Combinational Sensitivity Analysis
Expected Utility Results
Alternative 1 (a )
1
(Processor A)
Criterion
(Y.)
sl
J
s2
Alternative 2 (a 2 )
(Processor B)
s2
sl
yl
98.99
98.99
98.99
98.99
y2
83.97
83.97
87.03
87.03
y3
98.75
107.25
64.99
77.60
y4
76.14
80.51
85.15
92.54
Y5
y6
y
7
y8
80.14
80.14
88.03
88.03
83.04
83.04
83.04
83.04
87.60
97.00
55.81
45.69
73.87
73.87
80.90
80.90
y9
73.20
73.20
68.18
68.18
ylO
98.22
98.22
89.71
89.71
Total
844.92
876.19
801.93
811.71
Taking into account the states of nature probabilities, the resulting final expected utility would be:
E(a )
1
= 844.92(0.75) + 876.19(0.25) = 852.74
E(a )
2
=
801.83(0.75) + 811.71(0.25)
=
804.30
155
Although these results certainly cannot be construed as all inclusive, they do reflect that processor A
i'
. '
appears to have a reasonable margin over processor B as
the final choice.
And even if one were to compare the most
favorable final expected utility for processor B from
above (804.30) resulting from the most optimistic set of
decision criteria, to the original estimates for processor
A (Final Expected Utility
=
844.55, from Table 7.0-1), it
still shows a 5% margin in favor of processor A.
' ' 11'1
''
9.0
Summary and Conclusion
This paper has attempted to propose a systems
approach for a factual and thorough method of evaluating
CPU selection for a ground support equipment controller
application.
Although written around this specific
example, the methodology of performing a functional and
cost effectiveness evaluation is applicable in any instance
where this selection process is required, particularly the
first time a
~P
based design is attempted.
Although time consuming, this approach provides
several distinct advantages.
1)
It requires no large capital investment in
hardware and software to determine which CPU
(and its associated elements) will provide
the highest probability of success in the
system design.
2)
It forces detailed analysis of the capabilities
of the individual CPU, through its hardware
architecture, instruction set completeness,
support circuitry requirements, and accompanying hardware/software development aids software programming, prototyping, and testing
capabilities.
156
157
3)
It forces additional analysis into the functional performance realizable through these
capabilities as they apply to the system
design, formulating those factors of the
decision which ultimately will be the measure
of success of the design.
4)
It requires judgments to quantify those
factors which play a finite part in the
decision, but which are often omitted because
of their intangible measure of worth to the
end design.
5)
Lastly, it teaches a structured method for
approaching a complex decision, which will
become more important as microprocessors
become more prevalent in digital design.
BIBLIOGRAPHY
Periodicals
11
Barnes, J.
Unite ]JP Hardware and Software, 11 Electronic
Design, March 27, 1976, p. 74.
Bond, J.
"Designer's Guide to Software for the Hardware
Designer Part I and II," EDN, June 5, 1974, p. 40.
Bursky, D.
"Choosing a ]JP by Its Capabilities is a
Growing Family Affair," Electronic Design, July 5,
1977, p. 26.
11
Bursky, D.
It's Getting Easier to Program ]JPS with the
New Software Design Aids," Electronic Design, January
18' 1977' p. 20.
Cushman, R. H.
"Are You Taking Advantage of Available
Development Tools," EDN, March 20, 1976, p. 77.
vP
Cushman, R. H.
"Beware of the Errors that Can Creep into
vP Benchmark Programs," EDN, June 20, 1975, p. 105.
Cushman, R. H.
"Development System Solves a Microprocessor
Riddle," EDN, May 20, 1976, p. 69.
Cushman, R. H.
"EDN Microprocessor Design Series, .. EDN,
Vols. I and II, 1975.
Cushman, R. H.
"Exposing the Black Art of Microprocessor
Benchmarking," EDN, April 20, 1975, p. 41.
·
Cushman, R. H.
"How Development Systems Can Speed Up the
]JP Design Process," EDN, April 20, 1976, p. 63.
Cushman, R. H.
"Let the Interrupts Do Their Work When
Designing with a ]JP'," EDN, June 5, 1976, p. 92.
Cushman, R. H.
"Microprocessor Benchmarks: How Well Does
the vP Move Data," EDN, May 20, 1975, p. 43.
Cushman, R. H.
"Take a Common Sense Approach to Your vP
Application," EDN, October 20, 1976, p. 85.
Dermott, J.
"Experts Tell How to Hold Down the High Cost
of Processor Programs," Electronic Design, December
20, 1975, p. 20.
158
159
Etchverry, F. W.
1976, p. 40.
"Binary Serial Interface," EDN, April 20,
Falk, H.
"Linking Microprocessors to the Real World,"
IEEE Spectrum, September 1974, p. 59.
Falk, H.
"The Microprocessor Takeover," IEEE Spectrum,
April 1976, p. 44.
Frankenberg, R. J.
"Designers Guide to Semiconductor
Memories Parts 1 thru 9," EDN, August 5, 1975 thru
January 5, 1976.
Frankenberg, R. J.
"User Microprogramming," Mini-Micro
Systems, July 1977, p. 44.
Franson, P.
"The World of Interfacing Microcomputers,"
EDN, August 5, 1976, p. 38.
Gladstone, B.
"Software Development: It Pays to Have the
Right Tool at the Right Time," EDN, June 20, 1976,
p. 91.
Gladstone, B.
"Software Development: Some Tools Do Big
Jobs Automatically," EDN, August 20, 1976, p. 45.
Hoff, M.
"Designing With Semiconductor RAM's, Part 1 & 2,"
EDN, August 5, 1973, p. 30, August 20, 1973, p. 50.
Jones, T., and P. Thomas.
"Challenges in Microprocessor
System Design," Computer Design, November 1976, p. 109.
Knoblock, D. E., D. C. Loughry, and C. A. Vissers.
"Insight into Interfacing," IEEE Spectrum, May 1975,
p. 50.
Levine, S. T.
"Assembly Language for l-IP's," Electronic
Design, December 20, 1975, p. 58.
Lewis, D. R.
"Microprocessors or Random Logic?" Electronic
Design, September 1, 1973, p. 106.
1
Logan, J.D., and P. s. Kreager.
"Using a MicroprocessorA Real Life Application," Computer Design, September
1975, p. 69.
Metzer, J., and J. Seaman.
"The Large RAM Arrives,"
Electronic Products, November 1976, p. 72.
"Microprocessor Data Manual," Electronic Design Staff,
Electronic Design, p. 54.
i.
:1
160
"Microprocessors," Electronics Staff, Electronics,
April 15, 1976, p. 74.
Ogdin, C. A.
"Microcomputer Design Course," EDN, November
20, 1976, p. 127.
Ogdin, c. A.
"Microprocessors Have Their Problems Too,"
Instruments and Control Systems, August 1976, p. 35.
Ogdin, c. A.
"Single Board Computers," Mini-Micro Systems,
July 1977, p. 30.
Ogdin, c. A.
"Single Chip Versus Two Chip Microcomputers,"
Mini-Micro Systems, May 1977, p. 43.
Ogdin, C. A.
p. 67.
"Software Design Course," EDN, June 5, 1977,
Olson, K.
"Your Micro-based Future, A Return to Sweat
Equity," Digital Design, March 1976, p. 39.
Pine, K.
"Logic Analyzers - Know What You Need," Electronic Products, June 1977, p. 36.
"Primer on Microprocessors Part 1 & 2," Electronic Products, January 20, 1975, p. 25, February 17, 1975, p. 37.
Raphael, H.
"How to Expand a Microcomputer's Memory,"
Electronics, December 23, 1976, p. 67.
Raphael, H.
"Simplify Low Cost llP Selection," Electronic
Design, March 1, 1977, p. 60.
Riley, W. B.
"Blending Hardware and Software," Electronics,
July 11, 1974, p. 103.
Rosenfeld, P.
"Developing Modular Software for the 8080A,"
Electronics, September 30, 1976, p. 83.
Rosenfeld, P.
"Is There a High-Level Language in Your
Microcomputer's Future," EDN, May 20, 1976, p. 62.
Santari, A.
"Peripheral Chips Add Functions - And Problems
- to llP Systems," Electronic Design, May 10, 1977,
p. 32.
Schoeffler, J. D.
"Microprocessor Architecture," IEEE
Transactions on Industrial Electronics and ContrOl
Instrumentation, August 1975, p. 256.
'I
,,
p
161
Seabury, T.
"Microprocessors and Their Applications,"
EE/Systems Engineering Today, December 1973, January
1974.
Springer, J.
"Designers Guide to Semiconductor Memory
Systems," EDN, September 5, 1974, p. 49.
Thomas, A. T.
"Design Techniques for Microprocessor
Memory Systems," Computer Design, August 1975, p. 73.
Titus, J.
"How to Design a 11P Based Controller System,"
EON, August 20, 1974, p. 49.
Toong, Hoo-Min D.
"Microprocessors," Scientific American,
September 1977, p. 146.
Torrero, E. A.
"An Introduction to Microprocessors,"
Electronic Design, April 26, 1976, p. 58.
Torrero, E. A.
"Focus on Microprocessors," Electronic
Design, September 1, 1974, p. 52.
Torrero, E. A.
"Just Getting Into Microprocessors?"
Electronic Design, January 5, 1976, p. 46.
Torrero, E. A.
"Microprocessors - New Direction for
Designers," Electronic Design, Hayden Book Company.
Trifari, J.
"Digital Systems Problems? Use a Logic
Analyzer," Electronic Products, March 1976, p. 33.
Trifari, J.
"ROM's -A Choice for Almost Every Occasion,"
Electronic Products, November 1976, p. 79.
Ulrickson, R. W.
"Software is Vital Part of any Computer,"
Electronic Design, January 4, 1977, p. 90.
Ulrickson, R. W.
"Solve Software Problems Step-by-Step,"
Electronic Design, January 18, 1977, p. 54.
Ulrickson, R. W.
"Your Microcomputer's I/O Software,"
Electronic Design, March 29, 1977, p. 76.
Wyland, D. C.
"Employ 11P Software Tools Properly,"
Electronic Design, December 20, 1975, p. 50.
l
I
162
Books
English, J. Morley. Cost Effectiveness.
Sons, Inc., 1968.
John Wiley and
Korn, Granino A. Minicomputers for Engineers and
Scientists. New York: McGraw-Hill Book Company, 1973.
Lifson, Melvin W.
Books, 1972.
Decision and Risk Analysis.
Cahners
McCluskey, Edward J. Design of Digital Computers.
Springer Verlag, 1975.
Smith, Gerald w. Engineering Economy: Analysis of
Capital Expenditures. The Iowa State University
Pressi 1973.
Soucek, Branko. Microprocessors and Microcomputers.
John Wiley and Sons, Inc., 1976.
Wester, John G. Software Design for Microprocessors.
Texas Instruments, Inc., 1976.