*banner
 
 

cg

This page is for the internal management of the Ptolemy Project's Code Generation Effort. For details, see: Actor Model-to-C Embedded Programming

Membership in this workgroup is by invitation only.

This page is for the internal management of the Ptolemy Project's Code Generation Effort.

Modular Code Generation

In this project we study how to generate executable code from different high-level models (Simulink, SDF, ...) such that the code preserves the semantics of these models. We focus on models that contain hierarchy as the primary modularity concept, and on modular code generation. Modular means code for a given component (e.g., a composite actor) is generated independently from context (e.g., independently from the diagram in which this actor is embedded). Modular code generation is essential for many reasons, among which is component reuse and incremental/scalable code generation (not having to re-generate code for an entire model when only part of the model changes). Modular code generation also addresses IP (intellectual property) concerns, since it allows to build libraries of pre-compiled components and reuse them without having access to their internals, therefore treating them as "black boxes".

Our approach is based on the notion of "profiles" for each component. Profiles can be seen as abstractions of components, that capture the essential information needed during composition. Modular code generation with profiles is essentially a profile synthesis problem: how to synthesize a profile for a composite block given the profiles of its internal blocks. Multiple profiles may be generated for a given component, with different trade-offs. We have followed this approach to develop modular code generation techniques for synchronous models, such as Simulink and the Synchronous-Reactive domain of Ptolemy II. We are currently extending these methods to SDF (Synchronous Data Flow).

[1]
R. Lublinerman, C. Szegedy and S. Tripakis. Modular Code Generation from Synchronous Block Diagrams: Modularity vs. Code Size. In POPL'09.
[2]
R. Lublinerman and S. Tripakis. Modular Code Generation from Triggered and Timed Block Diagrams. In Real-Time and Embedded Technology and Applications Symposium (RTAS'08).
[3]
R. Lublinerman and S. Tripakis. Modularity vs. Reusability: Code Generation from Synchronous Block Diagrams. In Design, Automation and Test in Europe (DATE'08).

Actor Model-to-C Embedded Programming

Embedded systems programming is often difficult because the current programming tools provide very little and only primitive mechanisms for expressing concurrency. Ptolemy II [1-3] addresses this problem. It is a software platform that allows safe and disciplined experimentation with various models of computation (MoCs). While its graphical syntax gives an intuitive easy-to-use user front end and component-based model, code generation (CG) is necessary for transforming applications from actor models to native code running on various embedded platforms. CG compiles actor models and specializes the code for performance and efficiency [4].

Compilation of actor models is not a straightforward process because application semantics can be expressed heterogeneously. This is realized by composition of MoCs. Each MoC inherently is expressed very differently in code (i.e. imagine the difference between a event-triggered program versus a dataflow program). CG needs to be able to express this composition as well [5]. This presents a wide range of challenges and optimization opportunities. CG uses a top-down mapping strategy using a special software architecture where helper classes are used as software containers to isolate the code complexity of director and actor classes. Various meta-programming techniques are used to maximize code reuse and statically parameterize the output code.

In addition to building primitive interface code and general optimizations, we also recognize the tradeoffs between different styles of code structure in various metrics relevant to embedded systems (e.g., code/data memory size, run-time performance, and parallel execution). The next step is to outline the metrics to measure CG and perform these measurements. We also want to gain understanding in the various kinds of parallelism provided by different hardware platforms. We envision automating the process of mapping of software concurrency to parallel processing units.

[1]
C. Brooks, E. A. Lee, X. Liu, S. Neuendorffer, Y. Zhao, and H. Zheng (eds.), "Heterogeneous Concurrent Modeling and Design in Java (Volume 1: Introduction to Ptolemy II," UC Berkeley EECS Department Technical Report No. UCB/EECS-2008-28, April 1, 2008.
[2]
C. Brooks, E. A. Lee, X. Liu, S. Neuendorffer, Y. Zhao, and H. Zheng (eds.), "Heterogeneous Concurrent Modeling and Design in Java (Volume 2: Ptolemy II Software Architecture)," UC Berkeley EECS Department Technical Report No. UCB/EECS-2008-28, April 1, 2008.
[3]
C. Brooks, E. A. Lee, X. Liu, S. Neuendorffer, Y. Zhao, and H. Zheng (eds.), "Heterogeneous Concurrent Modeling and Design in Java (Volume 3: Ptolemy II Domains)," UC Berkeley EECS Department Technical Reports, UC Berkeley EECS Department Technical Report No. UCB/EECS-2008-37, April 15, 2008.
[4]
G. Zhou, M.-K. Leung, and E. A. Lee, "A Code Generation Framework for Actor-Oriented Models with Partial Evaluation," Proceedings of International Conference on Embedded Software and Systems 2007, LNCS Vol. 4523, Daegu, South Korea, May 14-16, 2007, pp. 786-799.
[5]
Man-Kit Leung, Edward A. Lee. "An Extensible Software Synthesis Framework for Heterogeneous Actor Models", Proceedings of SLA++P 2008, Model-driven High-level Programming of Embedded Systems, Artist, March, 2008
©2002-2018 Chess