1. 1 System Modeling. Models of Computation. System Specification Languages Alexandru Andrei

2. 2 Models of Computation Basic models, specific features, comparison Multimodel specification Specification Languages, Formal Verification

3. 3 Introduction Behavioral Libraries Capture Behavior Verify Behavior Arch. Libraries Capture Arch. Functional Level Map Behavior to Architecture Verify Performance Mapping Level Refine HW/SW microArch Link to Hw/Sw Implementation Link to microArch Verification Architectural Level

4. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 17 Communication primitives Unsynchronized Read-modify-write Unbounded FIFO buffered Bounded FIFO buffered Petri net places Randezvous (single or multiple)

18. 18 Discrete-Event MOC Global event queue, totally ordered time Verilog, VHDL languages simultaneous events present a challenge for discrete-event MOCs A BCA BC t t t t A BC t t+dt

19. 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. 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 ABC D

21. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 32 Functional Behavior The functional behavior is determined by the specified transition relation (input_set, previous_state, output_set, next_state)

33. 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. 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. 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)