1. Embedded Architect: A Tool for Early Performance Evaluation of Embedded
Software
J e f f r y T Russell, M a r g a r i d a F J a c o m e
Department of Electrical and Computer Engineering
University of Texas at Austin
Austin, TX 78712 USA
jeffry@mail.utexas.edu, jacome@ece.utexas.edu
Abstract For component-based embedded systems, the need to
identify a subset of functionality for a performance
Embedded Architect is a design automation tool that evaluation is motivated by two primary issues. First, due to
embodies a static performance evaluation technique to economy of scale, components otten package functionality
support early, architecture-level design space exploration that goes unused in a final design [1]. Second, only a small
for component-based embedded systems. A static control subset of the useful functionality is considered for a
flow characterization, called an evaluation scenario, is performance evaluation. This is because components used
specified based on an incremental refinement of software in real designs have a functional description that is very
source code, Jhom which a pseudo-trace of operations is complex, mostly arising from error checking, exception
generated In combination with architecture mapping and handling, initialization, or other "housekeeping" details. A
several component parameters, a software performance "typical case" control flow through the specification serves
metric is estimated as the basis for a performance evaluation.
The novel contribution is the implementation of a tool The Embedded Architect tool demonstrates an
that automates specification of an evaluation scenario, implementation of our research into early, architecture-
which sets the context for a rapid performance evaluation level design automation for component-based embedded
of distinct candidate architectures. systems, The novel contribution is automation of the
evaluation scenario specification introduced in [3].
1. Introduction
The Embedded Architect design automation tool 2. Approach
supports design space exploration for component-based, The evaluation scenario is interactively defined by
embedded systems. Specifically, it assists an experienced identifying control flows in the system functionality that
designer in the specification of control paths from software correspond to a representative system behavior; a
source code, which serve as the context for a performance challenging task that is assisted by an extended form of
evaluation. Embedded Architect targets architecture-level structural analysis that can be applied simultaneously to
design of a class of embedded systems for which software and hardware components. An estimated trace is
performance is a figure of merit, as opposed to real-time statically generated, and pertinent architecture features are
embedded systems for which performance constraints must used to estimate the execution time of this pseudo-trace.
be satisfied for proper system operation.
A performance analysis involving real time constraints 2.1 Architecture Model
requires an examination of all functional paths. In contrast, An architecture is an abstract representation of a design
for the class of embedded systems contemplated, the that is a configuration of subsystems, organized into two
designer faces the challenge of identifying characteristic topologies. The functional architecture specifies a set of
functional paths to serve as the context for a performance concurrent, sequential processes using subsystems to
evaluation, called evaluation scenarios. Our previous work specify functionality and connections to indicate flow of
proposed a performance evaluation technique based on the control. The functional subsystems are specified with an
evaluation scenario to support a rapid, comparative imperative source code language that is predominantly
assessment of embedded system architectures [3]. software, but also includes hardware. The underlying
Component-based designs are beneficial in terms of formalism used to analyze software is a control flow graph
shorter development cycles, reduced cost, and improved (CFG) of primitive operations.
maintainability [2][4]. A component-based embedded The structural architecture consists of subsystems that
system favors an architecture consisting of predefined support execution of operations and connections that
subsystems, "packaged" as components, rather than custom represent communication paths. Operations from the
specified subsystems. Hardware components such as CPUs functional architecture are mapped to execution and storage
or memories provide structural resources, and software resources in the structural architecture.
components provide pure functionality.
0-7695-1877-X/03 $17.00 © 2003 IEEE 824

