Functional Verification

Overview
Subir K. Roy
International Institute of Information Technology,
Bangalore
 Verification, What Is It?

Formalization Architecture and Design

Idea Specification Product

Verification

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Design Vs Verification
Specification
Functional Verification
Design
RTL Code (Verilog/VHDL)
Synthesis Equivalence Checking
Netlist/Gate-level design
Backend LVS/DRC Checks
GDS
Fab Test & Product Engg.
Silicon Die

Packaging Signal Integrity Checks

System-In-Package (SIP)
Integration System Validation
Final Application on Board
Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 Motivation
• Pentium SRT Division Bug : $0.5 billion loss to
Intel
• Mercury Space Probe : Veered off course due to
a failure to implement distance measurement in
correct units.
• Ariane-5 Flight 501 failure : Internal sw
exception during data conversion from 64 bit
floating point to 16 bit signed integer value led
to mission failure.
• Exception handling mechanism contributed
to the processor being shutdown (This was
part of the system specification).
 Where do bugs come from ?
• Incorrect specifications.
• Misinterpretation of specifications.
• Misunderstanding between designers.
• Missed cases.
• Protocol non-conformance.
• Resource conflicts
• Cycle-level timing errors.
• ……
Trend of Verification Effort in the Design
• Verification portion of design increases to
anywhere from 50 to 80% of total
development effort for the design.

1996
300K gates
Code Verify (30 ~ Synthesis
40%) P&R

2000
1M SoC
Code Verify (50 ~ 80%) SynthesisP&R
Verification methodology manual, 2000-
TransEDA

6
 Percentage of Total Flaws

• About 50% of flaws are functional flaws.

– Need verification method to fix logical &
functional flaws
Other
Power 9%
Race 4%
5%
Clocking Logical/
5% Functional
Yield 45%
7%

Noise
12%
Slow Path
13%

From Mentor presentation material, 2003

7
 Percentage of Total Flaws

• Another recent independent study showed

that more than half of all chips require one or
more re-spins, and that functional errors
were found in 74% of these re-spins.
• With increasing chip complexity, this
situation could worsen.
• Who can afford that with >= 1M Dollar NRE
cost?

Current Status and Challenges of SoC Verification

for Embedded Systems Market - Chong-Min Kyung,
IEEE International SOC Conference, 2003
 Bug Fixing Cost in Time
• Cost of fixing a bug/problem increases as
design progresses.
– Need verification method at early design stage

Cost of
Fixing
a Problem

Behavioral RTL Gate Level Device

Design Design Design Production 9
Verification methodology manual, 2000 – TransEDA
 Verification Performance Gap; more
serious than the design productivity gap

• Growing gap between the demand for verification and

the simulation technology offered by the various
options. Verification Performance Gap
Simulation performance

Verification complexity
SOC

Complex
ASIC

Medium
Small ASIC
ASIC

10
Design complexity System-on-a-chip verification, 2001 – P.Rashinkar
Completion Metrics; How do we know when
the verification is done?
• Emotionally, or Intuitively;
– Out of money? Exhausted?
– Competition’s product is there.
– Software people are happy with your hardware.
– There have been no bugs reported for two weeks.
• More rigorous criteria;
– All tests passed
– Test Plan Coverage
– Functional Coverage
– Code Coverage
– Bug Rates have flattened toward bottom.
Current Status and Challenges of SoC Verification
for Embedded Systems Market - Chong-Min Kyung,
IEEE International SOC Conference, 2003
 Verification Challenges

• Specification or Operating Environment is

Incomplete/Open-Ended. (Verification metric
is never complete like last-minute ECO.)
• The Day before Yesterday’s tool for Today’s
Design.
• Design productivity grows faster than
Verification productivity.

Current Status and Challenges of SoC Verification

for Embedded Systems Market - Chong-Min Kyung,
IEEE International SOC Conference, 2003
Overview of Verification Methodologies

Prototyping
Emulation
Hardware
Accelerated
Simulation
Simulation
Basic Semi-formal
verification Verification
tool Formal
Verification

Current Status and Challenges of SoC Verification

for Embedded Systems Market - Chong-Min Kyung,
IEEE International SOC Conference, 2003
A Complex Multimedia SOC

Source : Cadence
A Complex Multimedia SOC

Source : Cadence
Tegra4i
Application Processor For Multimedia Systems

