1. Assertion-Based Verification
ABV

2. Assertion
Assertion:
is a conditional statement that checks for specific behavior and displays a message if it does not occur.
In Traditional Languages:
Designers historically had the ability to craft assertions using both the Verilog and VHDL design languages.
Lacking an assertion statement, the Verilog designer used a conditional statement to trigger the output of an error message.
The VHDL designer used the assert statement inherent in VHDL to check for the violation of a condition and to output a message.

3. Benefits Providing internal test points in the design.
Simplifying the diagnosis and detection of bugs by localizing the occurrence of a suspected bug to an assertion monitor, which is then checked.
Allowing designers to verify the same assertions using both simulation and formal verification.
Increasing observability in both simulation and formal verification.
Since the assertions were included in the design as it was created, formal verification could be started earlier, before any test vectors had been written.
Assertions are also used at the design boundaries to provide checks for interface behavior.
Useful when modules from different designers are integrated. Such interface-checking assertions make modules more portable.
 Modules with embedded assertions become self-checking wherever they are later reused.

4. Assertion in VHDL Syntax:
assert desired_condition report “repot message” severity severity_level
Modeling properties of the hardware system via “assert” is hard and tedious

5. Example1

6. Example2:

7. PSL (Property Specification Language)
What is PSL?
A declarative language for describing behavior and properties of system over time
Key characteristics of PSL :
Mathematically precise well-defined formal semantics.
Known efficient underlying verification algorithms.
Intuitive and easy to learn, read, and write.
A layered language, ideal for reuse, and supports multiple HDL flavors
VHDL
Verilog
SystemC
SystemVerilog

8. Use of PSL Formal verification ( Static verification ) Simulation
Documentation:
easy to read and write but precise and executable property description instead of ambiguity of natural languages is omitted
Driving Assertion-Based Verification:
Formal verification
( Static verification )
Simulation
( Dynamic verification )
Assertion based verification helps us in defining bugs at an earlier stage, before propagating to other parts of design

9. History FVTC: Formal Verification Technical Committee.
Sugar created at IBM
Haifa Research Labs
1994
1998
FVTC
formed in Accellera (OVI)
2001
FVTC considers: Temporal e
CBV ForSpec
Sugar
Linear-time semantics
Added to Sugar
Branching-time semantics
plus regular expressions
Syntactic sugaring of CTL
PSL
based on Sugar 2.0
2002
PSL 1.01
Approved
2003
2004
PSL 1.1
2005
IEEE 1850
PSL enhancements and clarifications
Sugar began as an internal development within IBM, where the CTL formalism (Computation Tree Logic) was used to express properties for model checking. The raw CTL notation allows the concise expression of temporal relationships, but was found hard to write and read by non-specialists. Sugar was developed to provide syntactic sugaring on top of CTL, , i.e. a layer of user-friendly syntax to hide the more obscure notation.
FVTC: Formal Verification Technical Committee.

10. PSL: A Layered Language
Boolean
Temporal
Verification
Modeling

11. PSL: A Layered Language
Boolean
Temporal
Verification
Modeling
assert
always
( not (A and B) )

12. Boolean Layer The Boolean layer is used to:
Specify logic expressions without specific timing information using a standard HDL syntax such as Verilog and VHDL
Example (Verilog):
// A and B are mutually exclusive
( !(A & B) )
Example (VHDL):
-- A and B are mutually exclusive
( not (A and B) )
Note that a property of a design states nothing about how to use it during verification!
An assertion is a specific property that is to be verified, while a constraint is a specific property of the environment that must not be violated during verification.

13. Boolean Layer
Any subprograms, overloaded functions etc. allowed in a VHDL boolean expression can be used.
Example:
always (unsigned(ASLV) <= 10)
always (MYFUNC(B) = '1')
For a VHDL expression containing only std_logic values, the equality operator (= ’1’ or = ’0’) can be omitted:
PSL interprets std_logic ’1’ as true and std_logic ’0’ as false.
never ((GNT and BUSY) = ’1’)
never (GNT and BUSY)
For a VHDL expression containing mixed boolean and std_logic values, the equality to ’1’ or ’0’ is required because VHDL logical operators cannot be used for combinations of boolean and std_logic types
Note that a property of a design states nothing about how to use it during verification!
An assertion is a specific property that is to be verified, while a constraint is a specific property of the environment that must not be violated during verification.

