In Ptolemy, a complex system is specified as a hierarchical composition (nested tree structure) of simpler subsystems. Each subsystem is modeled by a domain. A subsystem (also called a galaxy) can internally use a different domain than that of its parent or children. In mixing domains, the key is to ensure that at the interface, the child galaxy obeys the semantics of the parent domain. This interface is called a wormhole. Ptolemy does not yet make the wormhole mechanism foolproof. Any domain can be used at the top level.

As shown in Figure 1-2, Ptolemy consists of dataflow, discrete-event, and control-oriented families of domains. The Synchronous Dataflow (SDF) and Discrete-Event (DE) domains are the most mature. In terms of semantics, the Discrete-Event domains are the furthest from the dataflow domains in the 0.7 distribution. Other domains with semantics very different from dataflow, are the Finite State Machine (FSM) and Synchronous/Reactive (SR) domains.

Domains perform either simulation or code generation. Simulation domains are interpreters that run an executable specification of a system on the local workstation. Code generation domains translate the specification into some language such as C or VHDL and then optionally manage the execution of that generated code. In 0.6 and later, code generation domains can be mixed with each other and with simulation domains. Thanks to José Pino for developing hierarchical scheduling to support this capability.

The model of computation is the semantics of the network of blocks. It defines what is meant by an interconnection of blocks, and how the interconnection will behave when executed. The domain determines the model of computation, but in the case of code generation domains, it also determines the target language. So for example, the CGC (Code Generation in C), C50 (Code Generation for the Texas Instruments TMS320C50) and the CG56 (Code Generation for the Motorola DSP56000) domains all use the synchronous dataflow model of computation (the same as the SDF domain). The CGC domain also supports features of the Boolean dataflow (BDF) domain, which supports a measure of run-time scheduling in a very efficient way.

Simulation domains can be either timed or untimed. Untimed domains carry no notion of time in their semantic model. Instead of chronology, they deal only with the order of particles or actions. Timed domains have a notion of simulated time, where each particle or action is modeled as occurring at some particular point in this simulated time. Particles and actions are processed chronologically. Timed and untimed domains can be mixed. From the perspective of a timed domain, actions in an untimed domain will appear to be instantaneous. Moreover, timed domains can exist at several levels of the hierarchy, or in parallel at a given level of the hierarchy, separated by untimed domains, and their chronologies will be synchronized. That is, the notion of simulated time in Ptolemy is a global notion. When particles and actions are processed chronologically in each timed domain that is present, then they will be processed chronologically globally.

In this chapter, we also introduce the Target class. The basic role of this class is in managing design flow. In a simulation domain, the target selects the scheduler to use (there can be several schedulers in a single domain) and starts and stops a simulation. In a code generation domain, the target also selects the scheduler, but then also generates the code, compiles it, and runs it on a suitable platform. Targets can be defined hierarchically; for example, a multiprocessor target may consist of several, possibly heterogeneous execution platforms, each specified itself as a target. In this example, the top level target might handle the partitioning and interprocessor communication, and the lower level targets might handle the code generation, compilation, and execution. Targets play a much bigger role in code generation domains than in simulation domains.

Ptolemy users often prematurely set out to make a new domain. While it is the intent of Ptolemy to support such experimentation, this task should be undertaken with some trepidation. Although any software engineer can create a domain that will work, defining a useful and correct model of computation is a much harder task. It is very easy, for example, to define a non-determinate model of computation. This means that the behavior of an application will depend on implementation details in the scheduler that are not explicitly known to the user. As a consequence, a user make a small, seemingly innocuous change in an application, and unexpectedly get radically different behavior. At Berkeley, many more domains have been built than are currently distributed. Sometimes, domains have been discarded because of unexpected subtleties in the model of computation. In other cases, domains have been built on top of third-party software or hardware that has become obsolete.

A prerequisite for creating any new domain is understanding the existing domains in Ptolemy. Frequently, one of these domains will meet your needs with simpler extensions, like a new target or a family of stars. If, for example, you are unhappy with the performance of a scheduler, it may make more sense to define a new scheduler (and a target to support it) within an existing domain, rather than creating a new domain.

This chapter gives a brief introduction to the simulation and code generation domains released in Ptolemy 0.7. It also highlights the domains that were present in earlier versions of Ptolemy but are no longer released. This chapter ends with an overview of the interfaces to foreign tools, such as simulators, interpreters, and compilers.