PSG COLLEGE OF TECHNOLOGY

COIMBATORE-641004.

Functional Checking of Design Using

Formal Verification Techniques

PROJECT GUIDE INDUSTRIAL GUIDE STUDENT

1
Dr. V Lakshmi Prabha, Siva Shankar Kuppam R Hari Priya,
Visiting professor, Technologist, 17MV33.
PSG College of Technology. Western Digital.
2 OUTLINE

 INTRODUCTION
 VERIFICATION METHODOLOGIES
 WHY FORMAL VERIFICATION?
 FORMAL VERIFICATION OF OPERATION MODULE
 RESULTS
 FORMAL VERIFICATION OF CONFIGURATION MODULE
 RESULTS
 CONCLUSION
3 INTRODUCTION
 Verification is a process to ensure that the intent is preserved in the implementation. Verifies
the correctness of the Design.
 Verification consumes 70% of design effort in multi million gate ASICs, reusable IPs and SoC
designs.
 Verification – Am I building the product right?
 Implementation should meet specification

Verification has two principal objectives:

1) Discovery of defects in the system

2) The assessment of whether or not the system is usable in an operational situation
4 VERIFICATION METHODOLOGIES

Traditional
Functional - Simulation
Formal – Equivalence Checking

Property Based
Functional – ABV during the Design
Formal – Property Verification
5 ASSERTION BASED VERIFICATION

What is an assertion?
Assertion is a statement which is used in the design to
Check the intended behavior of the design
Ensure consistency between designer’s intention and what is
developed / implemented

Major Functionality
Error detection
Error notification
6 PROPERTY BASED VERIFICATION

 What is a property?
General behavior attribute to characterize a design
A collection of logical and temporal relationships between
and among subordinate Boolean expressions, Sequential
expressions and other properties that in aggregate represent
a set of design behavior
It can be used in verification as assertion or functional
coverage specification or constraints
7 Drawbacks of Simulation

 Test bench creation – manual application of stimulus, error

prone and time consuming
 Large simulation regression run times
 Simulation based verification can be incomplete
 Disadvantages : Exponential number of test vectors to exercise
all possible transitions between components
8 Why Formal Verification?
 Exhaustive verification is possible in Formal Approaches

 No test bench generation - Reduction in DV cycle time – Stimulus

generation is taken care by Formal tool

 Constraints needed to achieve verification can be included.

 Faster verification : Completion at fraction of time compared to

simulation when no memory blow-up

 Properties/Assertions when generic can be re-used and automatically

generated

 Comprehensive verification and coverage : High quality and

confidence. Better ability to detect errors
 9 How Formal Verification is done?

S1 S0 = p
Sw ...

Fixed Point
Initial Set of States

 Starting from Initial State, it explores all possible reachable states in one step
until it hits a fixed-point [beyond which no new states can be explored]
 Validate properties at all stages.
10 RESULT ANALYSIS
 PASS:
 No additional reachable states implies that all reachable states have been verified
 Assertion Passes

 FAIL:
 A Failing state indicates that the assertion fails.

 STATE SPACE EXPLOSION:

 Additional state space still being reached implies that the proof is not yet complete

 Cannot go on
 Time limitation
 Memory limitation
11 PROJECT WORK
 Understanding the SPEC of RTL modules of NAND Flash memory and make an
Assertion Plan.
 Generating Automated Assertion file.
 Load the Design files and Assertion files into the Formal Verification tool.
 Do Formal Verification for assertion checks.
 Debug the failures and Conclude whether the verification engineer understood the
feature of RTL in a wrong way or the RTL behaves in a unexpected way. The changes
needed can be done either by the Designer or Verification engineer.

Design Files Pass

Lib Files DEBUG ANALYZE
FORMAL TOOL Fail
Assertion file
Constraints
 12 Introduction to NAND Flash Memory
1. Flash memory stores information in an array of memory cells made from floating-gate transistors. In
traditional single-level cell (SLC) devices, each cell stores only one bit of information.
2. Some newer flash memory, known as multi-level cell (MLC) devices, including triple-level cell (TLC)
devices, can store more than one bit per cell by choosing between multiple levels of electrical charge to
apply to the floating gates of its cells.

FIGURE 1:FLOATING GATE TRANSISTOR

13
ASSERTION CREATION AND VERIFICATION FLOW

DESIGNER VERIFICATION
STEP 1: RTL PLAN DOCUMENT
INPUTS

STEP 2: AUTOMATION ASSERTION FORMAL

SPEC TOOL
SCRIPT .SV FILE

FAULT
Achieve
REPORTED TO DEBUG
100% clean
EITHER VE or
intented RTL
Designer
14 OPERATIONS OF NAND FLASH

The Main operations performed in NAND flash include

 Read
 Erase
 Program
15 OPERATION MODULE

 Inside each mode of operation several flavors of

operations are performed

 8 bit Operation codes are available to indicate which

Operation is performed.

 The operation codes along with favorable conditions

