The STATEMATE Semantics of Statecharts D. Harel and A. Naamand

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

2. 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 Fall 2001 CS599

3. 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 Fall 2001 CS599

4. 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.) Fall 2001 CS599

5. 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 Fall 2001 CS599

6. 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 Fall 2001 CS599

7. 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 Fall 2001 CS599

8. 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 Fall 2001 CS599

9. Static Reactions • Event/action  orthogonal AND-subset Fall 2001 CS599

10. 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 Fall 2001 CS599

11. 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) Fall 2001 CS599

12. 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 Fall 2001 CS599

13. 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 Fall 2001 CS599

14. 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 Fall 2001 CS599

15. Full configuration (all parents and root) Basic configuration Fall 2001 CS599

16. 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 Fall 2001 CS599

17. 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 Fall 2001 CS599

18. AND Fork Join Fall 2001 CS599

19. OR condition, selection and junction condition Fall 2001 CS599

20. CT • Initial CT • Continuation CT • Full CT is an initial CT and possibly several continuation CTs • See figures Fall 2001 CS599

21. Full CT Initial {t1, t2} Continuation CT {t5, t3} and {t5, t4} Fall 2001 CS599

22. Part II by Bob Chen Fall 2001 CS599

23. Fall 2001 CS599

24. DEALING WITH HISTORY • Algorithm Fall 2001 CS599

25. 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} Fall 2001 CS599

26. 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 Fall 2001 CS599

27. DEALING WITH HISTORY • Clear history of S first, or • Enter S via its history first • Answer is latter • hc! = history clear Fall 2001 CS599

28. 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 Fall 2001 CS599

29. SCOPE OF TRANSITIONS • Scope of t1 is S • Implies exiting states B2, B, A, C either C1 or C2 Fall 2001 CS599

30. SCOPE OF TRANSITIONS • Scope of t4 is U • Implies exiting states W & V • Entering states V & W • U is not exited Fall 2001 CS599

31. CONFLICTING TRANSITIONS • Two CTs are in conflict • There are common state that would be exited if any one of them were to be taken. Fall 2001 CS599

32. 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 Fall 2001 CS599

33. 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 Fall 2001 CS599

34. NONDETERMINISM • STATEMATE simulation tool • Wait selection from user • Dynamic, tries every possibility exhaustively • Nondeterminism • Two or more conflicting CTs with same priority Fall 2001 CS599

35. BASIC STEP ALGORITHM • Schematic description of the algorithm that executes a single step Fall 2001 CS599

36. BASIC STEP ALGORITHM Fall 2001 CS599

37. BASIC STEP ALGORITHM • Stage 2 Compute the contents of the step • Stage 3 Execute the CTs and SRs • Example Fall 2001 CS599

38. BASIC STEP ALGORITHM • Possible Steps Fall 2001 CS599

39. Part III by Xie Fall 2001 CS599

40. Two Models of Time 1. Synchronous time model 2. Asynchronous time model Fall 2001 CS599

41. Two Models of Time (2) Synchronous time modelassumes 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. Fall 2001 CS599

42. 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. Fall 2001 CS599

43. 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. Fall 2001 CS599

44. 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. Fall 2001 CS599

45. 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. Fall 2001 CS599

46. 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. Fall 2001 CS599

47. 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. Fall 2001 CS599

48. 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. Fall 2001 CS599

49. 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. Fall 2001 CS599

50. 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. Fall 2001 CS599