Qualis Design Corporation PO Box 4444 Beaverton, Oregon 97075-4444 USA Phone: +1-503-670-7200

1. Industry and Textbook Overview Qualis Design Corporation PO Box 4444 Beaverton, Oregon 97075-4444 USA Phone: +1-503-670-7200 FAX: +1-503-670-0809 http://www.qualis.com

2. Verification Process • Involves People Methods Tools

3. RTL Design & Coding Verification in Design Flow Architectural System Design C/C++ Component Specifications Paper Simulation Proofs Verilog, VHDL Physical Synthesis Synthesis & Layout

4. Verification vs Testing Manufacture Design Synthesis Spec HDL Gates Silicon DFT Testbench Equivalence Checking Testing Functional Verification

5. People in Verification • "We do not have the resources to have dedicated verification engineers" • Amount of work is the same • Slice it differently Design Design & Verification Verification

6. People in Verification • "I'm the best hardware designer. Therefore I know how to write testbenches" • Verification and design have different focus • Design: meeting performance requirements • Optimism • Coding & design style • Implementation architecture • Verification: make sure intent has been implemented • Paranoia • Requirement traceability • Controllability & observability

7. People in Verification • "I'm the best hardware designer. Therefore I know how to write testbenches" • Testbench design requires different skills from hardware design • Design: timing closure • Scripting • Physical effects • Power, timing • Verification: software engineering • Configuration management • Abstraction & Objected oriented • Random generation & coverage

8. People in Verification • "I want to be a hardware designer when I grow up" • Hardware design has all the glory • Spread to verification effort • Properly-designed verification environments require more creativity than design • More freedom in verification • No subset • No performance constraints • No technology constraints • All cool, new tools are in verification • Develop verification training &career paths

9. People in Verification • Supply industry aligning with task separation • P&L business units • Separate sales force • Specialized consultants and AEs • Verification-only companies • EDA • Services • IP • Verification curriculum in universities

10. Manual Checking • Unfortunately, very common • Use waveform viewer to interpret results • Non reproducible • Sensitive to misinterpretations • Cannot handle large number oftransactions Simulator Vector file Viewer Stimulus DUT

11. Golden Vectors • Natural extension of DFT & visual check • Compare results against known good results Simulator Vector file Viewer Stimulus DUT Vector file Comparator

12. On-The-Fly Self-Checking • Compute expected results on-the-fly • Significant effort investment • Tolerant of non-functional variations • Typical for datacom Scoreboard Transferfunction Data Structure Stimulus BFM (Compare) DUT

13. Post-Processing Self-Checking • Response verified against reference model • Compare function must tolerate non-functional differences • Typical for DSP and CPU • C reference model part of spec Simulator Stimulus DUT Comparator File Other REF File

14. Stimulus Traditional Approach • Self-checking not a requirement • Used with HDLs, or C/C++ • Large number of testbenches • Progress measured against check-list Goal % Testcases Time

15. Stimulus Random Approach • Progress measured using functional coverage metrics Goal Self-checking, random test environment development time % Testcases Time

16. Random Vs Traditional Productivity gain Goal % Testcases Time

17. Formal vs Random Vs Traditional Productivity gain Formal Verification (Assertions) Goal % Testcases Time

18. Verification IP PPP Mon CSIX HDLC PPP Gen PPP Mon Network Processor SPI4.2 PPP Packet Scoreboard HDLC PPP Gen PPP Mon Ethernet PPP Gen Testcases

19. Verification IP PPP Mon CSIX HDLC PPP Gen PPP Mon Network Processor SPI4.2 PPP Packet Scoreboard HDLC PPP Gen PPP Mon Ethernet PPP Gen Testcases

20. Verification IP • Verification IP helps reduce time-to-first-test Productivity gain Goal % Testcases Time Earlier time-to-1st-test

21. Self-Checking Transactions Verification Engineers Industry Status Custom Environment Verification Plan Specman, Vera Specs Coverage Driven Pop. Size Ad-Hoc Formal Verification Laggards Leaders

22. Self-Checking Transactions Verification Engineers My Book Custom Environment Verification Plan Specman, Vera Specs Coverage Driven Pop. Size Ad-Hoc Formal Verification Laggards Leaders

23. My Book

24. Genesis of the Book • Self-checking transaction-level testbenches based on verification plan and behavioral model • Nortel Networks, 1992 • Consulting services in verification • Self-employed, 1994 • Advanced verification class (3 days) • Qualis Design, 1996 • Book started • Dining room table, 1999

25. Objectives of the Book • Functional verification is critical • There is a process to functional verification • Functional verification is different from design • Engineers don't know HDLs as well as they think they do • Improve software engineering skills

26. For Undergrad Class • Chapter 1: What is Verification? • Why should you care • Chapter 2: Verification Tools • What should you use • Chapter 3: Verification Plan • What should you do • Chapter 4: Non-RTL Coding • There is (better) life beyond RTL • Verilog is not that easy to learn well

27. For Undergrad Class • Chapter 5: Stimulus and Response • How should you stimulate • How should you observe • How do you know it's correct • Appendix A: Coding Guidelines • How you should write your code

28. For Graduate Class • Chapter 3: Verification Plan • What should you do • Chapter 4: Non-RTL Coding • There is (better) life beyond RTL • Verilog is not that easy to learn well • Chapter 6: Architecting Testbenches • How to minimize your effort • Wrestling with VHDL • Chapter 7: Simulation Management • Actually using the stuff

29. For Professional Class • Chapter 3: Verification Plan • What should you do • Chapter 4: Non-RTL Coding • There is (better) life beyond RTL • Verilog is not that easy to learn well • Chapter 5: Stimulus and Response • How should you stimulate • How should you observe • How do you know it's correct

30. For Professional Class • Chapter 6: Architecting Testbenches • How to minimize your effort • Wrestling with VHDL • Chapter 7: Simulation Management • Actually using the stuff

31. For Prelude to HVLs • Chapter 1: What is Verification? • Why should you care • Chapter 2: Verification Tools • What should you use • Chapter 3: Verification Plan • What should you do • Chapter 5: Stimulus and Response • How should you stimulate • How should you observe • How do you know it's correct

32. In Future Edition • Chapter 2: Verification Tools • Assertions • Formal verification tools • HVLs (Specman, VERA) • Functional Coverage • Chapter 3: Verification Plan • Coverage-driven plan • Chapter 4: Non-RTL Coding • HVLs

33. In Future Edition • Chapter 5: Stimulus and Response • Scoreboarding • Chapter 6: Architecting Testbenches • Constrainable Random Generation • Functional Coverage • Chapter 7: Simulation Management • HVLS as reference models • Seed management

34. Support Material • Quiz • http://janick.bergeron.com/wtb/quiz.html • 3 questions per chapters • Answers supplied • Verification Project • http://janick.bergeron.com/guild/project.html • 4-port ATM switch • Design specification • Behavioral model (Verilog, VHDL) • Partial solutions provided by contributors

35. Industry and Textbook Overview Qualis Design Corporation PO Box 4444 Beaverton, Oregon 97075-4444 USA Phone: +1-503-670-7200 FAX: +1-503-670-0809 http://www.qualis.com