Nicolescu/Model-Based Design for Embedded Systems 67842_C009 Finals Page 246 2009-10-13
246 Model-Based Design for Embedded Systems
HDS API
HAL
CPU
Comm.
HALAPI
Task 1 Task 2 Task q
Intra-SubSys comm.
Intra-SubSys comm.
Abstract CPUs
& native SW execution
HdS API
HdS API
Comm. OS
Task 1 Task 2 Task n
Abstract CPUs
& native SW execution
HdS API
HdS API
Comm. OS
Task 1 Task 2 Task n
Abstract intra-
sub system comm.
& native SW execution
HdS API
Task 1 Task 2 Task n
Abstract intra-
sub system comm.
& native SW execution
HdS API

HW-SS
Application
HdS
API
OS
SW adapt. to specific
CPUs and memory
CPUs
ISS
HAL
System architecture
Virtual architecture
Transaction accurate architecture
Virtual prototype
Inter-subsystem communication
F
1
F
2
F
3
F
4
F
5
F
8
F
7
F

Intra-subsystem
communication
Inter-subsystem communication
HDS API
HAL
CPU
Comm.
HALAPI
Task 1 Task 2 Task p
HDS API
HAL
CPU Peripherals
Intra-subsyst.comm.
Comm OS
HAL API
Task 1 Task 2 Task n
Intra-subsyst.comm.
FIGURE 9.6
MPSoC programming steps.
The result of each of these four phases represents a step in the
software and communication refinement process. The refinement is an
incremental process. At each stage, additional software component and
Nicolescu/Model-Based Design for Embedded Systems 67842_C009 Finals Page 247 2009-10-13
Programming Models for MPSoC 247
architecture details are integrated with the previously generated and
validated components. This results to a gradual transformation of a high
level representation with abstract components and high level programming
models into a concrete low level executable software code. The transforma-
tion has to be validated at each design step. The validation can be performed
by formal analysis, simulation, or combining simulation with formal analy-

communication protocol implementation. During this stage, aspects related to
the communication protocol are detailed, for example, the synchronization
mechanism between the different processors running in parallel becomes
explicit. The software code has to be adapted to the synchronization method,
such as events or semaphores. This can be done by using the services of OS
and communication components of the software stack. The resulting model
is the Transaction Accurate Architecture model.
The final step corresponds to specific adaptation of the software to the tar-
get processors and specific memory map. This includes the integration of the
Nicolescu/Model-Based Design for Embedded Systems 67842_C009 Finals Page 248 2009-10-13
248 Model-Based Design for Embedded Systems
processor dependent software code into the software stack (HAL) to allow
low level access to the hardware resources and the final memory mapping.
The resulting model is called Virtual Prototype model.
These different steps of the global flow correspond to different software
components generation and validation at different abstraction levels.
9.6 Experiments with H.264 Encoder Application
In this section, we apply the proposed programming environment for a com-
plex MPSoC architecture. The target application corresponds to the H.264
encoder, also called AVC (advanced video coding). Firstly, the specification
of the target architecture and application are given, and then, the program-
ming steps at the system architecture, virtual architecture, transaction accu-
rate architecture, and virtual prototype levels are described, respectively.
9.6.1 Application and Architecture Specification
The H.264 encoder application is a video processing multimedia applica-
tion that supports coding and decoding of 4:2:0 YUV video formats [24]. The
main functions of the H.264 encoder are illustrated in Figure 9.7. The input
image frame (F
n
) of a video sequence is processed in units of a macroblock,

.yuv
+
+
+
–
Filter
FIGURE 9.7
H.264 encoder.
Nicolescu/Model-Based Design for Embedded Systems 67842_C009 Finals Page 249 2009-10-13
Programming Models for MPSoC 249
MEM SS ARM9 SS
DXM
NI
SRAM
NI
ARM9
ROM
POT SS
Hermes NoC
NI
Timer
Mailbox
AIC
SPI
NI
DMA
PIC
Mailbox
PMEM
REG1