Specification of Tegra 4i from NVidia

 CPU - Quad-Core with 5th battery-saver core
 Max Frequency – Single Core : 1.5 GHz, Quad Core : 1.4 GHz
 L2 Cache – 1MB
 L1 Cache(I/D) – 32 KB / 32 KB per core
 Memory : DDR3-L 1500 / LPDDR2-1066 (Upto 2 GB)
 GPU :
 Architecture ULP GeForce,

 2X performance for 3D relative to Tegra 2

 Cores : 12

 3D Stereo

 Full Programmability

 Video (1080p) : Decode – H.264(@40Mbps)/H.263/VC-1

AP/MPEG2/MPEG4/DivX 4 & 5/XviD HT/ Theora/VP8/WMV/…
Encode & Video Telecon. – H.264/H.263/MPEG4/VP8
Source : NVidia website
Application Processor For Multimedia Systems

Specification of Tegra 3 from Nvidia

 Audio (1080p) : Decode AAC-LC/AAC+/eAAC+/MP3/MP3
VBR/WAV/PCM/MPEG2 Audio/AMR-NB/AMR-
WB/BSAC/Vorbis/WMA9/WMA Pro/WMA
Lossless/G.729a/G.711/QCELP/EVRC/…
Encode– AAC-LC/AAC+/eAAC+/WAV/PCM/AMR-NB/AMR-WB
 Imaging :
 Primary Camera : 32 MP,
 Secondary Camera : 5 MP
 Mpixel/s : 300
 Digital Zoom : Upto 16X
 JPEG Encoding/Decoding : 80MP/sec
 Image Stabilization : Still & Video
 Features : Auto Exposure/Auto White Balance/ Auto Focus/ 9th Order
Lense Shading/ De-Mosaic/Sharpening/ Programmable De-Noise
 MIPI CSI
Source : NVidia website
Application Processor For Multimedia Systems

Specification of Tegra 3 from Nvidia

 Display :
 Display Controllers: 2 concurrent,
 HDMI : 1.4a (1920x1080)
 LCD : 2048x1536
 CRT : 1920x1200
 MIPI DSI
 Package
 14x14 BGA
 24.5x24.5 BGA
 Process – 40 nm

Source : NVidia website

We Will Be Discussing This
 Verification – What Is It?

 Design verification is the process of checking that an

implementation meets its specification
 Objective – Excellence in Quality
 Bug Free
 First time success & correctness
 First Time Silicon Success
 Reality & Hard Facts
 Have to live with some bugs
 First time Silicon success does not mean “Bug Free”
 Approach is that of risk mitigation - to minimize tolerable
bugs & eliminate completely fatal bugs
 Reduces the risk of having fatal bugs left in design on tape-out
 Allows one to measures the risk of having bugs left in the design
 Impossible to declare a bug free design.

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Verification – Why Do It?

 Murphy’s Law (aka The 4th Law of Thermodynamics):

 If something can go wrong, it will.
 Moore’s law :
 Designs are getting ever more complex – will not get better
 Mother Nature’s Laws:
 Bugs are natural things
 Complexity :
 SOCs today easily have > 2 billions transistors (Eg. Intel
Quad Core) as compared to human brain with 100 billion
neurons
 Way Out :
 Seek simplicity in complex things as human mind finds it
difficult to deal with the above complexity.
Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 Verification – What kind of Designs?

All kinds of designs

 Modules, IPs, Blocks
 Memory controller, UART, Cache, DMA
 FIFOs, Bus Bridges, Routers, Filters, …
 Bus Interconnect, Network on Chip
 …
 Sub-Systems
 Data Processing Hardware Accelerator (Audio, Video, …)
 Power Management Unit
 Communication sub-systems
 …
 Sub-Systems + Firmware / Software APIs
 Microprocessors (uP, uC, DSP, …)
Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 Verification – What kind of Designs?

 System-On-a-Chip ( SoC )
 Cell Phone
 Set-Top Boxes, TV Chips, …
 Car on-board system…
 Full systems
 Hardware with its embedded software

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 What do we verify in a Design?

 All basic functionalities

 All configurations
 Cross concurrent functionalities
 Cross functionalities / configurations
 Stress conditions / application scenarios
 Error conditions / Security Protections / Safety Critical
Behaviors
 Known Corner Cases
 Unknown Corner Cases ?
 ………

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Who verifies the Design?

