%% This is an example first chapter.  You should put chapter/appendix that you
%% write into a separate file, and add a line \include{yourfilename} to
%% main.tex, where `yourfilename.tex' is the name of the chapter/appendix file.
%% You can process specific files by typing their names in at the 
%% \files=
%% prompt when you run the file main.tex through LaTeX.
\chapter{Introduction}

Developing software for embedded systems is a very common task in both
industry and the military.  Today, microprocessors are in everything
from cars to televisions to kitchen appliances, and applications
promise only to grow as hardware costs continue to fall.  However, the
cost of developing software for embedded system remains high because
the embedded software development process is difficult.  

\section{Current Development Strategies}

In a typical embedded software development project, each engineer has
a workstation on which the software is written.  There are also
separate development environments in which the software is debugged
and tested.  The quality of these environments is directly linked to
software engineer productivity.  There are four basic types of
environments: laboratory, workstation-based target, cross, and
simulated.

\subsection{Laboratory-based Target Environment}

Because the target software must ultimately run on the target
hardware, every project must set up an environment containing the
actual target hardware.
%
%
%
This environment, called the target environment, also must contain
some facility for loading the target software into the target
hardware.  Depending on the nature of the project, other pieces of
hardware with which the target interacts may be necessary.  To make
the environment tolerable for the software developer, other tools may
be added.  One common and powerful tool is the in-circuit emulator,
which plugs into the socket for the target's microprocessor, emulates
the microprocessor, and links to a workstation running a symbolic
debugger.  In addition, tools that allow inspection of external
hardware devices or communication pathways can be useful.
%
%
%
However, such tools are typically expensive to acquire and maintain.
In general, the target environment suffers from two fundamental
problems.  The first is a lack of vision: it is very difficult to
inspect the internal state of all of the various hardware components.
The second is a lack of control: while it may be possible to suspend
the microprocessor and single-step, other hardware components may not
be so obliging, and may time out or otherwise behave differently than
they would at full-speed.  Similarly, while it may be possible to
arbitrarily change the internal state of the microprocessor or its
memory, it is generally impossible to arbitrarily change the internal
state of external hardware components.  These deficiencies can make it
very difficult to isolate what are theoretically very simple bugs.

\psfig{target-environment.idraw}{The Laboratory-based Target Environment}{intro:te}

\subsection{Workstation-based Target Environment}

In an attempt to get a better handle on the embedded system, the
workstation-based target environment requires that a project-specific
hardware interface be built between the target hardware and the
workstation.  Alongside an in-circuit emulator, this interface enables
special software on the workstation to fully monitor and control the
execution of the target, giving the developer control not only of the
microprocessor but also of the various special-purpose hardware
components on the embedded system.  This environment has a higher
startup cost than the laboratory environment --- building the
interface and the software to run it are not easy tasks.  Furthermore,
external hardware devices are every bit as hard to examine and control
as before.

\psfig{wks-target-environment.idraw}{The Workstation-based Target
Environment}{intro:wte}

\subsection{Workstation-based Cross-environment}

In response to the difficulties of the target environments, a
development team may set up a workstation-based cross-environment.
In this environment, portions of the embedded software are compiled
with the workstation's native compiler, and are debugged using the
workstation's development tools.  In this environment, engineers can
quickly isolate bugs having to do with logic in high-level routines.
The problems of control and vision are solved.  However, two
significant new limitations are introduced.  The first is a reduced
scope: code dealing directly with hardware, or written in a language
not available on the workstation (usually assembly language), must be
stubbed out.  The second is reduced faithfulness: conditions having to
do with timing, interrupts, hardware device handling, and so forth are
so different than in the target environment that there is a large
class of bugs that appear in one environment but not the other.
Nonetheless, without other alternatives, the gain in vision and
control is worth the effort of getting the embedded software to run
natively on the workstation.

\psfig{cross-environment.idraw}{The Workstation-based Cross-environment}{intro:ce}

\subsection{The Workstation-based Simulated Environment}

A third type of environment is the workstation-based simulated
environment, based on a specialized program called a microprocessor
simulator.  The microprocessor simulator runs on the workstations, and
can load the target software into workstation memory.  It then
simulates the target microprocessor, stepping instruction by
instruction, decoding each instruction, and performing its effects.
With a suitable user interface and symbolic debugging capabilities,
the vision and control of the workstation-based cross-environment can
be achieved.  Because it simulates at a target-instruction level, the
limited scope of the workstation-based cross-environment is overcome.
Part of the faithfulness problem is solved as well; if care is taken
when developing the simulator, it can simulate instruction timing and
interrupt handling to sub-microsecond accuracy.
%
%%%%%%%% The extensibility problem
%
However, a great problem for the simulated environment lies in
handling external hardware.  The target software must communicate with
external devices; these devices are not connected to the workstation,
and a generic microprocessor simulator knows nothing about them.
There are two obvious ways to handle this problem.
%
%%%%%%%% Previous attempts to solve the extensibility problem (?!?!?!)
%
First, two versions of the embedded software can be built: one for the
target environment, and one meant to run under the microprocessor
simulator.  The latter would have low-level device-handling code
stubbed out, replaced by routines that would feed the necessary
results back to test other parts of the embedded software.  In this
case, the scope and faithfulness of the environment are reduced, as in
the workstation-based simulated environment, and it is no longer
clearly worth the effort to acquire the simulator.  Another way to
handle external hardware is to extend the generic microprocessor
simulator with code to simulate external hardware components.  This is
a viable but difficult option.  The source code for the simulator must
be available.  The specifications for the hardware are frequently
unknown or change over the course of the project.  The simulator is
typically coded in a low-level language like ``C'' due to speed
considerations, and ``C'' is not a particularly convenient language
for implementing hardware simulation.  Once the current project ends
and the next begins, only the generic microprocessor portion of the
simulator is still useful.

\psfig{simulated-environment.idraw}{The Workstation-Based
Simulated Environment}{intro:se}


%
%%%%%%%% Proposed solution to the extensibility problem
%

Another way to solve the problem of external hardware in a simulated
environment is to equip the generic microprocessor simulator with a
hardware modeling language.  In addition to reading in the compiled
embedded software, it could also read and interpret programs in a
high-level language designed to describe the interaction between a
microprocessor and external hardware.  If this language is implemented
well, it can be ported from simulator to simulator, surviving not only
many projects but also many microprocessor types.  A simulator
equipped with such a language gives the vision and control of the
workstation-based cross-environment, the full scope of the target
environment, and, when programmed properly, can be made as faithful to
the target environment as is desired.  SOTEST is a successful example
of such a system, a combination of a microprocessor simulator (with a
symbolic debugger) and hardware modeling language.