ptolemy & models of computation -by hao chen, zhuang fan, jin xiao school of computer science...
TRANSCRIPT
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