Therefore, the H.264 application functions are mapped onto the available
SW-SS, as shown in Figure 9.9. Thus, the DSP1-SS is responsible for encoding
a frame of the video sequence. The DSP2-SS compresses the encoded frame.
The ARM9-SS creates the final bitstream and computes the bit-rate controller.
The application executes in pipeline fashion and requires three application
data transfers between the processors: COMM1 between DSP1 and DSP2,
COMM2 between DSP2 and ARM9,andCOMM3 between ARM9 and DSP1.
The resulting system architecture is modeled using the Simulink envi-
ronment. To validate the H.264 encoder algorithm, the system architecture
Nicolescu/Model-Based Design for Embedded Systems 67842_C009 Finals Page 250 2009-10-13
250 Model-Based Design for Embedded Systems
T
T
–1
Q
–1
+
+
+
–
F
n
F
n–1
F
n
Q
Reorder
T1 T2
T3

between the different subsystems during the encoding process of the 10
frames video sequence, using main profile configuration of the encoder algo-
rithm, was approximately 3085 kWords.
9.6.3 Programming at the Virtual Architecture Level
Programming at the virtual architecture level consists of generating the C
code for each task from the system architecture model. The generated tasks
code for the H.264 encoder application uses send_data( )/recv_data( )APIs
for the communication primitives and is optimized in terms of data memory
requirements.
Table 9.4 shows the task code and data size of the software at the virtual
architecture level. The first two columns represent the code, respectively the
data size of the functions that are independent of the design and optimiza-
tion methods, which are part of an independent library. The third and fourth
Nicolescu/Model-Based Design for Embedded Systems 67842_C009 Finals Page 251 2009-10-13
Programming Models for MPSoC 251
TABLE 9.4
Task Code Generation for H.264 Encoder
Library Code Library Data Multitasking Code Multitasking Data
Size (Bytes) Size (Bytes) Size (Bytes) Size (Bytes)
270,994 132 366,060 148
DXM
SRAM
T3
T3
T1
T2T1
T2
Abstract ARM9-SS
Comm1
Comm2

Nicolescu/Model-Based Design for Embedded Systems 67842_C009 Finals Page 252 2009-10-13
252 Model-Based Design for Embedded Systems
Total words
DXM + SRAM + DXM
DMEM1 + SRAM + DXM
DXM + DXM + REG1
DMEM2 + DXM + SRAM
DMEM1 + DMEM2 + SRAM
DXM + DMEM2 + DMEM1
DXM + DXM + DXM
0 1,000,000 2,000,000 3,000,000 4,000,000 5,000,000 6,000,000 7,000,000
5,971,700
3,085,850
6,171,670
3,285,820
3,085,840
5,971,690
6,171,680
FIGURE 9.11
Words transferred through the Hermes NoC.
TABLE 9.5
Results Captured in Hermes NoC Using DXM as Communication
Scheme
Read/Write Total Sent
H.264 NoC Address Requests Packets Sent MBytes
DXM 0 ×0 0 83,352 17,324
ARM9-SS 1 ×0 2,426 4,853 68
DSP1-SS 1 ×1 39,260 78,522 16,167
DSP2-SS 1 ×2 41,663 83,327 2,090
Table 9.5 summarizes the results captured during the simulation of the

interconnected through an explicit Hermes NoC.
The simulation of the transaction accurate architecture allows validating
the integration of the tasks code with the OS and communication libraries,
but it also provides better performance estimation, such as communication
performances.
At this level, in order to analyze the overall system performance, we
experimented with several communication architectures by changing the
interconnection component and/or communication mapping scheme. The
NoC allows various mapping schemes of the IPs over the NoC with different
impact on performance. In this work, two different mappings of the IP cores
MEM-SS
DXM
NI
SRAM
ARM9-SS
NI
Abstract
ARM9
Hermes noc
POT-SS DSP1-SS DSP2-SS
NI
Timer
Mailbox
Mailbox
Mailbox
AIC SPI
NI
DMA
PIC
REG1

