Download presentation
Presentation is loading. Please wait.
Published byDontae Benham Modified over 9 years ago
1
Prof. John Nestor ECE Department Lafayette College Easton, Pennsylvania 18042 nestorj@lafayette.edu ECE 491 - Senior Design I Lecture 11 - Case Study: Verifying Microprocessors Fall 2008 Read Salt & Rothery Ch. 4 (System Design)
2
ECE 491 Fall 2008Lecture 11 - Verif. Case Study2 Where we are Last Time Data Communications Today Verification Case Study: Validating the Pentium 4
3
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
4
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, Q1 2001. Bob Bentley, “Validating a Modern Microprocessor, talk slides, 17th Conference on Compuer-Aided Verification, 2005. Bob Colwell, The Pentium Chronicles, John Wiley, 2005. *available on the Moodle page
5
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
6
ECE 491 Fall 2008Lecture 11 - Verif. Case Study6 Pentium 4 - Microarchitecture Source: “The Microarchitecture of the Pentium® 4 Processor”, Intel Technology Journal, First Quarter 2001 http://developer.intel.com/technology/itj/q12001/articles/art_2.htm.
7
ECE 491 Fall 2008Lecture 11 - Verif. Case Study7 Pentium 4 Proliferations Pentium® 4 42M transistors / 1.3-1.8GHz 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 / 2.8-3.4GHz 115W L=90nm Area=112mm 2
8
ECE 491 Fall 2008Lecture 11 - Verif. Case Study8 Timeline - Pentium 4 Design Late 1996 - Structural RTL (SRTL) design begins at the “cluster level” Q1 1997 - First full-chip structural RTL integration Q2 1998 - Structural RTL largely completed Dec 1999 - A-step tapeout (layout goes to fab) Jan 2000 - First packaged parts arrive Q1 2000 - Initial samples shipped to customers Oct 2000 - Production ship qualification Nov 2000 - Product launch (1.4-1.5GHz)
9
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
10
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
11
ECE 491 Fall 2008Lecture 11 - Verif. Case Study11 P4 Validation Environment Hardware IBM RS/6000 workstations (0.5-0.6Hz 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!
12
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
13
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
14
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
15
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%)
16
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
17
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
18
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
19
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
20
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
21
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
22
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.
23
ECE 491 Fall 2008Lecture 11 - Verif. Case Study23 Postscript: How Not to do Verification
24
ECE 491 Fall 2008Lecture 11 - Verif. Case Study24 Coming Up Data Communications 2
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.