Verification Tools - Functional Verification - Lecture Slides, Slides of Computer Science

Download Verification Tools - Functional Verification - Lecture Slides and more Slides Computer Science in PDF only on Docsity!

Verification Tools

Verification Tools

 Linting Tools

 Simulators

 Third Party Models

 Waveform Viewers

 Code Coverage

 Verification Languages (Non-RTL)

 Revision Control

 Issue Tracking

 Metrics

Simulators

 Simulate the design before fabrication

 Simulation requires stimulus – not static tools

 Require to reproduce environment in which

design will be in – this facsimile is called a

testbench

 Simulation outputs are validated externally

against design intent (specification)

 Two types:

 Event based  Cycle based

Event Based Simulators

 Event based simulators are driven

based on events

 Outputs are a function of inputs

 The outputs change only when the inputs

do

 The event is the input changing

 This event causes simulator to re-evaluate

and calculate new output

Co-Simulation

 Co-simulators are combination of event,

cycle, and other simulators (acceleration,

emulation)

 Performance is decreased due to inter tool

communication.

 Ambiguities arise during translation from one

simulator to the other.

 Verilog’s 128 possible states to VHDL’s 9  Analog’s current and voltage into digital’s logic value and strength.

Third Party Models

 Board Verification???  Chip needs to be verified in its target environment – board  Do you develop or buy behaviorals for board parts?  May seem expensive  Ask yourself – If it was not worth designing on your own to begin with, why is writing your own model now justified?  Model you develop is not as reliable as the one you buy  One you buy is tested by many users, not just yourself  Remember – Always more expensive to develop your

model to the same degree of confidence then

licensing it Docsity.com

Waveform Viewers

 Some consider this as part of the simulator  Most common verification tools used  Purpose is to visually inspect design/testbench/verification environment  Things to consider:  Don’t use viewer to determine if design passes or fails a test

• use to debug  Recording waves causes a performance hit on the simulator  Some advanced viewers can compare waveform  Problem is how to determine what is ‘golden waves’  Most applicable to redesign where design must maintain cycle by cycle compatibility

Code Coverage

 Method used by software for some time.

 Main problem is that false positives answers

can look identical to true positive answers

 Code coverage can answer the question:

 Is there a function or combination of functions that have not been verified?

 Can run coverage on the testbench to

indicate what areas of the models are

executing most. This is known as a profiler –

It gives insight on what to optimize

 Many types of report metrics

Verification Languages

 Specific to verification principles  Deficiencies in RTL languages (Verilog and VHDL)  Verilog was designed with a focus on describing low-level hardware structures  No support for data structures (records, linked lists, etc)  Not object oriented  VHDL was designed for large design teams  Encapsulates all information and communicates strictly through well-defined interfaces

 These limitations get in the way of efficient

implementation of a verification strategy

Verification Languages (cont)

 Some examples of verification languages

 Verisity’s Specman Elite  Synopsys’ Vera  Chronology’s Rave  System C

 Problem is that these are all proprietary,

therefore buying into one will lock one into a

vendor.

Advanced Techniques in

Revision Control

 Configuration Management

 Pertains to a ‘view’ of the file system, known as a configuration

 Each user can have their own configuration

 Can refresh to new configurations as needed  I.E. You are working a bug and don’t want to corrupt your environment until it is fixed. Once fixed, you grab the ‘current’ configuration which brings you up to date.

 Configurations are just a combination of

different versions of each design and/or

verification pieces Docsity.com

Issue Tracking

 Another tool not considered a verification

tool.

 Face-it – verification engineer’s job is to find

bugs. We enjoy pointing out a designers

fault (keeps their ego’s in check).

 Issue tracking is used to deal with the bugs

that are found – bugs must be fixed

 Two things to consider

 What is an issue?  How to track it?

How to track an issue?

 Some methods:

 Grapevine System

 Post-It System

 Procedural System

 Computerized System

Grapevine

 This is the simplest tracking method

 What is it exactly – word of mouth! You find an issue, you walk over the your co-worker and tell him/her.

 Pros:

 Individuals are empowered!  Simple issues are solved almost immediately

 Cons:

 There is no history on the problem, history will repeat itself  Same issue may be revisited numerous times (no history)  Can lead to “finger pointing”