14. Temporal Layer always property never property next property
The temporal layer is used to:
Specify when the Boolean expression must be valid
Example:
// A and B are always mutually exclusive
always ( not (A and B) )
t.!(A(t) & B(t))
There are many temporal operators:
always property
never property
next property
until property …

15. Temporal Layer Operators
Occurrence operators:
always: the property should hold in every cycle.
never: the property should not hold during any cycle.
eventually!: the property shall hold in some cycle in the future but before the end of verification process.
next: the property shall hold in the next cycle(s).
Clock Cycle Definition:
never (GNT and
always (EN1 or and CLK = ’1’);
always(ACK -> next (not
It is possible to define a default clock and thus avoid the need to repeat the explicit clock in every single assertion.
default clock = (rising_edge (clk));
assert always CONDITION;

16. Temporal Layer Operators
until operator:
requires that first property hold till the second property holds.
pkt_startop |-> not pkt_xfer_en_n until pkt_endop
once a packet is started, the pkt_xfer_en_n shall be low until the packet ends.
before operator:
requires that one property hold before another.
opcode_fetch before execute_opcode;
an opcode_fetch process should occur before an execute_opcode phase
abort operator:
there is a need to abort the checking in case of a reset, soft reset, pkt_abort etc.
({pkt_sop} |-> {not pkt_xfer_en_n until pkt_eop}) abort pkt_abort;
aborts checking once a pkt_abort is seen.

17. Verification Layer Specify how to use the property:
The verification layer is used to:
Specify how to use the property:
assert: the tool should attempt to prove the property,
assume: the tool may assume the given property is true,
cover: the tool should measure how often the given property occurs during simulation.
Example1:
// A and B must always be mutually exclusive
assert always ( not (A and B) );
Example2:
assert (always (clk));

18. Modeling Layer
The modeling layer is used to:
allows extra code fragments from the underlying language (VHDL) to be included with the properties to augment what is possible using PSL alone.
For example, the modeling layer could be used to calculate the expected value of an output.
Example:
// If req is asserted, ack must be asserted in the next cycle
SIGNAL req;
req <= readA_req or readB_req;
-- psl assert always (req -> next (ack and gnt)) @rising_edge(clk);

19. PSL Layers signal req; req <= readA_req OR readB_req;
-- psl assert always (req -> next (ack AND gnt))
Boolean layer
Temporal layer
Verification layer
Modeling layer

20. Usage
Verification directives can be embedded in the HDL code as comments.
-- psl property ENABLED is always …
Can break over several lines as long as each line is commented.
-- These assertions are complete!
-- psl property NOT_GNTBUSY is
-- never (GNT and
-- psl property P1 is
-- always(ACK -> next (not
-- psl assert NOT_GNTBUSY;
-- psl assert P1;
Note: VHDL comments are not allowed inside a PSL assertion, i.e. between psl and the semi-colon terminating the assertion.

21. Usage
Assertions can be placed anywhere in a VHDL component, but it is better to group them together at the begining or end of your design code.
2. Alternatively, verification directives can be grouped into verification units, or vunits, and placed in a separate file.
Note: PSL keywords are case sensitive.

22. PSL Sequences Sequential Extended Regular Expressions:
SERE:
Sequential Extended Regular Expressions:
Where enabling and fulfilling conditions extended over several cycles.
PSL sequences enable us to describe a sequence of Boolean expressions (i.e. states)
PSL sequences are marked by curly braces ‘{’ and ‘}’.
Advancement of time occurs with each concatenation operator ‘;’
Example:
{ req; busy; gnt }

23. PSL Sequences Matching
A PSL sequence can have multiple matching diagrams
one possible match
req
busy
gnt
req
busy
gnt
another possible match
Example:
{ req; busy; gnt }
To explicitly match the waveform, we would need to specify the following
Example:
{ req and not busy and not gnt ;
not req and busy and not gnt ;
not req and not busy and gnt }
req
busy
gnt

24. Temporal Operators for Sequences
PSL supports the following temporal operators for sequences:
Overlapping implication |->
Non-overlapping implication |=>
Equivalent to next |->
Example(s):
sequence S1 = { req; ack } ;
sequence S2 = { start; busy; end } ;
// Event “start” occurs on the same clock cycle as “ack”
property P1 = always S1 |-> S2 ;
// Event “start” occurs on the next clock cycle after “ack”
property P2 = always S1 |=> S2 ;

25. Temporal Operators for Sequences
fifo_almost_full |=> fifo_push |-> fifo_full;
Once the fifo is almost full, a push in the next clock cycle shall make the fifo_full to be asserted (in the same clock as the fifo_push occurred).

26. Liveness Properties This is known as a liveness property.
assert always req -> eventually! ack;
i.e. whenever req is true, ack must go true at some future cycle, but there is no upper limit on the time by which ack is required to go true.
This is known as a liveness property.
Liveness properties are characterized by the fact that they do not possess a finite counter-example, and hence in principle they cannot be disproved by simulation.
However, liveness properties can in principle be proved or disproved by static model checking tools.

27. Evaluation of SERE Assertion
A SERE assertion, evaluated over several cycles, can pass through several states:
An assertion starts inactive.
At every evaluation point (e.g. clock edge), the first condition in the enabling SERE is checked.
If this condition is true, the assertion becomes active.
If the enabling SERE fails to complete, then the assertion becomes inactive without any error message.
If the enabling SERE completes, then the assertion is enabled and the fulfilling SERE is checked.
If this completes then the assertion passes.
If the fulfilling SERE of an enabled assertion does not complete, the assertion fails.

28. Operators for SERE PSL supports the following operators for SERE:
Repetition in n consecutive clock cycles [*n]
Repetition in n non-consecutive clock cycles [=n]
Repetition in n non-consecutive clock cycles [->n]
we want to go to the nth repetition and immediately (1 clock after) after the occurrence of that last repetition we would like to check for the next expression in sequence. The intermediate repetitions may be non-consecutive i.e. can be spread across multiple cycles
Repetition for 0 or any number of clock cycles [*]
Repetition for 1 or any number of clock cycles [+]
Repetition for n to m clock clock cycles [*n:m]
The number of repetitions must be a positive integer
Keyword inf stands for an infinite number of clock cycles

29. Operators for SERE {S; T[*3]; V} Equivalent to {S; T; T; T; V}
{a[*2]} means {a;a}
{S; T[*3]; V} Equivalent to {S; T; T; T; V}
{a[*]} means {a;a;...;a} with a repeated zero or more times
{a[+]} means {a;a;...;a} with a repeated one or more times
{[*]} matches any sequence whatsoever
{S; [*2]; V} Equivalent to {S; -; -; V}
where - represents a cycle in which no checks are performed
Or operator:
sequence S4 is {B; C};
sequence S5 is {R; S};
property P3 is
always ( {T} |=> {S4} | {S5} );
After T occurs, either S4 or S5 must start in the next evaluation cycle.
The following sequences would satisfy this property:-
Sequence 1 is {T; B; C}
Sequence 2 is {T; R; S}
Sequence 3 is {T; (B and R); S}
In sequence 3, both S4 and S5 start in the cycle following T. However only S5 completes.
{a[=2]} means {[*];a;[*];a;[*]}, i.e. non-consecutive repetition
{a[*1 to 3]} means {a} or {a;a} or {a;a;a}

30. Operators for SERE Example(s): sequence S1 = { rd[*5] } ;
// means {rd;rd;rd;rd;rd}
sequence S2 = { rd[->3] } |=> { wr } ;
// {not rd[*]; rd; not rd[*]; rd; not rd[*]; rd}
sequence S3 = { req} |=> { ack[=1]; done} ;
// {not ack[*]; ack; not ack[*]}
sequence S4 = { rd[*]; rd; wr };
sequence S5 = { rd[+]; wr } ;
sequence S6 = { rd[*2:5] } |=> { wr } ;

31. Example clock req ack write wait done
property P1 = { req[+]; ack; wr[*4] } |=> { (wait and (not req))[*]; done } ;
assert always P1;
write
wait
req
ack
done
clock
0 or more
1 or more

32. Example Properties are Derived from Specification
Receiving Data:
When the reception of data is complete, then an interrupt should occur:
property done_rcving_implies_int = always rose(done_rcving) -> rose(int) ; assert done_rcving_implies_int ;

33. Example Properties are Derived from Specification
Receiving Data:
If the signal that indicates a reception in progress is active, then it should remain active until the reception is complete:
property rcving_until_done_rcving = always rose(rcving) -> (rcving until done_rcving) ; assert rcving_until_done_rcving ;
For a given property f and signal clk, clk), and all have equivalent
semantics, provided that signal clk takes on only 0 and 1 values, and no signal in f changes at the same time as clk

34. [Example] RTL Implementation Queue
Design intent
“If Queue is full, then an attempt to insert data is ignored.” (Overflow)
“If Queue is empty, then an attempt to remove data is ignored.” (Underflow)
RTL implementation fragment:
function [3:0] qNext;
input [3:0] p;
qNext = ((p + 1) mod `qSize);
endfunction;
assign qFull = (qNext(qLast) == qFirst);
assign qEmpty = (qLast == qFirst); …
PSL implementation assertions:
assert always (qFull and qInsert -> next not qEmpty) abort ~rstN ;
assert always (qEmpty and qRemove -> next not qFull) abort ~rstN;
qFirst
qLast
qInsert
qRemove
qEmpty
qFull
qDataIn
qDataOut 1 2 3 4 5 6 7
qError
cntrl
In this example, we demonstrate how to code a few simple RTL implementation assertions using the OVL. The assertions in this example specify that the attempt to insert data into a full queue will be ignored, and no incorrect behavior will occur. Similarly, an attempt to remove data from an empty queue will not result in incorrect behavior.

35. Verification Units VU for Grouping Properties and Directives Example:
Verification with PSL is based on using verification units
vunit <name> [(<module binding>)] {
<declarations and verification layer directives> };
RTL module
vunit
inputs
outputs
A vunit binds to a module or an instance
Usually a separate file from RTL
Example:
vunit my_unit (my_module) {
default clock = rising_edge (clk);
assume never read AND write;
property P1 = never (full AND write);
assert P1;
assert always (read -> NOT empty); };

36. [Types of Assertions and PSL Expressiveness]
Data
Integrity
Packet Ordering
High-level requirements
End-to-end
Black box
Based on design intent
Generally require modeling+assertions
Design Intent
RTL Implementation
RTL implementation assertions
Localized
Implementation-specific
Generally can be expressed using only assertions
This slide illustrates the difference between high-level requirements and RTL implementation assertions. Note that RTL implementation assertions are ideal for simulation, since they isolate the problem down to a small section of the RTL code. High-level requirements, however, are ideal for formal verification, since they verify more behavior, and correspond to requirements defined in the micro-architectural specification.
One important difference between higher-level assertions (used to specify high-level requirements) and lower-level assertions (used to describe implementation details) is that higher-level assertions require a little additional modeling (often coded with Verilog or VHDL) combined with an assertion language to express the intended complex behavior. Lower-level assertions can be expressed directly using an assertion language and generally do not require extra modeling to express the intended implementation behavior
Increment
By 1
One
Hot
FIFO Overflow
FIFO Overflow
Design Behavior

37. Tools ( cont )

38. Refrences
URL: Property Specification Language Reference Manual Version 1.1
URL:
URL:
URL:
URL:
URL:
URL:
URL:
URL:
URL:
URL:
URL:

39. Companies and Tools Simulation Formal Verification @HDL Cadence
@Verifier Studio
@Verifier
Cadence
Incisive Unified Simulator
Incisive Static Verifier
Mentor Graphics
ModelSim 5.8
Safelogic
Safelogic Monitor and Safelogic Verifier
0-in
Esterel
FTL
IBM