3. Our Experience With Existing Methodology
• Verification process has been successful
– Rigorous flow to guarantee chip success
– Successfully executed for several generations of chips
• Recently we have seen bugs found late in the verification process
– Such bugs are often malicious
– Indicate that we need to improve the methodology
– Need more visibility into what’s been tested
• Assertion based verification improves the visibility
3
4. Why ABV is Not Officially Part Of Our Flow
• We are familiar with assertion based verification (ABV)
– Some designers do write assertions
– We have experience on using formal tools with assertions
• Issues in manual ABV
– Learning SVA language and mastering assertion coding is challenging
• Difficult for designers to grasp the language after several training classes
• “Implication” is not intuitive
• Written assertions often do not EXACTLY match designer’s intent
– Debugging assertions requires simulation cycles and is time consuming
– No good measurement of the quality of hand written assertions
– No clear guideline on sufficient number of assertions
• Therefore, we don’t enforce ABV
– We encourage designers to write assertions
4
5. Overview of Assertion Synthesis Technology
• Assertion synthesis produces properties which
– Be true on all given tests
– Not directly implied by RTL only
– Not implied by other properties
• Designer review properties to decide if a property is an assertion or
reveals a coverage hole
– Assertions help block integration
– Coverage defines signoff criteria
• Why Broadcom select Nextop’s assertion synthesis tool BugScope?
– Improved quality of block level verification
• Our eval showed it can find corner case, late stage and post-silicon bugs missed in
our old flow
• Auto-generated properties provide good functional coverage with increased visibility
– High quality properties with low noise ratio
• On average, there are 1 property per 20 lines RTL
– Property review provides an excellent platform for design review
5
8. Experience On Enhanced Verification Flow
• Bugs found through BugScope in most blocks
– Most bugs cannot be found with the old flow
– Some bugs are found during property review
– Improved block level verification quality
• Classified assertions improve visibility at component/chip/emulation
– Large number of synthesized checkers to help capture problems and debug
– Provide a mechanism to collect coverage with no additional cost
• Overall investment is worthy
– The main cost is designer’s time to review properties
– Classified assertions are reused in all levels up (free)
• Connect flows at different stages
8
9. Bug1: Review Find Bugs Without Running Tests
Key observation: A spurious property often points to bugs directly
9
10. Bug2: Coverage Closure Find Corner Case Bugs
. Key observation: Better functional view than conditional coverage
10
11. Bug3: Better Debug On Emulation Using
Assertions
Key observation: Property to pinpoint the root cause of bugs
11
13. Future Improvement Area
• From what we experience, we like to see BugScope improves on
– Outputting cross module properties
– A GUI tool to support classification
• Allow more refined classification rules
– Performance improvement on large number of instances
• Performance is linear to number of instances per module
• Our methodology can improve in
– Seamless integration with emulation/TBA automation
– When and how many times we should run the tool
13
14. Conclusion
• Assertion Synthesis is a natural addition to the verification flow
– Increases block verification quality with meaningful functional coverage
– Provides the needed observability in chip/TBA/Emulation testing
– Reduces the demand for manual assertions
• Enhanced methodology is proven to be useful
– Based on the number of bugs found
– The quality of the found bugs
• Signoff with BugScope increase our verification confidence
14
