Ptolemy

The Ptolemy Project [Hylands et al., 2003,www-Ptolemy, ] is an informal group of researchers that is part of the Chess (Center for Hybrid and Embedded Software Systems) at the University of California, Berkeley. According to its authors, Ptolemy is above all ``a laboratory for experimenting with design techniques''.

The main focus of the Ptolemy Project is on embedded systems (embedded software is software that resides in devices that are not first-and-foremost computers), particularly those that mix technologies including, for example, analog and digital electronics, hardware and software, and electronics and mechanical devices. But the group is also interested on systems that are complex in the sense that they mix different operations such as networking, signal processing, or user interfaces.

Ptolemy is open source but its BSD license allows commercial software to be created with it, therefore maximizing its impact.

The Ptolemy group has produced three different frameworks: Gabriel, Ptolemy Classic and Ptolemy II.

Gabriel was developed between 1986 and 1991. It was written in Lisp and focused on signal processing. It included code generators for DSP's that produced efficient assembly code, especially for Motorola processors, and also hardware/software simulators which ran a parallel processor simulation.

Ptolemy Classic was developed between 1990 and 1997 but it has been still in use thereafter. It is written in C++. It was the first modeling environment to support multiple MoCs, hierarchically combined. The SDF (see 1.5.1) MoC implementation was ported from Gabriel and Boolean Dataflow (BDF), Dynamic Dataflow (DDF), multidimensional synchronous dataflow (MDSDF) and Process Networks (PN) were also added. DSP code generators were ported and C and VHDL code generators were developed. They developed a discrete-event domain and demonstrated joint modeling of communication networks and signal processing. And they also developed a hardware simulation domain called Thor. Portions of Ptolemy Classic were commercialized in different products.

The Ptolemy II version was started in 1996. The main reason for starting it was to exploit the capabilities of Java. It introduced the notion of domain polymorphism (a component could be designed to work on different domains) and modal models (where FSM are combined hierarchically with other MoC's). Ptolemy II added a sophisticated type system where components can be designed to operate on multiple data types and an expression language. Ptolemy II uses XML for data persistence. Some (but not all) the SDF capabilities of Ptolemy Classic were ported. The Ptolemy project contributed to a user-interface toolkit called Diva and used it to design a user-interface called Vergil. They built models that could be used as applets from a web browser. Different experimental domains for real-time and distributed computing were also implemented. Instead of components as generators Ptolemy II uses a component-specialization framework built on top of a Java compiler toolkit called Soot. From now on when talking about ``Ptolemy'' we will be referring to the Ptolemy II version.

Ptolemy has a visual (block diagram) programming interface and a textual interface that offer two different ways of defining and modifying networks. Furthermore, the primitive actors or processes can be extended using the host language (Java).

The Model of Computation is not completely integrated into the framework and as a matter of fact, one of the goals of Ptolemy is to offer a platform for testing different MoCs[Lee and Park, 1995]. Nevertheless, some models of computation are already available and don't have to be provided by the user. Ptolemy offers support for Synchronous Dataflow Networks (SDF), Dynamic Dataflow Networks (DDF)*, Boolean Dataflow Networks (BDF)* and a more generic Process Network model (PN)^2.2. Ptolemy also offers support for some other MoC's that are less interesting from our point of view. These include Component Interaction (CI), Communicating Sequential Processes (CSP) ,Continuous Time (CT), Discrete Events (DE), Distributed Discrete Events (DDE), Discrete Time (DT), Finite State Machines (FSM), Process Networks (PN), Synchronous Dataflow (SDF), Synchronous Reactive (SR), and Timed Multitasking (TM).

The amount of MoC's makes it difficult to choose one although most developers are usually just faced with a small subset of them. Nevertheless to design interesting systems heterogeneous models need to be used. According to the authors a grand unified approach could try to seek a model that serves all purposes. This could be accomplished by creating a mix of all the previous ones but such a mixture would be extremely complex and difficult to use.

Ptolemy supports both interpreted and compiled execution modes. Nevertheless, the code generation mechanism does not implement optimizations as these require more knowledge about the primitives than simply gluing together code fragments from each process.

Subgraphs can be encapsulated into a single node but it is always important to make sure that the resulting hierarchical node preserves properties of the conforming actors (see [Lee and Park, 1995] for examples of how this is not always guaranteed).

In Ptolemy, like in many similar software environments there are three phases to the execution of a program: setup, run and wrap-up.

In the first phase the hierarchical graph is traversed in order to initialize delays and state variables, evaluate parameters and the part of the schedule that can be statically evaluated, and perform other setup operations. Parameters evaluated during this phase represent the part of the operation that does not operate on streams, defining a clear syntactic difference between parameter arguments and stream arguments. When compiled mode is used, code generation is done after the parameters have been evaluated, allowing for highly-optimized code. In Ptolemy, an actor or process that only has parameters as inputs is called a source as it has no dynamic inputs.

In the Run phase, the execution is carried on following either a precomputed schedule or computing the schedule on the fly.

Finally, in the Wrap-up phase if the run is finite (it is often not the case) the memory is freed and final results are presented to the user.

Ptolemy uses polymorphism for process data transmission. Input and output ports are strongly typed but they only expect data tokens. Any data type, even an array, can be encapsulated in a token.

Ptolemy is highly modular and has a careful package structure: core packages: support data model or abstract syntax and offer abstract semantics; UI packages: support for XML file format and visual interface; library packages: provide actor libraries that can operate on a variety of domains; and domain packages: provide domains each of which implements a MOC and some of which provide their own domain-specific actor libraries.