Fully configurable hierarchical transaction level verifier for functional verification

1
Fully configurable hierarchical transaction level
verifier for functional verification
Masters 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
2
Outline

• Problem Statement
• NAND Flash Memory Design
• Regression Testing
• Transaction Level Verification
• Microcode Regression
• Comparison at a glance
• Controllable comparison
• Results and Future Work

3
Problem Statement
To verify the functional correctness of design
revisions of the fullchip netlists in NAND Flash
memory design group, Intel Corporation, Folsom,
CA.
4
Physics behind Flash Cell
5
Flash Transistor Structure
FG
CG
6
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.

7
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.
8
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.
9
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.

10
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.

11
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.
12
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.
13
Why NAND Flash

• NAND Flash Array Architecture makes its cell size
  almost half compared to a NOR cell.

14
Intels new 34nm 32Gb NAND Flash chip
15
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.

16
How is Regression Testing done?
Stimulus
Test Model
Golden Model
Response
Response
Comparison
17
Abstraction Levels
Abstraction
TLM
System Level
RTL
Transaction Level
TLM
RTL
RTL
Gate Level
Transaction Level
Transistor
RTL
Gates
Transistors
Layout
18
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.

19
TLM Vs RTL

• Details of communication among modules
• Communication is done using Transactions

• Details of implementation of modules
• Implementation is at the signal level

20
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.

21
Benefits of TLM

1. Embedded Software Development
2. Functional Verification

22
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
23
Functional Verification

• TLM models help the verification engineers to
• Develop targeted tests that help in system
  verification as a whole.
• Design hierarchical verification methodologies.

24
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.

25
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.

26
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.

27
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.

28
Verification Environment
Verifies the algorithm flow
Manual review of microcode in execution
Microcode Flow
Verifies the signal flow
Waveform Comparison
Signals
29
Drawbacks

• a) Review of the microcode in execution
• Extremely manual
• Excessive domain knowledge
• Prone to human errors

30
Drawbacks

• b) Waveform comparison of golden and test
  simulation data results in
• irrelevant differences
• comparing huge waveform databases which is very
  time-consuming

31
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.

32
Hierarchical Transaction Level Verifier
33
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.

34
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.

35
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.

36
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.

37
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 dont 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.

38
Algorithm in execution
39
Slicing based signal comparison
40
Microcode Comparison Algorithm
41
Golden Test
JMP
AND
REGACC
NOP
JMP
SET
Microcode 1
Microcode 2
Microcode 3
Microcode 4
Microcode 5
Microcode 6
Match?
If the microcode flow matches, then only Compare
the events on the signals during this
transaction. (Waveform compare)
Don't compare
42
Automation

• Slice the golden simulation into Microcode
  Execution Slices.
• Determine how signals change for each Microcode
  Execution Slice.
• Store the information
• Read the Test waveform and perform similar
  slicing.
• Compare signal changes (or signal status) for
  each Microcode Execution Slice that has been
  validated.
• Process, and report differences.

43
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.

44
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.

45
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.