TDAG: A T ransaction D riven, A bstraction G uided Random Simulation Framework

1. TDAG: A Transaction Driven, Abstraction Guided Random Simulation Framework Authors Debapriya Chatterjee, Jayesh Gaur Electrical Engineering & Computer Science Department The University of Michigan, Ann Arbor

2. Motivation • Industrial Designs are Huge ! • Bugs are buried deep in the design • We need to improve controllability at the actual interface • Will benefit Semi-Formal Verification 101010011 101110111

3. Outline • Goal • Prior Work • TDAG Framework • Extracting Transactions • Distance Function Creation • TDAG Tool • Experimental Results • Lessons Learned • Group Dynamics • Conclusion

4. Goal • Enable Semi-Formal Verification for the target module • Need better controllability for the Actual Interface Under Verification

5. Prior Work • Regression Tests • Example – Consider a multiprocessor system • Need to excite the checker Assembly Test Assembly Test Assembly Test Core 1 Cross-bar Checker Core 2 Difficult to create all possible scenarios at this interface Core 3

6. Prior Work • Random Verification • Create Model for Connecting Modules • Bus Functional Models • How to make sure model is correct ? • IQ Test – Wagner et. al. ASP-DAC 2006 • Transaction Driven Verification of interfaces • Transactions are multi-cycle activities • Reads / Writes • User defines Transactions for Interface Under Test • Closed Loop Verification Methodology • User Defined Transactions difficult to create Ref : "Depth-Driven Verification of Simultaneous Interfaces"Ilya Wagner et al, ASP-DAC, Yokohama City, Japan, January 2006

7. Prior Work • Semi-Formal Verification • Guide random simulations based on a DUT abstraction • Scalability is higher • Powerful methodology for Verification • Activities at primary inputs may not reflect inside the design • Semi-Formal will not work efficiently • Most activities occur at level of transactions • Guiding simulations every cycle does not help • Efficient methodology required : • Semi-Formal Verification at Transaction Level • Transactions to be applied at secondary inputs TDAG

8. TDAG Framework : Transaction Pool Secondary Inputs Primary Inputs 0 1 0 1 1 0 1 1 0 0 0 0 1 0 1 0 1 0 1 1 0 0 0 1 Transaction Pool Multicycle interactions Burst Read Trans Burst Write Trans How to Find Transactions ? legal series of inputs at the interface over multiple cycles Process

9. TDAG Framework : Extracting Transactions • Extracting Transactions • We use Inferno Ref : "Verification Through the Principle of Least Astonishment“ Beth Isaksen and Valeria Bertacco, ICCAD, San Jose, CA, November 2006 Figure Courtesy: Valeria Bertacco (GSRC ’07)

10. TDAG Framework : Driving Transactions • After Transaction Pool has been extracted • The DUT is only the module + checker • Effectively stimuli applied at secondary inputs • We can apply Semi-Formal Verification now, on sub-module Transaction Pool Trans T1 :10 cycles, Trans T2 :12 cycles, Trans T3 : 16 cycles T1 T3 T2

11. Semi-Formal Approach 1 3 0 2 4 Abstract model Formal analysis • An abstraction of the design is selected based on the goal • Formal analysis is done on the abstraction and costs are assigned to states based on the distance from the goal • Cost layers guide the simulation DUV DUV state space Figure Courtesy: Valeria Bertacco (GUIDO DAC’06)

12. TDAG Framework : Distance Bins -4 -1 0 -3 -2 • Write a checker which has a latch named “accept” • 1 is loaded into accept if bug condition is detected • Take “accept” and other relevant latches of the module into abstraction • Perform backward reachability on the abstraction, construct distance bins / function, done with fix-point based BDD calculations. • Distance function: Given the state vector tells which bin it belongs to shell 0 shell 1 shell 2 shell 3 shell 4 Figure Courtesy: Valeria Bertacco (GUIDO DAC’06)

13. TDAG Tool • Progress in abstraction space => Grant transaction • No progress=> Abort with Prob. p < 1 o/p Latches Semi-Formal Engine 0 1 1 0 0 0 1 0 1 1 0 1 1 1 0 1 i/p sv T1 T2 checker State Vector: sv Transaction Pool T1,T2,T3 Continue till checker fires

14. TDAG Tool - Insights • Tool written in a mix of C/C++ • The simulation part uses PLI 2.0 to communicate with simulator • ModelSim used as the simulator • CUDD 2.4.1 used as the BDD Package • Design Compiler used for Synthesis • To create distance function from abstraction

15. Experimental Results • Design Characteristics • Bug Injection • All simulations run on a 2.3 GHz, 32 bit Linux Machine with 2 GB RAM

16. Experimental Results • Memory Controller * U.D – Un-detected; T.O – TimeOut • Bugs in Timing Module • Based on Sun Ultrasparc IV errata for memory controller • Back-to-Back Bursts result in error on system bus • Similar bug models created for Memory Controller

17. Experimental Results • OpenSparcCrossBar • Processor to Cache Crossbar • Four Cores accessing One Cache • Bugs in Arbiter Module • Commented code inside Verilog of the arbiter module • Bugs related to some earlier implementation of FIFO Pointers • Read/Write Pointers

18. Lessons Learned • C/C++ interfaces are difficult to handle • Library issues can be painful • Use Vera/System-Verilog instead of PLI • Every simulator has it’s own way of implementing PLI • Lot of time spent on working with VCS – Finally ModelSim used • BDD’s explode just too often !! • Just looking at number of latches does not help • Memory controller does not have too many latches • Beware of OpenSparc • Especially the CCX Crossbar – Too Complex !!

19. Group Dynamics • Project work was equally divided • Both of us worked equally on all aspects of the project • Idea, Coding, Experiments, Presentation/Report • At a very high level • Debapriya held responsibility of “Formal” part • Jayesh held responsibility of “Simulation” part

20. Conclusions • TDAG is novel • Semi-Formal Verification at the level of Transactions • Application of Transactions at secondary inputs • Experimental results demonstrate effectiveness • Future Work • Experiment on more designs • Can have other interesting applications

21. Questions