Ecological Niche or Survival Gear? Improving an Industrial Simulation Methodology with Formal Methods FMCAD 2006 Wolfg

1. Ecological Niche or Survival Gear? Improving an Industrial Simulation Methodology with Formal Methods FMCAD 2006 Wolfgang Roesner IBM Systems & Technology Group Hardware Verification Austin, TX. USA wolfgang@us.ibm.com (c) IBM Corporation

2. Overview 1. The Target : High-End Server Micros/Systems 2. The Gorilla Scaling the Simulation-Based Methodology 3. Successes in the Application of (S)FV 4. New Design Challenges 5. Growing the Brain Scaling the (S)FV - Methodology (c) IBM Corporation

3. > 1.5 M Lines of VHDL Several 100s of people High-End Server: POWER5 Chip • Topology: • Two cores on chip, a 2-way SMP. • Core private L1s (64KB I, 32KB D) • Simultaneous Multi Threading SMT • Chip private 1.875 MB L2 • L3 directories on chip. • L3 36 MB data off chip. • Technology: • 130nm Copper & SOI • 389 mm2 die size. • 8 Layers of metal • 276 million transistors on chip. • 1.9 GHz clock. • Custom & Semi-Custom Design Style • High Frequency Constraints (c) IBM Corporation

4. High-End Server: POWER5 Multi-Chip Module 95x95mm Four POWER5 Chips Four Cache Chips 4,491 signal I/Os 89 layers of metal MCM builds 8 way SMP. (c) IBM Corporation

5. High-End Server: POWER5 64-Way SMP System • Interconnection exploits enhanced distributed switch • All intra MCM POWER5-to-POWER5 connection run at processor speed • All other POWER5-to-POWER5 and POWER5-L3 connections run at half processor speed and scale with processor frequency (c) IBM Corporation

6. RTL Verification RTL PSL et al. Driver/Checker (VHDL, Verilog) Assertions Physical VLSI Language Compile Design Tools / Model Build Custom Design Test Program Generator Cycle-Based Model Constraint Random C++ Unit Testbench Testbench Formal Software Simulator Verification : (Semi) Formal Verification Boolean Equivalence Hardware Check Accelerator Hardware Emulator (c) IBM Corporation

7. Overview 1. The Target : High-End Server Micros/Systems 2. The Gorilla Scaling the Simulation-Based Methodology (c) IBM Corporation

8. Scaling the Simulation-Based Methodology Hardware Emulator Engine (10k – 100k x) VPO Level HW/FW Verification VBU Level System Level Hardware Accel Engine (10-1k x) Chip Level Element Level Unit Level Software Sim Engine (1x) Hardware Verification VBU = Virtual Bring-up (chip) VPO = Virtual Power-On (system) (c) IBM Corporation

9. Driver Driver Driver Driver Unit 2 Model Unit 1 Model Unit 2 Checker (properties) Unit 1 Checker (properties) Driver Driver Unit 2 Model Unit 1 Model Unit 2 Checker (properties) Unit 1 Checker (properties) Testbench Components Design Components Scaling the Simulation-Based Unit Environments (c) IBM Corporation

10. Scaling the Simulation-Based Methodology (cont.) • Success Factors: • Simulation Technology scales well • cycle-based streamlined algorithms • super-linear scaling with “parallel instance support” • large workstation “farms” • Hardware engines for acceleration/emulation • Layered Re-use of checking components • “vertical re-use” -> major productivity • unit->core->chip->system • Sophisticated generation technology • simple constraint-based random at unit level • constraint-based, on-the-fly transaction generation for data-mover units (e.g. memory sub-system) • heavy constraint-based test program generation at core/chip/system (c) IBM Corporation

11. “Gorilla Muscles” • Unit Level : • Interface-specific checking • Intrusive checking • Implementation dependent • Lots of code ( > 500k LOC C++) • Score-boarding • accumulate state in data structures • Sophisticated drivers (constraint random) • Core Level : • Integrate unit level checkers • Re-use drivers or use architecture testgen • Chip Level : • Integrate cores + select/re-use • Architecture testgen • System Level : • Big environment integration job (several chip env) • Architecture testgen System Chip Core Unit # Verification Engineers (c) IBM Corporation

12. Don’t Underestimate the Gorilla’s IQ • Experienced verification engineers • productivity differences >10x • Sophisticated Generation Technology • model-based generation • Coverage Technology (c) IBM Corporation

