![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);](https://image.slidesharecdn.com/kawarpal-dvclub-130422122838-phpapp02/85/Finding-Bugs-Faster-with-Assertion-Based-Verification-ABV-6-320.jpg)
![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](https://image.slidesharecdn.com/kawarpal-dvclub-130422122838-phpapp02/85/Finding-Bugs-Faster-with-Assertion-Based-Verification-ABV-14-320.jpg)
Finding Bugs Faster with Assertion Based Verification (ABV)
- 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