Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 306 2009-10-2
306 Model-Based Design for Embedded Systems
are different ways in which the cost may be calculated. Steps 6–7 in
Figure 10.12 illustrate two different types of processing elements that
may be used, and the interface to inform them which processing rou-
tine they should compute a cost for. The type of the processing element
may be changed easily to provide the necessary balance between the
speed of simulation and the required pre-simulation effort.
10.6.1.3 Mapped System
Table 10.4 describes the 48 mappings investigated. These vary from 11 PEs
to 1 PE. Partitions are broken down by the Rx, the Tx, the RLC, and the MAC
functionalities. Each is categorized into one of nine separate classes based on
the number of processing elements and the mix of pre-profiled and runtime
processing elements. Mappings are further categorized as purely runtime
processing (RTP) elements, purely profiled processing (PP) elements, or a
mix (MIX).
10.6.1.4 Results
Results relating to the design effort, the processing time, the framework sim-
ulation time, and the event processing are analyzed. Five different models
were used: a timed SystemC UMTS model [55], a timed M
ETRO II UMTS
model, an untimed M
ETRO II UMTS model, a SystemC runtime processing
model, and a M
ETRO II architectural model. In specific configurations, METRO
II constraints were used as opposed to explicit synchronization. The selection
of constraints, functional model configuration, architectural model parame-
ters, and mapping assignment is all achieved through small changes to the
top-level netlist. All results are gathered on a 1.8 GHz Pentium M laptop
running Windows XP with 1GB of RAM.
Figure 10.13 shows the UMTS estimated execution times (cycles) along