Hermes NoC running H.264 encoder application.
Nicolescu/Model-Based Design for Embedded Systems 67842_C009 Finals Page 254 2009-10-13
254 Model-Based Design for Embedded Systems
Y\ X 0 1 2
0 MEM-SS POT-SS -
1 ARM9-SS DMA1 DMA2
2 - DSP1-SS DSP2-SS
Scheme A
Y\X 0 1 2
0 DMA1 - -
1 ARM9-SS MEM-SS DSP2-SS
2 POT-SS DSP1-SS DMA2
Scheme B
FIGURE 9.13
IP cores mapping schemes A and B over the NoC.
over the Mesh and Torus NoC are experimented: Scheme A and Scheme B,
respectively. Figure 9.13 summarizes these schemes by presenting the corre-
spondence between the Network Interface and the IP core, e.g., the MEM-SS
is connected in Scheme B at the network interface with address 1 × 1(bothx
and y coordinates are 1).
Table 9.6 presents the results of the transaction accurate simulations
for various interconnection components (AMBA bus, NoC) with different
topologies for the NoC (Torus, Mesh), different IP cores mapping over the
NoC and diverse communication buffer mapping schemes. The estimated
performance indicators are: estimated execution cycles of the H.264 encoder,
the simulation time using the different interconnect components on a PC
running at 1.73 GHz with 1 GBytes RAM and the total routing requests
for the NoC. These results were evaluated for the two considered IP map-
ping schemes shown in Figure 9.13 (A and B) and for three communication
buffer mapping schemes: DXM+DXM+DXM, DMEM1+DMEM2+SRAM

DMEM1 + DMEM2
+SRAM
Mesh Scheme A 28,573,705 12 min 54 s 1,428,685 1846 13,118,044 10
DMEM1 + DMEM2
+SRAM
Torus Scheme A 26,193,039 12 min 1,309,652 1819 12,674,692 9
DMEM1 + SRAM +
DXM
Mesh Scheme A 26,233,039 14 min 55 s 1,594,237 1466 13,144,538 11
DMEM1 + SRAM +
DXM
Torus Scheme A 26,193,040 14 min 48 s 1,309,652 1475 14,479,723 10
DXM + DXM + DXM Mesh Scheme B 35,070,577 18 min 34 s 1,753,529 1574 24,753,610 9
DXM + DXM + DXM Torus Scheme B 35,070,587 19 min 8 s 1,753,529 1527 24,753,488 9
DMEM1 + DMEM2
+SRAM
Mesh Scheme B 31,964,760 17 min 8 s 1,598,238 1555 18,467,386 13
DMEM1 + DMEM2
+SRAM
Torus Scheme B 31,924,752 16 min 14 s 1,595,238 1639 15,213,557 13
DMEM1 + SRAM +
DXM
Mesh Scheme B 31,964,731 18 min 38 s 1,598,237 1430 18,512,403 15
DMEM1 + SRAM +
DXM
Torus Scheme B 31,924,750 16 min 42 s 1,596,238 1593 18,115,966 14
DXM + DXM + DXM AMBA — 17,436,640 8 min 24 s 871,832 1730 — 9
DMEM1 + DMEM2
+SRAM
AMBA — 17,435,445 7 min 18 s 871,772 1990 — 9

DSP2
ISS
Mailbox
DMEM2REG2
SPIAIC
HAL
HAL API
OS
HdS API
T3
Comm
HAL
HAL API
OS
HdS API
T2
Comm
HAL
HAL API
OS
HdS API
T1
Comm
Hermes NOC
FIGURE 9.14
Global view of the virtual prototype for Diopsis R2DT with Hermes NoC
running H.264 encoder application.
fix the final memory mapping. The H.264 encoder running on the Diopsis
R2DT architecture at the virtual prototype level is illustrated in Figure 9.14.
There are three final software stacks running on the architecture, one per

