Week 6Fall 2001 CS5991 The STATEMATE Semantics of Statecharts D. Harel and A. Naamand Ahmad Alsawi 1-4 Bob Chen 5-8 Dapeng Xie 9-11

Week 6Fall 2001 CS5992 Introduction to STATEMATE STATEMATE is a system Statechart is a language (executable semantics) Initial version 10 years ago Simulation, dynamic tests, and code generation tools of STATEMATE since ‘87

Week 6Fall 2001 CS5993 STATEMATE Design Objectives Intended for “real engineers in real systems” Support different styles of modeling Simple Intuitive Straightforward –To enable fast simulation of models –To generate s/w and h/w codes

Week 6Fall 2001 CS5994 Basics (1) Used for modeling reactive systems Based on structured analysis paradigm –Activity-chart (hierarchical data-flow diagram) Functional description: Activities, data elements, and signals Behavior desc.: Control-activities Functional semantics is dynamically noncommitting –Only activities can happen –But no will happen, when, or why (behavior desc.)

Week 6Fall 2001 CS5995 Basic (2) Activity's statechart controls dynamics of –Sub activities –Data flow Activate and deactivate activities Write, read, and update data Send and sense signals Defining semantics of activity-chart is the core for how the tool works

Week 6Fall 2001 CS5996 Terminology State Types –OR-states have XOR substates –AND-states have AND substates –Basic state no substates Root: no parent state Event e Condition c Action a

Week 6Fall 2001 CS5997 Syntax General syntax: e[c]/a All are optional Special e, c, and a –Start(P), st!(P) causes the activity P to start –Entered(S), en(S) is an event Events and conditions are closed under Boolean ops: or, and, and not

Week 6Fall 2001 CS5998 Timing of Conditions Actions associated with entrance to S are executed in the step in which S is entered same as Actions on the transition leading into S Events are sensed one step after it happened –Ex(S) is sensed one step after S was existed

Week 6Fall 2001 CS5999 Static Reactions Event/action  orthogonal AND-subset

Week 6Fall 2001 CS59910 Behavior Run: a set of possible behavior –A series of snapshots of system responses to external environment stimuli Status: a snapshot of system situation Step: transition between two snapshots

Week 6Fall 2001 CS59911 Some Timing Issues An activity A is active within state S, means throughout S Schedule(a,d): d is time units Timeout(e, d) The execution takes zero time The time between two consecutive steps is excluded from step semantics (this is part of user control)

Week 6Fall 2001 CS59912 Principles in Defining the semantics Reactions to events, and changes occurred within a step, can be sensed only after the step Events live in the step following their occurrence, for one step only. Calculations are based on situation at the beginning of the step A maximal subset of nonconflicting transactions and SRs is always executed

Week 6Fall 2001 CS59913 Configuration A maximum set of states (C) that the system can be simultaneously in C contains root state If C contains OR-state A, it must contain only one of A’s substates If C contains AND-state A, it must contain all of A’s substates The only states in C are the above no extra

Week 6Fall 2001 CS59914 Configuration (cont) Configurations are closed upward –system in state A, and it must be in A’s parent state Basic configuration is a maximal set of basic states that the system can be in simultaneously

Week 6Fall 2001 CS59915 Basic configuration Full configuration (all parents and root)

Week 6Fall 2001 CS59916 Racing X:=X+1; Y:=X*5; if …. else Semicolon means “do this in parallel” not “do this in sequence” In this case, no problematic racing –The value of x is changed at the end of step

Week 6Fall 2001 CS59917 Compound Transitions (CT) Execution of a setup must lead to a legal configuration Statechart cannot be in non basic state without being able to enter appropriate substate CT is full transitions, combined triggers and concatenated actions

Week 6Fall 2001 CS59918 AND Fork Join

Week 6Fall 2001 CS59919 OR condition, selection and junction condition

Week 6Fall 2001 CS59920 CT Initial CT Continuation CT Full CT is an initial CT and possibly several continuation CTs See figures

Week 6Fall 2001 CS59921 Full CT Initial {t1, t2} Continuation CT {t5, t3} and {t5, t4}

Week 6Fall 2001 CS59922 Part II by Bob Chen

Week 6Fall 2001 CS59923

Week 6Fall 2001 CS59924 DEALING WITH HISTORY Algorithm

Week 6Fall 2001 CS59925 DEALING WITH HISTORY T1 to target state: B1 {t1, t2} T1 to target state: B2{t1, t3} T1 to target state: B{t1, t4, t2}

Week 6Fall 2001 CS59926 DEALING WITH HISTORY t1, t2 has priority over t3 C1 is false t3 is executed C2 is false it is a loop STATEMATE will detective a loop

Week 6Fall 2001 CS59927 DEALING WITH HISTORY Clear history of S first, or Enter S via its history first Answer is latter hc! = history clear

Week 6Fall 2001 CS59928 SCOPE OF TRANSITIONS CT is enabled –At the beginning of the step the system is in all the states of its source set & if its trigger is true CT often pass different levels of statechart hierarchy tr –scope of a CT the lowest OR-state in the hierarchy of states that is a proper common ancestor of all the sources and targets of tr –Includes nonbasic states that are explicit sources or targets of transition arrow appearing in tr

Week 6Fall 2001 CS59929 SCOPE OF TRANSITIONS Scope of t1 is S Implies exiting states B2, B, A, C either C1 or C2

