Specifying circuit properties in PSL / Sugar

But first some background…

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)

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

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

But

temporal logics hard to read and write!

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

Break for some history

Nov. ’94 Intel FPU bug

• 824633702441.0 times (1/824633702441.0) = 0.99999999274709702

• Fault in look-up table

• COST $475.000.000

$15 per transistor!!

• ”We are heading for a brick wall”

• ”We can’t fill the fabs”

• ”A first requirement is a formal semantics”

We thought

Cost of design is soaring

Price of getting it wrong is high

Formal verification (and particularly model checking) must be the answer!

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

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

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

Why?

Limits in capacity of commercial tools

Lack of methodology (e.g. about coverage)

Not enough perceived payoff

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)

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

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)

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

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

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 sequences of states

It is a building block for a property

http://www.accellera.org/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

SERE examples

{req, busy, grnt}

req

busy

grnt

is in the set of traces

SERE examples

{req, busy, grnt}

req

busy

grnt

This too

SERE examples

{req, busy, grnt}

req

busy

grnt

and this

SERE examples

{req, busy, grnt}

req

busy

grnt

but not this

Why?

SERE examples

How can we specify ONLY those traces that start like this?

req busy

grnt

SERE examples

req

busy

grnt

{req & !busy & !grnt, !req & busy & !grnt, !req & !busy & grnt}

SERE examples

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

req busy

grnt

SERE examples

{[*], req, busy, grnt}

req

busy

grnt

[*] means skipzero or more cycles

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

&&

Simultaneous subsequencesSame length, start and end together

{start, a[*], end} && {!abort[*]}

||

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}

Properties at last!

SEREs are not properties in themselves

{SERE1} => {SERE2} is a property

If a sequence matches SERE1, then itscontinuation should match SERE2

if then

{true[*], req, ack} => {start, busy[*], end}

Not just the first req, ack{true[*], req, ack} => {start, busy[*],

end}

if then

if then

Overlap also possible!{true[*], req, ack} => {start, busy[*],

end}

if then

ifthen

if then

{true[*], req, ack} => {start, data[*], end}

{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 sequence matches SERE1, then itscontinuation should match SERE2

But SERE2 doesn’t have to ”reach its end”

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}!

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 !)

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

Note && cannot appear in the right hand sequence

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

Sugar Formulas

1. Every boolean expression is a Sugar formula

2. Every Sugar formula of the linear fragment is a Sugar formula

Sugar Formulas

3. If f, f1 and f2 are Sugar formulas and r is a SERE, then the following are Sugar formulas:

i. !fii. f1 & f2iii. EX fiv. E [f1 U f2]v. EG fvi. {r}(f)

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

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

Sugar

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

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/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]}})

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