1. Specifying circuit properties in PSL / Sugar

2. But first some background…

3. Formal methods
Mathematical and logical methods used in system development
Aim to increase confidence in riktighet of system
Apply to both hardware and software

4. Formal methods Complement other analysis methods
Are good at finding bugs
Reduce development (and test) time (Verification time is often 70% of total time in hardware design projects)

5. Successful formal methods
Integrated in the design flow
Avoid new demands on the user
Work at large scale
Save time or money in getting a good quality product out

6. Some fundamental facts
Low level of abstraction, Finite state systems
=> automatic proofs possible
High level of abstraction, Fancy data types, general programs
=> automatic proofs IMPOSSIBLE

7. Two main approaches
Squeeze the problem down into one that can be handled automatically
industrial success of model checkers
automatic proof-based methods very hot
Use powerful interactive theorem provers and highly trained staff
for example Harrison’s work at Intel on floating point algorithms (

8. Model Checking MC G(p -> F q) yes no p q property algorithm
finite-state model
algorithm
counterexample
(Ken McMillan)

9. Again two main approaches
Linear Temporal Logic (LTL)
must properties, safety and liveness
Pnueli, 1977
Computation Tree Logic (CTL)
branching time, may properties, safety and liveness
Clarke and Emerson, Queille and Sifakis, 1981
Linear time conceptually simplier (words vs trees)
Branching time computationally more efficient
We will return to this in a later lecture

10. But
temporal logics hard to read and write!

11. Computation Tree Logic
A sequence beginning with the assertion of signal strt, and containing two not necessarily consecutive assertions of signal get, during which signal kill is not asserted, must be followed by a sequence containing two assertions of signal put before signal end can be asserted
AG~(strt & EX E[~get & ~kill U get & ~kill & EX E[~get & ~kill U get & ~kill & E[~put U end] | E[~put & ~end U (put & ~end & EX E[~put U end])]]])

12. Break for some history

13. Nov. ’94 Intel FPU bug
times (1/ ) =
Fault in look-up table
COST $

14. $15 per transistor!! ”We are heading for a brick wall”
”We can’t fill the fabs”
”A first requirement is a formal semantics”

15. We thought Cost of design is soaring Price of getting it wrong is high
Formal verification (and particularly model checking) must be the answer!

16. Some great successes Intel floating point verification
(see video from MEMOCODE 2004 (google for it))
Bug finding at Motorola, Digital etc.
Elegant verifications at AMD... Successes at Siemens

17. Some great successes
And equivalence checking is now standard and widely used
But no breakthrough for model checking to a larger market (see Deepchip (google again))

18. Why? Again see MEMOCODE videos Too little concentration on ease of use
Developers don’t want to do formal verification (”a vague and confusing form of testing”)
Disruption to the design flow

19. Why? Limits in capacity of commercial tools
Lack of methodology (e.g. about coverage)
Not enough perceived payoff

20. Response (standard)
Industry effort to develop standardised property specification languages (e.g. PSL, SVA)
Try to solve the above problems while remaining compatible with standard design flow (e.g. Jasper)

21. Sugar (IBM, Haifa) Grew out of CTL Added lots of syntactic sugar
Engineer friendly, used in many projects
Used in the industrial strength MC RuleBase

22. Assertion Based Verification (ABV) can be done in two ways
During simulation
(dynamic, at runtime, called semi-formal verification, checks only those runs)
As a static check
(formal verification, covers all possible runs, more comprehensive, harder to do, restricted to a subset of the property language)

23. Properties
always (p)
Asserts that p (a boolean expression made from signal names, constants and operators) is true on every cycle of the simulation
always (! (gr1 & gr2))

24. Properties always (a -> b) If a is true, then b is true
a implies b a -> b !a | b
always (a -> prev(b))
If a is true, then b was true at the previous cycle

25. Safety Properties always (p) ”Nothing bad will ever happen”
Most common type of property checked in practice
Easy to check (more later)
Disproved by a finite run of the system

26. Observer: a second approach
Observer written in same language as circuit
Safety properties only
Used in verification of control programs (and in Lava later) F
Prop ok

27. Back to PSL always (p) Talks about one cycle at a time
Sequential Extended Regular Expressions (SEREs) allow us to talk about spans of time
A SERE describes a set of sequences of states
It is a building block for a property

28. SERE examples {req, busy, grnt}
All sequences of states, or traces, in which req is high on the first cycle, busy on the second, and grnt on the third.
(source Sugar 2.0 presentation from IBM’s Dana Fisman and Cindy Eisner, with thanks)

29. SERE examples
{req, busy, grnt}
req
busy
grnt

30. SERE examples
{req, busy, grnt}
req
is in the set of traces
busy
grnt

31. SERE examples
{req, busy, grnt}
req
This too
busy
grnt

32. SERE examples
{req, busy, grnt}
req
busy
and this
grnt

33. SERE examples
{req, busy, grnt}
req
busy
but not this
Why?
grnt

34. SERE examples
How can we specify ONLY those traces that start like this?
req
busy
grnt

35. SERE examples req busy grnt {req & !busy & !grnt, !req & busy & !grnt,

36. SERE examples req busy grnt
How do we say that the {req,busy,grnt} sequence can start anywhere?
req
busy
grnt

37. SERE examples req busy grnt {[*], req, busy, grnt} [*] means skip
zero or more
cycles
busy
grnt

38. SERE examples {[*],req, busy, grnt} req busy grnt
so our original trace
is still in the set
described
busy
grnt

39. SERE examples {true, req, busy, grnt} req busy grnt
says that the req, busy, grnt
sequence starts exactly in the second cycle. It constrains only cycles 2,3,4
busy
grnt

40. {true[4], req, busy, grnt}
rbg sequence must start at cycle 5
{true[+], req, busy, grnt} true[+] = [+]
one or more trues
true[*] = [*]

41. {[*], req, busy[3..5], grnt}
at least 3 and at most 5 busys
{[*], req, {b1,b2}[*], grnt}
{[*], req, {b1,b2,b3}[7], grnt}
subsequences can also be repeated

42. && Simultaneous subsequences Same length, start and end together
{start, a[*], end} && {!abort[*]}

43. || One of the subsequences should be matched
Don’t need to be the same length
{request,
{rd, !cncl_r, !dne[*]} || {wr,!cncl_w,!dne[*]}, dne}

44. Properties at last! SEREs are not properties in themselves
{SERE1} => {SERE2} is a property
If a sequence matches SERE1, then its
continuation should match SERE2

45. {true[*], req, ack} => {start, busy[*], end}if
then

46. Not just the first req, ack {true[. ], req, ack} => {start, busy[
Not just the first req, ack {true[*], req, ack} => {start, busy[*], end}
then if
then if

47. Overlap also possible! {true[*], req, ack} => {start, busy[*], end}
then if
then if

48. {true[*], req, ack} => {start, data[*], end}if
then

49. {true[*], req, ack} => {start, data[=8], end}
Can check for data in non-consecutive cycles
{true[*], req, ack} => {start, data[=8], end} if
then 1
5 6 7 8

50. A form of implication {SERE1} => {SERE2}
If a sequence matches SERE1, then its
continuation should match SERE2
But SERE2 doesn’t have to ”reach its end”

51. Safety properties {SERE1} => {SERE2}
If a sequence matches SERE1, then it should not be followed by a continuation that does not match SERE2
Checkable by simulation
For model checking, there is a stronger version of the => construct, that demands that the second sequence complete
{SERE1} => {SERE2}!

52. Another form of implication
{SERE1} -> {SERE2}
If a sequence matches SERE1, then SERE2 should be matched, starting from the last element of the sequence matching SERE1
So there is one cycle of overlap in the middle
This also has a strong version (ending !)

53. Example {[*], start, busy[*], end} -> {success, done}
If signal start is asserted, signal end is asserted at the next cycle or later, and in the meantime signal busy holds, then success is asserted at the same time as end is, and in the next cycle done is asserted

54. Example {[*], {start, c[*], end}&&{!abort[*]}} -> {success}
If there is no abort during {start,c[*],end}, success will be asserted with end
Note && cannot appear in the right hand sequence

55. Both are formulas of the linear fragment
{SERE1} => {SERE2} =
{SERE1} -> {true, SERE2}
Both are formulas of the linear fragment
Sugar has a small core and the rest is syntactic sugar, for example
always{r} = {true[*]} -> {r}
b[=i] = {!b[*], b}[i] , !b[*]

56. Sugar Formulas Every boolean expression is a Sugar formula
Every Sugar formula of the linear fragment is a Sugar formula

57. Sugar Formulas
If f, f1 and f2 are Sugar formulas and r is a SERE, then the following are Sugar formulas: !f
f1 & f2
EX f
E [f1 U f2]
EG f
{r}(f)

58. Sugar Formulas {r}(f) (which was 3(vi))
Holds for a state s if, for all finite sequences starting from s on which r holds, formula f holds on the final state of the sequence r

59. Sugar Formulas
If we delete rule 2 (the linear fragment) and rule 3(vi), then we have CTL!
Next lectures build up to what CTL is and how to model check it

60. Sugar Regular expressions (plus some operators) +
Linear temporal logic (LTL)
Computation tree logic (CTL)
Lots of syntactic sugar

61. Example revisited
A sequence beginning with the assertion of signal strt, and containing two not necessarily consecutive assertions of signal get, during which signal kill is not asserted, must be followed by a sequence containing two assertions of signal put before signal end can be asserted
AG~(strt & EX E[~get & ~kill U get & ~kill & EX E[~get & ~kill U get & ~kill & E[~put U end] | E[~put & ~end U (put & ~end & EX E[~put U end])]]])

62. In PSL/Sugar (with 8 for 2)
A sequence beginning with the assertion of signal strt, and containing eight not necessarily consecutive assertions of signal get, during which signal kill is not asserted, must be followed by a sequence containing eight assertions of signal put before signal end can be asserted
AG({strt, {get[=8]}&&{kill[=0]}}
=> {{put[=8]}&&{end[=0]}})

63. PSL Seems to be reasonably simple, elegant and concise!
Jasper AB (formerly called Safelogic), the Göteborg based makers of the Jasper Gold Lite 4.0 Early Access tool, are involved in simplifying the semantics