Transcript System Modeling. Models of Computation. System Specification Languages Alexandru Andrei Models of Computation •Basic models, specific features, comparison •Multimodel specification Specification Languages, Formal Verification.

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