Models of Computation

1
Models of Computation

• ECE 253 Embedded System Design
• Ryan Kastner
• January 22, 2007

2
Mapping Application to Computing System

• Mapping tools transform one representation into
  another
• Ideal full automation
• Reality semi-automated
• Enables design space exploration
• Performs some of the tasks
• Each system should be fully specified
• How do you specify the application and system?

3
Methodical System Design

• Ad hoc approach to design does not work beyond a
  certain level of complexity, that is exceeded by
  vast majority of embedded systems
• Methodical, engineering-oriented, tool-based
  approach is essential
• specification, synthesis, optimization,
  verification etc.
• prevalent for hardware, still rare for software
• One key aspect is the creation of models
• concrete representation of knowledge and ideas
  about a system being developed - specification
• model deliberately modifies or omits details
  (abstraction) but concretely represents certain
  properties to be analyzed, understood and
  verified
• one of the few tools for dealing with complexity

4
Abstractions and Models

• Foundations of science and engineering
• Activities usually start with informal
  specification
• Writing on back of a napkin, project reports
• However, soon a need for Models and Abstractions
  is established
• e.g. Chess and Poker - Without rules (model), no
  games
• Connections to Implementation (h/w, s/w) and
  Application
• Two types of modeling system structure system
  behavior
• the behavior and interaction of atomic components
• coordinate computation of communication between
  components
• Models from classical CS
• FSM, RAM (von Neumann)
• CSP (Hoare), CCS (Milner)
• Pushdown automata, Turing machine

5
Good Models

• Simple
• Amenable for development of theory to reason
• should not be too general
• Has High Expressive Power
• Provides Ability for Critical Reasoning
• Executable (for Simulation)
• Synthesizable
• Unbiased towards any specific implementation (h/w
  or s/w)
• Fits the task at hand

6
Models of Computation

• Continuous time (ODEs)
• Discrete time
• Rendezvous
• Synchronous/Reactive
• Dataflow
• Finite State
• Many, many more

Each of these provides a formal framework for
reasoning about certain aspects of embedded
systems.
7
Model Of Computation

• Definition A mathematical description that has a
  syntax and rules for computation of the behavior
  described by the syntax (semantics). Used to
  specify the semantics of computation and
  concurrency.
• Definition a set of computational components as
  well as the laws of physics that govern the
  interaction between the components

8
Model Of Computation

• An MoC allows
• To capture unambiguously the required
  functionality
• To verify correctness of the functional
  specification wrt properties
• To synthesize part of the specification
• To use different tools/environments (all must
  understand the model)
• MOC needs to
• be powerful enough for application domain
• have appropriate synthesis and validation
  algorithms

9
Usefulness of a Model of Computation

• Expressiveness
• Generality
• Simplicity
• Compilability/ Synthesizability
• Verifiability
• The Conclusion

• One way to get all of these is to mix diverse,
  simple models of computation, while keeping
  compilation, synthesis, and verification separate
  for each MoC. To do that, we need to understand
  these MoCs relative to one another, and
  understand their interaction when combined in a
  single system design.

10
Common Models of Computation

• Finite State Machines
• finite state
• no concurrency nor time
• Data-Flow
• Partial Order
• Concurrent and Determinate
• Stream of computation
• Discrete-Event
• Global Order (embedded in time)
• Continuous Time

11
Control versus Data Flow

• Fuzzy distinction, yet useful for
• specification (language, model, ...)
• synthesis (scheduling, optimization, ...)
• validation (simulation, formal verification, ...)
• Rough classification
• control
• dont know when data arrive (quick reaction)
• time of arrival often matters more than value
• data
• data arrive in regular streams (samples)
• value matters most

12
Control versus Data Flow

• Specification, synthesis and validation methods
  emphasize
• for control
• event/reaction relation
• response time (Real Time scheduling for deadline
  satisfaction)