Verification becomes a specialized job:

 Design engineers design (and are busy enough)
 Using Verilog, VHDL, C (HLS), Matlab, Simulink, …

 Verification engineers verify

 With a different approach than designers

 With a real intent to check / verify / break the design

 Using state-of-the-art methodology

 Using specialized tools

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Functional Verification Planning?

Verification task is like a project needing :

 Project Management:
 Schedule and Planning
 Resource and tasks allocation

 Specification: Verification Plan

 Execution
 Environment settings, testbench development
 Test scenarios implementation
 Assertions development
 Simulation runs
 Proof runs
 Reporting and risk assessments
Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 Verification Planning - What is it?

 Verification Plan
 Specifies how the design will be tested

 Specifies which features will be exercised

 Specifies which checker will be implemented

 The verification plan should be reviewed before the

actual verification starts:
 Architecture, Design and Verification should agree on
 Features

 Priorities

 Major bugs can be found during this review, with no

simulation.
Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 Verification Plan - What does it consist of?
Verification Plan- This is the specification for the verification
 Scope of verification
 What part of the design are we going to verify
 What part are we not going to verify
 Limitations
 Priority in regards to schedule
 Technical limitations
 Methodology used (simulation, CDV, formal proof, …)
 Features that needs to be verified
 Protocol assertions
 Features and Expected behavior
 Configurations
 External events
 Known corner cases
 Stress scenarios / Use case Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 Verification Report - What is it?

Verification should end with a verification report

 Results
 Coverage
 Bugs found,
 Bugs fixed,
 Bugs left (workaround),
 Bugs deferred or postponed

 Verification holes

 Risk: degree of confidence / quality

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Verification : Who Does It?

Specification

readings

Designer’s
Interpretation
Designer’s own
Verification

Coding

Design

Source : Writing Testbenches, J. Bergeron, 2000

 Bug Categories

Design
No-Bug Bug
Verification

False True
Test Fails
Negative Positive

Test Passes True False

Negative Positive

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Verification : Who Does It?

Specification

readings readings

Designer’s DV Engineer’s
Interpretation Interpretation

Coding Verification

Design

Source : Writing Testbenches, J. Bergeron, 2000

 System Verification Platforms

 Simulations
 Simple integration tests
 Pros: controllability, debug
 Cons: runtime

 Prototype (FPGA based):

 Run more complex software and use case.
 Pros: runtime
 Cons: controllability, debug

 Systems (Board level)

 Validate high level system cases with external world.
 Example of System Verification Plan

 Check processors boot process

 Check all register values after reset
 Check read/write to all writeable registers
 Check read/write to all memories
 Check access to all IPs
 Check all interrupts
 Check use cases of Video + Audio
 Check use cases of Video + Modem
 Check use cases of the Camera
 Check Low Power Mode use cases…

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Software Simulation
• Dynamic verification method
• Bugs are found by running the design
implementation.
• Thoroughness depends on the test vector used.
• Some parts are tested repeatedly while other parts
are not even tested.

Other parts are

Testbench DUV not even tested.

a = 1;
#20 b = 1; Some part of the
$display (“status is = %d”,c); design is tested
... repeatedly.

Current Status and Challenges of SoC Verification

for Embedded Systems Market - Chong-Min Kyung,
IEEE International SOC Conference, 2003
 Cycle-Based Simulation
• Simulate the behavior of the design cycle-by-cycle.
• Cycle-accurate information is provided as a result
of simulation.
• Only signals at the flip-flop input are evaluated to
be stored, not internal signals of combinational
logic.

Combinational Combinational
Combinational
logic logic
logic

Current Status and Challenges of SoC Verification

for Embedded Systems Market - Chong-Min Kyung,
IEEE International SOC Conference, 2003
 Cycle-based vs. Event-driven

Cycle-based Event-driven
Timing resolution Clock cycle User-defined minimum
delay
Evaluation time point Rising/falling/both At the occurrence of
clock edges events
Evaluation node Every flip-flop At the output of every
boundary logic gate on the event
propagation path
Simulation time Proportional to the Proportional to the
(number of cycles) number of events (circuit
times (C/L size * size* no. of cycles*event
number of F/F’s) density)

Current Status and Challenges of SoC Verification

for Embedded Systems Market - Chong-Min Kyung,
IEEE International SOC Conference, 2003
 Software Simulation
• Pros
– The design size is limited only by the computing
resource.
– Simulation can be started as soon as the RTL
description is finished.
– Set-up cost is minimal.
• Cons
 Slow (~100 cycles/sec) ; Speed gap between the
