Embedded System Design Issues (the Rest of the Story)

Philip Koopman
Engineering Design Research Center
Carnegie Mellon University
Pittsburgh, PA 15213
koopman@cs.cmu.edu
http://www.cs.cmu.edu/~koopman/

Abstract present “design challenges” encountered in the course of

designing several real systems. These challenges are both
Many embedded systems have substantially different design opportunities to improve methodology and tool support as
constraints than desktop computing applications. No single well as impediments to deploying such support to embedded
characterization applies to the diverse spectrum of embed- system design teams. In some cases research and develop-
ded systems. However, some combination of cost pressure, ment has already begun in these areas — and in other cases
long life-cycle, real-time requirements, reliability require- it has not.
ments, and design culture dysfunction can make it difficult The observations in this paper come from the author’s
to be successful applying traditional computer design meth- experience with commercial as well as military applications,
odologies and tools to embedded applications. Embedded development methodologies, and life-cycle support. All
systems in many cases must be optimized for life-cycle and characterizations are implicitly qualified to indicate a typi-
business-driven factors rather than for maximum computing cal, representative, or perhaps simply an anecdotal case
throughput. There is currently little tool support for expand- rather than a definitive statement about all embedded sys-
ing embedded computer design to the scope of holistic em- tems. While it is understood that each embedded system has
bedded system design. However, knowing the strengths and its own set of unique requirements, it is hoped that the
weaknesses of current approaches can set expectations ap- generalizations and examples presented here will provide a
propriately, identify risk areas to tool adopters, and suggest
ways in which tool builders can meet industrial needs.
SOFTWARE AUXILIARY
SYSTEMS
FPGA/ MEMORY (POWER,
ASIC COOLING)
1. Introduction
Approximately 3 billion embedded CPUs are sold each
HUMAN DIAGNOSTIC
year, with smaller (4-, 8-, and 16-bit) CPUs dominating by INTERFACE CPU PORT
quantity and aggregate dollar amount [1]. Yet, most re-
search and tool development seems to be focussed on the
needs of high-end desktop and military/aerospace embedded A/D D/A
CONVERSION CONVERSION
computing. This paper seeks to expand the area of discus- ELECTROMECHANICAL
sion to encompass a wide range of embedded systems. BACKUP & SAFETY
The extreme diversity of embedded applications makes
generalizations difficult. Nonetheless, there is emerging SENSORS ACTUATORS
interest in the entire range of embedded systems (e.g., [2],
[3], [4], [5], [6]) and the related field of hardware/software EXTERNAL
codesign (e.g., [7]). ENVIRONMENT
This paper and the accompanying tutorial seek to identify
significant areas in which embedded computer design differs Figure 1. An embedded system encompasses the CPU

as well as many other resources.

from more traditional desktop computer design. They also
broad-brush basis for discussion and evolution of CAD tools · Software often has a fixed function, and is specific to the
and design methodologies. application.
In addition to the emphasis on interaction with the exter-
nal world, embedded systems also provide functionality
2. Example Embedded Systems specific to their applications. Instead of executing spread-
Figure 1 shows one possible organization for an embed- sheets, word processing and engineering analysis, embedded
ded system. In addition to the CPU and memory hierarchy, systems typically execute control laws, finite state machines,
there are a variety of interfaces that enable the system to and signal processing algorithms. They must often detect
measure, manipulate, and otherwise interact with the exter- and react to faults in both the computing and surrounding
nal environment. Some differences with desktop computing electromechanical systems, and must manipulate applica-
may be: tion-specific user interface devices.
In order to make the discussion more concrete, we shall
· The human interface may be as simple as a flashing light discuss four example systems (Table 1). Each example
or as complicated as real-time robotic vision.
portrays a real system in current production, but has been
· The diagnostic port may be used for diagnosing the system slightly genericized to represent a broader cross-section of
that is being controlled — not just for diagnosing the applications as well as protect proprietary interests. The four
computer. examples are a Signal Processing system, a Mission Critical
· Special-purpose field programmable (FPGA), application control system, a Distributed control system, and a Small
specific (ASIC), or even non-digital hardware may be used consumer electronic system. The Signal Processing and
to increase performance or safety. Mission Critical systems are representative of traditional

