The RASSP Digest - Vol. 2, No. 1, 1st. Qtr. 1995

Technology Base

The Ptolemy Kernel Supporting Heterogeneous Design

by The Ptolemy Team

1. Introduction

A technology base team at the University of California at Berkeley is developing a software environment called Ptolemy that supports heterogeneous design. An early contribution of this effort has been the design of a compact software infrastructure upon which specialized design environments (called domains) can be built. The software infrastructure, called the Ptolemy kernel, is made up of a family of C++ class definitions. Domains are defined by creating new C++ classes derived from the base classes in the kernel.

Domains can operate in any (or all) of three modes: At Berkeley, we have built a variety of domains that operate in the first two modes only, although code generation domains often have elements of optimization from the third.

The use of an object-oriented software technology permits each of these domains to interact with one another without knowledge of each others' features or semantics. Thus, using a variety of domains, a team of designers can model each subsystem of a complex, heterogeneous system in a manner that is natural and efficient for that subsystem.

2. The Design of the Kernel

The overall organization of the latest release of the Ptolemy system is shown in Figure 1. A typical use of Ptolemy involves starting two UNIXTM processes, as shown in Figure 1(a), the first containing the user interface (VEM) and the design database (OCT), and the other containing the Ptolemy kernel. An alternative is to run Ptolemy without the graphical user interface, as a single process, as shown in Figure 1(b). A textual interpreter called "ptcl" is used in this case. It is also possible to design other user interfaces for the system.


Figure1. The overall organization of Ptolemy version 0.5.1, showing two possible execution styles. This report concentrates on the kernel and its relationship to the domains.


The executables "pigiRpc" or "ptcl" can be configured to include any subset of the available domains. The most recent picture of the domains that Berkeley has developed is shown in Figure 2. Many different styles of design are represented by these domains. More are constantly being developed both at Berkeley and elsewhere, to experiment with or support alternative styles.


Figure 2. The most recent view of the set of domains developed at Berkeley. This article will discuss only CG, which underlies all of code generation.


The Ptolemy kernel provides the most extensive support for domains where a design is represented as a network of blocks, as shown in Figure 3. A base class in the kernel, called Block, represents an object in this network. Base classes are also provided for interconnecting blocks (PortHole) as well as for carrying data between blocks (Geodesic) and managing garbage collection efficiently (Plasma). Not all domains use these classes, but most current ones do, and hence can very effectively use this infrastructure.


Figure 3. Block objects in Ptolemy can send and receive data encapsulated in Particles through Portholes. Buffering and transport is handled by the Geodesic and garbage collection by the Plasma. Some methods are shown.



Figure 3 shows some representative methods defined in these base classes. For example, note the initialize, run, and wrapup methods in the class Block. These provide an interface to whatever functionality the block provides, representing for example functions performed before, during, and after execution of the system.

Blocks can be hierarchical, as shown in Figure 4. The lowest level of the hierarchy, as far as Ptolemy is concerned, is derived from a kernel base class called "Star." A hierarchical block is a "Galaxy," and a top-level system representation is a "Universe."


Figure 4. A complete Ptolemy application (a Universe) consists of a network of Blocks. Blocks may be Stars (atomic) or Galaxies (composite). The “XXX” prefix symbolizes a particular domain (or model of computation).



3. Models of Computation

The Ptolemy kernel does not define any model of computation. In particular, although the Berkeley team has done quite a bit of work with dataflow domains in Ptolemy, every effort has been made to keep dataflow semantics out of the kernel. Thus, for example, a network of blocks could just as easily represent a finite-state machine, where each block represents a state. A particular domain defines these semantics. Suppose we wish to define a new domain, called XXX. We would define a set of C++ classes derived from kernel base classes to support this domain. These classes might be called "XXXStar," "XXXUniverse," etc., as shown in Figure 4.

The semantics of a domain are defined by classes that manage the execution of a specification. These classes could invoke a simulator, or could generate code, or could invoke a sophisticated compiler. The base class mechanisms to support this are shown in Figure 5. A "Target" is the top-level manager of the execution. Similar to a Block, it has methods called "setup," "run," and "wrapup." To define a simulation domain called "XXX," for example, one defines at least one object derived from Target that runs the simulation. As suggested by Figure 5, a Target can be quite sophisticated. It can, for example, partition a simulation for parallel execution, handing off the partitions to other Targets compatible with the domain.


