Ptolemy & Models of Computation -by Hao Chen, Zhuang Fan, Jin Xiao School of Computer Science University of Waterloo Claudius Ptolemaeus, the second century Greek astronomer, mathematician, and geographer.

Outline Introduction –What is model of computation –Motivation and goal of Ptolemy –Some concepts in Ptolemy –Relationship between ADL and model of computation –Type system in Ptolemy Detailed introduction of models of computation System Level Design Language (SLDL) Conclusion

What Is Model of Computation Theory perspective –RE, FA/DFA, CFG, Parse tree, Turing Machine System perspective –It is the “laws of physics” governing the interaction between components –It is the modeling paradigm –E.g. CSP, PN, DF/SDF… Concentrate on these that deal with concurrency and time

Motivation & Goal of Ptolemy Motivation –Embedded system –Support for design and simulate heterogeneous embedded systems Goal –designing components that can be used under different models of computation

Some Concepts in Ptolemy Domain –Realization of model of computation Actor –Component with ports and attributes Port –Actor sends/receives message through ports Token –Data transferred between components

Actors with Ports and Attributes

Relationship with ADL ADLs focus on describing the rich set of interactions between components. Models of computation define the characteristics of interactions in a system –E.g. rendezvous-style, synchronize/asynchronous, event- based, time-driven, data-flow(stream) based ADLs are usually suitable for some particular MoCs –E.g. Wright is suitable for CSP, but awkward for FIFO channel communications

Type System in Ptolemy Classic type system –Define the token type –Each port is associated with a type –Static and dynamic type checking and converting System level type –Data type only specify static aspects of interface –Extends type system to capture the dynamic interaction of components in types –Use interface automata (de Alfaro & Henzinger)

Classic Type System : Data Type Lattice Organize all types in a lattice structure Combination of subtyping relation in OO languages, and ad hoc subtyping rules Specify lossless conversion

Classic Type System : Type compatibility rule Static type checking Dynamic type conversion sendType  receiveType

System-Level Type System: Why Ptolemy wants to define actors to be domain polymorphic How can you make sure the actor is domain polymorphic? Use interface automata

System-Level Type System : Interaction Semantics In Ptolemy, communication between components is defined by a Receiver interface In Receiver, there are get(), put(), hasRoom(), hasToken()

System-Level Type System: Idea Each domain has corresponding Receiver interface Use automata to describe the Receiver interface’s dynamic behavior, we get receiver automaton for each domain By automaton simulation, we get a lattice structure

System-Level Type Lattice

System-Level Type System: Idea (Cont’d) Now define the actor interface automaton Check the compatibility between actor interface automaton and domain interface automata Type lattice is used here –D1  D2 and Actor x is compatible with D1, x also compatible with D2

Model of Computation Agenda –Design concept: polymorphism –Universal actor: concept and design –The models of computation CSP, PN, SDF, DT, SR, CT, FSM, DE, DDE –How to choose the right one? –Hybrid designs

Polymorphism re-use potential is maximized through the use of polymorphism. Ptolemy includes libraries of polymorphic actors using both kinds of polymorphism to maximize re-usability.

Data Polymorphism A data polymorphic actor is one that can operate on any of a number of input data types. For example, AddSubtract can accept any type of input.

Domain Polymorphism Most actors access their ports as shown in figure 3.5, Those methods are polymorphic, in that their exact behavior depends on the domain.

Universal Actor: the Concept An component that can be used unmodified and meaningfully under different models of computation Support data polymorphism and domain polymorphism Universal actors in Ptolemy implements an standard actor interface

Designing Actors explains the common, domain- independent principles in the design of components that are actors. how to design actors so that they are maximally domain polymorphic.

The Universal Actor Interface Initialization Phase –Executed once Iteration Phase –Executed multiple times –Prefire –Fire –Postfire Termination Phase

Initialization

Prefire Consider for example an actor that reads from trueInput if a private boolean variable _state is true, and otherwise reads from falseInput. The prefire() method might look like this:

