Finding Bugs Faster with Assertion Based Verification (ABV)

697 views
564 views

Published on

Published in: Technology, Design
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
697
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Finding Bugs Faster with Assertion Based Verification (ABV)

  1. 1. INVENTIVEKanwar Pal SinghCadence Design SystemsFinding Bugs Faster withAssertion Based Verification (ABV)
  2. 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• Conclusion2
  3. 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 backfrom top-level interfaces.• This is a form of black-boxverification.3Verification EnvironmentHDL
  4. 4. Assertion-Based Solution• Verification objects are added to “interesting” points inside thedesign.• These verification objectstransform 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 verification4Verification EnvironmentHDLAAAAAAAA
  5. 5. What is an Assertion?• Assertions are verificationobjects that:– Watch for forbiddenbehavior within a designblock or on it’s interfaces– Track expected behaviordocumented in theassertions– Improvement upon $display,$monitor and assertstatements5Verification EnvironmentHDLAAAAAAAA
  6. 6. Assertion Example6A description out of the spec“After interrupt is asserted, acknowledge must come”intriack0 1 2 3 4 5always @(posedge intr)beginrepeat (3) @(posedge clk);fork: pos_posbegin@(posedge iack)$display("Assertion Success",$time);disable pos_pos;endbeginrepeat (4) @(posedge clk);$display("Assertion Failure",$time);disable pos_pos;endjoinend // alwaysPSL : // psl ackn_protocol : assert always{ rose(intr)} |=> {[*2];iack }! @(posedge clk);SVA : ackn_protocol : assert property (@(posedge clk)$rose(intr) |=> ##2 iack);
  7. 7. Functional Verification With Assertions• Improved observability• Identifies errors where theytake place instead of at theoutputs• Monitors behavior for allvectors• Improved controllability• Improved coverage• Verification starts sooner7LargeDesignInterfaceConstraints andAssertionsAAAAAA AA AAAA A AA AARTLAssertionsVerification Environment
  8. 8. Assertion-based VerificationWhat are the High level Benefits?• Reduced TTM– Start verification sooner– Significantly improve the debug time (documented customercases have shown up to 50% time savings)• Facilitates verification reuse– Preserve design knowledge within Assertions• Same assertions can be used for simulation, formalanalysis, and acceleration• Productivity gains – stable model reached quicker– Coverage holes identified8
  9. 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 tests9
  10. 10. What Aren’t Assertions Used For?• Race conditions• Timing checks• Equivalence Checking• Checking data transformation• Code coverageLintingStatic timing analysisFormal equivalence checkingSimulation/AccelerationCode coverage tool10
  11. 11. Resources for Extracting AssertionsDomain Action to extract assertionSpecification Review specifications documentsand extract featuresPort list Review functionality of all blockports and extract featuresFlow diagrams and waveform Review data and control flowthrough block; extract featuresBlock functional characteristics Review block functionalcharacteristics; extract featuresTeam reviews Conduct team reviews to extractadditional features11Don’t worry about overlap, worry about holes
  12. 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• Conclusion12
  13. 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 IPcontaining assertions of the other language13
  14. 14. Recommended PSL and SVA Subset14Operators PSL SVA NotesSequence DelimitersConsecutive Repetition: zero or more cyclesConsecutive Repetition: one or more cyclesConsecutive RepetitionNon-Consecutive RepetitionSequence Concatenation (non-overlapping)Signal Edge DetectionPrevious Values of SignalsalwaysneverBoolean Livenessinterrupt{...}[*][+][*count] [*range][=count] [=range];rose(), fell()prev(sig, n)alwaysnevereventually!abortnotdisable iffSVA is implicitly always by defaultBoolean 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 formSVA only has sequence formSequence Non-Overlapping ImplicationSequence Overlapping Implication|=>|->|=>|->80% of assertions can be written with 20% of languageonehot, onehot0 $onehot, $onehot0Built-in Functions
  15. 15. Latest Language Standards• 1800-2009 – IEEE standard for System Verilog--UnifiedHardware Design, Specification, and VerificationLanguage– SVA is part of the standard and is covered in 2 chapters• 1850-2010 – IEEE standard for Property SpecificationLanguage (PSL)15
  16. 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• Conclusion16
  17. 17. ABV Tools17Functional Coverage• Assertions and cover directives measurefunctional coverage for each test.• Functional coverage from all tests iscombined into a report of the test suite’stotal functional coverage.Simulation (Dynamic ABV)• Assertions act as monitors duringsimulation.• Assertions can be used for interactivedebugging during simulation.• Assertion activity indicates functionalcoverage.Assertion-Based Acceleration (ABA)• Assertions helps isolate the cause offailures• Catch bugs that require long setup times• Accumulate additional coverageinformationFormal Analysis• Assertions define correct behavior andlegal inputs.• Exhaustive analysis of all possible stateswithout a testbench.• Improves productivity and quality.
  18. 18. Simulation + Assertions = Observability• Once an Assertion is violated, a message appears in theconsole:– 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) Assertiontest.inst1.example has failed (5 cycles, starting 440 NS)• Assertions can generate transactions18Points out explicitly whichexpression in a sequencecaused the failure
  19. 19. Static ABV + Assertions = Controllability• Verification can start early withouta testbench• Exhaustive verification withcounter example for failures• Helps find corner case bugs19
  20. 20. 20Simulation (Dynamic ABV)• Depends on quality of testbench• Follows specific paths• Limited controllability• Applicable later in design cycleFormal Analysis (Static ABV)• No testbench needed – can use earlier• Few depths typically equivalent tomillions of simulation vectors• Limited by state space explosion• Explored Depth– Uncovers local corner case bugs– Reports verification proof radiusReachableState SpacexxxxxxxxxxBugs triggeredwith simulationStartingState PointThe Difference Between Dynamic and Static• Exhaustive– Uncovers all possible bugsxxxxxx
  21. 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 onlyenvironment• 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 assertions21
  22. 22. Functional Coverage22•Formal AnalysisAAAAAAAAModule / Block•Formal Analysis•SimulationAAAAAAAAA AAAAAA AAAAAAIntegrated Blocks•Simulation•HW Acceleration•Emulation AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAA AAAAATop-level Integrated DesignAggregatedCoverageTotalCoverageMetricsPlan
  23. 23. ABV Methodology RecapJuly 8, 2011 Cadence Confidential: Cadence Internal Use Only23CoverageMetricsSpecPlanUnified MetricsAggregatedCoverage&CheckingLeverage assertions as checks for feature validation throughoutthe entire verification processVerificationEngineersDesignersEngineers
  24. 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• Conclusion24
  25. 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 numerousenvironments– Is independent of language25
  26. 26. Conclusion (2)• An ABV methodologyprovides– Productivity• Removes duplication ofeffort between designer andverification engineer• Encourages reuse– Quality• Executable specification• Formal exhaustiveness• Methodology focused onchecking in addition tocoverage26Traditional FlowRTL RTLBlock / Module Cluster / Block Full ChipRTL RTLRTLRTLSimulation SimulationHW-basedSimulationTestbenchStimuliFormal AnalysisPotential limited useConfidenceTime95+%DoneSim & HW+ some formalLimited sanity simIncisiveFormalVerifierIncisiveFormalVerifierHW-basedSimulationTestbenchStimuliTargeted useSimulationIncisiveFormalVerifierNew DoneTTM GainsOriginalDoneEnhanced FlowIncisiveUnifiedSimulatorIncisiveUnifiedSimulatorAssertion-BasedAcceleration

×