An example of: Signal Processing Mission Critical Distributed Small

Computing speed 1 GFLOPS 10 - 100 MIPS 1-10 MIPS 100,000 IPS
I/O Transfer Rates 1 Gb/sec 10 Mb/sec 100 Kb/sec 1 Kb/sec
Memory Size 32 - 128 MB 16 - 32 MB 1 - 16 MB 1 KB
Units Sold 10 - 500 100 - 1000 100 - 10,000 1,000,000+
Development Cost $20M - $100M $10M - $50M $1M - $10M $100K - $1M
Lifetime 15 - 30 years 20 - 30 years 25 - 50 years 10 - 15 years
Environment Vibration, Heat Heat, Vibration, Dirt, Fire Over-voltage, Heat,
Lightning Vibration
Cost Sensitivity $1000 $100 $10 $0.05
Other Constraints Size, weight, power Size, weight Size Size, weight, power
Safety — Redundancy Mechanical Safety —
Maintenance Frequent repairs Aggressive fault Scheduled “Never” breaks
detection/maintenance maintenance
Digital content Digital except for ~½ Digital ~½ Digital Single digital chip; rest
signal I/O is analog/power
Certification authorities Customer Federal Government Development team Customer;
Federal Government
Repair time goal 1-12 hours 30 minutes 4 min. - 12 hours 1-4 hours
Initial cycle time 3-5 years 4-10 years 2-4 years 0.1-4 years
Product variants 1-5 5-20 10-10,000 3-10
Engineering allocation Per-product budget Per-product budget Allocation from large Demand-driven daily
method pool from small pool
Other possible Radar/Sonar Jet engines High-rise elevators Automotive auxilliaries
examples in this Video Manned spacecraft Trains/trams/subways Consumer electronics
category: Medical imaging Nuclear power Air conditioning “Smart” I/O
Table 1. Four example embedded systems with approximate attributes.
military/aerospace embedded systems, but in fact are be- 3.1. Real time/reactive operation
coming more applicable to general commercial applications
Real time system operation means that the correctness of
over time.
a computation depends, in part, on the time at which it is
Using these four examples to illustrate points, the follow-
delivered. In many cases the system design must take into
ing sections describe the different areas of concern for em-
account worst case performance. Predicting the worst case
bedded system design: computer design, system-level
may be difficult on complicated architectures, leading to
design, life-cycle support, business model support, and de-
overly pessimistic estimates erring on the side of caution.
sign culture adaptation.
The Signal Processing and Mission Critical example sys-
Desktop computing design methodology and tool support tems have a significant requirement for real time operation
is to a large degree concerned with initial design of the digital in order to meet external I/O and control stability require-
system itself. To be sure, experienced designers are cogni- ments.
zant of other aspects, but with the recent emphasis on quan- Reactive computation means that the software executes
titative design (e.g., [8]) life-cycle issues that aren’t readily in response to external events. These events may be peri-
quantified could be left out of the optimization process. odic, in which case scheduling of events to guarantee per-
However, such an approach is insufficient to create embed- formance may be possible. On the other hand, many events
ded systems that can effectively compete in the marketplace. may be aperiodic, in which case the maximum event arrival
This is because in many cases the issue is not whether design rate must be estimated in order to accommodate worst case
of an immensely complex system is feasible, but rather situations. Most embedded systems have a significant reac-
whether a relatively modest system can be highly optimized tive component.
for life-cycle cost and effectiveness. Design challenge:
While traditional digital design CAD tools can make a · Worst case design analyses without undue pessimism in
computer designer more efficient, they may not deal with the the face of hardware with statistical performance charac-
central issue — embedded design is about the system, not teristics (e.g., cache memory [9]).
about the computer. In desktop computing, design often
focuses on building the fastest CPU, then supporting it as
required for maximum computing speed. In embedded sys- 3.2. Small size, low weight
tems the combination of the external interfaces (sensors, Many embedded computers are physically located within
actuators) and the control or sequencing algorithms is or some larger artifact. Therefore, their form factor may be
primary importance. The CPU simply exists as a way to dictated by aesthetics, form factors existing in pre-electronic
implement those functions. The following experiment versions, or having to fit into interstices among mechanical
should serve to illustrate this point: ask a roomful of people components. In transportation and portable systems, weight
what kind of CPU is in the personal computer or workstation may be critical for fuel economy or human endurance.
they use. Then ask the same people which CPU is used for Among the examples, the Mission Critical system has much
the engine controller in their car (and whether the CPU type more stringent size and weight requirements than the others
influenced the purchasing decision). because of its use in a flight vehicle, although all examples
In high-end embedded systems, the tools used for desktop have restrictions of this type.
computer design are invaluable. However, many embedded Design challenges:
systems both large and small must meet additional require-
ments that are beyond the scope of what is typically handled
· Non-rectangular, non-planar geometries.
by design automation. These additional needs fall into the
· Packaging and integration of digital, analog, and power
circuits to reduce size.
categories of special computer design requirements, system-
level requirements, life-cycle support issues, business model
compatibility, and design culture issues. 3.3. Safe and reliable
Some systems have obvious risks associated with failure.
In mission-critical applications such as aircraft flight con-
3. Computer Design Requirements
trol, severe personal injury or equipment damage could
Embedded computers typically have tight constraints on result from a failure of the embedded computer. Tradition-
both functionality and implementation. In particular, they ally, such systems have employed multiply-redundant com-
must guarantee real time operation reactive to external puters or distributed consensus protocols in order to ensure
events, conform to size and weight limits, budget power and continued operation after an equipment failure (e.g., [10],
cooling consumption, satisfy safety and reliability require- [11])
ments, and meet tight cost targets. However, many embedded systems that could cause per-
sonal or property damage cannot tolerate the added cost of 4.1. End-product utility
redundancy in hardware or processing capacity needed for
The utility of the end product is the goal when designing
traditional fault tolerance techniques. This vulnerability is
an embedded system, not the capability of the embedded
often resolved at the system level as discussed later.
computer itself. Embedded products are typically sold on
Design challenge: the basis of capabilities, features, and system cost rather than
· Low-cost reliability with minimal redundancy. which CPU is used in them or cost/performance of that CPU.
One way of looking at an embedded system is that the
3.4. Harsh environment mechanisms and their associated I/O are largely defined by
the application. Then, software is used to coordinate the
Many embedded systems do not operate in a controlled mechanisms and define their functionality, often at the level
environment. Excessive heat is often a problem, especially of control system equations or finite state machines. Finally,
in applications involving combustion (e.g., many transpor- computer hardware is made available as infrastructure to
tation applications). Additional problems can be caused for execute the software and interface it to the external world.
embedded computing by a need for protection from vibra- While this may not be an exciting way for a hardware
tion, shock, lightning, power supply fluctuations, water, engineer to look at things, it does emphasize that the total
corrosion, fire, and general physical abuse. For example, in functionality delivered by the system is what is paramount.
the Mission Critical example application the computer must Design challenge:
function for a guaranteed, but brief, period of time even
under non-survivable fire conditions.
· Software- and I/O-driven hardware synthesis (as opposed
to hardware-driven software compilation/synthesis).
Design challenges:
· Accurate thermal modelling.
· De-rating components differently for each design, depend- 4.2. System safety & reliability
ing on operating environment. An earlier section discussed the safety and reliability of
the computing hardware itself. But, it is the safety and
reliability of the total embedded system that really matters.
3.5. Cost sensitivity
The Distributed system example is mission critical, but does
Even though embedded computers have stringent re- not employ computer redundancy. Instead, mechanical
quirements, cost is almost always an issue (even increasingly safety backups are activated when the computer system loses
for military systems). Although designers of systems large control in order to safely shut down system operation.
and small may talk about the importance of cost with equal A bigger and more difficult issue at the system level is
urgency, their sensitivity to cost changes can vary dramati- software safety and reliability. While software doesn’t nor-
cally. A reason for this may be that the effect of computer mally “break” in the sense of hardware, it may be so complex
costs on profitability is more a function of the proportion of that a set of unexpected circumstances can cause software
cost changes compared to the total system cost, rather than failures leading to unsafe situations. This is a difficult
compared to the digital electronics cost alone. For example, problem that will take many years to address, and may not
in the Signal Processing system cost sensitivity can be esti- be properly appreciated by non-computer engineers and
mated at approximately $1000 (i.e., a designer can make managers involved in system design decisions ([12] dis-
decisions at the $1000 level without undue management cusses the role of computers in system safety).
scrutiny). However, with in the Small system decisions Design challenges:
increasing costs by even a few cents attract management · Reliable software.
attention due to the huge multiplier of production quantity · Cheap, available systems using unreliable components.
combined with the higher percentage of total system cost it · Electronic vs. non-electronic design tradeoffs.
represents.
Design challenge:
· Variable “design margin” to permit tradeoff between prod- 4.3. Controlling physical systems
uct robustness and aggressive cost optimization. The usual reason for embedding a computer is to interact
with the environment, often by monitoring and controlling
external machinery. In order to do this, analog inputs and
4. System-level requirements outputs must be transformed to and from digital signal levels.
In order to be competitive in the marketplace, embedded Additionally, significant current loads may need to be
systems require that the designers take into account the entire switched in order to operate motors, light fixtures, and other
system when making design decisions. actuators. All these requirements can lead to a large com-
puter circuit board dominated by non-digital components. rent product and manufacturing process design, production,
In some systems “smart” sensors and actuators (that and deployment. But in many embedded systems, the de-
contain their own analog interfaces, power switches, and signer must see past deployment and take into account
small CPUS) may be used to off-load interface hardware support, maintenance, upgrades, and system retirement is-
from the central embedded computer. This brings the addi- sues in order to actually create a profitable design. Some of
tional advantage of reducing the amount of system wiring the issues affecting this life-cycle profitability are discussed
and number of connector contacts by employing an embed- below.
ded network rather than a bundle of analog wires. However,
this change brings with it an additional computer design
problem of partitioning the computations among distributed
5.1. Component acquisition
computers in the face of an inexpensive network with modest Because an embedded system may be more application-
bandwidth capabilities. driven than a typical technology-driven desktop computer
Design challenge: design, there may be more leeway in component selection.
· Distributed system tradeoffs among analog, power, me- Thus, component acquisition costs can be taken into account
chanical, network, and digital hardware plus software. when optimizing system life-cycle cost. For example, the
cost of a component generally decreases with quantity, so
design decisions for multiple designs should be coordinated
4.4. Power management to share common components to the benefit of all.
A less pervasive system-level issue, but one that is still Design challenge:
common, is a need for power management to either minimize · Life-cycle, cross-design component cost models and opti-
heat production or conserve battery power. While the push mization rather than simple per-unit cost.
to laptop computing has produced “low-power” variants of
popular CPUs, significantly lower power is needed in order
5.2. System certification
to run from inexpensive batteries for 30 days in some appli-
cations, and up to 5 years in others. Embedded computers can affect the safety as well as the
Design challenge: performance the system. Therefore, rigorous qualification
procedures are necessary in some systems after any design
· Ultra-low power design for long-term battery operation.
change in order to assess and reduce the risk of malfunction
or unanticipated system failure. This additional cost can
5. Life-cycle support negate any savings that might have otherwise been realized
by a design improvement in the embedded computer or its
Figure 2 shows one view of a product life-cycle (a sim- software. This point in particular hinders use of new tech-
plified version of the view taken by [13]). First a need or nology by resynthesizing hardware components — the re-
opportunity to deploy new technology is identified. Then a designed components cannot be used without incurring the
product concept is developed. This is followed by concur- cost of system recertification.
NEED/ One strategy to minimize the cost of system recertifica-
OPPORTUNITY tion is to delay all design changes until major system up-
RETIREMENT/ CONCEPT grades occur. As distributed embedded systems come into
DISPOSAL DEVELOPMENT more widespread use, another likely strategy is to partition
the system in such a way as to minimize the number of
subsystems that need to be recertified when changes occur.
This is a partitioning problem affected by potential design
MANUFACTURING PRODUCT
PROCESS
changes, technology insertion strategies, and regulatory re-
UPGRADES DESIGN quirements.
DESIGN
Design challenge:
· Partitioning/synthesis to minimize recertification costs.