Fire To get data polymorphism, use the methods of the Token class for arithmetic whenever possible When data polymorphism is not practical or not desired, then it is usually easiest to use the set- TypeEquals() to define the type of input ports. A domain-polymorphic actor cannot assume that there is data at all the input ports. Some domains invoke the fire() method multiple times, iterating towards a converged solution.

Postfire The postfire() method has two tasks: – updating persistent state, and – determining whether the execution of an actor is complete.

Termination Wrapup() called –Called only once –Only called if actor terminates normally without exception –It is used typically for displaying final results.

A Simple Example

Communicating Sequential Processes Concurrently executing processes Rendezvous: atomic, instantaneous actions –Simultaneous interaction –Uninterruptible No notion of time, partial event ordering

Communicating Sequential Processes Model of Computation semantics: –Bubble: processes –Arrow: message passing –Constraint: synchronous communication, process blocking and atomic interaction

Rendezvous

Nondeterministic Rendezvous Nondeterministic redezvous has the form: Guard; Communication  Statements; –Guard: evaluation statement, only can refer local variable. Can not alter process state –Communication: simple send or receive action –Statements: any number of statements

Communicating Sequential Processes E.g. Pipeline (data sharing) A (generator), B (refinement), D (consumer), C (alarm)

Communicating Sequential Processes Advantage –Resource sharing Disadvantage –Difficult to maintain determinacy –No notion of time Application –Client-server database model –Multi-tasking or multiplexing of hardware resources

Process Networks Loosely coupled concurrent processes communicate via buffered message passing Data values are exchanged between processes (Kahn PN) Processes are input-output mapping functions No notion of time, partial event ordering

Process Networks Model of Computation semantics: –Bubble: processes (functions) –Arrow: data values –Constraint: asynchronous communication, message buffering, and data passing

Kahn Process Networks Processes only communicate via unidirectional channels with unbounded capacities The channel is single input single output FIFO Possibly infinite sequence of data Read once semantic

Kahn Process Networks Operational semantics –Each process executes a sequential program –A process can read from an input channel and write to an output channel at any time –Can not poll a channel for the presence of data –A read from empty input channel blocks the process until data is available –Monotonic process (topology, not implementation)

Process Networks E.g. Pipeline (data passing) A (generator), B (refinement), D (consumer), C (monitor)

Process Networks Advantage –Loosely coupled, easy to parallelize and distribute –Easy to implement Disadvantage –Hard to specify complex control logic (data value) Application –Signal processing

Synchronous Dataflow Dataflow model –Special case of PN –Data passing –Atomic actors (indivisible) triggered by availability of input data Synchronous dataflow –Special case of data flow model –Synchronous data passing

Synchronous Dataflow Model of Computation semantics: –Bubble: atomic actors –Arrow: flow of data –Constraint: synchronous communication, atomic components, and input data based action trigger

Synchronous Dataflow E.g. Iterative production A (initiator), B (refinement), D (commit), C (monitor)

SDF Properties Actor action is atomic The firing of actors are scheduled to ensure the number of tokens remains unchanged before and after any actor action Deadlock free SDF Director is used for the above scheduling

Consistency in SDF

Consistent Model vs. Inconsistent Model

A Simple Example of SDF

Synchronous Dataflow Advantage –Deadlock and boundedness are decidable Disadvantage –Restrictive –More general DF models, such as BDF and DDF has to be simulated using PN Application –Embedded real-time software

Discrete Time Extends the SDF by introducing the notion of clock Data are uniformly sent out by actors per “clock tick” Entity represents relation between input and output on each clock tick Multi-rate DT model

Discrete Time Model of Computation semantics: –Bubble: input to output relation –Arrow: timely delivery of data –Constraint: synchronous communication, atomic components, input data based action trigger, and global clock

Discrete Time E.g. Conservative Timed production A (initiator), B (refinement), D (commit), C (monitor)

Discrete Time Advantage –Guaranteed causal component behavior –Efficient (time-triggered architecture) Disadvantage –Regularity Application –Digital signal processing

Synchronous/Reactive Connection represents timed value –The data value are sent(updated) at aligned global clock tick –No guarantee of data value sending at each clock tick –Models systems with irregular events Entities represents relations between input and output on clock tick