8. W. Wolf, High-Performance Embedded Computing: Architectures, Applica-
tions, and Methodologies, Morgan Kaufmann Publishers, Inc., San Fran-
cisco, CA, 2006.
9. D. Culler, J.P. Singh, A. Gupta, Parallel Computer Architecture: A Hardware/
Software Approach, Morgan Kaufmann Publishers, Inc., San Francisco,
CA, August 1998, ISBN 1558603433.
10. P. Paulin, C. Pilkington, M. Langevin, E. Bensoudane, D. Lyonnard,
O. Benny, B. Lavigueur, D. Lo, G. Beltrame, V. Gagne, G. Nicolescu, Par-
allel programming models for a multi-processor SoC platform applied
to networking and multimedia, IEEE Transactions on VLSI Journal, 14(7),
667–680, 2006.
11. A. Bouchhima, X. Chen, F. Pétrot, W. Cesario, A.A. Jerraya, A unified
HW/SW interface model to remove discontinuities between HW and
SW design, Proceedings of EMSOFT 2005, New Jersey City, NJ, September
18–22, 2005.
12. A. Jerraya, W. Wolf, Hardware-software interface codesign for embed-
ded systems, Computer, 38(2), 63–69, February 2005.
13. D. Skillicorn, D. Talia, Models and languages for parallel computation,
ACM Computing Surveys, 30(2), 123–169, 1998.
Nicolescu/Model-Based Design for Embedded Systems 67842_C009 Finals Page 258 2009-10-13
258 Model-Based Design for Embedded Systems
14. A. Jerraya, A. Bouchhima, F. Petrot, Programming models and HW-SW
interfaces abstraction for multi-processor SoC, Proceeding of DAC 2006,
San Francisco, CA, 2006, pp. 280–285.
15. Simulink, The MathWorks Inc., http://www.mathworks.com
16. F. Ghenassia, Transaction-Level Modeling with SystemC. TLM Concepts and
Applications for Embedded Systems, Springer, New York, 2005, ISBN 0-387-
26232-6.
17. S. Yoo, M.W. Youssef, A. Bouchhima, A.A. Jerraya, M. Diaz-Nava,
Multi-processor SoC design methodology using a concept of two-layer

M
ETROPOLIS and METRO II
Felice Balarin, Massimiliano D’Angelo, Abhijit Davare, Douglas
Densmore, Trevor Meyerowitz, Roberto Passerone, Alessandro Pinto,
Alberto Sangiovanni-Vincentelli, Alena Simalatsar, Yosinori Watanabe,
Guang Yang, and Qi Zhu
CONTENTS
10.1 Introduction 260
10.2 Platform-Based Design 261
10.2.1 Design Challenge 261
10.2.2 Principles of Platform-Based Design 262
10.2.2.1 PBD Flow 263
10.2.2.2 “Fractal” Nature of PBD: Successive Refinements 264
10.2.2.3 Design Parameters for PBD . 266
10.3 M
ETROPOLIS DesignEnvironment 267
10.3.1 Overview 267
10.3.2 M
ETROPOLIS Meta-Model 268
10.3.2.1 Function Modeling 268
10.3.2.2 Architecture Modeling 269
10.3.2.3 Mapping 271
10.3.2.4 Recursive Paradigm of Platforms 273
10.3.3 M
ETROPOLIS Tools 275
10.3.3.1 Simulation 275
10.3.3.2 Formal Property Verification . 276
10.3.3.3 Simulation Monitor 276
10.3.3.4 Quasi-Static Scheduling 277
10.4 M

