Model-Based Design for Embedded Systems- P30 pdf

Nicolescu/Model-Based Design for Embedded Systems 67842_C009 Finals Page 256 2009-10-13
256 Model-Based Design for Embedded Systems
ARM9-SSMEM-SS
DXM
NI
POT-SS
NI
Timer Mailbox
PIC
NI
DMA
DSP1
ISS
Mailbox
DMEM1REG1
PIC
NI
DMA
DSP2-SS
DSP1-SS
NI
SRAM
ARM9
ISS
SW Stack ARM9
SW Stack DSP1
SW Stack DSP2
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
processor. The hardware platform includes ISS to execute the final software.
The ISS allows determining the execution cycles spent on each task.
9.7 Conclusions
In this chapter, we discussed the use of high level programming for the

abstraction of hardware–software interfaces. A programming model is made
of a set of functions (implicit and/or explicit primitives) that can be used by
the software to interact with the hardware. In case of heterogeneous MPSoC
design, the programming model hides both hardware and software refine-
ments. We proposed a Simulink- and SystemC-based programming environ-
ment, which combines high level programming models with the low level
details and involves design at various abstraction levels. The proposed pro-
gramming environment was applied upon a complex MPSoC architecture to
execute efficiently the H.264 video encoder application and to explore differ-
ent communication schemes.
Nicolescu/Model-Based Design for Embedded Systems 67842_C009 Finals Page 257 2009-10-13
Programming Models for MPSoC 257
References
1. H. Meyr, Application specific processors (ASIP): On design and imple-
mentation efficiency, Proceeding of SASIMI 06, Nagoya, Japan, 2006.
2. TI OMAP.
3. Nomadik.
4. Nexperia.
5. P.S. Paolucci, A. Jerraya, R. Leupers, L. Thiele, P. Vicini, SHAPES: A tiled
scalable software hardware architecture platform for embedded systems,
Proceeding of CODES+ISSS 2006, Seoul, Korea, 2006, pp. 167–172.
6. J. Turley, Survey says: Software tools more important than chips, Embed-
ded Systems Design, April 11, 2005 [Online]. Available: http://www.
embedded.com/columns/surveys/160700620?_requestid=177492
7. MPICH—MPI implementation. />mpich/index.htm
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.,
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
hardware-dependent software, Proceedings of DATE’04, Paris, France,
February 2004.
18. P. van der Wolf, E. de Kock, T. Henriksson, W. Kruijtzer, G. Essink,
Design and programming of embedded multiprocessors: An interface-
centric approach, Special Session, Proceeding of CODES+ISSS 2004, Stock-

holm, Sweden, September 2004.
19. D.R. Butenhof, Programming with POSIX Threads, Addison Wesley,
Boston, MA, May, 1997.
20. E. Cheong, J. Liebman, J. Liu, F. Zhao, TinyGALS: A programming model
for event-driven embedded systems, Proceeding of 2003 ACM Symposium
on Applied Computing, Melbourne, FL, March 9–12, 2003, pp. 698–704.
21. J.A. Rowson, Hardware/software cosimulation, Proceeding of DAC 1994,
San Diego, CA, June 6–10, 1994, pp. 439–440.
22. L. Semeria, A. Ghosh, Methodology for hardware/software
co-verification in C/C++, Proceeding of ASP-DAC 2000, Yokohama,
Japan, 2000, pp. 405–408.
23. S. Kunzli, F. Poletti, L. Benini, L. Thiele, Combining simulation and for-
mal methods for system-level performance analysis, Proceeding of DATE
2006, Munich, Germany, March 6–10, 2006, pp. 236–241.
24. J W. Chen, C Y. Kao, Y L. Lin, Introduction to H.264, Proceeding of
ASP-DAC 2006, Yokohama, Japan, January 24–27, 2006, pp. 736–741.
25. P.S.Paolucci,A.A.Jerraya,R.Leupers,L.Thiele,P.Vicini,SHAPES:Atiled
scalable software hardware architecture platform for embedded systems,
Proceeding of CODES+ISSS 2006, Seoul, Korea, 2006, pp. 167–172.
26. F. Moraes et al., HERMES: An infrastructure for low area overhead
packet-switching networks-on-chip integration, VLSI Journal, 38(1), 2004,
69–93.
Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 259 2009-10-2
10
Platform-Based Design and Frameworks:
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
ETRO IIDesignEnvironment 278
10.4.1 Overview 278
10.4.2 M
ETRO IIDesignElements 279
10.4.2.1 Components 280

10.4.2.2 Ports 282
10.4.2.3 Constraint Solvers 282
10.4.2.4 Annotators and Schedulers 283
10.4.2.5 Mappers 283
10.4.2.6 Adaptors 284
10.4.3 M
ETRO IISemantics 284
10.4.3.1 Three-Phase Execution 285
10.4.3.2 Semantics of Required/Provided Ports 287
10.4.3.3 Semantics of Mapping 287
259
Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 260 2009-10-2
260 Model-Based Design for Embedded Systems
10.5 Related Work 292
10.5.1 Origin of M
ETRO II: From Polis to METROPOLIS 292
10.5.2 Industrial Approaches 294
10.5.3 Academic Approaches 295
10.6 Case Studies 301
10.6.1 UMTS 301
10.6.1.1 Functional Modeling 301
10.6.1.2 Architectural Modeling 304
10.6.1.3 Mapped System 306
10.6.1.4 Results 306
10.6.1.5 Conclusions 312
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
Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 261 2009-10-2
Platform-Based Design and Frameworks: METROPOLIS and METRO II 261
these needs. Further, we will present M
ETROPOLIS, a software framework
supporting this methodology, and M

