PSL Sugar Formal Specification Language PROSYD Project

1
PSL SugarFormal Specification LanguagePROSYD
Project

• Marco Roveri
• ITC-irst
• roveri_at_irst.itc.it

Material partially taken from slides by D. Fisman
(Weizmann Institute IL) and C. Eisner (IBM
Haifa)
2
Model Checking
3
Specifying Properties

• 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
• CTL vs LTL
• Linear time conceptually simpler (words vs trees)
• Branching time computationally more efficient

4
Specifying Properties

• It is possible to eventually serve a process.
• CTL EF p.running
• LTL not expressible
• From any state it is always possible to restart a
  process
• CTL AG EF p.restart
• LTL not expressible
• A request (req) will be eventually acknowledged
  (ack)
• CTL AG (req -gt AF ack)
• LTL G (req -gt F ack)
• The signal fail never holds
• AG !fail
• G !fail
• Infinitely often a process is running
• CTL not expressible
• LTL GF p.running

5
But

• Translation of a property expressed in natural
  language into temporal logic is not always
  trivial.
• Temporal logic formulas are hard to read and
  write!!!!
• Example
• 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))
• Notice that, here we express that it is never the
  case that there is an execution that violates the
  property (e.g. a sequence where initally strt
  holds, it is followed by two non consecutive get,
  and an end before two put, or a single put
  followed by an end follows).

6
Sugar (IBM, Haifa)

• Grew out of CTL
• Sugar is a formalism to reason about behavior
  over time
• Uses of Sugar
• For documentation easy to read, yet precise
  specification
• Input to formal verification tools (model
  checkers, theorem provers)
• Input to simulation tools (source of
  automatically generated monitors)

7
Goals (in designing the language)

• Easy to learn, read and write
• Mathematically precise
• rigorously well defined formal syntax and
  semantics
• Higly expressive
• permitting the specification of a large class of
  real world
• design properties
• Known efficient underlying algorithms
• in simulation
• in model checking (with reasonable complexity)

8
History

• 1994
• Syntactic sugaring of CTL for RuleBase model
  checker
• 1995
• Addition of regular expressions
• 1997
• Automatic generation of simulation monitors
• 2001
• Move to linear (LTL-based) semantics
• 2002
• PSL 1.0 Selected by Accellera for IEEE
  standardization
• 2004
• PSL 1.01 Under IEEE standardization
• 2005
• PSL 1.1 Approved as IEEE 1850

9
Structure of PSL
10
Structure of PSL

• Boolean layer
• Used to reason about states of the design
• Temporal layer
• Used to reason about behavior of the design over
  time
• Modeling layer
• Used to model auxiliary state variables and
  state machines
• Verification layer
• Directives to the verification tool
  assert/assume/cover
• Sugar comes with different flavors
• Verilog/VHDL/EDL/SMV

11
Boolean Layer

• Used to reason about states of a design
• Describe relationship among signal
• It does not specify whether or when it should
  hold (or not)

12
Boolean Layer

• There is a push without a pop on a fifo that is
  full, and with reset not asserted.
• !reset !pop push wc MAX
• When a reset is false and there is a push with no
  pop, then wc needs to be incremented.
• (!reset !pop push) -gt (inc_wc !dec_wc)

13
Boolean Layer

• Expressions evaluated over a single state
• !reset !pop push wc MAX
• Holds in S1, in S2, but it does not hold in S3

S1 !reset, !pop, push, wcMAX, inc_wc,
!dec_wc ..
S2 !reset, !pop, push, wcMAX, !inc_wc,
dec_wc .
S3 reset, !pop, push, wcMAX, inc_wc,
!dec_wc ..
14
Structure of PSL

• Boolean layer
• Used to reason about states of the design
• Temporal layer
• Used to reason about behavior of the design over
  time
• Modeling layer
• Used to model auxiliary state variables and
  state machines
• Verification layer
• Directives to the verification tool
  assert/assume/cover
• Sugar comes with different flavors
• Verilog/VHDL/EDL/SMV

15
The Temporal Layer

• Boolean Expressions
• expressions evaluated over a single state
• Sugar Extended Regular Expressions (SERE)
• expressions evaluated over a bounded sequence of
• states
• Sugar Foundation Language
• expressions evaluated over finite or infinite
  sequence
• of states
• Optional Branching Extension (OBE)
• expression evaluated over infinite trees of
  states
• (relevant for formal verification only)