10.6.2 Intelligent Buildings: Indoor Air Quality 313
10.7 Conclusions 315
Acknowledgments 316
References 317
10.1 Introduction
System-level design (SLD) means many different things to many different
people. In our view, SLD is about the design of a whole that consists of
several components where specifications are given in terms of functionality
along with
• Constraints on the properties the design has to satisfy
• Constraints on the components that are available for implementation
• Objective functions that express the desirable features of the design
when completed
This definition is general since it relates to many application domains
from semiconductors to systems such as cars, airplanes, buildings, telecom-
munications, and biological systems. To deal with system-level problems,
our view is that the issue to address is not developing new tools, albeit
they are essential to advance the state of the art in design; rather it is the
understanding of the principles of system design, the necessary change to
design methodologies, and the dynamics of the supply chain. Developing
this understanding is necessary to define a sound approach to the needs of
the system and component industry as they try to serve their customers bet-
ter, and to develop their products faster and with higher quality. This chapter
is about principles and how a unified methodology together with a support-
ing software framework, as challenging as it may seem, can be developed to
bring the embedded electronics industry to a new level of efficiency.
To demonstrate this view, we will first present the design challenges for
future systems and a manifesto espousing the benefits of a unified methodol-
ogy. We will then summarize a methodology, platform-based design (PBD),
that has been developed over the past decade and that we believe can fulfill

overcome unless new design methods are used where unwanted behaviors
are excluded by the design. In addition, safety, security, and privacy con-
cerns will be imposed by regulatory bodies as well as by customers, thus
adding new dimensions to the problem of design.
The fundamental issue is understanding the principles of system design,
the necessary change to design methodologies, the creation of appropriate
abstractions, and the dynamics of the supply chain, i.e., a novel science and
engineering for system design. Developing this science and engineering is
necessary to define a sound approach to the needs of the system and IC (inte-
grated circuit) companies as they try to serve their customers better, and to
develop their products faster and with a higher quality. Major investments
are necessary from all constituencies: industry, governments, and research
institutions.
Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 262 2009-10-2
262 Model-Based Design for Embedded Systems
10.2.2 Principles of Platform-Based Design
We need to adopt a methodology that can be applied seamlessly at all levels
of abstractions and that can capture design constraints and components at
each level. In addition, the methodology must favor a system view of the
design so that it can deliver an increased productivity and the capability of
dealingwithmultipledesigngoals,thusalwayskeeping in mindperformance,
power, reliability, and cost as essential characteristics of the final solution.
Productivity can be increased by a number of techniques including
• Design reuse, i.e., the capability of utilizing preexisting designs or
components
• Early verification and analysis
• Virtual prototyping
• Automatic traversal of the design hierarchy from specifications to
implementation
The overall quality of the final product can also be substantially enhanced by

upon a lower level of abstraction that, in this case, is not available yet. A
platform instance is a set of components that is selected from the library (the
platform) and whose parameters are set. In the case of a virtual component,
the parameters are set by the requirements rather than by the implementa-
tion. In this case, they have to be considered as constraints for the next level
of refinement.
10.2.2.1 PBD Flow
The PBD flow concept of platform encapsulates the notion of reuse as a
family of solutions that share a set of common features (the elements of
the platform). Since we associate the notion of platform to a set of poten-
tial solutions to a design problem, we need to define functionality (what the
system is supposed to do), the process of mapping a functionality onto the
platform elements that will be used to build a platform instance or an “archi-
tecture” (how the system does what it is supposed to do), and the constraints
and goals that need to be considered when implementing the functionality.
This process provides a mechanism to proceed toward implementation in
a structured way. We strongly believe that the function and the architec-
ture should be kept separate as these two aspects are often defined inde-
pendently by different groups (e.g., video encoding and decoding experts
versus hardware/software designers for multimedia systems). Too often we
have seen designs being difficult to understand and debug because the func-
tionality and the architecture are intermingled during the design capture
stage. If the functional aspects are indistinguishable from the implementa-
tion aspects, it is very difficult to evolve the design over multiple hardware
generations.
Functionality is an implicit or explicit relationship between a set of input
signals and a set of output signals defined at a given level of abstraction, i.e.,
a process [37]. This relationship may be structured as a set of communicat-
ing subprocesses. Constraints and goals for the design are expressions that
involve variables including physical quantities such as power, latency, and

