Fully configurable hierarchical transaction
level verifier for functional verification
Master’s Defense
Chaitanya Bandi
Dept. of ECE, Auburn University
Project Advisor: Dr. Vishwani D. Agrawal
Committee Members: Dr. Victor P. Nelson, Dr. Fa F. Dai
Dept. of ECE, Auburn University
February 25, 2009
Chaitanya: MEE Project Defense
1
Outline
 Problem Statement
 NAND Flash Memory Design
 Regression Testing
 Transaction Level Verification
 Microcode Regression
 Comparison at a glance
 Controllable comparison
 Results and Future Work
February 25, 2009
Chaitanya: MEE Project Defense
2
Problem Statement
To verify the functional correctness of design revisions of the
fullchip netlists in NAND Flash memory design group, Intel
Corporation, Folsom, CA.
February 25, 2009
Chaitanya: MEE Project Defense
3
Physics behind Flash Cell
February 25, 2009
Chaitanya: MEE Project Defense
4
Flash Transistor Structure
FG
CG
February 25, 2009
Chaitanya: MEE Project Defense
5
Threshold Voltage Modulation
• The threshold voltage, Vth of a transistor is
the gate voltage required to invert the
channel and allow the conduction of electrons
from the source to drain.
• Information is stored in and erased from the
flash cell by adding or removing electrons
from the floating gate.
• The voltage Vth can be modulated by adding
or removing electrons from the floating gate.
February 25, 2009
Chaitanya: MEE Project Defense
6
Erased Cell Vs Programmed Cell
a) Erased cell
b) Programmed cell
A flash cell can exist in one of the two states, erased or
programmed.
February 25, 2009
Chaitanya: MEE Project Defense
7
Reading from a erased cell
a) Erased cell
b) Erased cell after application of gate voltage
An application of Vg = 0-0.8V results in a current flow from the
source to the drain which is represented as a logic ‘1’ in the cell.
February 25, 2009
Chaitanya: MEE Project Defense
8
Reading from a programmed cell
a) Programmed cell
b) Programmed cell after application of gate voltage
 An application of Vg = 0-0.8V does not result in a current flow from
the source to the drain which is represented as a logic ‘0’ in the cell.
 The threshold voltage required in this case is greater than the actual
Vth of the device because of the presence of electrons on the floating
gate.
 This change in the required threshold voltage is due to the principle
