Upload
brian-blevins
View
19
Download
0
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
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
Reduce development (and test) time (Verification time is often 70% of total time in hardware design projects)
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
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/)
Model Checking
MC
G(p -> F q)yes
nop
q
p
q
property
finite-state model
algorithm
counterexample
(Ken McMillan)
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 efficientWe will return to this in a later lecture
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])]]])
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
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!)
Properties
always (p)
states that p (a boolean expression made from signal names, constants and operators) is true on every cycle
always (! (gr1 & gr2))
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) )
Safety Properties
always (p) ”Nothing bad will ever happen”Most common type of property checked
in practiceEasy to check (more later)Disproved by a finite run of the system
Observer: a second approach
Observer written in same language as circuit
Safety properties only
Used in verification of control programs (and in Lava later)
FProp
ok
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 tracesIt is a building block for a property
http://www.eda.org/vfv/docs/PSL-v1.1.pdf
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)
SERE examples
{[*]; req; busy; grnt}
req
busy
grnt
so our original traceis still in the setdescribed
SERE examples
{true; req; busy; grnt}
req
busy
grnt
says that the req, busy, grntsequence starts exactly in the second cycle. It constrains only cycles 2,3,4
{true[*4]; req; busy; grnt}rbg sequence must start at cycle 5 {true[+]; req; busy; grnt} true[+] =
[+]one or more trues
true[*] = [*]
{[*]; 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
||
One of the subsequences should be matchedDon’t need to be the same length
{request; {rd; !cncl_r; !dne[*]} || {wr;!cncl_w;!dne[*]};dne}
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 itscontinuation should match SERE2
{true[*]; req; ack} => {start; data[=8]; end}
if then
1 2 3 4 5 6 7 8
Can check for data in non-consecutive cycles
A form of implication
{SERE1} |=> {SERE2}If a trace matches SERE1, then itscontinuation should match SERE2
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
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
Example
{[*]; {start; c[*]; end}&&{!abort[*]}} |-> {success}
If there is no abort during {start,c[*],end}, success will be asserted with end
{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)
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
PSL
Regular expressions (plus some operators)+Linear temporal logic (LTL)+ Lots of syntactic sugar+ (optional)Computation tree logic (CTL)
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])]]])
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]}})
From PSL to CTL?
always {a;b[*];c} -> {d;e[*];f}
(source, lecture notes by Mike Gordon, question asked by PSL/Sugar designers)
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)