SUPPORT/ PRODUCTION
MAINTENANCE 5.3. Logistics and repair
DEPLOYMENT Whenever an embedded computer design is created or
changed, it affects the downstream maintenance of the prod-
Figure 2. An embedded system lifecycle.
uct. A failure of the computer can cause the entire system to
be unusable until the computer is repaired. In many cases ponents are no longer economically available, the entire
embedded systems must be repairable in a few minutes to a embedded computer must sometimes be redesigned or up-
few hours, which implies that spare components and main- graded. This redesign might need to take place even if the
tenance personnel must be located close to the system. A system is no longer in production, depending on the avail-
fast repair time may also imply that extensive diagnosis and ability of a replacement system. This problem is a signifi-
data collection capabilities must be built into the system, cant concern on the Distributed example system.
which may be at odds with keeping production costs low. Design challenge:
Because of the long system lifetimes of many embedded · Cost-effectively update old designs to incorporate new
systems, proliferation of design variations can cause signifi- components.
cant logistics expenses. For example, if a component design
is changed it can force changes in spare component inven-
tory, maintenance test equipment, maintenance procedures, 6. Business model
and maintenance training. Furthermore, each design change The business models under which embedded systems are
should be tested for compatibility with various system con- developed can vary as widely as the applications themselves.
figurations, and accommodated by the configuration man- Costs, cycle time, and the role of product families are all
agement database. crucial business issues that affect design decisions.
Design challenge:
· Designs optimized to minimize spares inventory.
6.1. Design vs. production costs
· High-coverage diagnosis and self-test at system level, not
just digital component level. Design costs, also called Non-Recurring Engineering
costs (NRE), are of major importance when few of a particu-
lar embedded system are being built. Conversely, produc-
5.4. Upgrades
tion costs are important in high-volume production.
Because of the long life of many embedded systems, Embedded systems vary from single units to millions of
upgrades to electronic components and software may be units, and so span the range of tradeoffs between design
used to update functionality and extend the life of the em- versus production costs.
bedded system with respect to competing with replacement At the low-volume end of the spectrum, CAD tools can
equipment. While it may often be the case that an electronics help designers complete their work with a minimum of
upgrade involves completely replacing circuit boards, it is effort. However, at the high-volume end of the spectrum the
important to realize that the rest of the system will remain designs may be simple enough and engineering cost such a
unchanged. Therefore, any special behaviors, interfaces, small fraction of total system cost that extensive hand-opti-
and undocumented features must be taken into account when mization is performed in order to reduce production costs.
performing the upgrade. Also, upgrades may be subject to CAD tools may be able to outperform an average engi-
recertification requirements. neer at all times, and a superior engineer on very large
Of special concern is software in an upgraded system. designs (because of the limits of human capacity to deal with
Legacy software may not be executable on upgraded re- complexity and repetition). However, in small designs some
placement hardware, and may not be readily cross-compiled embedded computer designers believe that a superior human
to the new target CPU. Even worse, timing behavior is engineer can outperform CAD tools. In the Small system
likely to be different on newer hardware, but may be both example a programmer squeezed software into a few hun-
undocumented and critical to system operation. dred bytes of memory by hand when the compiler produced
Design challenge: overly large output that needed more memory than was
· Ensuring complete interface, timing, and functionality available. It can readily be debated whether CAD tools or
compatibility when upgrading designs. humans are “better” designers, but CAD tools face skepti-
cism in areas that require extraordinary optimization for size,
performance, or cost.
5.5. Long-term component availability Design challenge:
When embedded systems are more than a few years old, · Intelligently trade off design time versus production cost.
some electronic components may no longer be available for
production of new equipment or replacements. This prob-
lem can be especially troublesome with obsolete processors
6.2. Cycle time
and small-sized dynamic memory chips. The cycle time between identification of a product oppor-
When a product does reach a point at which spare com- tunity and product deployment (also called Time to Market)
can be quite long for embedded systems. In many cases the on simulation and CAD tools to provide engineering trade-
electronics are not the driving force; instead, product sched- offs based on accurate performance and cost predictions.
ules are driven by concerns such as tooling for mechanical Computer designers venturing into the embedded arena
components and manufacturing process design. Superfi- must realize that their culture (and the underlying tool infra-
cially, this would seem to imply that design time for the structure) are unlike what is commonly practiced in some
electronics is not an overriding concern, but this is only other engineering disciplines. But, because embedded sys-
partially true. tem design requires a confluence of engineering skills, suc-
Because the computer system may have the most malle- cessful computer designers and design methodologies must
able design, it may absorb the brunt of changes. For exam- find a harmonious compromise with the techniques and
ple, redesign of hardware was required on the Mission methodologies of other disciplines as well as company man-
Critical example system when it was found that additional agement. Also, in many cases the engineers building em-
sensors and actuators were needed to meet system perform- bedded computer systems are not actually trained in
ance goals. On the Small example system, delays in making computer engineering (or, perhaps not even electrical engi-
masked ROM changes in order to revise software dominate neering), and so are not attuned to the culture and method-
concerns about modifications (and programmable memory ologies of desktop computer design.
is too expensive). So, although the initial design is often not
in the critical path to product deployment, redesign of the
computer system may need to be done quickly to resolve 7.1. Computer culture vs. other cultures
problems. A specific problem is that computer design tools have
Design challenge: progressed to the point that many believe it is more cost-ef-
· Rapid redesign to accommodate changing form factors, fective to do extensive simulation than build successive
control algorithms, and functionality requirements. prototypes. However, in the mechanical arena much exist-
ing practice strongly favors prototyping with less exhaustive
up-front analysis. Thus, it may be difficult to convince
6.3. Product families project managers (who may be application area specialists
In many cases embedded system designs are not unique, rather than computer specialists) to spend limited capital
and there are a variety of systems of various prices and budgets on CAD tools and defer the gratification of early
capabilities forming a product family. To the extent that prototype development in favor of simulation.
system designers can reuse components, they lower the total Design challenge:
cost of all systems in the product family. · Make simulation-based computer design accessible to non-
However, there is a dynamic tension between overly specialists.
general solutions that satisfy a large number of niche require-
ments, and specifically optimized designs for each point in
a product family space. Also, there may be cases in which 7.2. Accounting for cost of engineering design
contradictory requirements between similar systems prevent One area of common concern is the effectiveness of using
the use of a single subsystem design. In the Mission Critical engineers in any design discipline. But, some computer
and Small examples different customers require different design CAD tools are very expensive, and in general organi-
interfaces between the embedded system and their equip- zations have difficulty trading off capital and tool costs
ment. In the Distributed example regulatory agencies im- against engineering time. This means that computer design-
pose different safety-critical behavior requirements ers may be deprived of CAD tools that would reduce the total
depending on the geographic area in which the system is cost of designing a system.
deployed.
Also, in high-volume applications engineering costs can
Design challenge: be relatively small when compared to production costs.
· Customize designs while minimizing component variant Often, the number of engineers is fixed, and book-kept as a
proliferation. constant expense that is decoupled from the profitability of
any particular system design, as is the case in all four
example systems. This can be referred to as the “Engineers
7. Design culture Are Free” syndrome. But, while the cost of engineering time
Design is a social activity as well as a technical activity. may have a small impact on product costs, the unavailability
The design of desktop computers, and CPUs in particular, of enough engineers to do work on all the products being
has matured in terms of becoming more quantitative in designed can have a significant opportunity cost (which is,
recent years. With this new maturity has come an emphasis in general, unmeasured).
 Design challenge: current form. Such methodologies may not be cost-effective
