Ecological Niche or Survival Gear?

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