13. Overview 1. The Target : High-End Server Micros/Systems 2. The Gorilla Scaling the Simulation-Based Methodology 3. Successes in the Application of (S)FV (c) IBM Corporation

14. Formal Methods • Formal Methods are a vital complement to simulation flow: • Abstract Coherency Protocol verification • Equivalence Checking (Boolean & Sequential) [Paruthi] • almost total elimination of gate-level verification • Coverage Reachability Analysis • RTL - Special Focus areas • sub-unit level, macro, multi-macro • designer-assertions and FV-expert testbenches • FPU – unit data-path verification [Jacobi] • “Pervasive Logic” [Gloekler] • Lab Bring-up Bug re-creation • often faster repro • high-coverage/proof of side-effect-free fixes (c) IBM Corporation

15. RTL Verification Summary • Successes: • Methodology scaled well even for POWER5/POWER6-size project • POWER6 : two-core, 4-5GHz, 750M transistors • POWER4/5/6 systems booted O/S with first pass hardware • RTL abstraction worked well, even for full custom chip design style • Very repeatable, disciplined, verifiable methodology • Extension of verification with (S)FV helped in many areas of critical complexity (c) IBM Corporation

16. Endangered Species ?? … or is the Gorilla really a Frog ?? (c) IBM Corporation

17. Overview 1. The Target : High-End Server Micros/Systems 2. The Gorilla Scaling the Simulation-Based Methodology 3. Successes in the Application of (S)FV 4. New Design Challenges (c) IBM Corporation

18. New Pressures On the Ecosystem • New design requirements that multiply complexity (aside from multi-core explosion ) • Error Recovery • high-end designs have lots of error detection logic • many different recovery schemes • centralized – checkpoint/restart from recovery unit • decentralized error check/correction • Strategy : error injection • Problems : • myriads of injection points in almost any “mainline state” of the design • end-to-end spec easy (architectural correctness) but unit-level specification is extremely hard and always in flux • Asynchronous Interfaces • higher integration • creates much larger distances between parts of chip – difficult to control clock skew globally • modular high-frequency building blocks for productivity (c) IBM Corporation

19. New Pressures On the Ecosystem (cont) • New design requirements that multiply complexity (aside from multi-core explosion ) • Power Save Modes • clock gating • nap, doze, sleep modes • functional power gating – unplug power from part of the design • Again : a unit-based specification of correctness is not easily available • -> Partitioning of the problem to unit-level is hard or impossible • Observation : • Many of the above challenges involve “override” or exception functionality • under all conditions, if <exception> then some properties hold • this allows specifications that replace large logic cones to be replaced by free variables • easy problem reduction by (S)FV tools • while simulation still runs a full model (c) IBM Corporation

20. Overview 1. The Target : High-End Server Micros/Systems 2. The Gorilla Scaling the Simulation-Based Methodology 3. Successes in the Application of (S)FV 4. New Design Challenges 5.Growing the Brain Scaling the (S)FV - Methodology (c) IBM Corporation

21. Scaling the (S) FV Methodology • Scaling our use of (S)FV is undisputedly our main lever to improve pre-silicon verification • Wherever we use (S)FV successfully, the verification is stronger • Our strategy to improve verification quality is Non-Intrusive Formal Verification [Baumgartner] • Rather than wait for • “the new verification engineer” (in large numbers) • or a break-through in technology • Shape overall methodology to allow leverage of most work in both halves of the methodology • simulation • (S)FV • What are the successes, what are the obstacles ? (c) IBM Corporation

22. Sidebar Sidebar -5 Ground rules for successful methodology evolution (c) IBM Corporation

23. Ground Rule 1 : Management Force Is Not Effective • A team that does not buy into a methodology change will make it fail • Example : Design Verification Coverage • the “6-KiloTon-Coverage” story (c) IBM Corporation

24. Ground Rule 2 : It’s Evolution • Don’t bank on quick revolutions in design/verification methodology development… • … unless there is reason to hire a new design/verification team • … unless a previous project was a disaster • Design/verification methodologies advance in evolutionary ways • teams want to keep successful methods • exchange only deficient parts of existing methodology (c) IBM Corporation

25. Anticyclic Investments; Iterative, Collective Learning Methodology Change Cycle effort Design Project Cycle time Evolution happens in time windows between projects – these windows shrinking ! Introduction of new technologies/methodologies Technology utilization • Example: • the “Logic-Synthesis” story Second cycle back-lash time Early exuberant enthusiasm (c) IBM Corporation

