1) Assertion-based verification introduces assertions into a design to improve observability and controllability during simulation and formal analysis. 2) Assertions define expected behavior and can detect errors by monitoring signals within a design. 3) An assertion-based verification methodology leverages assertions throughout the verification flow from module to system level using various tools like simulation, formal analysis, and acceleration for improved productivity, quality, and reduced verification time.

1. INVENTIVE
Kanwar Pal Singh
Cadence Design Systems
Finding Bugs Faster with
Assertion Based Verification (ABV)

2. Agenda
• Assertion-Based Verification Introduction
• Assertion Languages
– SVA and PSL
– Language Standards
• ABV Tools and Methodology
– What does each tool do?
– How do these tools complement each other?
– Overall methodology
• Conclusion
2

3. Traditional Verification
• Verification typically is focused on:
– Providing stimulus to blocks or an entire design.
– Watching for a response.
– The stimulus is applied to top-level interfaces, the response is read back
from top-level interfaces.
• This is a form of black-box
verification.
3
Verification Environment
HDL

4. Assertion-Based Solution
• Verification objects are added to “interesting” points inside the
design.
• These verification objects
transform a “black-box”
verification, to a “white-box”
scenario
• The effort needed to create the “white-box” scenario:
– Makes verification more efficient
– Allows you to use additional technology for verification
4
Verification Environment
HDL
A
A
A
AA
A
A
A

5. What is an Assertion?
• Assertions are verification
objects that:
– Watch for forbidden
behavior within a design
block or on it’s interfaces
– Track expected behavior
documented in the
assertions
– Improvement upon $display,
$monitor and assert
statements
5
Verification Environment
HDL
A
A
A
AA
A
A
A