• priority among events and processes
• for data
• functional dependency between input and output
• memory/time efficiency
• (Dataflow scheduling for efficient pipelining)
• all events and processes are equal

13
Elements of a Model of a Computation

• Set of symbols with superimposed syntax
  semantics
• textual (e.g. matlab), visual (e.g. simulink)
  etc.
• Syntax rules for combining symbols lexical
  analysis
• well structured, intuitive
• Semantics rules for assigning meaning to symbols
  and combinations of symbols - parsing
• without rigorous semantics, precise model
  behavior over time is not well defined
• ideal - full executability and automatic h/w or
  s/w synthesis
• E.g. operational semantics (in terms of actions
  of an abstract machine), denotational semantics
  (in terms of relations)

14
Simulation and Synthesis

• Simulation scheduling the execution on desktop
  computer(s)
• Synthesis scheduling the code generation in C,
  C, assembly, VHDL, etc.
• Validation by simulation important throughout
  design flow
• Models of computation enable
• Global optimization of computation and
  communication
• Scheduling and communication that is correct by
  construction

15
Models Useful In Validating Designs

• By construction
• property is inherent.
• By verification
• property is provable.
• By simulation
• check behavior for all inputs.
• By intuition
• property is true. I just know it is.
• By assertion
• property is true. Wanna make something of it?
• By intimidation
• Dont even try to doubt whether it is true
• It is generally better to be higher in this list

16
Heterogeneous Systems

• Hierarchical composition of models
• Need to understand how models relate when
  combined in a single system

Evans
17
Modeling Embedded Systems

• Functional behavior what does the system do
• in non-embedded systems, this is sufficient
• Contact with the physical world
• Time meet temporal contract with the environment
• temporal behavior important in real-time systems,
  as most embedded systems are
• simple metric such as throughput, latency, jitter
• more sophisticated quality-of-service metrics
• Power meet constraint on power consumption
• peak power, average power, system lifetime
• Others size, weight, heat, temperature,
  reliability etc.
• System model must support description of both
• functional behavior and physical interaction

18
Modeling of Time in Embedded Systems
Transformational
Reactive
Interactive
Physical Processes
Physical Processes

• Reactive systems - react continuously to their
  environment at the speed of the environment.
• Interactive systems - react with the environment
  at their own speed
• Transformational systems, which simply take a
  body of input data and transform it into a body
  of output data

19
Importance of Time in Embedded Systems Reactive
Operation

• Computation is in response to external events
• periodic events can be statically scheduled
• aperiodic events harder
• worst case is an over-design
• statistically predict and dynamically schedule
• approximate computation algorithms
• As opposed to Transformation or Interactive
  Systems

20
Reactive Operation

• Interaction with environment causes problems
• indeterminacy in execution
• e.g. waiting for events from multiple sources
• physical environment is delay intolerant
• cant put it on wait with an hour glass icon!
• Handling timing constraints are crucial to the
  design of embedded systems
• interface synthesis, scheduling etc.
• increasingly, also implies high performance

21
Real Time Operation

• Correctness of result is a function of time it is
  delivered the right results on time!
• deadline to finish computation
• doesnt necessarily mean fast predictability is
  important
• worst case performance is often the issue
• but dont want to be too pessimistic (and costly)
• Accurate performance prediction needed

22
Shades of Real-time

• Hard
• the right results late are wrong!
• catastrophic failure if deadline not met
• safety-critical
• Soft
• the right results late are of less value than
  right results on time
• more they are late, less the value, but do not
  constitute system failure
• usually average case performance is important
• failure not catastrophic, but impacts service
  quality
• e.g. connection timing out, display update in
  games
• most systems are largely soft real-time with a
  few hard real-time constraints
• (End-to-end) quality of service (QoS)
• notion from multimedia/OS/networking area
• encompasses more than just timing constraints
• classical real-time is a special case

23
Many Notions of Time
24
Timing Constraints

