1. The Secrets of Practical Verification… © 2008 Think Verification

2. Introduction Welcome to “The Secrets of Practical Verification” What is Think Verification? A leading website about functional verification Lots of useful information Go to www.thinkverification.comwww.thinkverification.com Why is this lecture important? Improve work habits Learn from experience Apply advanced techniques Why? Because Verification takes a lot of time If we apply the Secrets of Practical Verification Verification will be more efficient Verification will take less time Verification will be less tiring © 2008 Think Verification

3. Secret #1 – Block design is done when its verification is done Common mistake in project management Detaching module design task from its verification task Defining “block done == RTL coding is complete” Verification is an integral part of block development A block with no verification is not going to work Block design is a confined task by nature Verification is a non confined effort by nature The secret to success Break down verification effort into small well-defined tasks Couple block design and block verification Define “block done” as “block verification is complete” Don’t start system level integration too early © 2008 Think Verification

4. Secret #2 – A verification plan with no priorities is not a verification plan What we usually think at the beginning of the project This time is going to be different We will cover each and every feature this time Therefore, no need for priorities The truth There’s never enough time to verify everything There is always enough time to verify the top priority features The solution Set strict priorities in the verification plan This will artificially confine verification effort and define boundaries Imagine working against a well prioritized plan © 2008 Think Verification

5. Secret #3 – Don’t get addicted to random tests Random Tests Very popular today Coverage Driven Verification “One test does it all” It’s all so true Directed Tests Have one big advantage – quick ROI Can also help verify corner cases Can be implemented with smart constraints So? Keep an open mind Use directed tests where needed– it’s OK. More information and examples in the article “To Randomize or not to Randomize” on Think Verification website © 2008 Think Verification

6. Secret #4 – Reuse isn’t luxury, it’s inevitable Common misconception “Reuse is good only if you want to use the same code in future projects” Not really… Can reuse code at different levels of verification Reusable code can serve multiple engineers during the same project What does “Reuse” really mean today? Coding style Advanced programming standards Object (Aspect) Oriented Programming Reuse as a way of life Write once, use always Helps handle enormous amounts of code Less code  less bugs © 2008 Think Verification

7. Secret #5 – Unenforced methodology only does more damage Does this sound familiar? Too many “methodology documents” Nobody knows exactly what is “company methodology” What to do? No methodology? Stick to industry-proven ones. Customize according to project needs Enforce your methodology in small steps What’s more? Use “skeletons” or code templates Go for short documents Make sure people add meaningful comments to their code © 2008 Think Verification

8. Secret #6 – Verification starts with Verification Plan + Typical Test The most practical secret What’s a Verification Plan? Long list of feature to be verified With priorities, remember? If you don’t know WHAT you want to verify, HOW can you verify it? What’s a Typical Test? Think of it as the User Interface of your environment It’s how the test writer will control your environments “knobs” What’s next? Don’t start before you’re clear about these 2 things Use your imagination to picture your SVE up and running and deduce back to understand how the SVE should be constructed SVE = Simulation and Verification Environment © 2008 Think Verification

9. Secret #7 – The Cold Swimming Pool Principle Verification is complex What’s the Cold Swimming Pool Principle? Imagine a cold swimming pool You put one leg in and wait ‘till you’ve gotten used to the cold You do the same with the other leg, and so on. Eventually, you’re ok and ready to swim What’s this got to do with Verification? Testing and Debug should be done gradually How else can you handle the huge amount of information that’s being simulated + bugs? Open constraints gradually, so you have prior knowledge of what’s supposed to happen Of course, at a certain point we need to go fully random What else? Code your environment in steps. © 2008 Think Verification

10. Thank You ! © 2008 Think Verification We’d love to hear your comments: mail@thinkverification.com