1 / 45

Fully configurable hierarchical transaction level verifier for functional verification

Master’s Defense Chaitanya Bandi Dept. of ECE, Auburn University. Fully configurable hierarchical transaction level verifier for functional verification. Project Advisor: Dr. Vishwani D. Agrawal Committee Members: Dr. Victor P. Nelson, Dr. Fa F. Dai Dept. of ECE, Auburn University.

sharla
Télécharger la présentation

Fully configurable hierarchical transaction level verifier for functional verification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Master’s Defense Chaitanya Bandi Dept. of ECE, Auburn University Fully configurable hierarchical transaction level verifier for functional verification Project Advisor: Dr.Vishwani D. Agrawal Committee Members: Dr.Victor P. Nelson, Dr. Fa F. Dai Dept. of ECE, Auburn University Chaitanya: MEE Project Defense

  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 Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  4. Physics behind Flash Cell Chaitanya: MEE Project Defense

  5. Flash Transistor Structure FG CG Chaitanya: MEE Project Defense

  6. Threshold Voltage Modulation • The threshold voltage, Vthof 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. Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  8. Reading from a erased cell a) Erased cell b) Erased cell after application of gate voltage An application of Vg = 0-0.8Vresults in a current flow from the source to the drain which is represented as a logic ‘1’ in the cell. Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  13. Why NAND Flash • NAND Flash Array Architecture makes its cell size almost half compared to a NOR cell. Chaitanya: MEE Project Defense

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

  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. Chaitanya: MEE Project Defense

  16. How is Regression Testing done? Stimulus Test Model Golden Model Response Response Comparison Chaitanya: MEE Project Defense

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

  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. Chaitanya: MEE Project Defense

  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 Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  21. Benefits of TLM • Embedded Software Development • Functional Verification Chaitanya: MEE Project Defense

  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 Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

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

  29. Drawbacks a) Review of the microcode in execution • Extremely manual • Excessive domain knowledge • Prone to human errors Chaitanya: MEE Project Defense

  30. Drawbacks b) Waveform comparison of golden and test simulation data results in • irrelevant differences • comparing huge waveform databases which is very time-consuming Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  32. Hierarchical Transaction Level Verifier Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  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}. Chaitanya: MEE Project Defense

  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 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. Chaitanya: MEE Project Defense

  38. Algorithm in execution Chaitanya: MEE Project Defense

  39. Slicing based signal comparison Chaitanya: MEE Project Defense

  40. Microcode Comparison Algorithm Chaitanya: MEE Project Defense

  41. Controllable comparison Golden Test If the microcode flow matches, then only Compare the events on the signals during this transaction. (Waveform compare) Match? Don't compare Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

  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. Chaitanya: MEE Project Defense

More Related