Who’s Watching the Watchmen? The Time has Come to Objectively Measure the Quality of Your Verification by David Brownell Design Verification Analog Devices.

Slides:



Advertisements
Similar presentations
© Copyright 2013 Xilinx. How to Kill 4 Birds with 1 Stone: Using Formal Verification to Validate Legal Configurations, Find Design Bugs, and Improve Testbench.
Advertisements

Configuration management
Test process essentials Riitta Viitamäki,
Javascript Code Quality Check Tools Javascript Code Quality Check Tools JavaScript was originally intended to do small tasks in webpages, but now JavaScript.
Detecting Bugs Using Assertions Ben Scribner. Defining the Problem  Bugs exist  Unexpected errors happen Hardware failures Loss of data Data may exist.
- Verifying “Golden” reused IPs The Evil’s in the Edits William C Wallace Texas Instruments Nitin Jayaram Texas Instruments Nitin Mhaske Atrenta Inc Vijay.
CSE 331 SOFTWARE DESIGN & IMPLEMENTATION DEBUGGING Autumn 2011 Bug-Date: Sept 9, 1947.
Software Testing Testing.
Xiushan Feng* ASIC Verification Nvidia Corporation Automatic Verification of Dependency 1 TM Jayanta Bhadra
Annoucements  Next labs 9 and 10 are paired for everyone. So don’t miss the lab.  There is a review session for the quiz on Monday, November 4, at 8:00.
Effective RTL coding rules to avoid Simulation Shoot-thru Udit Kumar 1, Bhanu Prakash 1, Olivier Florent 1, Paras Mal Jain 2, Anshu Malani 2, Shaker Sarwary.
Mutation Analysis with Coverage Discounting Peter Lisherness, Nicole Lesperance, and Kwang-Ting (Tim) Cheng University of California – Santa Barbara.
MS-SoC Best Practices – Advanced Modeling & Verification Techniques for first-pass success By Neyaz Khan Greg Glennon Dan Romaine.
Coverage Discounting: Improved Testbench Qualification by Combining Mutation Analysis with Functional Coverage Nicole Lesperance, Peter Lisherness, and.
(Quickly) Testing the Tester via Path Coverage Alex Groce Oregon State University (formerly NASA/JPL Laboratory for Reliable Software)
Important concepts in software engineering The tools to make it easy to apply common sense!
Testing HCI Usability Testing. Chronological order of testing Individual program units are built and tested (white-box testing / unit testing) Units are.
CSC 395 – Software Engineering Lecture 9: Testing -or- How I Stopped Worrying and Learned to Love the Bug.
Applied Software Project Management 1 Introduction Dr. Mengxia Zhu Computer Science Department Southern Illinois University Carbondale.
2/9/2007EECS150 Lab Lecture #41 Debugging EECS150 Spring2007 – Lab Lecture #4 Laura Pelton Greg Gibeling.
EE694v-Verification-Lect5-1- Lecture 5 - Verification Tools Automation improves the efficiency and reliability of the verification process Some tools,
Principle of Functional Verification Chapter 1~3 Presenter : Fu-Ching Yang.
02/10/06EECS150 Lab Lecture #41 Debugging EECS150 Spring 2006 – Lab Lecture #4 Philip Godoy Greg Gibeling.
Types and Techniques of Software Testing
CS527: (Advanced) Topics in Software Engineering Overview of Software Quality Assurance Tao Xie ©D. Marinov, T. Xie.
Microsoft ® Office Outlook ® 2007 Training See and Use Multiple Calendars ICT Staff Development presents:
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
CS 501: Software Engineering Fall 1999 Lecture 16 Verification and Validation.
CMSC 345 Fall 2000 Unit Testing. The testing process.
1 Debugging and Testing Overview Defensive Programming The goal is to prevent failures Debugging The goal is to find cause of failures and fix it Testing.
SOFTWARE ENGINEERING1 Introduction. Software Software (IEEE): collection of programs, procedures, rules, and associated documentation and data SOFTWARE.
What is Software Testing? And Why is it So Hard J. Whittaker paper (IEEE Software – Jan/Feb 2000) Summarized by F. Tsui.
Chapter 8 – Software Testing Lecture 1 1Chapter 8 Software testing The bearing of a child takes nine months, no matter how many women are assigned. Many.
ASIC/FPGA design flow. FPGA Design Flow Detailed (RTL) Design Detailed (RTL) Design Ideas (Specifications) Design Ideas (Specifications) Device Programming.
 CS 5380 Software Engineering Chapter 8 Testing.
