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

PortPort

A ctor Actor

L inkRelation

Actor

Port

connection

connection connection

L ink

Link

A ttribu tes A ttribu tes

A ttribu tes

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

sendTypereceiveType

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