Specifying circuit properties in PSL / Sugar

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 (http://www.cl.cam.ac.uk/users/jrh/)

8. G(p -> F q) yes property MC algorithm no p p q q counterexample finite-statemodel Model Checking (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 • 824633702441.0 times (1/824633702441.0) = 0.99999999274709702 • Fault in look-up table • COST $475.000.000

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. Prop F ok Observer: a second approach Observer written in same language as circuit Safety properties only Used in verification of control programs (and in Lava later)

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 http://www.accellera.org/PSL-v1.1.pdf

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 {req & !busy & !grnt, !req & busy & !grnt, !req & !busy & grnt} busy grnt

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

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

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

39. SERE examples {true, req, busy, grnt} req 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. then if {true[*], req, ack} => {start, busy[*], end}

46. 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. then if {true[*], req, ack} => {start, data[*], end}

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

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”