s
16
The Temporal Layer

• Boolean Expressions
• Sugar Extended Regular Expressions (SERE)
• expressions evaluated over a bounded sequence of
• states
• Sugar Foundation Language
• expressions evaluated over finite or infinite
  sequence
• of states
• Optional Branching Extension (OBE)
• expression evaluated over infinite trees of
  states
• (relevant for formal verification only)

s
17
The Temporal Layer

• Boolean Expressions
• Sugar Extended Regular Expressions (SERE)
• expressions evaluated over a bounded sequence of
• states
• Sugar Foundation Language
• expressions evaluated over finite or infinite
  sequence
• of states
• Optional Branching Extension (OBE)
• expression evaluated over infinite trees of
  states
• (relevant for formal verification only)

s
18
The Temporal Layer

• Boolean Expressions
• Sugar Extended Regular Expressions (SERE)
• expressions evaluated over a bounded sequence of
• states
• Sugar Foundation Language
• expressions evaluated over finite or infinite
  sequence
• of states
• Optional Branching Extension (OBE)
• expression evaluated over infinite trees of
  states
• (relevant for formal verification only)

s
19
The Temporal Layer

• Boolean Expressions
• Sugar Extended Regular Expressions (SERE)
• Sugar Foundation Language
• Optional Branching Extension (OBE)

s
20
The Temporal Layer

• Boolean Expressions
• Sugar Extended Regular Expressions (SERE)
• Sugar Foundation Language
• Temporal formulas where the atoms are Booleans
• Temporal formulas where the atoms are SEREs
• Temporal formulas where the atoms are Booleans
  and/or SEREs
• Optional Branching Extension (OBE)

21
A simple example

• Temporal formulas where atoms are Booleans
• A request is eventually fulfilled
• AG (req -gt AF gnt)
• G(req -gt F gnt)
• From any state it is always possible to receive a
  grant
• AG EF gnt

22
SEREs - Examples

• A SERE describes a set of sequences (possibly
  empty) of states (which can be represented using
  timing diagrams)
• All sequences of states (traces), in which req
  is high on the first cycle, busy on the second,
  and gnt on the third.
• req busy gnt

23
SEREs - Examples
This diagram is also described by the SERE
This diagram is described by the SERE
24
SEREs - Examples
This diagram is NOT described by the SERE!
This diagram is also described by the SERE
req initially false
req
busy
gnt
25
SEREs - Examples
If we want to describe only this diagram we have
to change the SERE
26
SEREs - Examples
27
SEREs - Examples
28
SEREs - Example
reqbusybusybusygnt reqbusybusybusybusygnt
reqbusybusybusybusybusygnt
reqgnt reqbusygnt reqbusybusygnt reqbusybu
sybusygnt reqbusybusybusybusygnt .
29
SEREs - Examples

• How can we say that the req, busy, gnt sequence
  can start anywhere?
• req busy gnt
• means skip zero or more cycles
• true req busy gnt
• says that the req, busy, gnt sequence starts
  exactly in the second cycle. It constrains only
  cycles 2,3,4
• true4 req busy gnt
• req, busy, gnt sequence starts exactly at cycle 5
• true req busy gnt
• req, busy, gnt sequence starts no earlier than
  next cycle
• Syntactic sugar
• true
• true

30
SEREs - Examples

• req busy3..5 gnt
• Characterize a sequence where
• the signal req is eventually reached, and it is
  followed by
• at least 3 and at most 5 busy signals
• before asserting gnt

31
SEREs - Examples

• Subsequences can also be repeated
• req busy1busy2 gnt
• req busy1busy2busy37 gnt

32
SEREs - Examples

• Fusion operator ()
• Used to construct SERE in which the second
  sequence starts at the cycle in which the first
  sequence completes.
• request busy busy ready request

request busy busy ready request
33
SEREs - Examples

• Simultaneous subsequences ()
• Same length
• Start and end together
• start a end !abort

start !abort end !abort start !abort a
!abort end !abort start !abort a !abort
a !abort end !abort .
34
SEREs - Examples

• One of the subsequence matched (II)
• No need to be of the same length
• request read !cncl_r !dne
  write !cncl_w !dne

request read !cncl_r request read !cncl_r
!dne request write !cncl_w request write
!cncl_w !dne .
35
SEREs - Examples

