1. Constraints Assisted Modeling and Validation Presented in CS294-5 (Spring 2007) Thomas Huining Feng Based on: [1]Constraints Assisted Modeling and Validation in Metropolis Framework. Guang Yang, Harry Hsieh, Xi Chen, Felice Balarin, Alberto Sangiovanni-Vincentelli. [2]Logic of Constraints: A Quantitative Performance and Functional Constraint Formalism. Xi Chen, Harry Hsieh, Felice Balarin, Yosinori Watanabe.

2. Design in Block Diagram Q-mgr real time Q-mgr power Q-mgr memory ProcessConnectionMediumQuantity Manager 2

3. Producer-Consumer Model process X name P 1 process X name P 2 process X name C medium S name M process X { port Read R; port Write W; void thread() { while (true) { x = R.read(); z = foo(x); W.write(z); } interface Read extends Port { update int read(); eval int nItems(); } interface Write extends Port { update int write(int data); eval int nSpace(); } medium S implements Read, Write { int n, space; int[] storage; int read() { … } int nItems() { … } int write(int data) () { … } int nSpace() { … } } 3 event stream

4. Mapping Function to Architecture System FunctionSystem Architecture BUS CPU 1 CPU 2 CPU 3 Mapping Implementation 4

5. Motivation System is nicely structured (opposed to arbitrary C++ code) – Single thread of control in a process – No sharing between processes – Model of computation determined by (passive) media Not only correct behavior is important, but also other aspects: – Virtual time – Real time – Power consumption (for embedded devices) – Memory consumption Quantity managers annotate events; properties can be formally checked and dynamically verified. Not only verify properties, but also enforce properties. 5

6. LTL (Linear Temporal Logic) L ::= a| ¬ L | L 1  L 2 | L 1  L 2 | X L | G L | F L | L 1 U L 2 | L 1 R L 2 a is a literal X – next G – global F – future U – until R – release L 1 U L 2 : L 1 R L 2 : Negated normal form: Contains only ¬   X U R, and ¬ only appears before literals. – F L ≡ true U LG L ≡ ¬ F ¬ L – ¬ X L ≡ X ¬ L – ¬ ( L 1 R L 2 ) ≡ ¬ L 1 U ¬ L 2 – ¬ ( L 1 U L 2 ) ≡ ¬ L 1 R ¬ L 2 L2L2 L2L2 L2L2 L2L2 L2L2 L2L2 L1  L2L1  L2 L1L1 L1L1 L1L1 L2L2 6 ¬L1¬L1 ¬L1¬L1 ¬L1¬L1 ¬L2¬L2 ¬L2¬L2 ¬L2¬L2 ¬L2¬L2 ¬L2¬L2 ¬L2¬L2 ¬L2¬L2 ¬L 1  ¬L 2

7. LTL in the Model constraint { ltl G( begin(P 1.write) → !begin(P 2.write) U end(P 1.write) && begin(P 2.write) → !begin(P 1.write) U end(P 2.write) ); } 7 process X name P 1 process X name P 2 process X name C medium S name M process X { port Read R; port Write W; void thread() { while (true) { x = R.read(); z = foo(x); W.write(z); } interface Read extends Port { update int read(); eval int nItems(); } interface Write extends Port { update int write(int data); eval int nSpace(); } medium S implements Read, Write { int n, space; int[] storage; int read() { … } int nItems() { … } int write(int data) () { … } int nSpace() { … } }

8. LOC (Logic of Constraints) Term ::= c | i | val(e[t]) | f (e[t]) | o(t 1, t 2, …, t n ) – c is a value. – i is the only index variable. – e is an event. – For t  Term, val(e[t]) represents the value of the t th occurance of e. – f (e[t]) is an annotation that returns the value of the t th occurance of e. – o is an n-ary operator that returns a value. LOC: a Boolean-valued term. Examples: – data (input [i]) = data (output [i]) – vt (display [i+100]) – vt (display [i])  1000 8

9. LTL and LOC LTL and LOC are incomparable. LTL is good for liveness; LOC is good for safety. – It is easy to express “infinitely often” in LTL. G F p – To disprove a safety property in LOC, just find an i such that the constrain is violated. (i is unbounded but finite.) data (input [i]) = data (output [i]) vt (display [i+100]) – vt (display [i])  1000 Verifying simulation with LTL and LOC  Enforcing property with LTL (Büchi Automata)  Enforcing property with a subset of LOC 9

10. Büchi Automata A Büchi automaton is , S, S 0, , F  where  is a finite set of events. S is a finite set of states. S 0  S is a set of initial states.  : S    2 S is a transition function. F  2 S is a set of sets of final states. A run is s = [s 0, s 1, …] such that s i+1   (s i,  i ) where  i   is the i th input. A run s is accepting if  F k  F, s visits some states in F k infinitely often. 10

11. LTL (p U q)  Büchi Automata 11 p U q  q  (p  X (p U q))(  ) Init old: { } new: {p U q} next: { } old: {p U q} new: {q} next: { } old: {p U q} new: {p} next: {p U q} old: {p U q, q} new: { } next: { } q old: {p U q, p} new: { } next: {p U q} p old: { } new: { } next: { } true old: { } new: {p U q} next: { } true old: {p U q, q} new: { } next: { } old: { } new: { } next: { } Create an Init state. The old set contains sub- formulas that hold up to this point. The new set contains sub- formulas that need to hold in the future. The next set contains sub- formulas that need to hold at the next point. For p U q, split into two cases using (  ). Move atomic propositions (p and q in this case) from new to old. Take the conjunction of atomic propositions in old for the transition label. Create a new state whose new set equals the old state’s next set. The old set and the next set are empty. Since the new state’s old set contains no atomic proposition, the transition condition is simply true. States with the same sets can be merged. Finally, examine all states to find final states. Recall that F  2 S. For each sub-formula x U y, create F k such that:  f  F k. y  f.old  x U y  f.old F = {F k } now old new next

12. Enforcing Büchi Automata (1) Size: exponential Keep track of 2 sets of states: – The system states – The Büchi Automata’s states (one for each LTL constraint) 12 Move forward until next event Choose the best transition Eliminate transitions disallowed by BA Get possible transitions due to system states Initiate states of both system and BA

13. Enforcing Büchi Automata (2) 13 Move forward until next event Choose the best transition Eliminate transitions disallowed by BA Get possible transitions due to system states Initiate states of both system and BA !begin(P 1.write) U (end(P 1.read)  ready(M)) Do not make any transition if P 1 tries to write, but P 1.read has not ended, or M is not ready. end(P 1.read)  ready(M) !begin(P 1.write) true

14. Enforcing Büchi Automata (3) 14 Move forward until next event Choose the best transition Eliminate transitions disallowed by BA Get possible transitions due to system states Initiate states of both system and BA Use heuristics when multiple transitions in BA are enabled. Maximize the number of events that can run – E.g., with events !begin(P 1.write), end(P 1.read), ready(M) and enabled transitions end(P 1.read)  ready(M), !begin(P 1.write) we choose the former transition. end(P 1.read)  ready(M) !begin(P 1.write) true s1s1 s2s2

15. Enforcing Büchi Automata (4) 15 Move forward until next event Choose the best transition Eliminate transitions disallowed by BA Get possible transitions due to system states Initiate states of both system and BA Use heuristics when multiple transitions in BA are enabled. Try to lead the execution to a final state – E.g., with events !begin(P 1.write), end(P 1.read), ready(M) and enabled transitions going to s 1 (final), s 2 we choose the former transition. end(P 1.read)  ready(M) !begin(P 1.write) true s1s1 s2s2

16. Enforcing a Subset of LOC Hard to enforce LOC, but algorithms have been found to enforce a subset of LOC E.g., vt (display [i+100]) – vt (display [i])  1000 Generalize to var (event [i+n]) – var (event [i])  m Resolve to a constraint on an increasing variable Enforcing: – Easy for vt – simply refuse to increase if new update tends to violate a constraint – Hard for rt – static analysis necessary; may not be possible at all 16

17. Runtime Monitoring 17 LTL  BA Subset of LOC Checker Generation System FunctionSystem Architecture BUS CPU 1 CPU 2 CPU 3 Mapping Implementation

18. Case Study (1) The PIP (Picture-in-Picture) model has 22 concurrent processes, and 300+ media. 18 TS_DEMUXPES_PARSER MPEG USR_CONTROL JUNGGLERRESIZE

19. Case Study (2) Discovered a bug in the RESIZE module: Hard to manually fix it. Fix it with LTL enforcement: – G( end(P 1.write) → !begin(P 1.write) U end(C.read) ) G( end(P 2.write) → !begin(P 2.write) U end(C.read) ) G( end(C.read) → !begin(C.read) U (end(P 1.write)  end(P 2.write) ) ) Checking time linear in trace size. Memory consumption remains constant. – Time to generate the checker and to check 120,000 lines of trace: < 1m 19 P1P1 P2P2 C C may not read all of P 1 ’s output due to lack of handshaking; same for P 2.

20. Conclusion Use LTL to constrain behavioral property. Use LOC to constrain quantitative property (e.g., time, power consumption, etc). – [2] Logic of Constraints: A Quantitative Performance and Functional Constraint Formalism. Xi Chen, Harry Hsieh, Felice Balarin, Yosinori Watanabe. Not only verify constraints, but also enforce them, even if the implementation does not satisfy. Automatically generate verifier/enforcer from LTL and a subset of LOC. – Can be very effective in specifying coordination between threads. 20