Presentation is loading. Please wait.

Presentation is loading. Please wait.

Analyzing and Verifying Esterel Programs Taisook Han 2009-12-19, Division of Computer Science, KAIST.

Similar presentations

Presentation on theme: "Analyzing and Verifying Esterel Programs Taisook Han 2009-12-19, Division of Computer Science, KAIST."— Presentation transcript:

1 Analyzing and Verifying Esterel Programs Taisook Han 2009-12-19, Division of Computer Science, KAIST

2 Contents  Introduction to Esterel  Over-approximated CFGs (Control Flow Graphs)  A Logical Semantics with Separating Micro- and Macro-steps  Summary of Execution Traces  Conclusion 2009. 12. 19Taisook Han2

3 2009. 12. 19Taisook Han3 Introduction to Esterel

4 Esterel  Introduction  A synchronous programming language by Gérard Berry at 1983  Well-adopted to complex control-dominant reactive systems  Man-machine interfaces or supervision programs are typical examples  Characteristics  Synchronous model of time  Time is divided into a sequence of discrete logical time units  Program executions are synchronized to an external clock  Imperative and concurrent language  An Esterel program can be compiled into both software (C, SystemC) and hardware (Verilog, VHDL) 2009. 12. 19Taisook Han4 Reactive systems are embedded systems that instantly react to environmental changes Instant

5 Synchronization & Preemption  Synchronization can be controlled by pause stmt  A pause stmt indicates the end of the current instant  All operations within an instant are performed simultaneously  Reset signals when a new instant starts  Preemption between threads  Strong preemption  Halt the remaining task immediately, and perform the preempted task  Weak preemption  After finishing the remaining task in the current instant, perform the preempted task 2009. 12. 19Taisook Han5 Signal statuses are Preserved only for an instant ⇒ suspend stmt ⇒ trap & exit stmt

6 Kernel Language of Esterel StatementsIntuitive Meanings nothing Do nothing pause Consume a clock tick (finish the current instant) emit S Emit a signal S (change the status of S to present) p ; q After finishing p, run q instantly p || q Run both p and q simultaneously loop p end Repeat p infinitely signal S in p end Declare a new local signal S ; it is valid only within p present S then p else q end Test the status of the signal S suspend p when S Suspend p while S is present trap T in p end Declare a new exception T ; it is valid only within p exit T Raise exception T 2009. 12. 19Taisook Han6

7 Goals  Synchronization and preemption in Esterel make it difficult  To represent the exact behavior  To analyze, verify, or detect errors  To analyze an Esterel program, analyzers can  Describe when and how synchronization occurs  Represent implicit interferences between threads  Specify and detect errors of Esterel programs  We want to develop useful static analysis bases on Esterel 2009. 12. 19Taisook Han7

8 2009. 12. 19Taisook Han8 Over-approximated CFGs

9 Example 1: trap U in 2: trap T in 3: emit A; pause; exit T 4: || 5: emit B; pause; exit U 6: end trap 7:emit C 8: end trap 2009. 12. 19Taisook Han9 Start trap U trap T || emit Aemit B pause exit Texit U end of || end of trap T end of trap U End emit C U T T U U

10 Schizophrenic Stmt. Detection Algorithm 2009. 12. 1910Taisook Han loop … … end loop emit S; First-surface Last-surface Schizophrenic Emit Statements An emit statement is executed more than once in an instant.

11 Example 2009. 12. 1911Taisook Han loop_start loop_end parallel_start parallel_end test(I) pause test(J) emit(X) pause emit(O) test_end(I) test_end(J) loop_start loop_end parallel_start parallel_end test(I) pause test(J) emit(X) pause emit(O) test_end(I) test_end(J) Schizophrenic Emit Statement

12 Experiments ProgramsLOC# of loops Schizophrenic Signal Declarations # of candidates Previous work Our resultManual check atds1006225516950 mca20053541380000 mejia361210000 tcint357321100 ww360831111 dlx334375500 fbus285760000 Total7673442231661 12

13 2009. 12. 19Taisook Han13 A Logical Semantics with Separating Micro- and Macro-steps

14 A Logical Semantics  Separation of micro-steps and macro-steps  Moves ( ) : computations within an instant (Micro-steps)  Instant changes ( ): computations across instants (Macro-steps)  Formal specification and detection of errors  Postpone error-declarations until instant changes  We define execution processes using configurations and their transitions 2009. 12. 19Taisook Han14 Ignore inconsistent configurationsApply all proper moves