with the average processing-element utilization. Utilization is calculated as
the percentage of simulation rounds that an architectural processing element
has enabled outstanding functional model event requests for its services.
Low utilization indicates that a processing element is idle despite available,
outstanding requests. The x-axis (mapping #) is ordered by increasing execu-
tion times. The data is collected for each of the three scheduling algorithms.
For round-robin scheduling, the lowest and highest execution times are
obtained with mapping #1 (11 Sparcs) and mapping #46 (1 μBlaze), respec-
tively. Mapping #1 is 2167% faster than mapping #46. This shows a large
range in potential performances across mappings. It is interesting to note
that there are 23 different mappings that offer better performance than the
11 μBlaze or 11 ARM7 cores (mappings #2 and #3). This illustrates that inter-
processor communication is a bottleneck for many designs, and despite hav-
ing more concurrency those designs cannot keep pace with smaller, more
heavily-loaded mappings. Among all four processor systems, mapping #14
has the lowest execution time (two ARM9s used for the receiver and two
Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 307 2009-10-2
Platform-Based Design and Frameworks: METROPOLIS and METRO II 307
TABLE 10.4
Mapping Scenarios for the UMTS Case Study
# Type Partition # Type Partition # Type Partition
1 1: RTP 11 Sp 17 6: PP 2 μB (2), 2 A9 (3) 33 7: MIX A7 (4), Sp (5), μB (6), A9 (7)
22:PP 11μB 18 6: PP 2 A9 (2), 2 μB (3) 34 7: MIX A7 (4), Sp (5), A9 (6), μB(7)
3 2: PP 11 A7 19 6: PP 2 A7 (2), 2 A9 (3) 35 7: MIX A7 (4), μB (5), Sp (6), A9 (7)
4 2: PP 11 A9 20 6: PP 2 A9 (2), 2 A7 (3) 36 7: MIX A7 (4), μB (5), A9 (6), Sp (7)
5 3: RTP 4 Sp (1) 21 7: MIX Sp (4), μB (5), A7 (6), A9 (7) 37 7: MIX A7 (4), A9 (5), μB (6), Sp (7)
64:PP 4μB (1) 22 7: MIX Sp (4), μB (5), A9 (6), A7 (7) 38 7: MIX A7 (4), A9 (5), Sp (6), μB(7)
7 4: PP 4 A7 (1) 23 7: MIX Sp (4), A7 (5), μB (6), A9 (7) 39 7: MIX A9 (4), Sp (5), μB (6), A7 (7)
8 4: PP 4 A9 (1) 24 7: MIX Sp (4), A7 (5), A9 (6), μB(7) 40 7: MIX A9 (4), Sp (5), A7 (6), μB(7)
95:MIX2Sp(2),2μB (3) 25 7: MIX Sp (4), A9 (5), A7 (6), μB (7) 41 7: MIX A9 (4), μB (5), Sp (6), A7 (7)

10 5: MIX 2 μB (2), 2 Sp (3) 26 7: MIX Sp (4), A9 (5), μB (6), A7 (7) 42 7: MIX A9 (4), μB (5), A7 (6), Sp (7)
11 5: MIX 2 Sp (2), 2 A7 (3) 27 7: MIX μB (4), Sp (5), A7 (6), A9 (7) 43 7: MIX A9 (4), A7 (5), μB (6), Sp (7)
12 5: MIX 2 A7 (2), 2 Sp (3) 28 7: MIX μB (4), Sp (5), A9 (6), A7 (7) 44 7: MIX A9 (4), A7 (5), Sp (6), μB(7)
13 5: MIX 2 Sp (2), 2 A9 (3) 29 7: MIX μB (4), A7 (5), Sp (6), A9 (7) 45 8: RTP 1 Sp
14 5: MIX 2 A9 (2), 2 Sp (3) 30 7: MIX μB (4), A7 (5), A9 (6), Sp (7) 46 9: PP 1 μB
15 6: PP 2 μB (2), 2 A7 (3) 31 7: MIX μB (4), A9 (5), A7 (6), Sp (7) 47 9: PP 1 A7
16 6: PP 2 A7 (2), 2 μB (3) 32 7: MIX μB (4), A9 (5), Sp (6), A7 (7) 48 9: PP 1 A9
(1=RxMAC,TxMAC,RxRLC,TxRLC),(2=RxMAC,RxRLC),(3=TxMAC,TxRLC)
(4 = Rx MAC), (5)(Rx RLC), (6)(Tx MAC), (7 = Tx RLC) (Sp = Sparc, μB = Microblaze, A7 = ARM7, A9 = ARM9)
Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 308 2009-10-2
308 Model-Based Design for Embedded Systems
0.0E + 00
1 4 14 31 37 26 27 33 13 5 8
45 48 12 24 29 30 43 19 35 10 21 36 42 17 2 22 28 39 41 32 25 34 44 20 23 38 11 15 18 40 3 7 9 16 6 47
46
1.0E + 07
2.0E + 07
3.0E + 07
4.0E + 07
5.0E + 07
6.0E + 07
Mapping
Execution cycles
0%
10%
20%
30%
40%
50%
60%

70%
80%
90%
100%
110%
Percentage utilization per PE
RR Ex PR Ex FCFS Ex RR Util PR Util FCFS Util
UMTS estimated execution time and utilization for various OS scheduling policies
FIGURE 10.13
The UMTS estimated execution time vs. utilization for various OS scheduling policies.
Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 309 2009-10-2
Platform-Based Design and Frameworks: METROPOLIS and METRO II 309
Sparcs used for the transmitter). Mapping #31 has a similar execution time
with four different processors (Rx MAC on μBlaze, Rx RLC on ARM9, Tx
MAC on ARM7, and Tx RLC on Sparc). Many of the execution times are
similar and the graph shows that there are essentially four performance
groupings.
The lowest utilization values for round robin occur in the 11 processor
setups (an average of 15%). The highest is 100% for all single processor
setups. The max utilization before 100% is 39%. This gap points to ineffi-
ciency in the round-robin scheduler. It may be a goal of the other scheduling
algorithms to close this gap. Also notice that for similar execution times, uti-
lization can vary as much as 28% (mappings #41 and #32, for example).
The priority-based scheduling keeps the same relative ordering amongst
the execution times but reduces them on average by 13%. The highest is an
18% reduction (mapping #22, for example) and the smallest reduction is 9%
(mapping #8, for example). The utilization numbers are actually reduced
as well by an average of 2%. The largest reduction was 7% (in mapping
#6, for example) and the smallest was 1% (in mapping #31, for example).
As expected there was no change in the utilization or execution times for

mappings involving either eleven processing elements (fully concurrent) or
those with one element (no scheduling options). The utilization drop results
from high-priority, data-dependent jobs running before low-priority, data-
independent jobs.
The FCFS scheduling also does not change the relative ordering of execu-
tion times but is not as successful at reducing them. The average reduction
is only 7%. The maximum reduction is 11% (in mapping #24, for example)
and the minimum reduction is 4% (in mapping #5, for example). However,
utilization is increased by 27%. The max increase was 45% (in mapping
#31, for example) and the minimum improvement was 20% (in mapping #5,
for example). The FCFS increases utilization due to the fact that many jobs
that would be low priority often request processing in the same round as
high-priority jobs. While technically they are both “first,” the priority would
negate this fact. The FCFS’s round-robin tie-breaking scheme helps smaller
jobs in this case.
The analysis of execution and utilization for the UMTS shows that high
utilization is difficult to obtain due to the data dependencies in the applica-
tion. Also, some of the partitions explored do not balance computation well
amongst the different processing elements in the architecture. Many of the
coarser mappings only make this problem worse. A solution is to further
refine the functional model to extract more concurrency. From an execution-
time standpoint, scheduling can improve the overall execution time but not
as much as is needed to make a large majority of these mappings desirable
for an actual implementation.
An accuracy comparison was performed with mappings #2, #6, and #46
(pure μBlaze mappings). These designs were created on the Xilinx ML310
development board. For mappings #2 and #46, there was only a 3.1% and
Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 310 2009-10-2
310 Model-Based Design for Embedded Systems
a 2% increase, respectively, in execution times in the actual designs. For

mapping #6 (when scheduling affects the outcome), the increase was 16.2%
(RR), 18% (PR), and 15% (FCFS). Mapping #46 inaccuracy is due to the start-
up code and IO operations not captured by the model. Mapping #2 suffers
from a slightly oversimplified point-to-point communication scheme in the
model as compared to the FSL links used by the MicroBlazes. Finally, map-
ping #6 requires a more refined OS model to more closely match the schedul-
ing overhead of the actual OS used. This comparison shows that M
ETRO II
simulation can closely (within 5%) reflect actual implementations, and in
the cases where the differences are greater, a trade-off between the mod-
eling detail, the simulation performance, and the accuracy can be quickly
analyzed.
The untimed M
ETRO II UMTS functional model contains 12 processes
while the architectural model may contain up to 26 processes. This is a large
design, spread across 85 files and 8,300 lines of code. The changing of a map-
ping is trivial however, which requires only changing a few macros and
recompiling two files (2.3% of total; <20 s). All 48 mappings can be done
in less than 16 min.
The conversion of the SystemC timed functional model to an untimed
M
ETRO II functional model removes 1081 lines of code (related to scheduling
and timing—both of which are in the architecture model). M
ETRO II mapping
removes much of the overhead associated with the SystemC model synchro-
nization.
M
ETRO II constraints for the read/write semantics of a FIFO only require
60 lines of code, which is 1.4% of the total code cost. The average difference
of the entire conversion to M

ETRO II was only 1% per file. More than half of
these lines (58%) have to do with registering the constraints with the solvers.
The conversion of a SystemC runtime processing model (the Sparc pro-
cessing element) to M
ETRO II only requires 92 additional lines. This was a
mere 3.4% increase (2773 lines to 2681 lines). This includes adding sup-
port for loading a new code at runtime, returning the cost of operation to
the netlist, and exposing events for mapping. This result is encouraging for
importing code.
Figure 10.14 illustrates the percentage of the actual simulation runtime
spent in each of M
ETRO II’s simulation phases for the nine classes of map-
pings. The SystemC entry indicates the time spent in the SystemC simulation
infrastructure upon which M
ETRO II is built.
On an average, 61% of the time is spent in Phase 1 (lowest section on
the bar graph), 5% in Phase 2 (second section), and 17% in Phase 3 (third
section). For models with only runtime processing elements (R), the aver-
ages are 93%, 0.9%, and 3%, respectively. This indicates that in runtime
processing, the M
ETRO II activities of annotation and scheduling are negli-
gible in the runtime picture. For pure profiled (P) mappings, they are 21%,
7%, and 26%. In this case, one can see that M
ETRO II now accounts for a
greater percentage of runtime. (Phase 1 alone is the representative of other
Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 311 2009-10-2
Platform-Based Design and Frameworks: METROPOLIS and METRO II 311
Runtime spent in different phases
0%
10%

20%
30%
40%
50%
60%
70%
80%
90%
100%
Mix
avg
Avg.PP avgRTP
avg
987654321
Class
Percentage runtime
System C
Phase 3
Phase 2
Phase 1
FIGURE 10.14
M
ETRO II phase runtime analysis.
simulation environments.) For mixed classes, the numbers are 82%, 2.6% and
7.6%. Again the runtime processing elements dominate. It should be noted
that while Ps have higher averages, the average runtime toprocess 7000 bytes
of data was 54 seconds. The Phase 1 runtime and the SystemC overhead are
the main contributors to overall runtime.
If we consider the SystemC timed functional model, the M
ETRO II timed

functional model, and the M
ETRO II untimed functional model mapped to an
architecture, the M
ETRO II timed functional model had an average increase of
7.4% in runtime for the nine classes while the mapped version had a 54.8%
reduction. This reduction is due to the fact that M
ETRO II Phases 2 and 3
have significantly less overheads than the timer- and scheduler-based sys-
tem required by the SystemC timed functional model.
Table 10.5 shows the average number of event state changes per phase
and the average number of phases an event waits.
On an average, only 0.14 events are annotated or scheduled per round.
Because of the architectural model integration with the UMTS functional
model, there are a limited number of synchronization points (which satisfy a
rendezvous constraint, and, hence, an event state change). As shown in Fig-
ure 10.14, Phases 2 and 3 do not account for a large portion of the runtime, so,
while the event state change activity is low, it does not translate to increased
runtime. Runtime is not increased directly by changing an event’s state, but
rather by the total number of events in Phases 2 and 3.
Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 312 2009-10-2
312 Model-Based Design for Embedded Systems
TABLE 10.5
METRO II Phase Event Analysis
Class Event/Ph. Comp. % Comm. % Coord. % Avg Wait
1 0.091 0.083 0.083 0.833 3839.240
2 0.091 0.083 0.083 0.833 3839.240
3 0.169 0.125 0.042 0.833 6276.190
4 0.169 0.125 0.042 0.833 6276.190
5 0.131 0.170 0.114 0.716 5117.003
6 0.169 0.170 0.114 0.716 6276.190

7 0.150 0.101 0.088 0.811 5691.130
8 0.176 0.319 0.043 0.638 6718.550
9 0.176 0.319 0.043 0.638 6718.550
Avg 0.147 0.166 0.072 0.761 5639.143
Events in Classes 1 and 2 on average wait 42% less than the worse case.
These classes are precisely those that provide maximum concurrency (11
processing elements). The worst is in Classes 8 and 9 (single processing ele-
ments). As one would expect, when the scheduling overhead is lower and
more processing elements are available, events wait much less for resource
availability.
Finally, it should be noted that runtime processing vs. pre-profiled pro-
cessing does not impact this aspect of simulation. Comparing Classes 1 with
2 or 3 with 4 confirms this. This contrasts heavily with the runtime of the
simulation (in which the PE type is a key factor). The runtime processing in
the microarchitectural model is treated as a black box by M
ETRO II such that
the internal events are unseen and do not trigger phase changes. This indi-
cates that SystemC components can be imported quite easily into M
ETRO II
without affecting the three-phase execution semantics.
The 3rd, 4th, and 5th columns of Table 10.5 categorize the events in
Phase 1. Computational events request processing-element services directly.
Communication events transfer data between FIFOs, and coordination
events maintain correct simulation semantics and operation. The table indi-
cates that events in the system are heavily related to coordination. Classes 8
and 9 have the lowest percentage of coordination events (64%), since these
are single-PE systems.
10.6.1.5 Conclusions
We illustrated how an event-based design framework, M
ETRO II, may be used

to carry out architectural modeling and design-space exploration. Experi-
mental results show that M
ETRO II is capable of capturing functional mod-
eling, architectural modeling, and mapping for a UMTS case study with
limited overhead as compared with a baseline SystemC model. We showed
that the design effort involved in carrying out 48 separate mappings with a
variety of architectural models is minimal. Within the framework, we detail
Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 313 2009-10-2
Platform-Based Design and Frameworks: METROPOLIS and METRO II 313
the runtime spent in the three different M
ETRO II execution phases and pro-
vide an idea of how events move throughout the system.
Future work involves identifying and removing events not relevant for
annotation or scheduling from M
ETRO II’s second and third phases, support
for a wider variety of declarative constraints, and the analysis of other appli-
cations that may be mapped onto similar architectural platforms.
10.6.2 Intelligent Buildings: Indoor Air Quality
The construction of future energy-efficient commercial buildings will make
use of sophisticated control architectures that are able to sense several phys-
ical quantities, compute control laws, and apply control actions through
actuators. Sensors, actuators, and computation units are physically dis-
tributed over the buildings. The control algorithm can be run on either
distributed controllers or a central controller. The control performance is crit-
ically affected by both computation and communication delays that need to
be within precise bounds in order to guarantee energy savings while main-
taining the comfort level. Thus, a major challenge in designing such systems
is to balance the computation and communication efforts. In particular, a
designer needs to decide how to map the control algorithm on a set of con-
trollers and needs to find an optimal communication network, meaning the

communication medium and the network topology.
The goal of this case study is to model and simulate the control of the
temperature in the rooms of a building at a high level of abstraction. The
simulation results will be used to partition the sensor–actuator delay into
computation and communication latency requirements. The communication
latency requirements are then passed to an optimization tool that finds the
best communication network that supports the gathering of data from the
sensors and the delivery of commands to actuators.
Our design flow is shown in Figure 10.15. In Step 1, both the function-
ality of the system and the architecture platform are modeled. The map-
ping between function and architecture models is carried out where the
controllers and the point-to-point communication between sensors, actu-
ators, and controllers are annotated with actual computation delays and
virtual communication delays. The performance of the control algorithm is
evaluated for different values of the communication delays until the least
constraining latency requirements are found. The communication require-
ments are then passed to an external network synthesis tool—the commu-
nication synthesis infrastructure (COSI) [51]. In Step 2, the COSI synthe-
sizes the communication network of the system based on the simulation
results. Then, in Step 3, the abstract point-to-point communication channels
are mapped to the communication network obtained by COSI.
Both the functionality and the architecture platforms of the control sys-
tem are modeled in M
ETRO II, while the environment dynamics is modeled
in OpenModelica [27], an external simulation tool. OpenModelica interacts
Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 314 2009-10-2
314 Model-Based Design for Embedded Systems
Step 1: modeling and
simulation
Mapping

Function
model
Architecture
model
Step 3: refinement
COSI
synthesis
results
Simulation
results
COSI
Step 2: synthesis
FIGURE 10.15
Design flow of the room temperature control system.
with the function model of the system. The M
ETRO II function model of
a two-room example and its interaction with OpenModelica is shown in
Figure 10.16. The environment dynamics is described in the Modelica
programming language. The Modelica language is designed to allow
Modelica
model
OpenModelica
CORBA communication
M
ETRO II
Interface to
OpenModelica
Controller1
FIFO_s1c
FIFO_s2c

FIFO_a1c
FIFO_a2c
Controller2
S2
S1
A2
A1
FIGURE 10.16
M
ETRO II function model and OpenModelica.
Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 315 2009-10-2
Platform-Based Design and Frameworks: METROPOLIS and METRO II 315
convenient, component-oriented modeling of complex physical systems, e.g.,
systems containing mechanical, electrical, electronic, hydraulic, thermal, con-
trol, electric power, or process-oriented subcomponents [46]. The Modelica
model in the indoor air quality case study deals with pressure and tempera-
ture dynamics in an indoor environment. It takes into account the structure
of the building, its floorplan, the sizes of the different rooms, and the place-
ment of doors and windows. Moreover, it includes outlet vents that can inject
a cold/hot air flow to perform cooling/heating of the environment; they are
the actuators of the control system, but expressed in Modelica in terms of
their effect on the temperature and pressure dynamics of the system.
The M
ETRO II model and the Modelica model are run together (co-
simulation [57]). Sensors and actuators in the functional model interact with
the plant to retrieve temperature values in the different rooms and to set the
status (closed/open; hot/cold air flow) of the vents. These operations obvi-
ously require synchronization and information exchange between the tools.
They are managed by the environment functional module, which controls
the execution of the Modelica model (start and stop the simulation) and it

is able to set and get the value of its parameters. From an implementation
point of view, this interaction is performed by the remote calling of a set of
services provided by OpenModelica over a CORBA connection [18] estab-
lished between the tools.
The architecture model includes generic electronic control units (ECUs)
communicating with sensors and actuators. During mapping, the controllers
in the function model are allocated onto ECUs. If multiple controllers are
mapped onto one ECU, a M
ETRO II scheduler is constructed to coordinate
their executions. Various scheduling policies can be applied by designing
different types of schedulers, while keeping the controller tasks intact. In
our example, we use round-robin scheduling. Sensors and actuators in the
function model are mapped to architectural sensors and actuators. The com-
munication between ECUs and sensoring/actuating units is modeled at an
abstract level in Step 1 of the design flow. The services of sensing, computing
control algorithms, and actuating are annotated with time by M
ETRO II anno-
tators. The end-to-end delays from sensing to actuating are computed dur-
ing simulation. The simulation results are sent to COSI, which synthesizes
the communication network in Step 2 of the design flow. Then the synthesis
results are utilized to refine the abstract communication network in Step 3 of
the flow.
10.7 Conclusions
We discussed the trends and challenges of system design from a broad per-
spective that covers both semiconductor and industrial segments that use