2. A component is hardware or software whose speci- foo.c ,
Embedded ArchitectE m
fication is fixed, though possibly parameterized. A compo-
nent represents some portion of an architecture, ranging
Gcc~L I 'real"
r~.l Correlator I [-~-14J.a,,"~"
~ source --~ I I ~ I A
from a single subsystem to a frozen portion of the config- I cpp ~J I code ~ T !4~
uration consisting of several subsystems and connections. I Source + "~ - -
I RTL : i code.view ~ User I
2.2 Design Space Exploration f -~ ' , ' ~ export . :F i flail,! Interface I
/ Library of / r--t--, I ,,.as :.:i:i " 1' '
Design space exploration (DSE) ~omponents j
research can be classified as I as I I,----L--i :: view 4,
addressing aspects of representation, 4' " ; [ I mep~rt ~ . ; .i t ~: : | Manual I
fo00
_" i [ ,..r~ J V .... l
" I .'l I
r ^ .
uycles i
I
estimation, and exploration a l g o - I Architecture ~
F~" w . ~ :::; : Intemal ~ .! I
rithms. As shown to the right, a
DSE framework generates candidate
"Generator"
,~,
]
' I T'ace Represen*a*'°°:
Generator CFG, PDG, Automatic
i
architectures using a library of Candidate I ,~,:: . labels Cycles
components. Each candidate is Architecture o I • Pseud ° Tr ace " : .
evaluated based on a set of metrics .a
that may guide future architecture 'i' "~ Figure 3. Embedded Architect implementation.
generation. Our Embedded Archi- Evaluator
tect tool supports an evaluator in an provides a constraint. Using this constraint, more
existing framework by providing a 't' automatic constraint cycles are attempted, continuing until
rapid estimate of a performance Metrics . . . . all predicates are constrained.
metric.
3. I m p l e m e n t a t i o n o f E m b e d d e d A r c h i t e c t
Figure 1. DSE flow
2.3 Scenario Specification An overview of the tool is shown in Figure 3. To
Intuitively, an evaluation scenario corresponds to a walk provide for a comparison of performance estimates to code
through the collection of CFGs that expresses the executing on real hardware, the starting point is the gee
functional architecture. The flow to specify a scenario is compiler, as it can produce production quality code for a
shown in Figure 2, which begins with a set of CFGs to variety of processor architectures. The compiler was
analyze and the start/end nodes of the scenario. To define a instrumented to export a CFG, which is imported into
scenario, the designer needs to constrain all control Embedded Architect. The dashed line represents Embedded
operation predicates. An initial pruning cycle analyzes the Architect, and the shaded portion indicates the focus of the
control dependences between the start and end nodes and research prototype.
extracts predicate constraints. This begins an automatic
4. F u t u r e W o r k
cycle in which constraints are applied, nodes are pruned
from the CFG, and data flow facts are propagated. Embedded Architect analyzes a candidate architecture
If the data flow fact propagation results in new and eventually leads to a performance estimate. In addition
constraints on any control operations, then subsequent to comparing the fidelity of the estimates, the efficacy of
automatic cycles continue until no new constraints are the scenario specification is demonstrated based on the
found. If there are any control operations letI to constrain, number of control operation nodes eliminated due to
a manual constraint cycle begins in which the designer pruning (more is better), the number of constraints found
automatically from propagation of data flow facts (more is
Initial pruning due better), and the number of manual constraints supplied by
to end nodes the designer (fewer is better).
Find initial I
constraints I " 5. R e f e r e n c e s
~ Designer
Constrain CFG pI--j ~constraint ~ ~, [1] V. Basili, B. Boehm, COTS-Based Systems Top 10 List,
' + Computer, v 34, n 5, May 2001, pp 91-93
[2] U. Rastofer, F. Bellosa, Component-based software
I Prune nodes, I engineering for distributed embedded real-time systems, IEEE
§1~ I pr°pagate facts J / A . n Y ~ -18 Proc.-Software, v 148, n 3, June 2001
[3] J. Russell, M. Jaeome, Scenario-Based SoRware
Characterization as a Contingency to Traditional Program
Profiling, CASES '02, Grenoble, France, Oct. 2002
[4] M. Sparling, Lessons learned through six years of
component-baseddevelopment, Comm. ACM, v43, nl0, Oct 2000
Figure 2. Flow to specify evaluation scenario.
825