1. February 25, 2009Chaitanya: MEE Project Defense1 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

2. February 25, 2009Chaitanya: MEE Project Defense2 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. February 25, 2009Chaitanya: MEE Project Defense3 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. February 25, 2009Chaitanya: MEE Project Defense4 Physics behind Flash Cell

5. Flash Transistor Structure February 25, 2009Chaitanya: MEE Project Defense5 CG FG

6. Threshold Voltage Modulation The threshold voltage, V th 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 V th can be modulated by adding or removing electrons from the floating gate. February 25, 2009Chaitanya: MEE Project Defense6

7. Erased Cell Vs Programmed Cell February 25, 2009Chaitanya: MEE Project Defense7 A flash cell can exist in one of the two states, erased or programmed. a) Erased cell b) Programmed cell

8. Reading from a erased cell February 25, 2009Chaitanya: MEE Project Defense8 An application of V g = 0-0.8V results in a current flow from the source to the drain which is represented as a logic ‘1’ in the cell. a) Erased cell b) Erased cell after application of gate voltage

9. Reading from a programmed cell February 25, 2009Chaitanya: MEE Project Defense 9  An application of V g = 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 V th 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. a) Programmed cell b) Programmed cell after application of gate voltage

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. February 25, 2009Chaitanya: MEE Project Defense10

11. Programming a flash cell February 25, 2009Chaitanya: MEE Project Defense11 Electrons in the substrate move through the gate oxide and are trapped in the floating gate by the phenomenon of Tunneling. a) Erased cell b) Programmed Cell

12. Erasing a flash cell February 25, 2009Chaitanya: MEE Project Defense12 Electrons that are trapped in the floating gate move through the gate oxide into the substrate through the phenomenon of Tunneling. a) Programmed cell b) Erased cell

13. Why NAND Flash NAND Flash Array Architecture makes its cell size almost half compared to a NOR cell. February 25, 2009Chaitanya: MEE Project Defense13

14. Intel’s new 34nm 32Gb NAND Flash chip Courtesy: http://www.intel.com/pressroom/archive/releases/20080529comp.htm14

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. February 25, 2009Chaitanya: MEE Project Defense15

16. How is Regression Testing done? February 25, 2009Chaitanya: MEE Project Defense16 Golden Model Test Model Stimulus Response Comparison

17. Abstraction Levels February 25, 2009Chaitanya: MEE Project Defense 17 Layout Transistor Transistors Gate Level Gates RTL Transaction Level System Level Abstraction RTL TLM

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. February 25, 2009Chaitanya: MEE Project Defense18

19. TLM Vs RTL Details of communication among modules Communication is done using Transactions February 25, 2009Chaitanya: MEE Project Defense19 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. February 25, 2009Chaitanya: MEE Project Defense20

21. Benefits of TLM a)Embedded Software Development b)Functional Verification February 25, 2009Chaitanya: MEE Project Defense21

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. February 25, 2009Chaitanya: MEE Project Defense22 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. February 25, 2009Chaitanya: MEE Project Defense23

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. February 25, 2009Chaitanya: MEE Project Defense24

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. February 25, 2009Chaitanya: MEE Project Defense25

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. February 25, 2009Chaitanya: MEE Project Defense26

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. February 25, 2009Chaitanya: MEE Project Defense27

28. Verification Environment February 25, 2009Chaitanya: MEE Project Defense 28 Microcode Flow Signals Manual review of microcode in execution Waveform Comparison Verifies the algorithm flow Verifies the signal flow

29. Drawbacks a) Review of the microcode in execution –Extremely manual –Excessive domain knowledge –Prone to human errors February 25, 2009Chaitanya: MEE Project Defense29

30. 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, 2009Chaitanya: MEE Project Defense30

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. February 25, 2009Chaitanya: MEE Project Defense31

32. Hierarchical Transaction Level Verifier February 25, 2009Chaitanya: MEE Project Defense32

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. February 25, 2009Chaitanya: MEE Project Defense33

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. February 25, 2009Chaitanya: MEE Project Defense34

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. February 25, 2009Chaitanya: MEE Project Defense35

36. Microcode Comparison Algorithm Let the microcode flow in the golden and test cases can be modeled as M G and M T, where M G = { m G1,m G2,...,m Gi,..m Gn } and M T = { m T1, m T2,...,m Ti,..m Tn }. February 25, 2009Chaitanya: MEE Project Defense36

37. 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, 2009Chaitanya: MEE Project Defense37

38. Algorithm in execution February 25, 2009Chaitanya: MEE Project Defense38

39. Slicing based signal comparison February 25, 2009Chaitanya: MEE Project Defense39

40. February 25, 2009Chaitanya: MEE Project Defense40 Microcode Comparison Algorithm

41. Golden Test February 25, 2009Chaitanya: MEE Project Defense41 JMP AND REGACC NOP JMP SET Microcode 1 Microcode 2 Microcode 3 Microcode 4 Microcode 5 Microcode 6 Match? Don't compare Controllable comparison If the microcode flow matches, then only Compare the events on the signals during this transaction. (Waveform compare)

42. 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, 2009Chaitanya: MEE Project Defense42

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 SimVision TM database. February 25, 2009Chaitanya: MEE Project Defense43

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. February 25, 2009Chaitanya: MEE Project Defense44

45. February 25, 2009Chaitanya: MEE Project Defense45 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.