Figure 4. A complete Ptolemy application (a Universe) consists of a network of Blocks. Blocks may be Stars (atomic) or Galaxies (composite). The “XXX” prefix symbolizes a particular domain (or model of computation).

A Target will typically perform its function via a Scheduler. The Scheduler defines the operational semantics of a domain by controlling the order of execution of functional modules. Sometimes, schedulers can be specialized. For instance, a subset of the dataflow model of computation called "synchronous dataflow" allows all scheduling to be done at compile time. The Ptolemy kernel supports such specialization by allowing nested domains, as shown in Figure 6. For example, the SDF domain (see Figure 2) is a sub-domain of the BDF domain. Thus, a scheduler in the BDF domain can handle all stars in the SDF domain, but a scheduler in the SDF domain may not be able to handle stars in the BDF domain. A domain may have more than one scheduler.


Figure 6. A Domain (XXX) consists of a set of Stars, Targets and Schedulers that support a particular model of computation. A sub-Domain (YYY) may support a more specialized model of computation.

4. Mixing Models of Computation

Domains in Ptolemy can be mixed. Thus, one system-level design can contain multiple subsystems that are designed or specified using different styles. The kernel support for this is shown in Figure 7. An object called "XXXWormhole" in the "XXX" domain is derived from "XXXStar," so that from the outside it looks just like a primitive in the XXX domain. Thus, the schedulers and targets of the XXX domain can handle it just as they would any other primitive block. However, inside, hidden from the XXX domain, is another complete subsystem defined in another domain, say "YYY." That domain gets invoked through the setup, run, and wrapup methods of XXXWormhole. Thus, the wormhole is polymorphic in a broad sense.


Figure 7. The universal EventHorizon provides an interface between the external and internal domains.

5. Code Generation

The domains shown in Figure 2 are divided into two classes: simulation and code generation. In the simulation domains, a scheduler invokes the run methods of the blocks in a system specification, and those methods perform some function associated with the design. In code generation domains, the scheduler also invokes the run methods of the constituent blocks, but these run methods synthesize code in some language. i.e., they generate code to perform some function, rather than performing the function directly. The Target is responsible then for generating the connecting code between blocks (if any is needed). This mechanism is very simple, and language independent. We have built code generators for a number of languages, as indicated in Figure 2.

An alternative mechanism that is supported but less exploited in current Ptolemy domains is for the target to analyze the network of blocks in a system specification and generate a single monolithic implementation. This is what we call compilation. In this case, the primitive blocks (Stars) must have functionality that is recognized by the target. In the previous code generation mechanism, the functionality of the blocks is arbitrary and can be defined by the end user.

6. Conclusions

In summary, the key idea in the Ptolemy project is to mix models of computation, implementation languages, and design styles, rather than trying to develop one, an all encompassing technique. The rationale is that specialized design techniques are (1) more useful to the system-level designer, and (2) more amenable to high-quality high-level synthesis of hardware and software. The Ptolemy kernel demonstrates one way to mix tools that have fundamentally different semantics, and provides a laboratory for experimenting with such mixtures.

The Ptolemy kernel has been used successfully outside Berkeley for a number of domain designs. A notable example is the work of Berkeley Design Technology, Inc., as part of the Martin Marietta RASSP program, to use the Ptolemy to connect the SPW and Bones tools from the Alta Group at Cadence.

The current Ptolemy team is: Shuvra Bhattacharyya, Joseph T. Buck, Wan-Teh Chang, Brian L. Evans, Steve X. Gu, Sangjin Hong, Christopher Hylands, Asawaree Kalavade, Alan Kamas, Allen Lao, Bilung Lee, Edward A. Lee, David G. Messerschmitt, Praveen K. Murthy, Thomas M. Parks, José Luis Pino, Farhana Shiekh, S. Sriram, Juergen Teich, Warren W. Tsai, Patrick J. Warner, Michael C. Williamson.
The RASSP Digest - Vol. 2, No. 1, 1st. Qtr. 1995

newsletter/html/95q1/news_7.html