Synchronous/Reactive Model of Computation semantics: –Bubble: input to output relation –Arrow: discretely timed event –Constraint: input data based action trigger and global clock

Synchronous/Reactive E.g. Timed production A (initiator), B (refinement), D (commit), C (monitor)

Synchronous/Reactive Advantage –Addressed the issue of irregular events in concurrent models –Tight synchronization Disadvantage –Modularity compromised (global fixed point at each clock tick) Application –Safety critical real-time applications

Continuous Time Components interact via continuous-time signals Actors specify algebraic or differential relations between inputs and outputs Director find a fixed-point (set of continuous-time functions that satisfy all the relations)

Continuous Time Model of Computation semantics: –Bubble: actor –Arrow: continuous-time signal –Constraint: director, global time, and the support of differential equation solvers

Continuous Time E.g. Timed Iterative production A (initiator), B (refinement), D (commit), C (monitor)

Continuous Time Advantage –Modeling algebraic or differential relations in a system Disadvantage –Often require interoperating with other domains, such as DT and FSM Application –Modeling of physical systems, especially mechanical devices, analog circuits, and microwave chips

Finite State Machines Sequential states Execution of the system is a strictly ordered set of such states and their corresponding transitions Often hierarchically combined with other domains to form *charts

Finite State Machines Model of Computation semantics: –Bubble: state –Arrow: transition –Constraint: non-concurrent state, distinct transitions, and state guard

Finite State Machines E.g. production control A (start), B (refining), D (end), C (error)

Finite State Machines Advantage –Can be the subject of formal analysis –Easy to implement Disadvantage –Not very expressive when used alone –Large number of states Application –Complex control logic

Starchart: Hierarchical Composition Solve the state explosion problem Allows for more expressiveness by combining FSM with other Models of Computation

Starchart: Hierarchical Composition

Discrete Events In discrete events, connections are: –Set of events on a timeline –Each event is associated with a value and timestamp Actions are: –Event generator: event firing –Event receiver: event triggered actions Events with simultaneous time are ordered based on data precedence

Discrete Events Model of Computation semantics: –Bubble: actor –Arrow: timed event –Constraint: timed event, global clock, event- triggered actions and global event queue

Discrete Events E.g. Real-time pipeline A (generator), B (refinement), D (consumer), C (control)

Discrete Events Advantage –Global event ordering –Timed event Disadvantage –Global consistent time –Centralized event queue Application –Design of communication systems

Distributed Discrete Events Variant of DE –Remove the need for global event queue, and global clock –Allows for better distributed system design Local notion of time on each connection Local timed ordering Use of null-time event

Distributed Discrete Events Model of Computation semantics: –Bubble: actor –Arrow: timed event –Constraint: timed event, event-triggered actions and local event queue

Distributed Discrete Events E.g. Real-time pipeline A (generator), B (refinement), D (consumer), C (control)

Distributed Discrete Events Advantage –Time event –Distributed event queue Disadvantage –Inconsistent time Application –Design of communication systems

A Few Remarks Some of the MoC (CSP, DDE, and PN) are thread-oriented, meaning that the components implement Java threads. Others (CT, DE, SDF) MoC implement their own scheduling between actors, rather than relying on threads. The FSM domain is in a category by itself, since in it, the components are not producers and consumers of data, but rather are states.

Choosing Model of Computation The treatment of time is an important factor –Models that explicitly represent time: CT, DE, DDE –Models that use discrete time: DT, SR –Models that impose causality: CSP, PN, SDF, FSM

Choosing Model of Computation Cooping with the diverse views –Unified approach: form one model that encompasses all models. Expressive, complex, hard to understand and validate –Specialized approach: choose one model, and fit all other models as extension of the basic model. Uniform, not exploiting the strength of each model

Heterogeneous Models Hierarchical heterogeneous combination of models of computation –E.g. combining CT with DT Requires domain polymorphic component –A component that can be executed under any number of models of computation

Heterogeneous Models Domain Polymorphism –Domain polymorphic components –Well-defined behavior under a number of different models of computation Aggregate domain polymorphism –An aggregation of components under the control of a domain should itself be a domain polymorphic component –Some Models are difficult to achieve this: CSP, PN