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)