Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

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

These are the Lecture Slides of Functional Verification which includes Reusable Verification Components, Verilog Implementation, Implementation, Autonomous Generation and Monitoring, Input and Output Paths, Verifying Configurable Designs, Reusable Test Harness, Testcase Specific Code, Abstraction etc. Key important points are: Verification Tools, Linting Tools, Simulators, Third Party Models, Waveform Viewers, Code Coverage, Verification Languages, Revision Control, Issue Tracking, Metrics

Typology: Slides

2012/2013

Uploaded on 03/22/2013

dhritiman
dhritiman 🇮🇳

4.7

(6)

107 documents

1 / 25

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Verification Tools
Docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19

Partial preview of the text

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”