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

1. System Modeling. Models of Computation. System Specification LanguagesAlexandru Andrei

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

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

4. 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 Introduction

5. 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 MOCs Basic Concepts

6. 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 Modeling with MOCs

7. 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 Modeling with MOCs (cont)

8. 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 Modeling with MOCs (cont)

9. 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 The Tagged-Signal Model

10. 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 Signals, tags, events

11. 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 Processes

12. 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) Processes (cont)

13. 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) Process composition

14. 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 Process composition (example)

15. 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) Concurrency and Communication

16. 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 Treatment of Time

17. Unsynchronized Read-modify-write Unbounded FIFO buffered Bounded FIFO buffered Petri net places Randezvous (single or multiple) Communication primitives

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

19. 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 Dataflow Process Networks

20. 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 Dataflow Process Networks (cont) C D A A B C D B

21. 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 Synchronous/Reactive

22. 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 Synchronous/Reactive (cont)

23. 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 Communicating Sync. FSM

24. 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) Communicating Sync. FSM (cont)

25. 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 Communicating Sync. FSM (cont)

26. 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 Process Algebrae

27. 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 Timed Automata

28. 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) Codesign FSM

29. 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 CFSM Communication

30. 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) CFSM Networks

31. 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 Timing Behavior

32. The functional behavior is determined by the specified transition relation(input_set, previous_state, output_set, next_state) Functional Behavior

33. 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) Functional Behavior (cont)

34. 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 CSFMs and Process Networks

35. 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) Conclusions