26. Ground Rule 3 : Balanced Optimization • A methodology optimization along just one axis of the design constraint space is doomed • Example : Design Verification Coverage • Higher-level design specification • the “FSM-Design-Language” story • Automatically extracted specification • the “Inferred-FSM” story (c) IBM Corporation

27. Ground Rule 4 : Exploit Synergies • Any verification methodology/technology advance has to embrace the verification team • A new tool or method must not put additional burden on the verification team w/o significant overall gain • Success is more likely if the additional effort can be used synergistically for more than one purpose (c) IBM Corporation

28. Ground Rule 5 : Leverage Industry Standards • A new methodology/technology will be more easily embraced if it involves learning a new, marketable skill • Examples: • the “xxx-to-VHDL” story • Counter-Example: • the “The-Team-That-Signed-Up-For-Life” story (c) IBM Corporation

29. Sidebar Sidebar - END (c) IBM Corporation

30. Synergistic Sim/FV Methodology Crucial Areas of Synergy : • 1. Common Design Model • No semantic gaps between simulation / FV • 2. Common Design Partitions / Units • 3. Common Designer Assertions / Coverage Specifications • 4. Common Verification Properties / Testbench Checkers • 5. Common Environment Specs / Testbench Drivers (c) IBM Corporation

31. 1. Common Design Model RTL PSL et al. Driver/Checker (VHDL, Verilog) Assertions Physical VLSI Language Compile Design Tools / Model Build Custom Design Test Program Generator Cycle-Based Model Constraint Random C++ Unit Testbench Testbench Formal Software Simulator Verification : (Semi) Formal Verification Boolean Equivalence Hardware Check Accelerator Hardware Emulator (c) IBM Corporation

32. 2. Common Design Partitions • The functional unit is the center of gravity for simulation-based verification • FV technologies that scale only to macro (sub-unit) level require specifications at non-documented, fluid interfaces • “impedance mismatch” between simulation/FV effort • Aggressive scaling of (S)FV (e.g. SixthSense) with unit level capacity goal (c) IBM Corporation

33. 3. Common Designer Assertion/Coverage Specifications • Synthesizable assertions / coverage events • easy : designers stay in their domain • hard : designers do “extra work” • Assertion-based verification is a great example of successful methodology evolution • PSL / SVA embed assertions in HDLs • Use (S)FV to discard unreachable assertions / coverage events • automatic integration into simulation flow largely lacking (c) IBM Corporation

34. 4/5. Common Testbench RTL PSL et al. Driver/Checker (VHDL, Verilog) Assertions Physical VLSI Language Compile Design Tools / Model Build Custom Design Test Program Generator Cycle-Based Model Constraint Random C++ Unit Testbench Testbench Formal Software Simulator Verification : (Semi) Formal Verification Boolean Equivalence Hardware Check Accelerator Hardware Emulator (c) IBM Corporation

35. 4./5. Common Testbench (cont.) • An FV requirement for a separate testbench (esp. driver) is the biggest obstacle against larger proliferation • Most success in situations where little or no specific environment specificationis necessary : • interfaces/properties where mostly non-deterministic driving is sufficient • use of an abstract HDL reference model and SEC (FPU data path [Jacobi]) • Re-use between Sim/FV requires a synthesizable testbench • High-level HDL synthesis forverification (minimize states for FV) • Goal conflict between… • ..easy to code sequential algorithms with dynamic score-boards (a la C++ container classes) • ..efficient mapping to hardware structures • Synthesis from HVL (high-level verification languages) has been worked on (for emulation) but with very limited success • SystemC (SVC) synthesis ? • Different language candidates ? (c) IBM Corporation

36. 4./5. Common Testbench (cont.) • Re-usable HDL template libraries seem practical way to drive forward • Needs gradual re-education of verification engineers • The same engineers that just went through the HVL transition  • Testbench drivers • First simple approach is to separate: • port driver - synthesizable, translator of transaction to pin interface ( aka transactor) • generator – • runtime constraint-based/pre-gen’d transactions for sim • non-deterministic environment for FV (procedural or constraint specified) (c) IBM Corporation

37. Conclusion • Hardware verification still is the bottle-neck • We desperately need the increasing scalability of (S)FV base technologies and take their arrival as a given • Simulation technology is improving in parallel, but does it get enough academic focus ? • We need better • re-use • synergy • seamless mix & match of the verification work in simulation and FV • We need to force investment in future verification infrastructure to support dual-use technology (c) IBM Corporation

38. Ecological Niche or Survival Gear? Improving an Industrial Simulation Methodology with Formal Methods Thank you! (c) IBM Corporation