speed of software simulation and real silicon widens.
(Simulation speed = size of the circuit simulated /
speed of the simulation engine)
 The designer does not exactly know how much
percentage of the design has been tested.
Current Status and Challenges of SoC Verification
for Embedded Systems Market - Chong-Min Kyung,
IEEE International SOC Conference, 2003
Test Bench Creation for Dynamic Simulation
 Still today one of the verification techniques is:
 Linear time based simulation,
 Accelerated (or emulated) simulation,
 Design to programmable devices (FPGA) with live debug in
the lab
 Pros
 Easy to start with - Same languages as design (VHDL or
Verilog)
 Cons
 Verification via simulation is straining under the complexity
of today’s designs,
 Emulation helps provide the ability to get around this
bottleneck but problems comes in the creation of stimulus
generator and response checker,
 Live debug leads to a substantial increase in difficulty and
time to debug. Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 Automating Generation of Stimuli

Random Stimuli
 Easy way to automate
 Poor quality:
 Can generate invalid inputs
 Might never reach desired functionality
Needs:
 Controlling randomness → Constraints
 Measuring what has been done → Coverage
 Automate behavior verification → Checks
→ Coverage Driven Verification

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Coverage Driven Verification (CDV)

Input
Coverage Generation

Output
Generation

Generation : Automate Tests

Checking : Verify Functional Behaviour
Coverage : Ensure everything planned for has indeed been done
Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 CDV --- Typical Test Bench

Test Scenario

Transaction Master
Generator BFM DUT

Seed

Source : Specman Training Material

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Bus Functional Model (BFM)
Synchronized function/task/block
 that takes as argument a transaction
 is linked to signals
Convert an abstract transaction to:
 Signal values
 Time synchronization
According to a protocol such as:
 AHB, APB, AXI, OCP, Wishbone, …
 ATM/UTOPIA, Ethernet, …
 SRAM, DDR, DDR2, …
 I2C, USB3, …
 DVI, Firewire, HDMI, …
 CPU instruction fetch, data access, …
 …
Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
Application : Arbiter Transaction (e-Language)

struct arbiter_transaction_s {
address : uint(bits:32);
data : uint(bits:32);
direction : [READ,WRITE];
delay : uint;
};

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Application : Arbiter BFM (e-Language)
BFMDrive (tr : arbiter_transaction_s) @clock {
sig_req$ = 1;
while not sig_gnt$ == 1 { wait };
if tr.direction == WRITE {
wait [tr.delay];
sig_data$ = tr.data;sig_dvalid$ = 1;
wait [1];
sig_dvalid$ = 0;
} else {
while not sig_dready$ == 1 { wait };
tr.data = sig_data$;
};
}; Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 Transaction Generator

Generate a structure defining a transaction:

 Address to access

 Data to write or that has been read

 Whether this is a read or a write

 Instruction opcode

 Instruction operands

Constraints make transaction chose its field values

within more or less random values

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Constraint Example

Specifying a constraint :
 A in [3..14]
 C in [12..15]
 A<B
 B<C

 Other constraint examples:

 Register accesses should be in a certain address range
 Register accesses are 32 bits wide
 Read only registers should not be written to
 Invalid opcodes should not be generated
 A branch should be followed by a NOP
 Time between two transactions should be at least two clock
cycles
 … Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 Example of Constraint in System Verilog
//-----------------------------------------//
//-- System Verilog Example --//
//-----------------------------------------//
Class tempo_config_c;
rand uint a;
rand uint b;

constraint a_less_than_b { a < b; }

constraint a_range { a >= 3 and a <=14; }
endclass

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Constraint Solver Problem/Issues
Specifying a constraint :
 A in [3..14]
 C in [12..15]
 A<B
 B<C
What if A is generated first and takes the value 14 ?

 Constraint Solver are complex algorithms

 Solving constraints is a NP-Complete Problem
 Solution involves graph theory,
 Mathematical Reduction,
 Backward Search,
 …
 EDA vendors have developed many different tools.
Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 CDV : Controlling Randomness

Fully random inputs

 Whichever opcode

 Whichever random address

Directed
 The ADD64 opcode

 Address = MAIN_CFG_REG_ADDR

Constrained
 Opcode in [ add , sub , mul , div , mac ]

 Address in [ base_address ... base_address +

memory_size ]
Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 Application : Arbiter Generation

var speed : [SLOW, MEDIUM, FAST, RANDOM];

gen speed;

