Introduction

RTL
VERIFICATION

RTL verication consists of

acquiring a reasonable condence
that a circuit will function correctly.

Verification is a process that

ensures conformance of a
design to some predefined set of
expectations.

Verification Complexity
As Design Size Grows
Controllability decreases
Tests more difficult to write

Observeability decreases
Tests are longer

Contain more blocks

Need more test benches

Some estimate that for a doubling of design size

Verification complexity increases by 4X

 60% - 80% time spent in verification WHY??

Design complexity
Product time-to-market
Volume of "bugs"
Development costs
Cost of bugs over time
Longer a bug goes undetected, the more expensive it is
Bug found early (designer sim) has little cost
Finding a bug at chip/system has moderate cost
Requires more debug time and isolation time
Could require new algorithm, which could effect schedule and cause board

rework

Finding a bug in System Test (test floor) requires new spin of a chip
Finding bug in customers environment can cost hundreds of

millions and worst of all - Reputation

Everyone knows debugging is twice as hard

as writing a program in the first place
Brian Kernighan
Elements of Programming Style 1974

Importance of Verification

DE
VE

DAVE

Initially-- DAVE - Design And Verification Engineer

Design complexity increasing
Now -- DE -- Design Engineer

VE -- Verification Engineer
Verification Engineers usually outweigh designers 2-1

Verification Approaches

Black-Box Approach
White-Box Approach
Grey-Box Approach

Black-Box Approach

Inputs

Some piece of logic

design written in
VHDL

Outputs

The black box has inputs, outputs, and performs some

function.

The function may be well documented...or not.

To verify a black box, you need to understand the function

and be able to predict the outputs based on the inputs.

The black box can be a full system, a chip, a unit of a chip,

or a single macro.

White-Box Approach
White box verification means that the internal

facilities are visible and utilized by the test bench

stimulus.

Full visibility and controllability of internals.

Tightly integrated with implementation.
Test bench must change if DUV changes.

Grey-Box Approach
Grey box verification means that a limited number

of facilities are utilized in a mostly black-box

environment.

Example: Most environments! Prediction of

correct results on the interface is occasionally

impossible without viewing an internal signal.

Verification Techniques
Simulation-Based Verification
Formal Verification
Emulation
Assertion Based Verification

Simulation Based Verification

Provide meaningful input stimulus
Check the output manually
Disadvantages??
Creation of entire suit of input stimulus
Time consuming
All conditions may not get covered

Formal Verification
Specifications are specified mathematically in

the form of a formal property specification.

Mathematically verifies the implementation

against the formal property specifications.

Two Types:
Equivalence Checking
Compares two models to see if equivalence

Model Checking
Looks for generic problems or violations of user defined rules

about the behavior of the design

Disadvantages??
Unable to tackle industrial designs due to the

complexity of the underlying algorithms

Applicable only to smaller component

Emulation
Process of imitating the behavior of one or more

pieces of hardware (typically a system under

design) with another piece of hardware, typically a
special purpose emulation system.

Advantage -- Very fast

Disadvantage -- Cost

Assertion Based Verification

(ABV)
Assertions What are they?
An assertion is an expression that, if false, indicates

an error

A conditional statement that checks for specific

behavior and displays a message if it occurs.

ABV- use assertions to capture specific design

intent

Can be used

in

Simulation
Formal verification
Emulation

Back to Simulation based

SIMULATION
BASED
ASSERTIONS

FORMAL

EMULATION

Problems ????
Simulation-based validation raises three important

questions:

What the stimulus should be

Whether it exposes any design errors
Whether the stimulus is long and varied enough to have

exposed all design errors

Historically, these three questions have been answered

manually:

By having a test engineer write test cases,

Check the results of simulation,
Make some informed guesses about how comprehensive the

test suite actually is

Process is tedious and error prone

Verification Challenges
Dealing with enormous design
Detecting incorrect behavior
Lack of golden reference model
Lack of proper verification metric

How to Improve
Simulation Based
Verification???

Requirements
Easy generation of various combinations of input

stimulus

Elimination of redundant values

Generation of interesting scenarios
Effective checking of outputs
Metrics showing progress of verification
Easier writing of test benches

Answers.
Easy generation of various combinations of input stimulus

Generating inputs randomly

Elimination of redundant values

Constraining the input values

Generation of interesting scenarios

Constrained random stimulus generation

Effective checking of outputs

Self checking test benches

Metrics showing progress of verification

Functional coverage aspects

Easier writing of test benches

Raising the level of abstraction (e.g.: C vs. Assembly)

Constrained Random
Verification
Constrained
random stimulus

11001001
01001010
00001001
01110110
01100110
01001001
01001110

Design
Under
Test

000010
010011
000010
100100
001000
110010
000011

Constrained Random
Verification
Checker
Constrained
random stimulus

11001001
01001010
00001001
01110110
01100110
01001001
01001110

Does it work?

Design
Under
Test

000010
010011
000010
100100
001000
110010
000011

Constrained Random
Verification
Checker
Constrained
random stimulus

11001001
01001010
00001001
01110110
01100110
01001001
01001110

Does it work?

000010
010011
000010
100100
001000
110010
000011

Design
Under
Test