· Improved productivity via using tools and methodologies given constraints on categories of expenditures, may not be
may be better received by managers if it is perceived to seen as worthwhile by non-computer-trained professionals,
increase the number of products that can be designed, or may simply be solving the wrong problems.
rather than merely the efficiency of engineers on any given Recent interest in hardware/software codesign is a step in
product design effort. This is a subtle but, in practice, the right direction, as it permits tradeoffs between hardware
important distinction. and software that are critical for more cost-effective embed-
ded systems. However, to be successful future tools may
well need to increase scope even further to include life-cycle
7.3. Inertia issues and business issues.
In general, the cost of change in an organization is high The tutorial slide presentation presented at the conference
both in terms of money and organizational disruption. The aug ments th is paper, and may be found at:
computer industry can be thought of as being forced to http://www.cs.cmu.edu/~koopman/iccd96/
change by inexorable exponential growth in hardware capa-
bilities. However, the impact of this growth seems to have Acknowledgements
been delayed in embedded system development. In part this
This work was sponsored, in part, by DARPA contract
is because of the long time that elapses between new tech-
DABT63-95-C-0026, and ONR contract N00014-96-1-
nology introduction and wide-scale use in inexpensive sys-
0202.
tems. Thus, it may simply be that complex designs will force
updated CAD tools and design methodologies to be adopted
for embedded systems in the near future. References
On the other hand, the latest computer design technolo- [1] Bernard Cole, “Architectures overlap applications”, Electronic
gies may not have been adopted by many embedded system Engineering Times, March 20, 1995, pp. 40,64-65.
makers because they aren’t necessary. Tool development [2] Stephanie White, Mack Alford & Julian Hotlzman, “Systems
that concentrates on the ability to handle millions of transis- Engineering of Computer-Based Systems.” In: Lawson
tors may simply not be relevant to designers of systems using (ed.), Proceedings 1994 Tutorial and Workshop on Systems
4- and 8-bit microprocessors that constitute the bulk of the Engineering of Computer-Based Systems, IEEE Computer
embedded CPU market. And, even if they are useful, the Society, Los Alamitos CA, 1994, pp. 18-29.
[3] Design Automation for Embedded Systems: an international
need for them may not be compelling enough to justify the
journal, Kluwer Academic, ISSN 0929-5585.
pain and up-front expense of change so long as older tech-
[4] Embedded Systems Programming, Miller Freeman, San Fran-
niques work. cisco, ISSN 1040-3272.
That is not to say that new tools aren’t needed, but rather [5] Daniel D. Gajski, Frank Vahid, Sanjiv Narayan & Jie Gong,
that the force of cultural inertia will only permit adoption of Specification and Design of Embedded Systems, PTR Pren-
low-cost tools with significant advantages to the problem at tice Hall, Englewood Cliffs NJ, 1994.
hand. [6] Jack Ganssle, Art of programming Embedded Systems, Aca-
Design challenge: demic Press, San Diego, 1992.
[7] Don Thomas & Rolf Ernst (eds.), Proceedings: Fourth Inter-
· Find/create design tools and methodologies that provide national Workshop on Hardware/Software Co-Design,
unique, compelling advantages for embedded design.
IEEE Computer Society, Los Alamitos CA, 1996.
[8] David Patterson & John Hennessy, Computer Architecture: a
Quantitative Approach, Morgan Kaufmann, San Mateo CA,
8. Conclusions 1990.
Many embedded systems have requirements that differ [9] Philip Koopman, “Perils of the PC Cache”, Embedded Systems
significantly both in details and in scope from desktop com- Programming, May 1993, 6(5) 26-34.
puters. In particular, the demands of the specific application [10] Shem-Tov Levi & Ashok Agrawala, Fault Tolerant System
and the interface with external equipment may dominate the Design, McGraw-Hill, New York, 1994.
system design. Also, long life-cycles and in some cases [11] Daniel Siewiorek & Robert Swarz, Reliable Computer Sys-
tems: design and evaluation (2nd edition), Digital Press,
extreme cost sensitivity require more attention to optimiza-
Burlington MA, 1992.
tion based on these goals rather than maximizing the com- [12] Nancy Leveson, Safeware: system safety and computers,
putational throughput. Addison-Wesley, Reading MA, 1994.
The business and cultural climates in many embedded [13] Georgette Demes et al., “The Engineering Design Research
system design situations are such that traditional simulation- Center of Carnegie Mellon University,” Proceedings of the
based computer design techniques may not be viable in their IEEE, 81(1) 10-24, January 1993.