var tr : arbiter_transaction_s;
gen tr keeping {
speed == SLOW → .delay in [10..20];
speed == MEDIUM → .delay in [5..9];
speed == FAST → .delay in [0..4];
speed == RANDOM → .delay in [0..20];
};
drive(tr);

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
Application : Arbiter Sequence Generation
Sequence INIT
//Macro do (arg) keeping (constraints) is
// gen arg keeping constraints;
// drive(arg);
//End Macro;
// do generate a transaction and call the drive method
do tr keeping {
.addr == REG_CFG_ADDR;
.data == 0xcafebabe;
.direction == WRITE; };
do tr keeping {
.addr == REG_SETUP_ADDR;
.data == 0xdeadbeef;
.direction == WRITE; };
Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
Application : Arbiter Sequence Generation

Sequence MAIN
do sequence keeping {
.kind == INIT;
};
for ii from 1 to 100 {
do sequence keeping {
.kind == RANDOM;
.speed in [FAST, VERY_FAST];
};
};
Sequences allow one to elevate the test scenario
abstraction level to a higher level view of the features
or application use-cases to be exercised.
Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 Checking Outputs

 Visual wave inspection

 Self-check HDL testbenches
 If sig_value != expected_value then print(“ERROR”);

 Dynamic Assertion Checking

 Temporal Assertions (e, PSL, SystemVerilog, …),
 Behavioral Assertions (e, PSL, SystemVerilog, …),

 Output Data Stream

 Scoreboard (Specman, SystemVerilog, SystemC, C++)
 Reference Model (Specman, SystemVerilog, SystemC, C++)

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 CDV --- Typical Test Bench

Scoreboard or Data
Test Scenario Ref. Model Check

Transaction Master Slave

Generator BFM DUT BFM

Seed
Protocol
Checker

Pass/Fail
Source : Specman Training Material Report
 Basic Scoreboard Implementation
Struct transaction {
address : address_t;
data : data_t;};
…
scoreboard : list keyed(address) of transaction;
…
on input_event {
var t : transaction = new;
t.address = ‘i_addr’;
t.data = ‘t.data’;
scoreboard.add(t);
};
on output_event {
if not scoreboard.key_exist(‘o_addr’) then
error(“Unable to find address in scoreboard”);
else
check that scoreboard.first(.addr = “o_addr”).data
Functional Verification= “o_data”;
Overview About Existing
Methodologies - François Cerisier 2010
}
 Protocol Checking

➢ After a request followed by a valid signal, a

grant should be asserted

// System Verilog Example

property my_protocol_checker;
request ##1 valid |=> grant
endproperty;

assert my_protocol_checker;

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Assertion Based Verification

➢ Model all protocol rules in assertions

➢ Make sure all assertions have been exercised.

➢ Assertions could be used during design

phase by designers.

➢ Assertions could be proven using formal

proof engines.

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Why Assertion Based Verification ?

The Cause-Effect Principle:

➢ A cause has consequence (that needs to be checked)
➢ If something happens, there is a cause, OR
➢ if there is no cause, nothing should happen (we need to
check this).
➢ This is not because a checker exists that it has been
exercised.
➢ This is not because a checker has checked a behavior
in a few hundred/thousands cases that the behavior is
OK in all cases.
➢ There might be corner cases not exercised
➢ There might be corner cases not reachable due to
environment constraints or hypothesis

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Different Kinds Of Coverage?

Code Coverage
➢ Has all RTL code been simulated ?

Functional Coverage
➢ Has all configuration been used ?

➢ Has all features been simulated ?

➢ …

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Code Coverage : Line/Block?
module simple_block;
input clock;
input a, b;
output c;
reg prev_a, prev_b;
always @ (posedge clock)
begin
prev_a <= a; // Line 1
prev_b <= b; // Line 2
if( a & prev_a)
c <= prev_b; // Line 3
else
c <= ~prev_a | prev_b; // Line 4
end
endmodule Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 Code Coverage : Condition/Path?
always @ (posedge clock)
begin
…
if( a & prev_a)
1: c <= prev_b;
else
2: c <= ~prev_a | prev_b;
if( b | prev_a)
3: d <= prev_c;
else
4: d <= ~prev_a | prev_b;
end
endmodule Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 Code Coverage : Condition/Path?
Conditions
C1: a = 1 and prev_a = 1
C2: a = 0 or prev_a = 0
C3: b = 1 and prev_a = ?
C4: b = ? and prev_a = 1
C5: b = 0 and prev_a = 0