can either Assert or De-assert operation signals.
16 SIGNALS OF ASSERTION & DE-ASSERTION

 Conditions to assert include:

Enable
Data
Conf (Based on Architecture)

 Condition to De-Assert include:

Sync_rst
Async_rst
17 SAMPLE SPEC SHEET OF OPERATION MODULE

OPERATION OPERATION ARCHITECTURE ENABLE CONF SYNC_RST ASYNC_RST

CODE SIGNAL
00 1
: 2
FF 3 NIL
18 ASSERTIONS PLAN

 property Flavor_1_3(clk,async_rst,code,enable,conf,sync_rst,signal);
@(posedge clk) disable iff (!async_rst)
(code && enable && conf && !sync_rst) |=> signal;
Endproperty

 property Flavor_neg_1_3(clk,async_rst,code,enable,conf,sync_rst,signal);
@(posedge clk) disable iff (!async_rst)
$rose(signal) |-> ($past(async_rst) == 'b1) && $past(enable) &&
$past(conf)&& $past(code) && $past(!sync_rst);
Endproperty
19 ASSERTIONS PLAN contd.,

 property Flavor_deassert1_3(clk,async_rst,data,enable,conf,sync_rst,signal);
@(posedge clk) disable iff (!async_rst)
(sync_rst) |=> !signal;
Endproperty

 property Flavor_deassertneg1_3
(clk,async_rst,data,enable,conf,sync_rst,signal);
@(posedge clk) disable iff (!async_rst)
$fell(signal) |-> ($past(sync_rst) == 1)) ;
Endproperty
 ASSERTIONS PLAN contd.,
 property Flavor_2(clk,async_rst,code,enable,signal);
20 @(posedge clk) disable iff (!async_rst)
(code && enable) |=> signal;
endproperty
 property Flavor_2_neg(clk,async_rst,code,enable,signal);
@(posedge clk) disable iff (!async_rst)
$rose(signal) |-> $past(code & enable);
endproperty
 property Flavor_2_deassert(clk,async_rst,code,enable,sync_rst,signal);
@(posedge clk) disable iff (!async_rst)
(!code) |=> !(signal);
endproperty
 property Flavor_2neg(clk,async_rst,code,enable,sync_rst,signal);
@(posedge clk)
$fell(signal) |-> ($past(!enable) || $past(!code)) || (!async_rst) ;
endproperty
21 ASSERTION.sv FILE
module check( input ports);
wire ;
wire ; //Wire declarations

Properties
:
:
assert property();
endmodule
bind
 THE RESULTS BEFORE DEBUG
22
 RESULTS AFTER DEBUG
23
24 REASONS FOR ASSERTION FAILURE

 Mismatch of SPEC and RTL

 Without the required code or favorable conditions the signal getting

asserted

 Any unintended behavior of RTL

 Unimplemented signals in RTL but provided in SPEC.

 If a Signal doesn’t arrive at all in RTL then vacuous pass will be attained.
25 CONFIGURATION MODULE
 The Configuration RTL module is implemented mostly as
configurable registers. The latches are implemented in two flavors,
they are with default values of either zero or non-zero.
 Due to huge loading time caused by high parasitic loading, the
loading operations take a lot of time. Hence the Configurations are
stored in ROMFUSE.
 When parameters are stored in ROMFUSE, timing during the
configuration loading operations can be minimized.
 Rather than accessing ROMFUSE each time to get Configurations,
On PowerOnRead, all the ROMFUSE configurations are loaded into
the LOCALREG. This is the main functionality of the RTL module.
26 SAMPLE SPECIFICATION DOCUMENT OF
CONFIGURATION

ADDRESS NAME OF CONFIGURATIONS INIT/DEFAULT

0 (zero)

A (non-zero)
 ASSERTION PLAN
 ASSERTION FOR REGISTERS WITH ZERO AS DEFAULT
27
 property local_reg(Addr,Reg);
@(posedge clk) disable iff(reset)
(( ADDR === Addr )) |->
(Reg ==DEFAULT );
Endproperty

ASSERTION FOR REGISTERS WITH NON-ZERO AS DEFAULT

 property local_reg_spl(Addr,Reg,set);
@(posedge clk ) disable iff(reset)
((ADDR === Addr)) |->
Reg == {set[7] & DEFAULT[7],
set[6] & DEFAULT[6],
set[6] & DEFAULT[6],
set[4] & DEFAULT[4],
set[3] & DEFAULT[3],
set[2] & DEFAULT[2],
set[1] & DEFAULT[1],
set[0] & DEFAULT[0] }; endproperty
28 RESULTS BEFORE DEBUG
29 RESULTS AFTER DEBUG
30 CONCLUSION
Using the Formal verification method,
 Exhaustive verification has been performed for the modules
“Operation” and “Configuration” and all the issues were listed to
the designers.

 The verification team has helped the design team to provide a

100% intended functionality in RTL.

 As a result of Formal verification of modules, golden modules are

obtained, which are stitched together as a whole design upon
which other verification techniques like UVM are performed.
31

THANK YOU