Contents:
Codegen has the following new features:
Primary Codegen Developers: Gang Zhou, Man-kit Leung.
Codegen Contributors: Christopher Brooks, Teale Fristoe, Edward A. Lee, Ye Zhou
Actor-oriented design is a common design strategy in embedded system design, where actors are concurrent components which communicate through ports by sending signals to one another. Such systems are frequently modeled with block diagrams, where the blocks represent systems and lines or arrows between blocks represent signals. Examples include Simulink, LabView, and VHDL/Verilog.
A common problem in such environments is managing complexity, particularly when the designs become large. Most actor-oriented design environments allow hierarchy, or systems (blocks) which are composed of other systems (blocks). To take this a step further, we are developing the Ptalon programming language, which allows users to parameterize components with other components.
We have developed a preliminary interpreter for the Ptalon language in the context of Ptolemy II, a general-purpose design environment for actor-oriented systems. We have also developed a mathematical framework for such languages, to help aid our understanding . We are currently investigating the resource management issues inherent in supporting large block-diagram models.
Primary Ptalon Developer: Adam Cataldo
Contributor: Elaine Cheong
In developing this sub-project, we highlight the following (increasing) list of criteria:
Primary Backtracking Developer: Thomas Huining Feng
The Continuous domain is a redesign of the Continuous Time (CT) domain with a rigorous semantics documented in the following papers:
Primary Continuous Domain Developers: Haiyang Zheng, Edward A. Lee
The model transformation facility provides a framework for the analysis and transformation of actor models using model transformation techniques.
The design of large-scale models poses a number of challenges. As the size of the models increases to thousands of actors or hundreds of thousands of actors, analysis and consistent modification on the models become extremely hard. Furthermore, to maximize component reuse, a systematic approach is needed for the specification and maintenance of common patterns in the models and the transformation of those patterns.
The model transformation framework to be developed in this project aims to support the flexible specification of patterns and replacements by means of rules in graph grammar. An intuitive graphical user interface will be built. For novice users, a set of common transformations will be included in a library to facilitate their common tasks.
The transformations are models in their own right. They can be embedded in larger models hierarchically. Heterogeneous models of computation can be used to control the application of individual "atomic" transformations. This makes it easy to create sophisticated transformations by composing simple ones in a manageable and disciplined way. The sophisticated transformations will also take advantage of the concurrency inherent in those models of computation.
Model transformation can be applied as an optimization of modal models. These are hierarchical state machines with refinements in their states, which are sub-models to be executed when those states are active. The current implementation includes the complete description of each refinement in the model description, even though refinements of the states in a state machine tend to have large commonality. With the transformation technique, only one refinement needs to be stored completely. The others are obtained by transformations performed on the stored refinement. This eliminates redundancy and eases the job of modifying multiple refinements consistently.
Other applications of the model transformation technique include recognizing common design patterns in the models in a static analysis, replacing exiting design patterns with more efficient ones, and reusing design patterns by incorporating them into new models.
Primary Model Transformation Developer: Thomas Huining Feng
boolean hasKnownLength() int length()The length() method throws a RuntimeException if invoked on an ArrayType with hasKnownLength() == false.
Existing ArrayType instances (creating using the ArrayType(Type) constructor have unknown length. A new constructor ArrayType(Type, int) creates array types with a known length. Generally speaking, array types with known length are incomparable with array types with different lengths, and can be converted to an array type with unknown length and compatible element type. Scalars are convertible to array types with length 1. Getting the code to do this right was significantly more complex than inferring sizes of Fix-point types because:
Unfortunately, this means that there is a signficant backward-compatibility issue Previously, if you wanted to force an arbitrary integer array type, you used {int}, which is really an array with one element. This now has the type arrayType(int, 1), which is more specific than you probably want.
As a result, in almost any case where the old style is used in a model to declare the type of a port in a model, e.g. {int}, it should be replaced with an arrayType declaration, e.g. arrayType(int, 7), or arrayType(int). If this is not done, such models will most likely have a type error related to an array of length one.
The existing models have been updated using the new description of an array type with an unknown length.
Note that arrayType(int) returns an instance of the special class UnsizedArrayToken, whose only purpose is to have an unknown array size. Regular array tokens always have a known length.
Note also that arrayType(unknown) is no longer the GLB of all of the arrayTypes. The GLB is now represented by BaseType.ARRAY_BOTTOM (which is not an instance of ArrayType). This required moving farther along the path of decoupling type constraints on array element types from the type objects themselves. TypeableElementTypeTerm can now refer to the element type of a typeable which may never esolve to a valid array type (resulting in an unsatisifed inequality term).
Primary Developer of ArrayType changes: Stephen Neuendorffer