Prof. John Nestor ECE Department Lafayette College Easton, Pennsylvania ECE Senior Design I Lecture 11 - Case Study: Verifying Microprocessors Fall 2008 Read Salt & Rothery Ch. 4 (System Design)

ECE 491 Fall 2008Lecture 11 - Verif. Case Study2 Where we are  Last Time  Data Communications  Today  Verification Case Study: Validating the Pentium 4

ECE 491 Fall 2008Lecture 11 - Verif. Case Study3 Review: Why do Verification?  Key to successful design  Finding bugs early is key S & R Fig. 6.4 During design During manufacturing After sale Cost of fixing flaws

ECE 491 Fall 2008Lecture 11 - Verif. Case Study4 Case Study: Verification in Industry  Motivation: Discuss verification of a “really big” design.  Sources for this Case Study  Bob Bentley, “Validating the Intel ® Pentium ® 4 Processor”, Proceedings 38th Design Automation Conference, June 2001*.  Bob Bentley and Rand Gray, “Validating the Intel ® Pentium ® 4 Processor”, Intel Technology Journal, Q  Bob Bentley, “Validating a Modern Microprocessor, talk slides, 17th Conference on Compuer-Aided Verification, Bob Colwell, The Pentium Chronicles, John Wiley, *available on the Moodle page

ECE 491 Fall 2008Lecture 11 - Verif. Case Study5 Microprocessor Design Scope  Typical lead CPU design requires:  500+ person design team: logic and circuit design physical design validation and verification design automation  2-2½ years from start of RTL development to A0 tapeout  9-12 months from A0 tapeout to production qual (may take longer for workstation/server products) Slide Source: Bob Bentley, “Validating a Modern Microprocessor, talk slides. 13th Conference on Compuer-Aided Verification, 2001

ECE 491 Fall 2008Lecture 11 - Verif. Case Study6 Pentium 4 - Microarchitecture Source: “The Microarchitecture of the Pentium® 4 Processor”, Intel Technology Journal, First Quarter

ECE 491 Fall 2008Lecture 11 - Verif. Case Study7 Pentium 4 Proliferations Pentium® 4 42M transistors / GHz 49-55W L=180nm Pentium® 4 “Northwood” 55M transistors / 2-2.5GHz 55W L=130nm Area=131mm 2 Process Shrinks Pentium® 4 “Prescott” 125M transistors / GHz 115W L=90nm Area=112mm 2

ECE 491 Fall 2008Lecture 11 - Verif. Case Study8 Timeline - Pentium 4 Design  Late Structural RTL (SRTL) design begins at the “cluster level”  Q First full-chip structural RTL integration  Q Structural RTL largely completed  Dec A-step tapeout (layout goes to fab)  Jan First packaged parts arrive  Q Initial samples shipped to customers  Oct Production ship qualification  Nov Product launch ( GHz)

ECE 491 Fall 2008Lecture 11 - Verif. Case Study9 RTL Coding Activity 3000 files, 1.3M lines total (including comments, white space) A0 tapeout First Full-Chip RTL Model 250K lines changed in one week RTL Coding Complete Slide Source: Bob Bentley, “Validating a Modern Microprocessor, talk slides. 13th Conference on Compuer-Aided Verification, 2001

ECE 491 Fall 2008Lecture 11 - Verif. Case Study10 Pentium 4 Validation - Staffing  10 people in initial “nucleus” from previous project  40 new hires in 1997  20 new hires in 1998

ECE 491 Fall 2008Lecture 11 - Verif. Case Study11 P4 Validation Environment  Hardware  IBM RS/6000 workstations ( Hz full processor model)  Pentium III Linux systems (3-5Hz full processor model)  Computing pool of “several thousand” systems  Simulation statistics  About 1 million lines of code in SRTL model  5-6 billion clock cycles simulated / week  200 billion total clock cycles simulated overall About 2 minutes of execution with a 1GHz clock!