• Simultaneous subsequences ()
• No need to be of the same length
• R1 R2 is equivalent to
• R1 R2 R1 R2
• Notice that, R1 R2R3
• Describes a path where R3 starts the next cycle
  the longest among R1 and R2 ends

36
PSL Sugar Properties

• Until now we saw examples for SEREs, which are
  not properties on their own, but rather building
  blocks of properties
• For SERE it is important where do they end
• We will now see examples of properties composed
  from the SERE building blocks

37
PSL Sugar Properties - Examples

• The suffix implication operator

• If the path starting now matches
• Then its continuation should match
• But, doesnt have to reach its end,
  provided that there is no evidence of its
  contradiction (e.g. in simulation on a truncated
  path).

38
PSL Sugar Properties Example1
39
PSL Sugar Properties Example1
40
PSL Sugar Properties Example1
Overlapping is also possible!
then
if
then
if
41
PSL Sugar Properties Example1
then
if
then
if
42
PSL Sugar Properties Example2
But what if data does not hold in contiguous
cycles?
43
PSL Sugar Properties

• SERE1 gt SERE2
• If a sequence matches SERE1, then it should not
  be followed by a continuation that does not match
  SERE2
• Checkable by simulation
• SERE1 gt SERE2!
• Demands that the second sequence complete
• Suitable for model checking

44
PSL Sugar Properties

• SERE1 -gt 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
• 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
• start busy end -gt success done
• If there is no abort during start c end,
  success will be asserted with end
• , start c end !abort -gt
  success
• Note cannot appear in the right hand sequence

45
PSL Sugar Properties

• SERE1 gt SERE2 ? SERE1 -gt true
  SERE2
• PSL Sugar has a small core and the rest is
  syntactic sugar, for example
• Always (r) ? true -gt r
• bi ? !b b i !b

46
PSL Sugar Properties

• Occurrences operators
• always must hold globally
• always (
  )
• never must not hold globally
• never (
  )
• eventually! must hold at some indefinite time
  in the future
• eventually! ( ack )

47
PSL Sugar Properties

• Occurrences operators
• next must hold at some specified future time
• next (ack)
• In the next cycle ack holds
• next3 (ack)
• At the 3rd next cycle ack holds
• next_a 0..4(ack)
• Ack holds from current cycle through next 4
  cycles
• next_e 0..4(ack)
• Ack holds at least once from current cycle until
  next 4 cycles

48
PSL Sugar Properties

• Occurrences operators
• until the left operand must hold until the
  right (the terminating property) operand holds
• busy until done -- weak until (busy can holds
  forever)
• busy busy done
• busy busy busy busy busy
• done
• busy until! done -- strong until (eventually
  done)
• busy busy done
• done
• busy until_ done -- weak overlapping until
  (busy can holds forever)
• busy busy done
• busy busy busy busy busy
• busy done
• busy until!_ done -- strong overlapping until
  (eventually done)
• busy busy done
• busy done

49
PSL Sugar Properties

• Occurrences operators
• before the left operand must hold before the
  right (the terminating property) operand holds
• busy before done -- weak before (!done can
  holds forever)
• !done until (!done busy )
• busy before! done -- strong before (eventually
  busy and !done)
• !done until! (!done busy )
• busy before_ done -- weak overlapping before
  (!done can holds forever)
• !done until busy
• busy before!_ done -- strong overlapping before
  (eventually busy)
• !done until! busy

50
PSL Sugar Properties

• LTL operators
• X next state a property holds
• Maps to next!() operator
• F eventually a property holds
• Maps to eventually! operator
• U strong until operator
• Maps to until!
• W weak until operator
• Maps to until
• G globally operator
• Maps to always

51
PSL Sugar Properties

• OBE (CTL) operators
• EX ? at least in one next state ? holds
• AX ? all next states ? holds
• EF ? there is a path where the ? eventually
  holds
• AF ? in all paths ? eventually holds
• E?1 U ?2 there is at least one path where ?1
  holds until ?2 holds
• A?1 U ?2 in all paths ?1 holds until ?2 holds
• EG ? there is a path where ? holds forever
• AG ? in all paths ? holds forever

52
PSL Sugar Formulas

• Every boolean expression is a PSL Sugar formula
• Every SERE is a PSL Sugar formula
• SERE1 -gt SERE2 is a PSL Sugar formula
• SERE1 gt SERE2 is a PSL Sugar formula
• If ?, ?1, ?2 are PSL Sugar formulas and r is a
  SERE then the following are PSL Sugar formulas