15 Error Detection  Attach the location information to assumed or emitted signals  Where the signal is assumed or emitted?  Location information helps to detect errors  Basic procedure of error detection  Micro-steps: mark the configurations having errors  Macro-steps: check if the marked configuration is consistent  Target errors  Instantaneous loops  Schizophrenic signal decl & schizophrenic parallel stmt  Multiple emission of a single signal 2009. 12. 19Taisook Han15

16 2009. 12. 19Taisook Han16 Summary of Execution Traces

17 Goal: Summary of Execution Traces  We want to get a new representation that comprehends all possible execution scenarios of a given Esterel program.  We call the representation the behavior of a program.  We summarize execution traces of pure Esterel programs based on abstract interpretation. 2009. 12. 19Taisook Han17

18 Safety property verification using observer ProgramObserver ∥ Model Checker (XEVE) SpecToObs Safety Property Model Observer: A program that generates a warning signal when a target program does not satisfy given safety property 2009. 12. 19Taisook Han18

19 Safety property verification using behavior ProgramObserver ∥ Checker SpecToObs Safety Property Behavior time signals status 2009. 12. 19Taisook Han19

20 CFG & Atomic terms  Esterel semantics is composed of control-flows and data-flows.  We use a CFG to denote the control-flow and define CFG- based denotational semantics.  Since data-flows are influenced by time progress and changes of signal status, we preserve such meanings as atomic terms.  Each edge represents a control-flow between program points and labeled by an atomic term.  Each node represents the program points after executing the atomic terms on the incoming edge. 2009. 12. 19Taisook Han20

21 Example module Ex1: loop pause; emit a; pause; end loop end module 2009. 12. 19Taisook Han21

22 More Example module Ex3: input s; output a, b, c; emit a; loop present s then emit b; pause; else pause; emit c; end present; end loop end module traces after the second iteration 2009. 12. 19Taisook Han22

23 Trace vs. Behavior     2009. 12. 19Taisook Han23

24 Concrete States vs. Abstract States  Concrete State (CStates)  An abstract state at a program point is composed of  The time at the point  The behavior summarized up to the point until the time  The execution condition if the point is in a conditional branch  Abstract State (AStates) 2009. 12. 19Taisook Han24

25 Observation (Symbolic Tick)  The instant to run a statement may not be unique because a program can reach a certain statement through many different paths.  We need a new time unit to summarize several instants. 2009. 12. 19Taisook Han25

26 Symbolic Tick Domain 2009. 12. 19Taisook Han26

27 Symbolic Tick Domain 2009. 12. 19Taisook Han27

28 Widening Operator  Widening operator captures the repeated actions in a single loop. time * ** * *  2009. 12. 19Taisook Han28

29 Example (Widening) 2009. 12. 19Taisook Han29

30 Example: a small bus arbiter  A bus arbiter of 3 cells 2009. 12. 19Taisook Han30

31 Cell module (a small bus arbiter) Taisook Han31

32 Evaluation  We summarize program traces in the general form so that programmers can easily figure out the program validity without execution and debugging.  The behavior of the cell program 2009. 12. 19Taisook Han32

33 Evaluation ( Arbiter)  Analysis results for arbiter growth  Safety property: there is at least one response incase of any request.  The size of the observers is proportional to the number of cells. 2009. 12. 19Taisook Han33

34 Conclusion 2009. 12. 19Taisook Han34

35 Summary  Over-approximated CFGs  Do not use any additional data structure or handlers  Show program structures as is  Our CFGs are proper to analyze programs via graph reachability  A new logical semantics with separating micro-steps (moves) and macro-steps (instant changes)  We specify some well-known errors of Esterel program  Instantaneous loop, schizophrenia ( signal, parallel ), multiple emission  A new representation of Esterel programs: “behavior”  We design new domains and CFG-based denotational semantics for the sake of path-sensitive analysis.  We devise widening operators that condense regularly-repeated actions. 2009. 12. 19Taisook Han35

36 Conclusion  Our CFGs  Approximated edges allow to represent all possible execution paths including implicit control flows  Simple construction and structure make it easy to apply graph-based program analyses  Our semantics  Separating micro- and macro-steps helps to specify precise behaviors of Esterel programs and to detect well-known errors  Presented CFGs and semantics can be a good framework for analyzing Esterel programs  Our representation  New domains and operators summarize execution traces of pure Esterel programs based on abstract interpretation. 2009. 12. 19Taisook Han36

37 Q or C Thanks! 2009. 12. 19Taisook Han37

Download ppt "Analyzing and Verifying Esterel Programs Taisook Han 2009-12-19, Division of Computer Science, KAIST."

Similar presentations

Ads by Google