of Threshold Voltage modulation.
February 25, 2009
Chaitanya: MEE Project Defense
9
Tunneling
• Tunneling is referred to as the
phenomenon where electrons can
tunnel through an oxide layer.
• This is achieved in the presence of a
huge potential difference applied
across the oxide.
February 25, 2009
Chaitanya: MEE Project Defense
10
Programming a flash cell
a) Erased cell
b) Programmed Cell
Electrons in the substrate move through the gate oxide and
are trapped in the floating gate by the phenomenon of
Tunneling.
February 25, 2009
Chaitanya: MEE Project Defense
11
Erasing a flash cell
a) Programmed cell
b) Erased cell
Electrons that are trapped in the floating gate move through
the gate oxide into the substrate through the phenomenon of
Tunneling.
February 25, 2009
Chaitanya: MEE Project Defense
12
Why NAND Flash
• NAND Flash Array Architecture makes its
cell size almost half compared to a NOR
cell.
February 25, 2009
Chaitanya: MEE Project Defense
13
Intel’s new 34nm 32Gb NAND Flash chip
Courtesy: http://www.intel.com/pressroom/archive/releases/20080529comp.htm
14
Regression Testing
• Testing a program after it has been
modified.
• Major component in the program
maintenance phase.
– Checks the correctness of the new logic,
– Ensures the continuous working of the
unmodified portions of a program,
– Validates that the modified program as a
whole functions correctly.
February 25, 2009
Chaitanya: MEE Project Defense
15
How is Regression Testing done?
Stimulus
Golden
Model
Test Model
Response
Response
Comparison
February 25, 2009
Chaitanya: MEE Project Defense
16
Abstraction Levels
TLM
System Level
RTL
Abstraction
RTL
Transaction
Level
RTL
Gate Level
Transistor
TLM
Transaction
Level
RTL
Gates
Transistors
Layout
February 25, 2009
Chaitanya: MEE Project
Defense
17
Transaction Level Modeling
• RTL is too low level of abstraction for
system level design.
• Reducing and encapsulating details of
design into transactions allows the
designer to get a quick perception of the
whole design in terms of its functionality.
February 25, 2009
Chaitanya: MEE Project Defense
18
TLM Vs RTL
• Details of
communication
among modules
• Details of
implementation
of modules
• Communication
is done using
Transactions
• Implementation
is at the signal
level
February 25, 2009
Chaitanya: MEE Project Defense
19
Example
• A transaction level model would
represent a read or write protocol using
a single function call, with an object
representing the request and another
object representing the response.
• An RTL HDL model would represent
such a read or write protocol as a series
of signal assignments and signal read
operations.
February 25, 2009
Chaitanya: MEE Project Defense
20
Benefits of TLM
a) Embedded Software Development
b) Functional Verification
February 25, 2009
Chaitanya: MEE Project Defense
21
Embedded Software Development
• Hardware models upon which embedded
software is to be tested are available
earlier in the design cycle in the form of
transactions.
• Software development usually starts only
after the hardware prototype is available.
HW SW Co-design and Validation
February 25, 2009
Chaitanya: MEE Project Defense
22
Functional Verification
• TLM models help the verification
engineers to
– Develop targeted tests that help in
system verification as a whole.
– Design hierarchical verification
methodologies.
February 25, 2009
Chaitanya: MEE Project Defense
23
Functional Verification in systems
with RTL-only design
• Functional verification can still be done
using hierarchical verification
methodologies.
• The verification environment must have
an ability to extract transactions.
February 25, 2009
Chaitanya: MEE Project Defense
24
How are transactions extracted?
• NAND Flash Memory Chip contains a
microcode processing unit, the
controller.
• Instructions or microcode being
executed in a simulation by the
controller are modeled as
transactions.
February 25, 2009
Chaitanya: MEE Project Defense
25
The Controller
• When the controller receives a “read” or a
“write” instruction, it sends out signals on the
bus to receive the data in the memory or to
write to the memory respectively.
• During a simulation, these series of
instructions are tracked as microcode
instructions and modeled as transactions for
the purpose of functional verification.
February 25, 2009
Chaitanya: MEE Project Defense
26
Verification Environment
• Verification environment currently in
NAND Flash design group involves
– A Step-by-step review of microcode in
execution using the fullchip simulation
information.
– Waveform comparison of the golden and
test simulation results.
February 25, 2009
Chaitanya: MEE Project Defense
27
Verification Environment
Microcode
Flow
Signals
February 25, 2009
Verifies the
algorithm
flow
Verifies the
signal flow
Manual review of
microcode in
execution
Waveform
Comparison
Chaitanya: MEE Project
Defense
28
Drawbacks
a) Review of the microcode in execution
– Extremely manual
– Excessive domain knowledge
– Prone to human errors
February 25, 2009
Chaitanya: MEE Project Defense
29
Drawbacks
b) Waveform comparison of golden
and test simulation data results in
– irrelevant differences
– comparing huge waveform databases
which is very time-consuming
February 25, 2009
Chaitanya: MEE Project Defense
30
Proposed Solution
• A verification environment in which
– Algorithm flow is checked automatically.
– Controllable comparison of waveform
database.
– Algorithm details at the transaction level
and signal details at the RTL are verified
simultaneously.
February 25, 2009
Chaitanya: MEE Project Defense
31
Hierarchical Transaction Level
Verifier
February 25, 2009
Chaitanya: MEE Project Defense
32
Features of the Verifier
• Model system functionality as transaction
packets.
• Each packet can further contain sub
transactions.
• This forms a hierarchical model.
• The leaf in the hierarchical verifier is at the
signal level.
February 25, 2009
Chaitanya: MEE Project Defense
33
Controllable Comparison
• User can configure whether to step
into a transaction packet or not
based on its relevance in the
hierarchy tree.
• The signals that are to be compared
can also be configured based on their
relevance to the parent packet.
February 25, 2009
Chaitanya: MEE Project Defense
34
Microcode Regression
• A set of stimulus is applied to the golden
netlist and the test netlist.
• Response is recorded as both microcode
flow from the data in the log files and
signal flow is determined from the
waveform database.
February 25, 2009
Chaitanya: MEE Project Defense
35
Microcode Comparison Algorithm
• Let the microcode flow in the golden
and test cases can be modeled as MG
and MT, where
MG = { mG1,mG2,...,mGi,..mGn} and
MT = { mT1,mT2,...,mTi,..mTn}.
February 25, 2009
Chaitanya: MEE Project Defense
36
Microcode Comparison Algorithm
• Compare the microcode instruction of Golden and Test
cases mGi and mTi
• If mGi and mTi matches, store the time slices between
which these instructions take place. Mark it as a good
time slice.
• If mGi and mTi don’t match, store the time slices
between which these instructions take place. Mark it
as a bad time slice.
• Perform an event based signal comparison only during
the time slices at which there is a microcode match.
February 25, 2009
Chaitanya: MEE Project Defense
37
Algorithm in execution
February 25, 2009
Chaitanya: MEE Project Defense
38
Slicing based signal comparison
February 25, 2009
Chaitanya: MEE Project Defense
39
Microcode
Comparison
Algorithm
February 25, 2009
Chaitanya: MEE Project Defense
40
Golden Test
JMP
Match?
Microcode 1
AND
Microcode 2
REGACC
Microcode 3
NOP
Don't
compare
If the microcode flow matches, then only Compare the events on the
signals during this transaction. (Waveform compare)
Microcode 4
Controllable comparison
JMP
Microcode 5
SET
Microcode 6
February 25, 2009
Chaitanya: MEE Project Defense
41
Automation
1. “Slice” the golden simulation into Microcode
Execution Slices.
2. Determine how signals change for each Microcode
Execution Slice.
3. Store the information
4. Read the Test waveform and perform similar
slicing.
5. Compare signal changes (or signal status) for each
Microcode Execution Slice that has been validated.
6. Process, and report differences.
February 25, 2009
Chaitanya: MEE Project Defense
42
Results
• Simulation is perfomed in Cadence NCVerilog
simulator.
• Microcode comparison is done using the
Transaction-Level verifier in PERL scripting
language.
• Signals are compared using the EventCom, a
waveform comparison tool that uses
SimVisionTM database.
February 25, 2009
Chaitanya: MEE Project Defense
43
Conclusion
• The entire process is automated and hence the
turnaround time for validating each netlist
revision is reduced from several days to several
hours.
• In the event of a mismatch in the simulation
results, the verification engineer can identify
which portions of the microcode flow is not being
validated and take measures appropriately.
February 25, 2009
Chaitanya: MEE Project Defense
44
Future Work
• In future, we can have additional features
to have the capability of viewing the
transactions in the waveforms.
• This will enable the verification engineers
to graphically visualize the transactions
and signals simultaneously in the
waveform window.
February 25, 2009
Chaitanya: MEE Project Defense
45