• !?
• ?1 ?2
• X ?, F ?, G ?, next(?), always(?),
  eventually(?), never(?)
• ?1 U ?2, ?1 until ?2, ?1 before ?2
• r -gt ?
• Holds for a state s if for all finite sequences
  starting from s on which r holds, formula ? holds
  on the final state of the sequence r
• Any OBE expression over OBE expression or Boolean
  is a PSL expression.
• Notice No mix of LTL and SERE with OBE
  expressions

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

54
In PSL Sugar

• 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.
• always(strt, get2kill0
  gt put2end0)
• And for 100?
• always(strt, get100kill0
  gt put100end0)

55
PSL Sugar Properties Example2
56
PSL Sugar Properties Example2
then
if
57
PSL Sugar Properties Example2
then
if
58
PSL Sugar Properties Example2
1
3
2
then
if
59
Expressiveness

• Theory
• At least as expressive as
• LTL
• CTL
• regular expressions
• Practice
• All properties suggested by Formal Verification
  Technical Committee of Accellera are concisely
  and intuitively expressible in PSL Sugar

60
Implementation

• PSL Sugar has a core of operators which determine
  its expressive power
• Other operators are syntactic sugaring
  (abbreviations) of the core operators
• A tool needs to implement
• Only the core operators
• Macro expansion of the syntactic sugaring
  operators

61
Implementation (of the core)

• Any PSL Sugar property can be reduced to an LTL
  or CTL property using auxiliary state machines.
• CTL and LTL have known model checking algorithms.
• For simulation it is only considered the subset
  that can be verified on-the-fly.
• For this subset there are simple transformation
  rules that transform the formula to a state
  machine describing all possible counter examples.

62
Structure of PSL

• Boolean layer
• Used to reason about states of the design
• Temporal layer
• Used to reason about behavior of the design over
  time
• Modeling layer
• Used to model auxiliary state variables and
  state machines
• Verification layer
• Directives to the verification tool
  assert/assume/cover
• Sugar comes with different flavors
• Verilog/VHDL/EDL/SMV

63
PSL Verification Layer

• Specifies directives to the verification tool on
  how to use a property.
• assert directive
• Tells the verification tool to verify that a
  property hols
• assert always (req -gt eventually! ack)
• assume directive
• Tells the tool to consider only those possible
  behaviors in the property holds
• assume never (req1 req2)
• vunit
• Associate PSL properties with a design module or
  instance.

entity E1 is port (req1 , req2, ) end
vunit (E1) . assert never (req1 req2)
64
Structure of PSL

• Boolean layer
• Used to reason about states of the design
• Temporal layer
• Used to reason about behavior of the design over
  time
• Modeling layer
• Used to model auxiliary state variables and
  state machines
• Verification layer
• Directives to the verification tool
  assert/assume/cover
• Sugar comes with different flavors
• Verilog/VHDL/EDL/SMV

65
PSL Modeling Layer

• Specifies HDL code within a vunit, for instance
  to model the environment.

vunit (E1) signal cnt Integer 0 cnt lt
cnt 1 when req1 else cnt 1 when
req2 else cnt assert never (cnt gt
10)
entity E1 is port (req1 , req2, ) end
66
PSL Sugar Home Page

• More information available on the sugar home page
  at
• http//www.pslsugar.org
• http//www.haifa.il.ibm.com/projects/verification/
  sugar/index.html
• Complete definition
• Tutorial
• Sugar parser
• Formal syntax and semantics
• More
• http//www.prosyd.org
• an EU Project aiming at the definition of a
  design methodology and support tools based on PSL
  Sugar.
• http//nusmv.irst.itc.it
• The first public available model checker
  supporting the PSL sugar temporal layer.

67
The PROSYD projecthttp//www.prosyd.org

• Increase competitiveness and efficiency of EU IT
  industry through the establishment of a a
  standard integrated property-based methodology
  for the design of electronic systems.
• The paradigm will integrate and unify the
  development phases (requirements definition,
  design, implementation and verification) into one
  coherent design process.
• The methodology will build on the PSL/Sugar
  specification language, recently selected as
  basis for an IEEE standard.
• The methodology will enable the development of
  electronic systems of higher quality within a
  shorter design cycle and thus at lower cost.
• Property-based system design will streamline the
  design process by providing methodologies and
  tools to promote reuse of design specifications
  in terms of properties.

68
The PROSYD design methodology flow