The “middle” is where functionality meets the platform. Given the original
semantic difference between the two, the meeting place must be described
with a common domain so that the “mapping” of the functionality to ele-
ments of the platform to yield an implementation can be formalized and
automated.
10.2.2.2 “Fractal” Nature of PBD: Successive Refinements
To better represent the refinement process and to stress that platforms may
preexist the functionality of the system, we turn the triangles on their side
and represent the “middle” as the mapped functionality. Then, the refine-
ment process takes place on the mapped functionality that becomes the
“function” at the lower level of the refinement. Another platform is then
considered side by side with the mapped instance and the process is iterated
until all the components are implemented in their final form. This process
can be applied at all levels of abstraction, thus exposing what we call the
fractal nature of design. Note that some of the components may reach their
final implementation early in the refinement stage if these elements are fully
detailed in the platform. Figure 10.1 exemplifies this aspect of the methodol-
ogy. It is reminiscent of the Y chart of Gajski, albeit it has a different meaning,
since, for us, architecture and functionality are peers and architecture is not
necessarily derived from functionality but may exist independently.
To progress in the design, we have to map the new functionality to the
new set of architectural components. In case the previous step used an archi-
tectural component that was fully instantiated, then that part of the design
is considered complete: the mapping process involves only those parts that
have not been fully specified as of yet.
In the PBD, the partitioning of the design into hardware and software is
not the essence of system design as many think; rather it is a consequence
Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 265 2009-10-2
Platform-Based Design and Frameworks: METROPOLIS and METRO II 265
Application instance

instance
Function instance
FIGURE 10.1
Hourglass diagram and fractal nature of the PBD. (From Sangiovanni-Vincentelli, A., Proc. IEEE, 95, 467, March 2007. With
permission.)
Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 266 2009-10-2
266 Model-Based Design for Embedded Systems
of decisions taken at a higher level of abstraction. Critical decisions instead
involve the abstraction levels and semantics with which the functionality and
the architecture are defined.
10.2.2.3 Design Parameters for PBD
In the PBD refinement-based design process, platforms should be defined
to eliminate large loop iterations for affordable designs. They should restrict
the design space via new forms of regularity and structure that surrender
some design potential for a lower cost and first-pass success. The library of
functional and communication components is the design space that we are
allowed to explore at the appropriate level of abstraction. Establishing the
number, location, and components of intermediate platforms is an essential
part of the PBD.
Designs with different requirements and specifications may use differ-
ent intermediate platforms, hence different layers of regularity and design-
space constraints. The trade-offs involved in the selection of the number
and characteristics of platforms relate to the size of the design space to
be explored and the accuracy of the estimation of the characteristics of
the solution adopted. Naturally, the larger the step across platforms, the
more difficult it is to predict the performance and provide tight bounds on
the performance. In fact, the design space for this approach may actually be
smaller than the one obtained with smaller steps because it becomes more
difficult to explore meaningful design alternatives and these restrictions
on search impede design-space exploration. Ultimately, predictions/abstrac-