Week 6Fall 2001 CS59930 SCOPE OF TRANSITIONS Scope of t4 is U Implies exiting states W & V Entering states V & W U is not exited

Week 6Fall 2001 CS59931 CONFLICTING TRANSITIONS Two CTs are in conflict –There are common state that would be exited if any one of them were to be taken.

Week 6Fall 2001 CS59932 CONFLICT - example t1 & t2 are in conflict. –They would each imply exiting state A. t4 is in conflict with all of t1, t2, t3. –When t4 is taken system must be in U and also in one of its substates. Therefore t1, t4 cannot both be taken in the same step

Week 6Fall 2001 CS59933 TREATING CONFLICTS Two kinds of conflict in the example –First trigger of both t1 & t2, nondeterminism –Second conflict, t4 has priority over t1, t2, t3, no nondeterminism –Priority: outside-in tx and ty be conflict transition Sx & Sy be their scope If Sx = Sy then tx & ty has equal priority, nondeterministic

Week 6Fall 2001 CS59934 NONDETERMINISM STATEMATE simulation tool –Wait selection from user –Dynamic, tries every possibility exhaustively Nondeterminism –Two or more conflicting CTs with same priority

Week 6Fall 2001 CS59935 BASIC STEP ALGORITHM Schematic description of the algorithm that executes a single step

Week 6Fall 2001 CS59936 BASIC STEP ALGORITHM

Week 6Fall 2001 CS59937 BASIC STEP ALGORITHM Stage 2 Compute the contents of the step Stage 3 Execute the CTs and SRs Example

Week 6Fall 2001 CS59938 BASIC STEP ALGORITHM Possible Steps

Week 6Fall 2001 CS59939 Part III by Xie

Week 6Fall 2001 CS59940 Two Models of Time 1. Synchronous time model 2. Asynchronous time model

Week 6Fall 2001 CS59941 Two Models of Time (2) Synchronous time model assumes that system executes a single step every time unit, reacting to all the external changes that occur in the one time unit that elapsed since the completion of the previous step.

Week 6Fall 2001 CS59942 Two Models of Time (3) Asynchronous time model assumes that the system reacts whenever an external change occurs, allowing for several external changes to occur simultaneously and, most importantly, allowing several steps to take place within a single point in time.

Week 6Fall 2001 CS59943 Two Models of Time (4) Superstep: a collection of steps which can take place within a single point in time. In the simulation and dynamic test tools, various code generators, different circumstances, the way the two models of time are reflected in the execution differs slightly among them.

Week 6Fall 2001 CS59944 Two Models of Time (5) This paper will concentrate on the way time is treated in the simulation tool. The synchronous time model fits systems that are highly synchronous. The asynchronous time model fits most kinds of asynchronous systems.

Week 6Fall 2001 CS59945 Two Models of Time (6) For example, in asynchronous time model, there are several different GO commands that let the user control the advance of time during simulation.

Week 6Fall 2001 CS59946 Two Models of Time (7) For example, in asynchronous time model, there are several different GO commands that let the user control the advance of time during simulation.

Week 6Fall 2001 CS59947 Two Models of Time (8) GO-REPEAT: the most important and frequently used GO command. GO-REPEAT does not increment the internal clock, so that many steps may be executed at the same point in time.

Week 6Fall 2001 CS59948 Two Models of Time (9) GO-REPEAT command may result in an infinite loop. There are several other GO commands, like GO- ADVANCE, GO-STEP, GO-NEXT, and GO- EXTENDED.

Week 6Fall 2001 CS59949 Two Models of Time (10) Dynamic test tools Hardware Code generator: 1. RTL code style 2. Behavioral code style Software code generator: 1. CPU clock time. 2. simulated clock.

Week 6Fall 2001 CS59950 Racing condition Reason: Racing conditions arise when the value of an element is modified more than once or is both modified and used at a single point in time.

Week 6Fall 2001 CS59951 Racing condition (2) More precise description: A race situation is one in which, had we executed the enabled transitions in a different order, we might have obtained different results in one or more of the data-items or conditions.

Week 6Fall 2001 CS59952 Racing condition (3) Sample: t1: e / f t2: f / x: =5 t3: f t4: /Y:=x+1

Week 6Fall 2001 CS59953 Multiple Statecharts Defination: Multiple statechart applies in all its aspects to several statecharts running simultaneously, which in STATEMATE occurs when they represent activities that happen to be active concurrently.

Week 6Fall 2001 CS59954 Multiple Statecharts (2) Multiple active statecharts are treated basically as orthogonal componets at the highest level of a single statechart, except that when one of the statecharts becomes nonactive, the other charts continue to be active.

Week 6Fall 2001 CS59955 Multiple Statecharts (3) In the asynchronous time model, the steps in multiple statecharts are carried out in synchronization, just as they would have if they were represented as orthogonal components of one big statechart. In the synchronous time model, on the other hand, each chart may have its own clock, telling it when to execute a step.

Week 6Fall 2001 CS59956 Strength Nice formal (theoretical) approach Good marketing for STATEMATE! Covered the topic with many examples and figures Quite valuable appendix

Week 6Fall 2001 CS59957 Weakness Failed to reference the relationship it has with automata theory Lack of definitions for many terms Lack of definitions for figure notations

Week 6Fall 2001 CS59958 Relevance Statechart modeling addresses many issues related to embedded software: –environmental triggers and events –Concurrency –Timing –Non determinism –Etc