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