System Modeling. Models of
Computation. System
Specification Languages
Alexandru Andrei
1
Models of Computation
•Basic models, specific features,
comparison
•Multimodel specification
Specification Languages, Formal Verification
2
Introduction
Behavioral
Libraries
Arch.
Libraries
Functional Level
Capture
Behavior
Verify
Behavior
Map Behavior to
Architecture
Refine HW/SW
microArch
Link to Hw/Sw
Implementation
Capture
Arch.
Verify
Performance
Mapping Level
Link to microArch
Verification
Architectural
Level
3
Introduction
• System design goals: time-to-market, safety,
low cost, reliability
• Specification - need for an unambiguos
formalism to represent design choices and
specifications
• Need for heterogeneity, unification for
optimization and verification purposes
4
MOCs Basic Concepts
• A MOC is composed of:
– description mechanism (syntax)
– rules for computation of the behavior
(semantics)
• Compactness of description, fidelity to
design style, ability to synthetize and
optimize the behavior to an implementation
5
Modeling with MOCs
• Allow distributed system description
(collection of modules)
• Rules dictating how modules compute
(function)
• Rules specifing the communication between
modules
• Function and communication may not be
described completely separately
6
Modeling with MOCs (cont)
• MOCs are implemented by a language and its
semantics (operational or denotational)
• MOCs describe:
– the kinds of relations that are possible in a denotational
semantics
– how the abstract machine behaves in a operational semantics
– how individual behavior is specified and composed
– how hierarchy abstracts the composition
– communication style
7
Modeling with MOCs (cont)
• Two levels of abstraction
– High level: processes and their interaction using
signals (TSM); denotational view; processes
describe both functional and communication
behavior
– Lower level: general primitives for function
and timing (the refinement of TSM processes);
operational view
8
The Tagged-Signal Model
• Formalism for describing aspects of MOCs
for embedded system specification
• A semantic framework for comparing and
studying and comparing of MOCs
• Very abstract: describing a particular model
involves imposing further constraints that
make more concrete
9
Signals, tags, events
• Event: a value/tag pair -> the fundamental
entity; tags usualy denote temporal behavior
• Signal: a set of events (abstract aggregation)
• Process: a relation on signals; set of n-tuples
of signals
• Different models of time -> different order
relations on the set of tags
• Timed systems, untimed systems
10
Processes
• Set of n-tuples of signals
• A signal satisfies a process if it belongs to the set behavior of the process
• A process is a set of possible behaviors
• Process in a systems are concurent and the
constraints imposed on the tags define the
communication between them
• The environment can be modeled as a process
11
Processes (cont)
• Signal partitions: inputs and outputs
(relation between inputs and outputs)
• Functional process - given input signals,
output is determined (injective)
• Completely specified process: for all the
inputs there is a unique behavior (bijective)
12
Process composition
• Assumption: all the processes are defined on the same set
of signals
• Intersection of the constraints imposed on each signal
• Which properties are preserved by composition
– inherent property: it can be shown formally to hold for all
specifications described using that model
– the property can be verified syntactically for a given specification
(it can be shown in polynomial time to hold for that specification)
– the property must be verified semantically for a given specification
(it can be shown only by execution of the specification for all
imputs that can occur)
13
Process composition (example)
• The functionality is inherent for dataflow networks, it
does not need to be checked for every model described
using dataflow nets
• For FSMs, even if the components are functional and
completely specified, the composition may be
incompletely specified- a syntactical check for is
proven to show if the result is completely specified
• For Petri nets, functionality is difficult to prove:
exhaustive simulation is needed to check it
14
Concurrency and Communication
• Communication can be:
– explicit - forcing an order on the events (sender
and receiver processes)
– implicit - sharing of tags (common time scale),
forces a common partial order of the events
• Time - a larger role in the embedded
systems (two events are synchronous if they
have the same tag)
15
Treatment of Time
• Discrete-event systems:a timed system where tags in each
signal are order-isomorphic with the natural numbers
• Synchronous system: every signal in system is
synchronous with every other signal in the system
• Discrete-time system: a sybchronous discrete-event system
• Asynchronous system: no two events can have the same
tag
– asynchronous interleaved - tags are totally ordered
– asynchronous concurrent - tags are partially ordered
16
Communication primitives
•
•
•
•
•
•
Unsynchronized
Read-modify-write
Unbounded FIFO buffered
Bounded FIFO buffered
Petri net places
Randezvous (single or multiple)
17
Discrete-Event MOC
• Global event queue, totally ordered time
• Verilog, VHDL languages
• simultaneous events present a challenge for
discrete-event MOCs
t
t
t
A
B
C
A
B
t
C
t
A
B
t+dt
C
18
Dataflow Process Networks
• Directed graph where the nodes (actors) represent
computations and arcs represent totally ordered sequences
of events (streams)
• Nodes can be language primitives specified in another
language (C)
• A process can use partial information about its input
streams to produce partial information at output ->
causality without time
• Each process is decomposed into a indivisible sequence of
firings, each firing consumes and produces tokens
19
Dataflow Process Networks (cont)
C
A
D
A
B
C
D
B
• A cycle in the schedule returns the graph in the original state
• Synchronous dataflow: processes consume and produce a
finite number of tokens for each firing
• Tagged token model: partial order of tokens is explicitly
carried in them
20
Synchronous/Reactive
• Synchronous
– All events are synchronous (all signals have identical
tags)
– Tags are totally ordered and globally available
– All signals have events at all clock ticks (unlike discrete
event model)
– At each cycle the order of event processing may be
determined by data precedences
– Inefficient for systems where events do not occur at the
same rate in all signals
21
Synchronous/Reactive (cont)
• Synchronous/Reactive
– set of concurrently-executing synchronized modules
– modules communicate through signals which are either
present or absent in each clock tick
• Computation is delay-free, arbitrary interconnection of
processes is possible
• Verifing causality (non-contradictory and deterministic) is
a fundamental challenge (a program may have no or
multiple interpretations)
• Can be translated into finite state descriptions or compiled
directly in hardware
22
Communicating Sync. FSM
• The amount of memory, halting and performance questions
are always decidable
• In practice it could be prohibitively expensive
• A traditional FSM consists of:
– a set of input symbols
– a set of output symbols
– a finite set of states
– an output function
– a next state function
23
Communicating Sync. FSM (cont)
• Synchronous: input and output symbols are well defined
(set of events with a given tag)
• Problematic for modeling concurrency or large memories
because of state explosion
• Mechanisms used to reduce the size of automata:
– hierarchy: being in state a means that the machine is in of the
states enclosed by a
– concurrency: two state machines are viewed being simultaneously
active
– non-determinism: reduce the complexity by abstraction (during
verification of a component, other comp can be modeled non-det)
24
Communicating Sync. FSM (cont)
• Harel’s statecharts model uses a sync.
concurrent model
• The set of tags is a totally ordered countable
set that denotes a global clock for the
system
• Events at a clock tick can trigger state
transitions in other parallel state machines
at the same clock
25
Process Algebrae
• Synchrony is hard to implement and is slow, so
more loosely coupled async FSM models have
evolved
• The behavior of each process is modeled by a
Labeled Transition System (arcs are labeled with
signals, the state transition activity imposes a total
order of signals)
• Communication based on randezvous
• Completely interleaved view of concurrent actions
26
Timed Automata
• Time as a continuous quantity to avoid the
state explosion in sync or async FSMs
• The state of a TA is the state of a FA plus a
set of clocks (real value)
• The state space is infinite, it admits a finite
state representation by partitioning into
equivalence classes
27
Codesign FSM
• Combine aspects of other MOCs preserving formality and
efficiency of implementation
• Each CFSM is an extended FSM extended to support
asynchrony and data handling
– a FSM part that has a set of inputs, outputs and states, a transition
relation, an output relation
– a data computation part in the form of references in the transition
relation to external, instantaneous (combinatorial) functions
– a locally sync behavior (each CFSM executes a transition by
producing a single output based on a single input in zero time)
– a globally async behavior (each CFSM reads inputs, executes a
transition and produces outputs in a finite amount of time)
28
CFSM Communication
• CFSMs communicate using signals (inputs,
outputs, state signals)
• The event is produced by a sender and
consumed by a receiver
• The input events determine when a CFSM
may react
• A CFSM with at least one input is runnable
29
CFSM Networks
• A net is a set of connections on the same output
• Multicast communication (one to many)
• A network is a set of CFSMs and nets; the behavior depends
both on the individual behavior and on the global system
• It can be implemented as:
– a set of CFSMs in software, a compiler, an OS and a
microprocessor
– a set of CFSMs in hardware (FPGA), a hardware initialization
scheme and a clocking scheme
– the interface between them (polling or interrupts to pass events
from hardware to software, a memory-mapped scheme to pass
from software to hardware)
30
Timing Behavior
• Global scheduler controls the interaction of the
CFSMs
• The scheduler decides which CFSM to run and
executes them
• During execution, a CFSM reads inputs, performs
computation, possibly changes state and writes
outputs
• Each CFSM execution can be associated with a
single transition point in time
31
Functional Behavior
• The functional behavior is determined by
the specified transition relation (input_set,
previous_state, output_set, next_state)
32
Functional Behavior (cont)
• At each execution:
– reads an input assignment
– looks for a transition matching the read input
and the present state
– if the transition is found: consumes the inputs,
compute next_state, writes output_set
– if it is not found, does not consume any inputs,
nor it calculates nor writes anything (empty
execution)
33
CSFMs and Process Networks
• CSFM are an async Extended FSM model
• Communication is via bounded non-bloking buffers
• CSFM can be modeled with an LTS in which each label
means presence or absence test of several signals
• Signals are distinguished between inputs and outputs
• The semantics is defined based on a global explicit notion
of time (imposing total ordering of events)-> synchronous
with relaxed timing
• Providing explicit handshaking or using scheduling
techniques so “critical” events are never lost
34
Conclusions
• Far from having a single agreed MOC
• Heterogeneity at the MOC level is an
essential argument
• CFSM is expressive enough to capture most
practical embedded systems (local
synchrony, global asynchrony, unbounded
buffers)
35