Tour of What's New in Version 7.0.
See also What's New in other versions.
Contents:
The SDF Template based C code generator (Codegen) generates code for
hierarchical Synchronous Dataflow (SDF), Finite State Machine (FSM) and
Heterochronous Dataflow Domain (HDF) models.
Codegen has the following new features:
- ptolemy.actor.lib.jni.EmbeddedCActor ($PTII/ptolemy/codegen was removed after Ptolemy II 8.0. Use $PTII/ptolemy/cg instead.) - Allows arbitrary C code to be embedded in a Java model. The entire Java model can then be converted to C code and the code within the EmbeddedCActor will be used.
- Enhanced polymorphic type system
- Support for invoking the Java plotter from a C version of a model
- and many more
Code Generator Documentation
Between Ptolemy II 8.0 and 10.0,$PTII/ptolemy/codegen was replaced with $PTII/ptolemy/cg
References
- 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.
Codegen Demonstrations
Some of the code generation demos might not work under Web Start because
Web Start uses a JRE, not a JDK.
Codegen demonstrations ($PTII/ptolemy/codegen was removed after Ptolemy II 8.0. Use $PTII/ptolemy/cg instead.)
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.
References
- E. A. Lee, "Model-driven Development--From Object-Oriented Design to Actor-Oriented Design," Workshop on Software Engineering for Embedded Systems: From Requirements to Implementation (a.k.a. The Monterey Workshop), Chicago, IL, 2003.
- A. Cataldo, E. Cheong, T. H. Feng, E. A. Lee, and A. Mihal, "A Formalism for Higher-Order Composition Languages that Satisfies the Church-Rosser Property," UC Berkeley EECS Technical Report No. UCB/EECS-2006-48, 2006.
- J. A. Cataldo, "The Power of Higher-Order Composition Languages in System Design," EECS Department, UC Berkeley, Technical Report No. UCB/EECS-2006-189, December 18, 2006.
- E. Cheong, "Actor-Oriented Programming for Wireless Sensor Networks," EECS Department, University of California, Berkeley Technical Report No. UCB/EECS-2007-112, August 30, 2007
Ptalon Demonstrations
Primary Ptalon Developer: Adam Cataldo
Contributor: Elaine Cheong
A backtracking facility enables the system to restore its old
state. It has many applications in practice, and is especially
important to high-performance distributed computation.
In developing this sub-project, we highlight the
following (increasing) list of criteria:
- Performance. The highest priority is awarded to the
performance of the resulting system (the Ptolemy II system with
backtracking support built in), as compared to the original
system. Novel approaches are employed mainly to improve performance,
with moderate complexity added.
- Automatic transformation. Transformation from the original
system to the backtracking-enabled system must be automated as much as
possible. Due to the size of the existing system, it is not realistic
to require a manual recoding in most of its sources. Moreover, coding
the backtracking sub-system by hand makes it hard to debug and evolve
over time.
- Clean interface to other parts. The
backtracking sub-system must reveal a small but powerful
interface to the other parts in the system. It provides
the users with functions such as creating checkpoints,
undoing multiple language-level operations by backtracking
to a previous checkpoint, and even redoing those
operations to achieve some form of laziness.
Primary Backtracking Developer: Thomas Huining Feng
Backtracking Demonstrations
The
Continuous domain
is a redesign of the Continuous Time (CT) domain with
a rigorous semantics documented in the following papers:
- Edward A. Lee, Haiyang Zheng, "Leveraging Synchronous Language Principles for Heterogeneous Modeling and Design of Embedded Systems," EMSOFT, September 30 - October 2, 2007, Salzburg, Austria.
- Haiyang Zheng, "Operational Semantics of Hybrid Systems," Ph.D. Dissertation, EECS Department, University of California, Berkeley, Technical Report No. UCB/EECS-2007-68, May 18, 2007.
- Edward A. Lee and Haiyang Zheng, "Operational Semantics of Hybrid Systems," Invited paper in Proceedings of Hybrid Systems: Computation and Control (HSCC) LNCS 3414, Zurich, Switzerland, March 9-11, 2005, pp.25-53.
The continuous domain models systems with continuous dynamics, including
for example analog circuits and mechanical systems, but also
cleanly supports discrete events, modal behaviors, and signals that
mix continuous-time behaviors with discrete events.
Models for continuous dynamics are equivalent to linear or nonlinear
integral equations. A sophisticated numerical solver for these equations
is integrated with the director.
The clean semantics of the Continuous domain enables its integration
in hierarchical heterogeneous models that use the Synchronous/Reactive (SR)
and Discrete Event (DE) domains. Arbitrary hierarchical mixtures of these
domains are supported, although if SR is at the top level, then the
period parameter of the director must be used so that time advances.
Domain interactions are documented in the following paper:
- A. Goderis, C. Brooks, I. Altintas, E. A. Lee, and C. Goble, "Heterogeneous Composition of Models of Computation," EECS Department, University of California, Berkeley, Tech. Rep. UCB/EECS-2007-139, Nov. 2007.
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.
References
Model Transformation Demonstrations
Primary Model Transformation Developer: Thomas Huining Feng
Continuous Time (CT)
In Ptolemy II 8.0, the continuous domain was created. Between Ptolemy II 8.0 and 10.0, ct was removed.
Discrete Event (DE)
Process Network (PN)
Synchronous Dataflow (SDF)
Synchronous/Reactive (SR)
User Interface Demonstrations
See also the Complete Demonstrations page.
ArrayType changes surrounding length
The ArrayType class
now represents the length of arrays. New methods were added:
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:
- The FixType modifications were easily factored since any FixType
with a known length is less than the single FixType with an unknown
length. ArrayType could not be factored this way because of the more
complex type relations.
- FixType doesn't have a contained type variable.
ArrayTypes now have a type construction functions: arrayType(int) and
arrayType(int, 4) represent the types that you might expect.
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
New Continuous Time (CT) actors: The CT domain was removed after Ptolemy II 8.0
- ptolemy.domains.ct.lib.DiscreteClock
New Synchronous Dataflow (SDF) actors:
New Code Generation Actors
( $PTII/ptolemy/codegen was replaced with $PTII/ptolemy/cg after Ptolemy II 8.0)
- ptolemy.codegen.c.actor.lib.ArrayElementAsMatrix
- ptolemy.codegen.c.actor.lib.ArrayPeakSearch
- ptolemy.codegen.c.actor.lib.CodegenActor
- ptolemy.codegen.c.actor.lib.CurrentTime
- ptolemy.codegen.c.actor.lib.Lattice
- ptolemy.codegen.c.actor.lib.MovingAverage
- ptolemy.codegen.c.actor.lib.Publisher
- ptolemy.codegen.c.actor.lib.PublisherTest
- ptolemy.codegen.c.actor.lib.RecursiveLattice
- ptolemy.codegen.c.actor.lib.SetVariable
- ptolemy.codegen.c.actor.lib.Subscriber
- ptolemy.codegen.c.actor.lib.SubscriptionAggregator
- ptolemy.codegen.c.actor.lib.VectorAssembler
- ptolemy.codegen.c.actor.lib.VectorDisassembler
- ptolemy.codegen.c.actor.lib.WallClockTime
- ptolemy.codegen.c.actor.lib.conversions.CartesianToComplex
- ptolemy.codegen.c.actor.lib.conversions.ComplexToCartesian
- ptolemy.codegen.c.actor.lib.gui.LEDMatrix
- ptolemy.codegen.c.actor.lib.hoc.MultiInstanceComposite
- ptolemy.codegen.c.actor.lib.test.RampNecessaryFiles
- ptolemy.codegen.c.domains.sdf.lib.BitsToInt
- ptolemy.codegen.c.domains.sdf.lib.Chop
- ptolemy.codegen.c.domains.sdf.lib.DownSample
- ptolemy.codegen.c.domains.sdf.lib.IntToBits
- ptolemy.codegen.c.domains.sdf.lib.LMSAdaptive
- ptolemy.codegen.c.domains.sdf.lib.RaisedCosine
- ptolemy.codegen.c.domains.sdf.lib.UpSample
- ptolemy.codegen.c.domains.sdf.lib.VariableFIR
- ptolemy.codegen.c.domains.sdf.lib.VariableLattice
- ptolemy.codegen.c.kernel.CCodegenUtilities