Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Who’s Watching the Watchmen? The Time has Come to Objectively Measure the Quality of Your Verification by David Brownell Design Verification Analog Devices."— Presentation transcript:

1 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.

2 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?

3 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!

4 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:

5 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

6 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

7 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

8 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;

9 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

10 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

11 Sponsored By: 11 of (28) Qualification Results

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

13 Sponsored By: 13 of (28) Example #1 : Processor Control Block Fault number 11757 – 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

14 Sponsored By: 14 of (28)

15 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

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

17 Sponsored By: 17 of (28)

18 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

19 Sponsored By: 19 of (28) Recent email 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

20 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

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

22 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

23 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

24 Sponsored By: 24 of (28) Lessons Learned

25 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

26 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

27 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

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


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

Similar presentations


Ads by Google