ECE 491 Senior Design I Lecture 13 Detailed

ECE 491 - Senior Design I Lecture 13 - Detailed Design Fall 2007 Reading: Colwell, Ch. 3 -4, “Design Reviews” Salt & Rothery Chapter 5, 6 Prof. John Nestor ECE Department Lafayette College Easton, Pennsylvania 18042 nestorj@lafayette. edu ECE 491 Fall 2005 Lecture 13 - Detailed Design 1

Where we are } Last Time: } Metastability } Today: } Detailed Design ECE 491 Fall 2005 Lecture 13 - Detailed Design 2

Detailed Design Overview BLOCK A: Detailed Design Implementation Debug and verify System Spec. BLOCK B: Detailed Design Implementation Debug and verify Project Plan System Integration And Test Prototype BLOCK J: Detailed Design Implementation Debug and verify Req. Spec Test Plan S & R Fig. 6. 1 ECE 491 Fall 2005 Lecture 13 - Detailed Design 3

Block Design Activities Manufacturing BLOCK A: Detailed design documentation System Spec. Project Plan Detailed design Implementation Debug & verification System integration And test S & R Fig. 6. 2 ECE 491 Fall 2005 Lecture 13 - Detailed Design 4

Testing & Verification Cost of fixing flaws } Key to successful design } Finding bugs early is key During design ECE 491 Fall 2005 During manufacturing After sale Lecture 13 - Detailed Design S & R Fig. 6. 4 5

Testing & Verification } Unit test – done during detailed design } Verify that blocks work correctly “standalone” } Allow for regression testing after design changes } System test – final test after integration } Often a formal event } Requires a detailed System Test Plan ECE 491 Fall 2005 Lecture 13 - Detailed Design 6

Design Management } Communications during design } Goal: reduce communication to allow independent block designs } Reality: some communication is necessary } Documentation } Key documents: schematics, HDL code, “theory of operation” document } Revision control – to keep documentation consistent and up to date } Design Reviews – to report on design progress and examine design decisions ECE 491 Fall 2005 Lecture 13 - Detailed Design 7

Colwell Ch. 3 - Refinement (cont’d) } } } Engineering Change Orders (from last time) The Bridge from Architecture to Design Product Quality - covered in Verification Design Reviews Anecdote: the P 6 Bus ECE 491 Fall 2005 Lecture 13 - Detailed Design 8

Engineering Change Orders (ECOs) } A way of tracking and managing design changes } Original form: “piece of paper” with approval signatures } Current: web-based or email-based } Sources of Change: } } Marketing / Management Performance Analysis Functional Validation Design Complexity Issues ECE 491 Fall 2005 Lecture 13 - Detailed Design 9

Managing ECOs } Start in Concept phase by documenting key ideas and decisions; communicating to others } Begin ECOs after behavioral model is designed } “ECO Czar” - responsible for tracking ECOs and keeping documents up to date } Approval process: signature list ECE 491 Fall 2005 Lecture 13 - Detailed Design 10

The Bridge from Architecture to Design } How do you transfer “core ideas from the heads of the architects into the heads of the design team? ” } Must transfer “philosophy” - ot just what is to be designed, but why? } Challenge: establishing trust with design team when unknowns persist } P 6 project used a library of video presentations } Focus Groups as a method of transfer ECE 491 Fall 2005 Lecture 13 - Detailed Design 11

Design Reviews } Goals of design review } Keep members of team up to date about state of design } Keep stakeholders up to date about state of design } Provide designer with feedback about key decisions ECE 491 Fall 2005 Lecture 13 - Detailed Design 12

Bell Labs Software Design Reviews } Presenter makes design materials available to reviewers in advance: } } Background information Relevant parts of design specification Source code Testing plans and status } Reviewers must study these materials in advance } Designer gains benefit from preparation ECE 491 Fall 2005 Lecture 13 - Detailed Design 13

Ingredients for a Successful Review } Collwell: Attitude is key } Both reviewer and designer must “distance themselves emotionally from the design under review” } “As a design engineer leading a design review, your job is to … put your ego in your desk drawer and present your design for review by smart people who are motivated to find things wrong with it” } “keep reminding yourself that the reviewers are seeking flaws in your design – not flaws in you” } “…someday you will have occasion to return the favor” ECE 491 Fall 2005 Lecture 13 - Detailed Design 14

Design Anecdote - The P 6 Bus } The Question } P 6 group designed a new bus } Original Pentium bus designers wanted P 6 to use their bus } Issues } New bus accounted for widening gap between processor clock and memory speed } But, new bus would require redesign of system logic, motherboards, etc. } How was the decision made? } Technical considerations vs. political considerations ECE 491 Fall 2005 Lecture 13 - Detailed Design 15

Colwell Ch. 4 - Realization Phase } Goal: build the design selected in Refinement } Large increase in number of participants } Time to commit and “burn the lifeboats” “Nothing will ever be attempted, if all possible objections must first be overcome” --Samuel Johnson } Result of realization: a prototype } Analogy: construction phase for a large building ECE 491 Fall 2005 Lecture 13 - Detailed Design 16

Realization Phase: Success Factors } Balanced decision making - who makes the call on design decisions? } Can’t consult architect for every decision - too many! } The “ 1% rule”: “If you believe that the performance impact of the choice is less than 1% on the designated benchmark, you are free to make the choice on your own. Higher than a 1% performance hit and you must include architects in the decision” } Documentation - “Microarchitecture Specifications” } Integrating architects and design engineers ECE 491 Fall 2005 Lecture 13 - Detailed Design 17

Performance/Feature Tradeoffs } Pitfall: “over-optimizing” performance “The best is the enemy of the good” --Voltaire } Reliability concerns } The need for error detection } What should happen when an error occurs? • Roll-back? • Restart? } Performance-monitoring facilities } Pitfall: “gratuitious innovation” ECE 491 Fall 2005 Lecture 13 - Detailed Design 18

Managing Realization } Metrics needed to track design progress } “Health of Model” Metric } } } Regression results Time to debug Forward progress High-priority bugs Age of bugs } Pitfall: many bugs are found in late stages of design; metric may get worse towards end ECE 491 Fall 2005 Lecture 13 - Detailed Design 19

Managing Realization } Awards, Rewards, and Recognition } A motivation tool for high performance } Pitfalls: • • Overlooking important achievements Giving credit to the wrong persons Not considering the larger context “Firefighting by arsonists” ECE 491 Fall 2005 Lecture 13 - Detailed Design 20

Managing Realization } Adding headcount doesn’t always help } New staff must be brought up to speed } But, may be useful in well-defined tasks “Adding manpower to a late software project makes it later” -- F. Brooks, “Brooks’ Law” ECE 491 Fall 2005 Lecture 13 - Detailed Design 21

Scheduling and Project Tracking } Predicting a schedule is difficult } Large amount of uncertainty } Make “best guess” based on experience } Use for high-level planning (project costing, staffing, etc. ) } Project Tracking } P 6 approach: Weekly report from engineers • Estimate how much of assignment is accomplished • Estimate how much time remains • See curves in Fig. 4. 1, 4. 2, 4. 3 pp. 107 -110 ECE 491 Fall 2005 Lecture 13 - Detailed Design 22

Coming Up } Handshaking to synchronize multiple FSMs } Intellectual Property } Ethernet ECE 491 Fall 2005 Lecture 13 - Detailed Design 23