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. http://www.omap.com 3. Nomadik. http://www.st.com 4. Nexperia. http://www.nxp.com 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. http://www-unix.mcs.anl.gov/mpi/ 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., 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 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.) . 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. 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,. 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