is based on formal semantics and remains general enough to support exist-
ing MoCs [37] and accommodate new ones. The MMM also includes a logic
language to capture nonfunctional and declarative constraints. This meta-
model can support not only the functionality capture and analysis, but also
the architecture description and the mapping of functionality to architectural
elements. Because the MMM has a precise semantics, in addition to a simula-
tion M
ETROPOLIS is able to perform synthesis, and formal analysis for complex
electronic-system design.
The M
ETROPOLIS design environment supports three design activities:
specification, analysis, and synthesis.
• Specification serves to communicate the design intent and expected
results. It focuses on the interactions among people working at differ-
ent abstraction levels and among people working concurrently at the
same abstraction level. The MMM includes constraints that represent,
in an abstract form, requirements not yet implemented or assumed to
be satisfied by the rest of the system and its environment.
• Analysis determines how well an implementation satisfies the require-
ments through simulation and formal verification. A proper use of
abstraction can dramatically accelerate verification. An overuse of
detailed representations, on the other hand, can introduce exces-
sive dependencies between developers, reduce understandability, and
diminish the efficiency of analysis mechanisms.
• Synthesis is supportedacross the abstraction levelsused in adesign. The
typical problems we address include setting the parameters of architec-
tural elements such as cache sizes, or designing scheduling algorithms
and interface blocks. We also deal with synthesis of the final implemen-
tations in hardware and software. In M
ETROPOLIS, a specification may

the port. In general, one may have a set of implementations of the same
interface, and we refer to objects that implement port interfaces as media.
Any medium can be connected to a port if it implements the interface of
the port. This mechanism allows the MMM to separate computation by pro-
cesses from communication among them. This separation is essential to facil-
itate the description of the objects to be reused for other designs. Figure 10.2
shows a network of two producer processes and one consumer process that
communicate through a medium.
ltl G( beg(P0, M.write) −> !beg(P1, M.write) U end(P0, M.write) &&
beg(P1, M.write) −> !beg(P0, M.write) U end(P1, M.write)); }
process X {
port Read R;
port Write W;
void thread(){
while(true){
x = R.read();
z = foo(x);
W.write(z);
}
}
}
process X
name C
process X
name P1
process X
name P0
medium S
name M
medium S implements Read, Write {

tions defining the set of legal executions [7,64]. For example, the constraint in
Figure 10.2 specifies the mutual exclusion of the two producers when one
calls the medium’s write method. Constraints describe the coordination of
processes or relate the behavior of networks through mapping or refinement.
10.3.2.2 Architecture Modeling
Architectures are distinguished by two aspects: the functionality they can
implement and that implementation’s efficiency. In the meta-model, the for-
mer is modeled as a set of services offered by an architecture to the functional
model. Services are just methods, bundled into interfaces [56].
To represent the efficiency of an implementation, we need to model the
cost of each service. This is done first by decomposing each service into a
sequence of events, and then annotating each event with a value representing
the cost of the event.
To decompose services into sequences of events, we use networks of
media and processes, just as in the functional model. These networks often
correspond to physical structures of implementation platforms.
For example, Figure 10.3 shows an architecture consisting of n pro-
cesses, T1, ,Tn, and three media, CPU, BUS,andMEM. The architecture in
Figure 10.3 also contains so-called quantity managers, represented by
diamond-shaped symbols. The processes model software tasks executing on
a CPU, while the media model the CPU, bus, and memory. The services
offered by this architecture are the execute, read,andwrite methods imple-
mented in the Task processes. The thread function of a Task process repeatedly
and nondeterministically executes one of the three methods. In this way, we
model the fact that the Tasks are capable of executing these methods in any
order. The actual order will become fixed only after the system functional-
ity is mapped to this architecture, when each Task implements a particular
process of the functional model.
While a Task process offers its methods to the functional part of the sys-
tem, the process itself uses services offered by the CPU medium, which, in

q–manager
BusArb
q–manager
Energy
q–manager
CpuArb
q–manager
Time
medium CPU implements CpuService {
prt BusService bus;
void execute(int n) {
{$
// make request to Time
// for a delay of n clock cycles
$}
}
void read() { bus.read(); }
void write() { bus.write(); }
}
medium BUS implements BusService {
port SlaveService mem;
void read() {
{$
// make request to BusArb
// to become bus master
$}
mem.read();
}
void write() { mem.write(); }
}