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 (

Model Checking MC G(p -> F q) yes no p 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 efficient We 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])]]])

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 practice Easy 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) F Prop ok

Assertion Based Verification (wars) OpenVera™ Assertions (OVA) language has been donated to the public domain by Synopsys™. It is based on VERA and provides comprehensive support for assertions. Property Specific Language (PSL) was donated by IBM® and is based on the Sugar formal property language. PSL provides the most advanced and complex assertion checking capability.

Assertion Based Verification (wars) Accelera Open Verification Library (OVL) provides ready to use assertion functions in the form of VHDL and Verilog HDL libraries. SystemVerilog is a next generation language standard based on many of the best features of the SUPERLOG, VHDL, VERA, C, C++, OVA, PSL/Sugar languages, added to the core Verilog HDL. SystemVerilog is aimed at becoming the next standard approved by IEEE (source, website of Aldec, a company providing related EDA tools,

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

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 skip zero or more cycles

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

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

{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 subsequences Same 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 its continuation 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 if then

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

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

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”

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.!f ii.f1 & f2 iii.EX f iv.E [f1 U f2] v.EG f vi.{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! Safelogic, the Göteborg based makers of the Verifier tool, are involved in simplifying the semantics Try it!

Don’t Miss Next Lecture by Jiri Gaisler, with his simple, elegant and practical approach to writing VHDL code High point of the course!