6. Assertion Example
6
A description out of the spec
“After interrupt is asserted, acknowledge must come”
intr
iack
0 1 2 3 4 5
always @(posedge intr)
begin
repeat (3) @(posedge clk);
fork: pos_pos
begin
@(posedge iack)
$display("Assertion Success",$time);
disable pos_pos;
end
begin
repeat (4) @(posedge clk);
$display("Assertion Failure",$time);
disable pos_pos;
end
join
end // always
PSL : // psl ackn_protocol : assert always
{ rose(intr)} |=> {[*2];iack }! @(posedge clk);
SVA : ackn_protocol : assert property (@(posedge clk)
$rose(intr) |=> ##2 iack);

7. Functional Verification With Assertions
• Improved observability
• Identifies errors where they
take place instead of at the
outputs
• Monitors behavior for all
vectors
• Improved controllability
• Improved coverage
• Verification starts sooner
7
Large
Design
Interface
Constraints and
Assertions
A
A
A
A
A
A A
A A
A
A
A A A
A AA
RTL
Assertions
Verification Environment

8. Assertion-based Verification
What are the High level Benefits?
• Reduced TTM
– Start verification sooner
– Significantly improve the debug time (documented customer
cases have shown up to 50% time savings)
• Facilitates verification reuse
– Preserve design knowledge within Assertions
• Same assertions can be used for simulation, formal
analysis, and acceleration
• Productivity gains – stable model reached quicker
– Coverage holes identified
8

9. What Are Assertions Used For?
• Assuring that the interface of the design is being exercised correctly
• Finding errors deep within the design
• Identifying hard-to-find corner cases
• Improving simulation tests with coverage analysis
– Identify holes in the set of tests
– Eliminate inefficient or redundant tests
9

10. What Aren’t Assertions Used For?
• Race conditions
• Timing checks
• Equivalence Checking
• Checking data transformation
• Code coverage
Linting
Static timing analysis
Formal equivalence checking
Simulation/Acceleration
Code coverage tool
10

11. Resources for Extracting Assertions
Domain Action to extract assertion
Specification Review specifications documents
and extract features
Port list Review functionality of all block
ports and extract features
Flow diagrams and waveform Review data and control flow
through block; extract features
Block functional characteristics Review block functional
characteristics; extract features
Team reviews Conduct team reviews to extract
additional features
11
Don’t worry about overlap, worry about holes

12. Agenda
• Assertion-Based Verification Introduction
• Assertion Languages
– SVA and PSL
– Language Standards
• ABV Tools and Methodology
– What does each tool do?
– How do these tools complement each other?
– Overall methodology
• Conclusion
12

13. PSL vs SVA
• THERE IS NO BAD CHOICE TO MAKE
– Besides some subtle differences, they are very similar
• Recommendations
– Pick a language as there is no need to learn both
– Have a verification environment that supports both
• It is quite likely that whatever you pick, you will run into IP
containing assertions of the other language
13

14. Recommended PSL and SVA Subset
14
Operators PSL SVA Notes
Sequence Delimiters
Consecutive Repetition: zero or more cycles
Consecutive Repetition: one or more cycles
Consecutive Repetition
Non-Consecutive Repetition
Sequence Concatenation (non-overlapping)
Signal Edge Detection
Previous Values of Signals
always
never
Boolean Liveness
interrupt
{...}
[*]
[+]
[*count] [*range]
[=count] [=range]
;
rose(), fell()
prev(sig, n)
always
never
eventually!
abort
not
disable iff
SVA is implicitly always by default
Boolean Overlapping Implication ->
Boolean Non-Overlapping Implication -> next Avoid nested “-> next”
(...)
[*0:$]
[*1:$]
[*count] [*range]
[*=count] [*=range]
##1
$rose(), $fell()
$past(sig, n)
Sequence Strong Interpretation ! SVA only has a strong form
SVA only has sequence form
Sequence Non-Overlapping Implication
Sequence Overlapping Implication
|=>
|->
|=>
|->
80% of assertions can be written with 20% of language
onehot, onehot0 $onehot, $onehot0Built-in Functions

15. Latest Language Standards
• 1800-2009 – IEEE standard for System Verilog--Unified
Hardware Design, Specification, and Verification
Language
– SVA is part of the standard and is covered in 2 chapters
• 1850-2010 – IEEE standard for Property Specification
Language (PSL)
15

16. Agenda
• Assertion-Based Verification Introduction
• Assertion Languages
– SVA and PSL
– Language Standards
• ABV Tools and Methodology
– What does each tool do?
– How do these tools complement each other?
– Overall methodology
• Conclusion
16

17. ABV Tools
17
Functional Coverage
• Assertions and cover directives measure
functional coverage for each test.
• Functional coverage from all tests is
combined into a report of the test suite’s
total functional coverage.
Simulation (Dynamic ABV)
• Assertions act as monitors during
simulation.
• Assertions can be used for interactive
debugging during simulation.
• Assertion activity indicates functional
coverage.
Assertion-Based Acceleration (ABA)
• Assertions helps isolate the cause of
failures
• Catch bugs that require long setup times
• Accumulate additional coverage
information
Formal Analysis
• Assertions define correct behavior and
legal inputs.
• Exhaustive analysis of all possible states
without a testbench.
• Improves productivity and quality.

18. Simulation + Assertions = Observability
• Once an Assertion is violated, a message appears in the
console:
– reports beginning: start time (when finished or failed is reported)
– reports length in terms of cycle (when finished or failed is reported)
– points to expression that was violated (when failed is reported)
– prints the assertion statement portion (when failed is reported)
// psl example: assert always {e;f;g} |=> {g; d | e; c};
|
ncsim: *E,ASRTST (./test.v,68): (time 500 NS) Assertion
test.inst1.example has failed (5 cycles, starting 440 NS)
• Assertions can generate transactions
18
Points out explicitly which
expression in a sequence
caused the failure

19. Static ABV + Assertions = Controllability
• Verification can start early without
a testbench
• Exhaustive verification with
counter example for failures
• Helps find corner case bugs
19

20. 20
Simulation (Dynamic ABV)
• Depends on quality of testbench
• Follows specific paths
• Limited controllability
• Applicable later in design cycle
Formal Analysis (Static ABV)
• No testbench needed – can use earlier
• Few depths typically equivalent to
millions of simulation vectors
• Limited by state space explosion
• Explored Depth
– Uncovers local corner case bugs
– Reports verification proof radius
Reachable
State Space
x
x
x
x
x
x
x
x
x
x
Bugs triggered
with simulation
Starting
State Point
The Difference Between Dynamic and Static
• Exhaustive
– Uncovers all possible bugs
x
x
xx
x
x

21. Assertion-based Acceleration (ABA)
• Assertion support in the acceleration adds observability with performance
– Enables exposing design problems quicker and reducing debug times
– Enables assertion firings from ‘long’ runs not viable in a simulation only
environment
• Supports same set of design files as simulation
• Executes long simulation runs much quicker
– Enables System level simulation with assertions
– Enables software bring-up with assertions
21

22. Functional Coverage
22
•Formal AnalysisA
A
A
A
A
A
A
A
Module / Block
•Formal Analysis
•Simulation
A
A
A
A
A
A
A
AA A
A
A
A
A
A A
A
A
A
AA
Integrated Blocks
•Simulation
•HW Acceleration
•Emulation A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A A
A
A
A
A
A
A
AA
A
A
A
A
A
A A
A
A
AA
Top-level Integrated Design
Aggregated
Coverage
Total
Coverage
Metrics
Plan

23. ABV Methodology Recap
July 8, 2011 Cadence Confidential: Cadence Internal Use Only23
Coverage
Metrics
Spec
Plan
Unified Metrics
Aggregated
Coverage
&
Checking
Leverage assertions as checks for feature validation throughout
the entire verification process
Verification
Engineers
Designers
Engineers

24. Agenda
• Assertion-Based Verification Introduction
• Assertion Languages
– SVA and PSL
– Language Standards
• ABV Tools and Methodology
– What does each tool do?
– How do these tools complement each other?
– Overall methodology
• Conclusion
24

25. Conclusion (1)
• An ABV methodology
– Begins with planning
– Spans the entire verification process from module to system
– Includes formal, simulation, and emulation/acceleration
– Is maximized by the integration of metrics from numerous
environments
– Is independent of language
25

26. Conclusion (2)
• An ABV methodology
provides
– Productivity
• Removes duplication of
effort between designer and
verification engineer
• Encourages reuse
– Quality
• Executable specification
• Formal exhaustiveness
• Methodology focused on
checking in addition to
coverage
26
Traditional Flow
RTL RTL
Block / Module Cluster / Block Full Chip
RTL RTLRTLRTL
Simulation Simulation
HW-based
Simulation
Testbench
Stimuli
Formal Analysis
Potential limited use
Confidence
Time
95+%
Done
Sim & HW
+ some formal
Limited sanity sim
Incisive
Formal
Verifier
Incisive
Formal
Verifier
HW-based
Simulation
Testbench
Stimuli
Targeted use
Simulation
Incisive
Formal
Verifier
New Done
TTM Gains
Original
Done
Enhanced Flow
Incisive
Unified
Simulator
Incisive
Unified
Simulator
Assertion-Based
Acceleration