ECE 491 Fall 2008Lecture 11 - Verif. Case Study12 Cluster-Level Testing  Divide overall design into 6 “clusters” + microcode  Develop “cluster testing environments” (CTEs) to validate each cluster separately (e.g. floating point, memory, bus)  Then validate using full processor model  Advantages of the approach  Controllability - control behavior at microarchitecture level  Early validation possible for each cluster  Decoupled validation possible for each cluster

ECE 491 Fall 2008Lecture 11 - Verif. Case Study13 Other Validation Features  Extensive validation of power-reduction logic  Code coverage and code inspections a major part of methodology  Formal verification used for Floating Point & Instruction Decode Logic

ECE 491 Fall 2008Lecture 11 - Verif. Case Study14 Formal Verification in P4 Validation  Based on model checking  Given a finite-state concurrent system  Express specifications as temporal logic formulas  Use symbolic algorithms to check whether model holds  Constructed database of 10,000 “proofs”  Over 100 bugs found  20 were “high quality” bugs not likely to be found by simulation  Example errors: FADD, FMUL

ECE 491 Fall 2008Lecture 11 - Verif. Case Study15 Validation Results  5,809 bugs identified by simulation  3,411 bugs found by cluster-level testing  2,398 found using full-chip model  1,554 bugs found by code inspection  492 bugs found by formal verification  Largest sources of bugs: memory cluster (25%)

ECE 491 Fall 2008Lecture 11 - Verif. Case Study16 Bug Sources Slide Source: Bob Bentley, “Validating a Modern Microprocessor, talk slides. 13th Conference on Compuer-Aided Verification, 2001

ECE 491 Fall 2008Lecture 11 - Verif. Case Study17 Bug Rate Slide Source: Bob Bentley, “Validating a Modern Microprocessor, talk slides. 13th Conference on Compuer-Aided Verification, 2001

ECE 491 Fall 2008Lecture 11 - Verif. Case Study18 Validation Results  Breakdown of bug sources (complete list in paper)  12.7%Goofs - simple typos, cut and paste errors, etc.  11.4% Miscommunication  9.3% Microarchitecture definition  9.3%Logic/microcode changes  8%Corner cases  5.3%Power down issues  4.4%Documentation  3.9%Complexity  3.4%Random Initialization  2.8%Late definition  2.8%Incorrect RTL assertions  2.6%Design mistake

ECE 491 Fall 2008Lecture 11 - Verif. Case Study19 Colwell on Verification  Errors are unavoidable!  Error reduction strategies that don’t work  “Make an example” of offender  Hire only geniuses  Blame the verification team  Recommended Strategy: “Avoid/Find/Survive”  Design to avoid bugs  When bugs do occur, try to find them before production  Plan to survive bugs that make it into production

ECE 491 Fall 2008Lecture 11 - Verif. Case Study20 Design to Avoid Bugs  Focus on getting design right the first time  Schedule pressure can result in buggy designs  Must trade off deadline vs. quality  Look for ways to manage design complexity  Most complexity is in control logic Microcode Interacting Finite State Machines Exceptions  Reduce complexity where possible

ECE 491 Fall 2008Lecture 11 - Verif. Case Study21 Plan to Survive Bugs  Anticipate that bugs will occur  Build debugging “hooks” into design  Example: Performance Counters  Verify debugging hooks, too

ECE 491 Fall 2008Lecture 11 - Verif. Case Study22 Colwell’s “6-Step Plan for High Product Quality” 1. Incorporate only the minimum necessary complexity. 2. Make sure design team and mgt. agree on the right level of quality. 3. Try to avoid a “design team / validators” pecking order. 4. Foster an emotional attachment to the project (but distance self from work when necessary). 5. Design and follow a bug-tracking method.

ECE 491 Fall 2008Lecture 11 - Verif. Case Study23 Postscript: How Not to do Verification

ECE 491 Fall 2008Lecture 11 - Verif. Case Study24 Coming Up  Data Communications 2