Transcript Model of Computation

Ptolemy & Models of
Computation
Claudius Ptolemaeus, the second century
Greek astronomer, mathematician, and
geographer.
-by Hao Chen, Zhuang Fan, Jin Xiao
School of Computer Science
University of Waterloo
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
connection
Actor
Port
Actor
Relation
Link
Link
Attributes
Port
on
ec
co
cti
nn
ne
Link
n
co
tio
n
Attributes
Port
Actor
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, eventbased, 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
sendType  receiveType
• Static type checking
• Dynamic type conversion
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, eventtriggered 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 threadoriented, 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