Fully configurable hierarchical transaction level verifier for functional

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. 8 V 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. 8 V 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 34 nm 32 Gb NAND Flash chip Courtesy: http: //www. intel. com/pressroom/archive/releases/20080529 comp. 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? s Golden Model Stimulu Test Model 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 Layout February 25, 2009 Transistor s 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 = { m. G 1, m. G 2, . . . , m. Gi, . . m. Gn} and MT = { m. T 1, m. T 2, . . . , m. Ti, . . m. Tn}. February 25, 2009 Chaitanya: MEE Project Defense 36

• Microcode Comparison Algorithm Compare the microcode instruction of Golden and Test cases m. Gi and m. Ti • If m. Gi and m. Ti matches, store the time slices between which these instructions take place. Mark it as a good time slice. • If m. Gi and m. Ti 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 Event. Com, a waveform comparison tool that uses Sim. Vision. TM 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