04 - PSLanguage

PSL
João Leonardo Fragoso
Contents
Definitions and Usage

Clarification and Background
SERE
Properties
1
Definition
Property Specification Language

– Linguagem to specify properties
What is a property?
– The sky is blue

– Apples and oranges are fruits
– The day is followed by the night
– If I sleep, I dream
Usage
Specification of Properties for:

– Simulation (and coverage)
– Formal verification
– Specification
2
Types of Properties
• Invariants, Reachability and Mutual Exclusion

• Liveness (signal, port, variable or register changes its
value forever)
• Fairness (every request will be eventually granted)

• Temporal Behaviour (every request will be granted in
given amount of time)
Clarification and Background
Who should write assertions or functional coverage conditions, and

when?
– Designers? In design stage?
Is it easy to write assertions?
How do we handle existing designs?

– Add interface assertions only?
When should we switch simulation and formal verification?
– Verify formally as much as possible?
3
Why to use assertion in the simulation?
Find bug and automation

Testbench
Automating the tests
– Testbenches
Specifying in PSL
Logic
• 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 simpler (words vs trees)
Branching time computationally more efficient
4
Tautology
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))
Tautology
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
10
5
Safety
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
11
Instance 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/
12
6
examples SERE
{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.
13
Examples SERE
14
7
João Leonardo Fragoso João Leonardo Fragoso
16
15
Examples SERE
Examples SERE
8
18
17
Examples SERE
Examples SERE
9
20
19
Examples SERE
Examples SERE
10
Exemples SERE
[*] means
skip zero
or more
cycles
21
Exemples SERE
So the
original trace
still is in the
described set
22
11
Examples SERE
23
Examples SERE
{true[4], req, busy, grnt}

rbg sequence must start at cycle 5
{true[+], req, busy, grnt} true[+] = [+]

one or more trues
true[*] = [*]
24
12
Examples SERE
{[*], 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
25
Examples SERE
Simultaneous subsequences
Same length, start and end together
{start, a[*], end} && {!abort[*]}
26
13
Examples SERE
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}
27
Examples SERE
[= ] Non-consecutive repetition
[-> ] GOTO repetition
Examples
always ({a} |=> {b[=2]; c});

-- If a then two occurrence of b before c;
always ({a} |=> {b[->2]; c});
-- If a then two occurrence of b any cycle
before c, but last b must occur in cycle before c;
28
14
SERE BNF
SERE ::=
Boolean
| Sequence
| SERE @ clock_Boolean
| SERE ; SERE
| Sequence : Sequence
| Sequence AndOrOp Sequence
| SERE [ * [ Count ] ]
| [ * [ Count ] ]
| SERE [ + ] Sequence ::=
|[+] { SERE }
| Boolean [ = Count ] | sequence_Name [ (Actual_Parameter_List ) ]
| Boolean [ -> [ positive_Count ] ]
29
SERE - proposition
SEREs are not properties in themselves

{SERE1} => {SERE2} is a property
If a sequence matches SERE1, then its

continuation should match SERE2
30
15
BNF property
property <name> = [operator] [enabling_condition(s)]

[implication_operator(s)] (fulfilling_condition)
[until | until_ | abort discharging_condition]
[@(clock_expression)];
Operator: always | never
31
Examples property
32
16
34
33
17
35
Implication
{SERE1} => {SERE2}

If a sequence matches SERE1, then its
continuation should match SERE2
But SERE2 doesn’t have to ”reach its end”
36
18
Implication
{SERE1} => {SERE2}

If a sequence matches SERE1, then it should not be
followed by a continuation that does not match
SERE2
There is a stronger version of the => construct, that
demands that the second sequence complete
{SERE1} => {SERE2}!
37
Another 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 !)
38
19
Another Implication 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
39
Syntactic Sugar
{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[*]
40
20
PSL VHDL
-- Complete SERE assertion

-- psl property P1 is
-- always( {REQ; GNT} |=>
-- {BUSY; DONE} )@rising_edge(CLK);
-- psl assert P1;
41
Examples
always ({a} |=> {b[*2]; c}); -- if a, then b; b; c sequence

always ({a} |=> {[*2]; c}); -- if a, then -; - ; c sequence
always ({a} |=> {b[*1 to 3]; c}); if a then either of sequences:
b; c | b; b; c | b; b; b; c
always ({a} |=> {b[*0 to 3]; c}); if a then either of sequences:
c | b; c | b; b; c | b; b; b; c
always ({a} |=> {b[+]; c}); -- if a then either of sequence
b; c | b; b; c | b; b;…..; b; c
always ({a} |=> {[*]; b; c}); -- Cannot fail. For functional coverage
if a then assertion completes when b; c sequence occurs.
42
21
Observers or Monitors
43
AMBA Example
Consider the AHB protocol:

– Section 3.9.4 says “If a slave provides an ERROR response then
the master may choose to cancel the remaining transfers in the
burst. However, this is not a strict requirement and it is also
acceptable for the master to continue the remaining transfers in

the burst.”
The AHB Specification doesn’t contain waveforms for either
alternative of this complex behavior
– probably because of limited space –the combinations grow
fast!
– this is not unique to ARM – all protocol specs are limited to a
few
44
22
46
45
23
47
AHB
AHB protocol has two outcomes for a transaction

– OKAY completions take one cycle
– ERROR completions take two cycles
Alternatives are easily described using PSL
( (HRESP == OKAY) && !HREADY)[*];

{ // this path is a normal completion
{ ( (HRESP == OKAY) && HREADY && (HRDATA == data_arg)
&& (HRESP == resp_val)) }
|
// this path is an error completion
{ ( (HRESP == ERROR) && !HREADY) ;
( (HRESP == ERROR) && HREADY && (HRDATA == data_arg)
&& (HRESP == resp_val))} }
48
24
PSL VHDL
-- These assertions are complete!

-- psl property NOT_GNTBUSY is
-- never (GNT and BUSY)@falling_edge(CLK);
-- always(ACK -> next (not BUSY))@rising_edge(CLK);

-- psl assert NOT_GNTBUSY;
-- psl assert P1;
49
Clock and Property
-- psl default clock is rising_edge(CLK);

-- always (REQ -> eventually! ACK);
50
25
Property is not a Test!!!
Always (a=0 |-> b=1);

– Property or Test
51
Exercise
Describe a FIFO in PSL

52
26

04 - PSLanguage

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

04 - PSLanguage

Uploaded by

Copyright:

Available Formats

PSL

João Leonardo Fragoso

Definitions and Usage

Property Specification Language

– The sky is blue

Specification of Properties for:

• Invariants, Reachability and Mutual Exclusion

• Fairness (every request will be eventually granted)

Clarification and Background

Who should write assertions or functional coverage conditions, and

How do we handle existing designs?

Find bug and automation

• Linear Temporal Logic (LTL)

• Computation Tree Logic (CTL)

is true on every cycle of the simulation

always (! (gr1 & gr2))

Most common type of property checked in practice

Sequential Extended Regular Expressions (SEREs)

{req, busy, grnt}

All sequences of states, or traces, in which req is

high on the first cycle, busy on the second, and

{true[4], req, busy, grnt}

{true[+], req, busy, grnt} true[+] = [+]

{[*], req, busy[3..5], grnt}

{[*], req, {b1,b2}[*], grnt}

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

One of the subsequences should be matched

always ({a} |=> {b[=2]; c});

SEREs are not properties in themselves

If a sequence matches SERE1, then its

property <name> = [operator] [enabling_condition(s)]

Operator: always | never

{SERE1} => {SERE2}

continuation should match SERE2

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

{SERE1} => {SERE2}

{SERE1} -> {SERE2}

{[*], start, busy[*], end} -> {success, done}

If signal start is asserted, signal end is asserted at

{SERE1} => {SERE2} =

Sugar has a small core and the rest is syntactic

-- Complete SERE assertion

-- psl assert P1;

always ({a} |=> {b[*2]; c}); -- if a, then b; b; c sequence

Consider the AHB protocol:

acceptable for the master to continue the remaining transfers in

AHB protocol has two outcomes for a transaction

-- These assertions are complete!

-- always(ACK -> next (not BUSY))@rising_edge(CLK);

Clock and Property

-- psl default clock is rising_edge(CLK);

Always (a=0 |-> b=1);

Describe a FIFO in PSL

You might also like

{[], req, {b1,b2}[], grnt}

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

{[], start, busy[], end} -> {success, done}