+ All Categories
Home > Documents > by David Brownell Design Verification Analog Devices Inc.

by David Brownell Design Verification Analog Devices Inc.

Date post: 23-Feb-2016
Category:
Upload: mea
View: 51 times
Download: 2 times
Share this document with a friend
Description:
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. Verification is Hard. Am I checking everything? Are my tests covering all the scenarios? What did I forget? - PowerPoint PPT Presentation
Popular Tags:
28
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.
Transcript
Page 1: by David Brownell  Design Verification Analog Devices Inc.

Who’s Watching the Watchmen?

The Time has Come to Objectively Measure the Quality of Your

Verification

byDavid Brownell

Design VerificationAnalog Devices Inc.

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

Page 3: by David Brownell  Design Verification Analog Devices Inc.

Sponsored By:

3 of (28)

Verification Complexity Increasing

Block/Chip Name RTL Line Count Testbench 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!

Page 4: by David Brownell  Design Verification Analog Devices Inc.

Sponsored By:

4 of (28)

Effective Verification

Activate Propagate Detect

Design Under Test

Stimulus Checker

FAIL!

For any bug that can exist in RTL the DV Environment must be able to:

Page 5: by David Brownell  Design Verification Analog Devices Inc.

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

Page 6: by David Brownell  Design Verification Analog Devices Inc.

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

Page 7: by David Brownell  Design Verification Analog Devices Inc.

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

Page 8: by David Brownell  Design Verification Analog Devices Inc.

Sponsored By:

8 of (28)

Example of Faults InsertedPort Faults Input : Stuck at 0, Stuck at 1, Negated

Output : Stuck at 0, Stuck at 1, NegatedCondition Faults Condition True, Condition False, NegatedDead Faults Dead Assign, Dead ElseBus Faults Flip First Bit, Flip Last Bit, Negate Bus, Operator faults Swap 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 Examplea = b || c;

Changed into:a = b && c;

Page 9: by David Brownell  Design Verification Analog Devices Inc.

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

Page 10: by David Brownell  Design Verification Analog Devices Inc.

Sponsored By:

10 of (28)

Fault Classifications

Category Description 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

Page 11: by David Brownell  Design Verification Analog Devices Inc.

Sponsored By:

11 of (28)

Qualification Results

Page 12: by David Brownell  Design Verification Analog Devices Inc.

Sponsored By:

12 of (28)

Issues Found During Functional Qualification

Page 13: by David Brownell  Design Verification Analog Devices Inc.

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

Page 14: by David Brownell  Design Verification Analog Devices Inc.

Sponsored By:

14 of (28)

Page 15: by David Brownell  Design Verification Analog Devices Inc.

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

Page 16: by David Brownell  Design Verification Analog Devices Inc.

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

Page 17: by David Brownell  Design Verification Analog Devices Inc.

Sponsored By:

17 of (28)

Page 18: by David Brownell  Design Verification Analog Devices Inc.

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

Page 19: by David Brownell  Design Verification Analog Devices Inc.

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

Page 20: by David Brownell  Design Verification Analog Devices Inc.

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

Page 21: by David Brownell  Design Verification Analog Devices Inc.

Sponsored By:

21 of (28)

I

FunctionalQualificatio

n!

How do I get started?

Page 22: by David Brownell  Design Verification Analog Devices Inc.

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

Page 23: by David Brownell  Design Verification Analog Devices Inc.

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

Page 24: by David Brownell  Design Verification Analog Devices Inc.

Sponsored By:

24 of (28)

Lessons Learned

Page 25: by David Brownell  Design Verification Analog Devices Inc.

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

Page 26: by David Brownell  Design Verification Analog Devices Inc.

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

Page 27: by David Brownell  Design Verification Analog Devices Inc.

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

Page 28: by David Brownell  Design Verification Analog Devices Inc.

Sponsored By:

28 of (28)

• Norwood DV and Design Team• Springsoft/Synopsys Marty Rowe/Myles Glisson


Recommended