1
System Modeling. Models of Computation. System Specification Languages
Alexandru Andrei
2
Models of Computation
•Basic models, specific features, comparison
•Multimodel specification
Specification Languages, Formal Verification
3
Introduction
Behavioral
Libraries
CaptureBehavior
VerifyBehavior
Arch.Libraries
CaptureArch.
Functional Level
Map Behavior toArchitecture
Verify Performance
Mapping Level
Refine HW/SWmicroArch
Link to Hw/SwImplementation
Link to microArchVerification
Architectural Level
4
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
5
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
6
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
7
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
8
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
9
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
10
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
11
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
12
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)
13
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)
14
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
15
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)
16
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
17
Communication primitives
• Unsynchronized
• Read-modify-write
• Unbounded FIFO buffered
• Bounded FIFO buffered
• Petri net places
• Randezvous (single or multiple)
18
Discrete-Event MOC
• Global event queue, totally ordered time• Verilog, VHDL languages
• simultaneous events present a challenge for discrete-event MOCs
A
B C A
B Ct
tt
t
A
B C
t
t+dt
19
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
20
Dataflow Process Networks (cont)
• 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
A C
B
D A B C D
21
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
22
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
23
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
24
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)
25
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
26
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
27
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
28
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)
29
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
30
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)
31
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
32
Functional Behavior
• The functional behavior is determined by the specified transition relation (input_set, previous_state, output_set, next_state)
33
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)
34
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
35
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)