Functional
Coverage
Are we done?

Constrained Random
Verification
Checker
Constrained
random stimulus

11001001
01001010
00001001
01110110
01100110
01001001
01001110

Does it work?

000010
010011
000010
100100
001000
110010
000011

Design
Under
Test

Functional
Coverage
Constraints
Increase
coverage

Are we done?

Development of Verification
Languages

Verification Languages

e
OpenVera
SystemVerilog
SystemC

e Language
ewas first developed in 1992 in Israel by

forSpecmansoftware.

Properties
Object-oriented language with concurrency
Ability to generate constrained random values
Mechanisms for checking functional (variable value)

coverage

Mechanisms to check temporal properties

(assertions).

OpenVera
OpenVera began life around 1995 as Vera, a proprietary

language implemented by Systems Science, Inc. mainly

for creating test benches for Verilog simulations.

Properties :
Concurrent language
Can execute in VHDL and Verilog simulators
Has all high level constructs loops, functions, strings

,associative arrays etc

Provides extensive facilities for generating biased random

patterns

Monitoring facilities for reporting coverage of state variables

Supports functional coverage checking

SystemVerilog
SystemVerilog is the industry's first unified

Hardware Description and Verification Language

(HDVL).

It became an official IEEE standard

(IEEE1800) in 2005 under the development

of Accellera.

SystemVerilog was released in two primary

stages -

SystemVerilog 3.0 (released June 2002)

extends the hardware modeling aspects of Verilog

SystemVerilog 3.1 (released June 2003)

extends the verification aspects of Verilog.

System C
Defined by the Open SystemC Initiative (OSCI) in 1999
Approved by the IEEE Standards Association as IEEE 1666-

2005- the SystemC Language Reference Manual (LRM).

The class library was released in stages.

The first stage, release 1.0 (presently at version 1.0.2)
Provides all the necessary modeling facilities to describe systems similar to

those which can be described using a hardware description language, such

as VHDL.

Release 2.0 (presently at version 2.0.1),

The class library has been extensively re-written to provide an upgrade

path into true system level design.

Includes events

Semantic similarities toVHDLandVerilog

Provides object-oriented design partitioning

Trends in languages used for

verification

SystemVerilog Features Overview

Synthesis-friendly "concise" RTL notation
Packages
Interfaces

SystemVerilog Assertions

As
s

er
tio
ns

pr R
og TL
ra +
m
m
in
g

C-style data types & control - enum, struct, typedef, ++, break, return

Clocking blocks (synchronization between DUT and test bench)

AP
I

Te
st

Be
nc
h

Object-oriented programming - classes

Constrained random stimulus generation
Functional coverage
Dynamic processes, dynamic arrays, queues, mailboxes, semaphores

Direct Programming Interface (DPI) - calling C from SystemVerilog

Features of SystemVerilog
Interfaces between Modules
Constrained Random Data Generation
Rand and randc variables

Extended Procedural Statements and Control Flow

initial (enable this statement at the beginning of

simulation and execute it only once)

final ( do this statement once at the end of simulation)

always, always_comb, always_latch, always_ff ( loop

forever )

task (do these statements whenever the task is called)

function( do these statements whenever the function is

called and return a value)

Enhanced Process Control

fork...join_any and fork...join_none.

 Coverage Constructs
Point coverage
Transition coverage
Cross coverage

Object Oriented Classes

Classes allow objects to be dynamically created,

deleted, assigned, and accessed via object

handles

Classes offer inheritance and abstract type modeling,

Interprocess Synchronization and Communication

Semaphores,mailboxes,events

Problems Again??
Test benches not reusable!!
Writing test benches time consuming!!
Design complexity increasing!!!
Lack of standards..!!!???

Evolution of verification
methodologies

Methodology What it is??

Enhance the features of verification language

by providing inbuilt class libraries to build the

entire verification environment.

Class libraries has inbuilt features which

support
Automated test pattern generation
Self checking verification environments
Configurable test benches
Customizable messaging
Transaction level communication between

components in the environment

Coverage metrics

Verification Methodology Advantages

Reusable
Repeatable
Systematic
Easy to Debug

Aprovenmethodologywithindustrywidesupport
andavailabilityofengineerswithexisting
knowledge/experience

Verification Methodologies History

Cadence
eRM

URM

Mentor

Synopsys

Vera

RVM

SV/e

AVM

OVM
OVM 2.1.1

SV/SC

SV

Accellera
UVM

SV

VMM

SV

Emergence of UVM

Why UVM?
uvm_test
uvm_test

The big wins are

Verification Quality

Reusable Verification Environment

uvm_scoreboar
d

Virtual
sequencer

Testbench / VIP reuse

Know how / skills reuse

uvm_agent

uvm_agent

DUT

uvm_agent

UVM: The Basic Facts

Open source (Apache) SystemVerilog Base

Class Library
Constrained random verification
Configurable, flexible, test benches
Mixed language vision

UVM Highlights
Separation of tests from test

bench

Transaction-level communication

(TLM)

Sequences
Factory and configuration
Message reporting
End-of-test mechanism
Register layer
A consistent, uniform structure

Conclusion

Verification importance, complexity and job

opportunities ever increasing