• Timing constraints are the key feature!
• impose temporal restrictions on a system or its
  users
• hard timing constraints, soft timing constraints,
  interactive
• Questions
• What kind of timing constraints are there?
• How do we arrange computation to take place such
  that it satisfies the timing constraints?

25
Achievable Latency Sample
x
y


D1
Longest Path for T
L
T
2m 3
L


D2
Longest Path for T
S
T
m 2
S

• TL max(I-O path, D-O path)
• TS max(D-D path, I-D path)

26
More General Timing Constraints

• Two categories of timing constraints
• Performance constraints set limits on response
  time of the system
• Behavioral constraints make demand on the rate
  at which users supply stimuli to the system
• Further classification three types of temporal
  restrictions (not mutually exclusive)
• Maximum no more than t amount of time may elapse
  between the occurrence of one event and the
  occurrence of another
• Minimum No less than t amount of time may elapse
  between two events
• Durational an event must occur for t amount of
  time
• Note Event is either a stimulus to the system
  from its environment, or is an externally
  observable response that the system makes to its
  environment

27
Maximum Timing Constraints

• A. S-S combination a max time is allowed between
  the occurrences of two stimuli
• e.g. 2nd digit must be dialed no later than 20s
  after the 1st digit
• B. S-R combination a max time is allowed between
  the arrival of a stimulus and the systems
  response
• e.g. the caller shall receive a dial tone no
  later than 2s after lifting the phone receiver
• C. R-S combination a max time is allowed between
  a systems response and the next stimulus from
  the environment
• e.g. after receiving the dial tone, the caller
  shall dial the first digit within 30s
• D. R-R combination a max time is allowed between
  two systems responses
• e.g. after a connection is made, the caller will
  receive a ringback tone no more than 0.5s after
  the callee has received a ring tone

28
More Complex Timing Constraints

• Performance constraints on a sequence of
  responses
• e.g. caller should dial 7 digits in 30s or less
  after lifting the receiver
• express using a timer
• Durational express duration of a stimulus or
  response
• e.g. to get back to the operator, press the
  button for at least 15s (but not more than 30s)
  to get the dial tone press the button for more
  than 30s.
• Two responses r1 and r2 should be heard within
  60s after a stimulus s1, and r2 should be delayed
  at least by 15s after r1 and should occur within
  30s after r1. Also, r1 r2 should last for 3s
  and 4s respectively.

29
Popular Computation Models for Embedded Systems

• Finite State Machines
• Communicating Finite State Machines
• Discrete Event
• Synchronous / Reactive
• Dataflow
• Process Networks
• Rendezvous-based Models (CSP)
• Petri Nets
• Tagged-Signal Model

30
How do the models differ?

• State finite vs. infinite
• Time untimed, continuous time, partial order,
  global order
• Concurrency sequential, concurrent
• Determinacy determinate vs. indeterminate
• Data value continuous, sample stream, event
• Communication mechanisms
• Others composability, availability of tools etc.

31
General Goals for Embedded MOC

• Allow a designer to capture the functionality of
  the system i.e. allow for system specification.
• Allow verification and/or simulation in order to
  verify the correctness of the specification
• Should be synthesizable
• Enable efficient and effective estimation of
  various properties of the system

32
Example Modeling DSP Systems
Evans
33
Conclusion

• A formal way to describe interactions between
  computational components
• An essential part of system design allows the
  move from ad-hoc to systematic design
• Many different models
• How to pick the best one?
• Can you compare different properties of models?
• Next time
• Finite State Machines and StateCharts
• Reading Harel, D. Lachover, H. Naamad, A.
  Pnueli, A. Politi, M. Sherman, R.
  Shtull-Trauring, A. Trakhtenbrot, M. STATEMATE
  a working environment for the development of
  complex reactive systems. IEEE Transactions on
  Software Engineering, vol.16, (no.4), April 1990.
  p.403-14.