ETRO II, a second-generation framework
tailored to industrial test cases. We conclude the chapter with two test cases
in two diverse domains: semiconductor chips (a UMTS multi-chip design)
and energy-efficient buildings (an indoor air quality control system).
10.2 Platform-Based Design
10.2.1 Design Challenge
The fundamental design problems are similar enough across the domains
exemplifying our work that a common design methodology can be used
across these domains (refer to [61] for an extensive review of SLD issues).
A design methodology for systems necessarily needs to encompass other
business and societal issues: the industrial supply chain participants have
to comprehend how to play in a rich environment where there are many
opportunities for innovating and optimizing products beyond what has been
possible so far. The revolution here is about interfaces and communication
patterns between the computing and the physical systems, as well as about
the functions that a rich ensemble of heterogeneous entities can collectively
implement. Not all the behaviors of these systems are designed on purpose;
some are unexpected and emerging from unforeseen interactions among
the myriad of components. Recently, malfunctioning of the new automatic
baggage-handling system at Heathrow has cost more than $50 million to
British Airways in a single day and caused havoc among passengers [35].
A data acquisition system program of the National Census Bureau based on
500,000 wireless handheld devices was canceled because cost overran from
$600 million to more than $1.3 billion due to incomplete specifications and
faulty design [14]. Design verification becomes a challenge that is difficult to
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,thusalwayskeepinginmindperformance,
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
a methodology that includes the possibility of
• Automatic synthesis that move from one level of abstraction to
another, thus allowing an effective design-space exploration
• Formally verifying the properties of the design as we progress toward
implementation

Our team has developed a design methodology over the past 10 years,
PBD [33,54], that in our opinion supports most of the above requirements.
A platform is defined to be a library of components that can be assem-
bled to generate a design at that level of abstraction. This library not only
contains computational blocks but also communication components that are
used to interconnect the computational components. It is important to keep
communication and computation elements well separated as we may want to
use different methods for representing and refining these blocks. For exam-
ple, communication plays a fundamental role in determining the properties
of models of computation (MoCs). In addition, designing by aggregation of
components requires great care in defining the communication mechanisms
as they may help or hurt the reuse of design. In design methodologies based
on the IP assembly, communication is the most important aspect. The unex-
pected behavior of the composition is often due to a negligence in defining
the interfaces and the communication among the components.
Each element of the library has a characterization in terms of performance
parameters (e.g., timing, power, and dimensions) together with the function-
ality it can support. The library is a “parameterization” of the space of pos-
sible solutions. Not all elements in the library are preexisting components.
Some may be placeholders or virtual components to indicate the flexibility
of customizing a part of the design into a hardware component (e.g., an
ASIC) that is offered to the designer. For this part, we do not have a com-
plete characterization of the element since performance parameters depend
Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 263 2009-10-2
Platform-Based Design and Frameworks: METROPOLIS and METRO II 263
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
throughput, defined at a multiplicity of levels of abstraction. For example,
assuming that the functionality to be implemented by the design is a fast
Fourier transform, the designer may have the maximum power consumed
by the implementation as a constraint, and area minimization and through-
put maximization as goals. These quantities are not defined at the level at

which the FFT algorithm is described; they appear when implementation
decisions are taken. The goals and constraints guide the selection of the plat-
form instance, since it is a composition of components with a set of character-
istics that may involve the variables that enter the constraint and goal expres-
sions. The constraint and goal expressions are called performance indexes of
the design and may have to be adjusted (propagated) to reflect the refine-
ments of the platforms as we move towards the final implementation. We
then define the specification of a design as the combination of functionality,
Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 264 2009-10-2
264 Model-Based Design for Embedded Systems
platforms, and performance indexes. The functionality specifies what the
system has to do, the platforms define what can be used to implement the
functionality, and the performance indexes guide the mapping process so
that the final implementation is feasible and optimized. The PBD design pro-
cess is not a fully top-down nor a fully bottom-up approach in the traditional
sense; rather, it is a meet-in-the-middle process (see Figure 10.1) as it can be
seen as the combination of two efforts:
• Top-down: Map an instance of the functionality of the design into an
instance of the platform and propagate constraints.
• Bottom-up: Define a platform by choosing its components and an asso-
ciated performance abstraction (e.g., timing of the execution of the
instruction set for a processor, power consumed in performing an
atomic action, number of literals for technology-independent optimiza-
tion at the logic synthesis level, and area and propagation delay for a
cell in a standard cell library).
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
System
platform
(HW and SW)
Platform
design-space

export
Platform
mapping
Architectural space
Application space
Platform instance
Mapped
Function
space
Platform
instance
Mapped
Platform
(architectural space)
Platform
(architectural space)
Function
space
Platform
mapping
Platform
design-space
export
Function instance
Platform
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.)