We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byJordy Kye
Modified over 2 years ago
The Secrets of Practical Verification… © 2008 Think Verification
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
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
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
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
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
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
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
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
Thank You ! © 2008 Think Verification We’d love to hear your comments: firstname.lastname@example.org
The First in GPON Verification Classic Mistakes Verification Leadership Seminar Racheli Ganot FlexLight Networks.
Week # 4 Quality Assurance Software Quality Engineering 1.
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
Kai H. Chang COMP 6710 Course NotesSlide ES- 1 Auburn University Computer Science and Software Engineering Course Notes : Examining the Specification Computer.
Describe the application and limits of procedural, object orientated and event driven programming.
1 Design and Integration: Part 2. 2 Plus Delta Feedback Reading and lecture repeat Ambiguous questions on quizzes Attendance quizzes Boring white lecture.
Chapter 7 The Practices: dX. 2 Outline Iterative Development Iterative Development Planning Planning Organizing the Iterations into Management Phases.
Program Design CMSC 201. Motivation We’ve talked a lot about certain ‘good habits’ we’d like you guys to get in while writing code. There are two main.
FPGA-Based System Design: Chapter 6 Copyright 2004 Prentice Hall PTR Topics n Design methodologies.
Computer Engineering 203 R Smith Agile Development 1/ Agile Methods What are Agile Methods? – Extreme Programming is the best known example – SCRUM.
WATERFALL DEVELOPMENT MODEL. Waterfall model is LINEAR development lifecycle. This means each phase must be completed before moving onto the next!!! WHAT.
By for Test Driven Development: Industry practice and teaching tool Robert Vanderwall, Ph.D. 1 WISTPC-15.
1 Lecture 5 Introduction to Software Engineering Overview What is Software Engineering Software Engineering Issues Waterfall Model Waterfall Model.
Software Engineering Salihu Ibrahim Dasuki (PhD) CSC102 INTRODUCTION TO COMPUTER SCIENCE.
Chapter 6 CASE Tools 1Chapter 6-- CASE TOOLS. Overview CASE Tools Flowcharts Decision tables Project management tools Prototyping Types & examples of.
© Janice Regan, CMPT 102, Sept CMPT 102 Introduction to Scientific Computer Programming The software development method algorithms.
10 JAVA MAXIMS: The Best Ways to Implement Your Design SJTU CLASS.
1 CODE TESTING Principles and Alternatives. 2 Testing - Basics goal - find errors –focus is the source code (executable system) –test team wants to achieve.
Software Engineering and Design Principles Chapter 1.
The Project AH Computing. Functional Requirements What the product must do! Examples attractive welcome screen all options available as clickable.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Introduction to Software Engineering CS-300 Fall 2005 Supreeth Venkataraman.
CompSci 230 Software Design and Construction
CIS-100 Chapter 3—The Ribbon. The Ribbon When you first open Word 2007, you may be surprised by its new look. Most of the changes are in the Ribbon, the.
1 Shawlands Academy Higher Computing Software Development Unit.
Business Building vs. “Get Rich Quick”
Advanced Web 2012 Lecture 4 Sean Costain PHP Sean Costain 2012 What is PHP? PHP is a widely-used general-purpose scripting language that is especially.
1 Design and Integration: Part 1 Nuggets about Design vs Project Management.
To Behave Everyday!!!8Things. Decades from now when you’re resting on your deathbed, you will not remember the days that were easy, you will cherish the.
Software Quality Assurance and Testing Fazal Rehman Shamil.
2. GATHERING REQUIREMENTS Object-Oriented Analysis and Design NTPCUG.
T Iteration Demo Team 13 I1 Iteration
Time Management Eric W. Ford, PhD 1/22/02. Plan a schedule of balanced activities. College life has many aspects that are very important to success.
Debugging, bug finding and bug avoidance Part 1 Alan Dix
Yeah but.. What do I do? Software Leadership Dan Fleck 2007.
1 The Software Development Process Systems analysis Systems design Implementation Testing Documentation Evaluation Maintenance.
Test Management Under construction – What happens? Maria Månsson.
Chapter 29: Integration Jacob Harper. The Integration Approach The order of adding components to a system is crucial Benefits to careful integration –
Individuals and interactions
Microsoft ® Office Outlook ® 2007 Training Manage your mailbox IV: Archive old messages P J Human Resources Pte Ltd presents:
Lecture 2b: Software Project Management CSCI102 - Introduction to Information Technology B ITCS905 - Fundamentals of Information Technology.
Westland Helicopters is an AgustaWestland Company.
GENERAL CONCEPTS OF OOPS INTRODUCTION With rapidly changing world and highly competitive and versatile nature of industry, the operations are becoming.
Unit 1 – Improving Productivity Instructions ~ 100 words per box.
1 Legacy Code From Feathers, Ch 2 Steve Chenoweth, RHIT Right – Your basic Legacy, from Subaru, starting at $ 20,295, 24 city, 32 highway.
CS 1120: Computer Science II Software Life Cycle Slides courtesy of: Prof. Ajay Gupta and Prof. James Yang (format and other minor modifications by by.
Test Driven Development Introduction Issued date: 8/29/2007 Author: Nguyen Phuc Hai.
Software Engineering Principles Principles form the basis of methods, techniques, methodologies and tools Principles form the basis of methods, techniques,
CSI 101 Elements of Computing Spring 2009 Lecture #2 Development Life Cycle of a Computer Application Monday January 26th, 2009.
© 2017 SlidePlayer.com Inc. All rights reserved.