1 / 49

Specifying circuit properties in PSL

Specifying circuit properties in PSL. Formal methods. Mathematical and logical methods used in system development Aim to increase confidence in riktighet of system Apply to both hardware and software. Formal methods. Complement other analysis methods Are good at finding bugs

lael
Download Presentation

Specifying circuit properties in PSL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Specifying circuit properties in PSL

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

  3. 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)

  4. 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

  5. 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/)

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

  7. Again two main approaches • Linear-time 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

  8. But temporal logics hard to read and write!

  9. 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])]]])

  10. Basis of PSL was Sugar (IBM, Haifa) Grew out of CTL (I believe) Added lots of syntactic sugar Engineer friendly, used in many projects Used in the industrial strength MC RuleBase

  11. 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) (Note: this duality has been important for PSL’s practical success, but it also complicates the semantics!)

  12. Properties always (p) states that p (a boolean expression made from signal names, constants and operators) is true on every cycle always (! (gr1 & gr2))

  13. Properties always (a -> b) If a is true, then b is true a implies b a -> b not a or b always ((rd=’0’) -> next (prev(dout)=dout) )

  14. 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

  15. 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)

  16. 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 traces It is a building block for a property http://www.eda.org/vfv/docs/PSL-v1.1.pdf

  17. 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)

  18. SERE examples {req; busy; grnt} req is in the set of traces busy grnt

  19. SERE examples {req; busy; grnt} req This too busy grnt

  20. SERE examples {req; busy; grnt} req busy and this grnt

  21. SERE examples {req; busy; grnt} req busy but not this Why? grnt

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

  23. SERE examples req {req & !busy & !grnt; !req & busy & !grnt; !req & !busy & grnt} busy grnt

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

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

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

  27. 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

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

  29. {[*]; 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

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

  31. || 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}

  32. Fancier properties at last! SEREs are themselves properties (in the latest version of PSL). Properties are also built from subproperties. {SERE1} |=> {SERE2} is a property If a trace matches SERE1, then its continuation should match SERE2

  33. then if {true[*]; req; ack} |=> {start; busy[*]; end}

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

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

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

  37. 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}

  38. A form of implication {SERE1} |=> {SERE2} If a trace matches SERE1, then its continuation should match SERE2

  39. Another form of implication {SERE1} |-> {SERE2} If a trace matches SERE1, then SERE2 should be matched, starting from the last element of the trace matching SERE1 So there is one cycle of overlap in the middle

  40. 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

  41. Example {[*]; {start; c[*]; end}&&{!abort[*]}} |-> {success} If there is no abort during {start,c[*],end}, success will be asserted with end

  42. {SERE1} |=> {SERE2}= {SERE1} |-> {true, SERE2} Both are formulas of the linear fragment (which is based on LTL) In Jasper Gold, we use this linear part. There is also an optional branching extension (which is where CTL comes back in)

  43. PSL has a small core and the rest is syntactic sugar, for example b[=i] = {not b[*]; b}[*i] ; not b[*] See formal semantics in LRM

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

  45. 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])]]])

  46. In PSL (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 always({strt; {get[=8]}&&{kill[=0]}} |=> {{put[=8]}&&{end[=0]}})

  47. From PSL to CTL? always {a;b[*];c} -> {d;e[*];f} (source, lecture notes by Mike Gordon, question asked by PSL/Sugar designers)

  48. PSL Seems to be reasonably simple, elegant and concise! Jasper’s Göteborg based team have helped to define and simplify the formal semantics. See the LRM and also the paper in FMCAD 2004 (on course home page)

  49. Friday’s lecture By Jiri Gaisler on his two process method of using VHDL Do NOT miss this lecture. It is brilliant! Next week, I will return to LTL, CTL and how to model check them

More Related