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.
Design in Block Diagram
Q-mgrreal time
Q-mgrpower
Q-mgrmemory
Process Connection Medium Quantity Manager
2
Producer-Consumer Model
process Xname P1
process Xname P2
process Xname C
medium Sname 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
Mapping Function to Architecture
System Function System Architecture
BUS
CPU1 CPU2 CPU3
Mapping
Implementation
4
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
LTL (Linear Temporal Logic)
• L ::= a | ¬ L | L1 L2 | L1 L2
| X L | G L | F L | L1 U L2 | L1 R L2
a is a literal
X – next G – global F – future U – until R – release
L1 U L2 :
L1 R L2 :
• Negated normal form:Contains only ¬ X U R, and ¬ only appears before literals.
– F L ≡ true U L G L ≡ ¬ F ¬ L
– ¬ X L ≡ X ¬ L
– ¬ ( L1 R L2 ) ≡ ¬ L1 U ¬ L2
– ¬ ( L1 U L2 ) ≡ ¬ L1 R ¬ L2
L2 L2 L2
L2 L2 L2 L1 L2
L1 L1 L1 L2
6
¬L1 ¬L1 ¬L1 ¬L2
¬L2 ¬L2 ¬L2
¬L2 ¬L2 ¬L2 ¬L1 ¬L2
LTL in the Model
constraint { ltl G( begin(P1.write) → !begin(P2.write) U end(P1.write) && begin(P2.write) → !begin(P1.write) U end(P2.write) );}
7
process Xname P1
process Xname P2
process Xname C
medium Sname 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() { … }}
LOC (Logic of Constraints)
• Term ::= c | i | val(e[t]) | f (e[t]) | o(t1, t2, …, tn)– 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 tth occurance of e.
– f (e[t]) is an annotation that returns the value of the tth 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
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
Büchi Automata
A Büchi automaton is , S, S0, , F where
is a finite set of events.
S is a finite set of states.
S0 S is a set of initial states.
: S 2S is a transition function.
F 2S is a set of sets of final states.
A run is s = [s0, s1, …] such that si+1 (si, i) where i is the ith input.
A run s is accepting if Fk F, s visits some states in Fk infinitely often.
10
LTL (p U q) Büchi Automata
11
p U q q (p X (p U q)) ()
Initold: { }
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
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 2S.
• For each sub-formula x U y, create Fk such that:
f Fk.y f.old x U y f.old
• F = {Fk}
now
old new
next
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 untilnext event
Choose the best transition
Eliminate transitions disallowed by BA
Get possible transitions due to system states
Initiate states of both system and BA
Enforcing Büchi Automata (2)
13
Move forward untilnext 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(P1.write) U (end(P1.read) ready(M))
Do not make any transition if P1 tries to write, but P1.read has not ended, or M is not ready.
end(P1.read) ready(M)
!begin(P1.write)
true
true
true
Enforcing Büchi Automata (3)
14
Move forward untilnext 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(P1.write), end(P1.read), ready(M)and enabled transitionsend(P1.read) ready(M), !begin(P1.write)we choose the former transition.
end(P1.read) ready(M)
!begin(P1.write)
true
true
true
s1 s2
Enforcing Büchi Automata (4)
15
Move forward untilnext 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(P1.write), end(P1.read), ready(M) and enabled transitions going tos1 (final), s2
we choose the former transition.
end(P1.read) ready(M)
!begin(P1.write)
true
true
true
s1 s2
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
Runtime Monitoring
17
LTL BASubset of LOC
CheckerGeneration
System Function System Architecture
BUS
CPU1 CPU2 CPU3
Mapping
Implementation
Case Study (1)
• The PIP (Picture-in-Picture) model has 22 concurrent processes, and 300+ media.
18
TS_DEMUX PES_PARSER
MPEG
MPEG
USR_CONTROL
JUN
GG
LE
R
RESIZE
Case Study (2)
• Discovered a bug in the RESIZE module:
• Hard to manually fix it.
• Fix it with LTL enforcement:– G( end(P1.write) → !begin(P1.write) U end(C.read) )
G( end(P2.write) → !begin(P2.write) U end(C.read) )G( end(C.read) → !begin(C.read) U (end(P1.write) end(P2.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
P1
P2
C
C may not read all of P1’s output due tolack of handshaking; same for P2.
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