1 Extending FPGA Verification Through The PLI Charles Howard Senior Research Engineer Southwest Research Institute San Antonio, Texas (210)
The First in GPON Verification Classic Mistakes Verification Leadership Seminar Racheli Ganot FlexLight Networks.
Dr. Tom WayCSC Testing and Test-Driven Development CSC 4700 Software Engineering Based on Sommerville slides.
From Quality Control to Quality Assurance…and Beyond Alan Page Microsoft.
DEBUGGING. BUG A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected.
Testing and Debugging Session 9 LBSC 790 / INFM 718B Building the Human-Computer Interface.
Software Testing and Maintenance 1 Code Review  Introduction  How to Conduct Code Review  Practical Tips  Tool Support  Summary.
What is Testing? Testing is the process of finding errors in the system implementation. –The intent of testing is to find problems with the system.
Design - programming Cmpe 450 Fall Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors.
Software Engineering 2004 Jyrki Nummenmaa 1 BACKGROUND There is no way to generally test programs exhaustively (that is, going through all execution.
12/14/2015 Concept of Test Driven Development applied to Embedded Systems M. Smith University of Calgary, Canada 1 Automated Testing Environment Concepts.
EE694v-Verification-Lect7-1- Verification Plan & Levels of Verification The Verification Plan Yesterdays and today’s design environment Design specification.
PROGRAMMING TESTING B MODULE 2: SOFTWARE SYSTEMS 22 NOVEMBER 2013.
Chapter 11 System-Level Verification Issues. The Importance of Verification Verifying at the system level is the last opportunity to find errors before.
Detecting Hardware Trojans in Unspecified Functionality Using Mutation Testing Nicole Fern K.-T. Tim Cheng UC Santa Barbara 1.
SOFTWARE TESTING SOFTWARE TESTING Presented By, C.Jackulin Sugirtha-10mx15 R.Jeyaramar-10mx17K.Kanagalakshmi-10mx20J.A.Linda-10mx25P.B.Vahedha-10mx53.
What is a software? Computer Software, or just Software, is the collection of computer programs and related data that provide the instructions telling.
Testing Integral part of the software development process.
Operating System Concepts with Java – 7 th Edition, Nov 15, 2006 Silberschatz, Galvin and Gagne ©2007 Chapter 0: Historical Overview.
A Few Review Questions Dan Fleck Fall System Test Case Enter invalid username in the input box Able to enter text Enter invalid password in the.
CSC 108H: Introduction to Computer Programming
Testing Tutorial 7.
Chapter 8 – Software Testing
Verification and Testing
Software Testing.
Fast Track Formal Verification Signoff
Software testing strategies 2
Automated Testing Environment
Testing and Test-Driven Development CSC 4700 Software Engineering
EECS150 Fall 2007 – Lab Lecture #4 Shah Bawany
Debugging EECS150 Fall Lab Lecture #4 Sarah Swisher
Debugging EECS150 Fall Lab Lecture #4 Sarah Swisher
that focus first on areas of risk.
Test Cases, Test Suites and Test Case management systems
Presentation transcript:

Who’s Watching the Watchmen? The Time has Come to Objectively Measure the Quality of Your Verification by David Brownell Design Verification Analog Devices Inc.

Sponsored By: 2 of (28) Verification is Hard Am I checking everything? Are my tests covering all the scenarios? What did I forget? Where is the spec? Am I done?

Sponsored By: 3 of (28) Verification Complexity Increasing Block/Chip NameRTL Line CountTestbench Line Count Peripheral Block~9K~14K Processor Control Block~15K~22K Memory Controller~18K~42K Small SOC~90K~17K Large SOC >250K Bugs very likely in Testbench code as well as RTL! Bugs in Testbench can mask bugs in RTL!

Sponsored By: 4 of (28) Effective Verification ActivatePropagateDetect Design Under Test StimulusChecker For any bug that can exist in RTL the DV Environment must be able to:

Sponsored By: 5 of (28) Current Verification Metrics Code Coverage Functional Coverage Verification Plans Good but not good enough –Focused on Activation –No Information about Propagation or Detection –Ignore Testbench completely

Sponsored By: 6 of (28) Functional Qualification is the Answer Systematically insert artificial bugs into the RTL Run tests to see if fault is detected Provides metrics for every fault as to whether: –Fault is activated –Fault is propagated –Fault is detected

Sponsored By: 7 of (28) Functional Qualification is the Answer Identifies Holes/Weaknesses in DV Environment –Inadequate Tests –Bad or Missing Checkers Objective measure of overall DV quality Results and Experiences presented today based Springsoft/Synopsys Certitude

Sponsored By: 8 of (28) Example of Faults Inserted Port FaultsInput : Stuck at 0, Stuck at 1, Negated Output : Stuck at 0, Stuck at 1, Negated Condition FaultsCondition True, Condition False, Negated Dead FaultsDead Assign, Dead Else Bus FaultsFlip First Bit, Flip Last Bit, Negate Bus, Operator faultsSwap operators Condition False Example: if(a || b) c <= d; Else c <= e; Changed into: if(1’b0) c <= d; Else c <= e; Dead Assign Example: assign a = b && c || d; Changed into: //line removed Bitflip Last Example: assign a = b == 3’b001; Changed into: assign a = b == 3’b000; Swap Operator Example a = b || c; Changed into: a = b && c;

Sponsored By: 9 of (28) Functional Qualification Phases Model Activate Detect Parse RTL Files to determine faults to insert Search for unreachable faults Determine cones of influence Create Instrumented RTL Files for next 2 phases Run every test once Determine which tests activate each fault Determine which faults are not activated Insert each fault into the RTL Simulate tests that activated fault Determine if any test is capable of propagating and detecting each fault

Sponsored By: 10 of (28) Fault Classifications CategoryDescription Non-Activated No test capable of activating the fault Non-Propagated Fault Activated, but not propagated to a checker Non-Detected Fault propagated to checker, but no fail reported Detected At least one test reported a failure

Sponsored By: 11 of (28) Qualification Results

Sponsored By: 12 of (28) Issues Found During Functional Qualification

Sponsored By: 13 of (28) Example #1 : Processor Control Block Fault number – assign rout[31:0] = wr_imm ? data1 : data0; FQ Forced condition to always evaluate to false – assign rout[31:0] = 1’b0 ? data1 : data0; Only 1 test activated this fault

Sponsored By: 14 of (28)

Sponsored By: 15 of (28) Example #1 : Processor Control Block Identified Weakness  Checker Error – Check written to fire “if (A && !A)” – Copy and paste error Impact – Potential Design Bug Miss – Not checking that correct data driven on rout

Sponsored By: 16 of (28) Processor Control Example #2 Fault number 6163 – 3’b000 : addr = 32’b ; Combo Logic fault – bitflip from a 0/1 to a 1/0 – 3’b000 : addr = 32’b ; 5 tests activated this fault

Sponsored By: 17 of (28)

Sponsored By: 18 of (28) Processor Control Example #2 Identified Weakness – Weak Checker – Address outputs driven to “0” when NOP in F stage. – Testbench not checking address bus when NOP in F stage Impact – Potential Design Bug Miss – If other blocks are relying on “0” on the address Bus

Sponsored By: 19 of (28) Recent from Colleague: I love finding things like this in my old testbench! //05/11/12 Removed this to prevent regression failures //compare_signals("Mmr_iexcp_h1f3", tb_mmr_iexcp_h1f); Example #3

Sponsored By: 20 of (28) Common Issues Found Missing checks on top level outputs –Most often heard phrase during FQ: “I meant to check that!” Missing reset cases –No test which asserts reset multiple times –Almost every TB we check has this problem Logic activated but poorly propagated Bad checkers –Checks written or called incorrectly

Sponsored By: 21 of (28) I Functional Qualification! How do I get started?

Sponsored By: 22 of (28) Experiences with FQ Setup (The Bad) First time setting up will likely take 1-2 days –Testbench/scripts must be able to do separate compile and run! Must take argument to define unique logname –Defining pass/fail for FQ is critical and easy to get wrong If this is wrong all results are invalid Sometimes difficult to tell when this incorrect –Separate compile/executable for each test can be painful! The instrumented code can increase the compile time a lot

Sponsored By: 23 of (28) Experiences with FQ Setup (The Good) Once you have done one, very easy to do the next project –Typical setup for a new project is a couple of hours –Process automated within ADI so setup is minutes Time to results very quick after setup –Model phase Typically <15minutes –Activate phase Typically <1hr –Detect phase to first non-detected fault Typically <1hr Interactive mode so you can debug faults while tool running

Sponsored By: 24 of (28) Lessons Learned

Sponsored By: 25 of (28) Lessons Learned Expect to be offended –Every TB has issues. –Functional Qualification will find them. Don’t Run before your environment is complete –If you know you are missing a check on some pins Functional Qualification is just going to point that out. Have a clear plan before you start: –0 non-activated and 0 non-detected –What faults are critical

Sponsored By: 26 of (28) Who Should be using FQ? You Any style testbench Block to System Level Only requirements –Self Checking Env/Tests –Design is RTL

Sponsored By: 27 of (28) Why Should you use FQ Higher Quality Verification Environment –More likely to catch RTL bugs Higher Quality Designs –Less chance of discovering bugs late in the process or after tape-out More confidence in RTL sign-off –Objective, quantifiable criteria Earlier Identification of Issues –Achieve robust verification environment more quickly Difference Between Thinking and Knowing –That your Environment is working

Sponsored By: 28 of (28) Norwood DV and Design Team Springsoft/Synopsys Marty Rowe/Myles Glisson