Paths:
C1 and ( C3 or C4 ) → exec line 1 and 3
C2 and ( C3 or C4 ) → exec line 2 and 3
C1 and C5 → exec line 1 and 4
C2 and C5 → exec line 2 and 4

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Code Coverage : Toggle
module test;
reg [2:0] a;
initial
begin
a = 3’b0;
#10;
a = 3’b110;
#10;
a = 3’b010;
#10;
end
endmodule

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Code Coverage : Toggle
a[0] toggle coverage:
0→0 0%

a[1] toggle coverage:

0→1 50%
1→0 0%

a[2] toggle coverage:

0→1 50%
1→0 50%

‘a’ toggle = 50 %
Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 Code Coverage : Analysis

➢ Non-Covered Lines:
➢ Not tested
➢ Useless / dead code

➢ Covered lines
➢ Executed

➢ Not necessarily tested and verified

➢ How about functionality ?

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 FSM Coverage

!req

IDLE

req

gnt
GNT REQ

gnt !gnt

WAIT

!gnt Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 Functional Coverage

Goal:
➢ Describe verification in terms of functionality

Problem:
➢ How do we describe functionality ?
➢ Instructions / Transactions,
➢ Configuration that need to be tested,
➢ Architectural limits that need to be tested (corner
cases)
➢ Any functional aspects of the design

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 CDV --- Typical Test Bench

Scoreboard or Data
Test Scenario Ref. Model Check

Transaction Master Slave

Generator BFM DUT BFM

Seed
Monitor Protocol
Checker

Functional Coverage DB
Pass/Fail
Report
Source : Specman Training Material
 Functional Coverage
We want to cover:
➢ All opcodes followed by all opcodes

➢ All opcodes with all operands

----------------------------------
-- e-Specman example --
----------------------------------
struct transaction {
event fetch is true(‘fetch’ = 1 and ‘stall’ = 0) @ clock;
opcode : [NOP,ADD,SUB,JUMP]
operand : [R0,R1,R2,R3];
cover fetch is {
item opcode; -- cover all opcodes
item operand; -- cover all operands
transition opcode; -- cover all opcodes/opcodes
cross opcode , operand; -- cover all opcodes/operands
};
}; Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 CDV Summary
All system behaviors should be:
➢ Exercised

➢ Checked

➢ Monitored

➢ This is not because the testbench that allows one to

generate a scenario really has generated it.
➢ This is not because the feature that one wishes to
have covered really has been checked.
➢ This is not because a checker exists that it has been
really been exercised.

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
 CDV : Pros & Cons

Pros:
➢ Automatic test generation to cover possible
interesting corner case scenarios
➢ To catch very tricky bugs that are difficult to
anticipate.

Cons:
➢ Traceability and reproducibility

➢ Needs good pseudo random constraints to reach

interesting cases.
➢ Functional Coverage may be hard to reach

Functional Verification Overview About Existing

Methodologies - François Cerisier 2010
Planning : Improving Verification Schedule
Random Generation
➢ Pros:
➢ Automatic test generation without too much thinking of what
is going to happen
➢ Cons:
➢ Sometimes difficult to generate corner cases or all possible
cases of complex scenarios.

Easing verification plan / test scenarios generation:

➢ Graph Based approaches (Breker Verification Systems,
Mentor Graphics)

→ Define verification goals in a graph that will then generate

tests and checkers
Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 Formal Verification
➢ Formal verification does not simulate the design.
➢ It checks that an assertion holds whatever the design
states.

→There is no possibility at all (from a mathematical

point of view) that the design can have a behavior in
contradiction with the assertion.

➢ Formally prove a specific behavior of the design

➢ No un-simulated inputs
➢ Given the input restrictions of the property.
➢ No un-checked value
➢ Given the value range defined in the property
➢ Based on mathematical proof engines
Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
 Summary

➢ What is verification ?
➢ A task which tries to minimize bugs
➢ Why is verification needed ?
➢ Because no-one is perfect
➢ Because designs are just too complex
➢ What do we verify ?
➢ Everything
➢ When do we verify ?
➢ The earlier the better
➢ Who does the verification ?
➢ A verification expert
➢ How do we verify?
➢ System Verification
➢ Coverage Driven Verification
➢ Formal Verification
➢ Graph Base Verification
Functional Verification Overview About Existing
Methodologies - François Cerisier 2010
Thank You