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

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

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

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

5. ECE 491 Fall 2005Lecture 13 - Detailed Design5 Testing & 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

6. ECE 491 Fall 2005Lecture 13 - Detailed Design6 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

7. ECE 491 Fall 2005Lecture 13 - Detailed Design7 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

8. ECE 491 Fall 2005Lecture 13 - Detailed Design8 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 P6 Bus

9. ECE 491 Fall 2005Lecture 13 - Detailed Design9 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

10. ECE 491 Fall 2005Lecture 13 - Detailed Design10 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

11. ECE 491 Fall 2005Lecture 13 - Detailed Design11 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  P6 project used a library of video presentations  Focus Groups as a method of transfer

12. ECE 491 Fall 2005Lecture 13 - Detailed Design12 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

13. ECE 491 Fall 2005Lecture 13 - Detailed Design13 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

14. ECE 491 Fall 2005Lecture 13 - Detailed Design14 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”

15. ECE 491 Fall 2005Lecture 13 - Detailed Design15 Design Anecdote - The P6 Bus  The Question  P6 group designed a new bus  Original Pentium bus designers wanted P6 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

16. ECE 491 Fall 2005Lecture 13 - Detailed Design16 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

17. ECE 491 Fall 2005Lecture 13 - Detailed Design17 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

18. ECE 491 Fall 2005Lecture 13 - Detailed Design18 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”

19. ECE 491 Fall 2005Lecture 13 - Detailed Design19 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

20. ECE 491 Fall 2005Lecture 13 - Detailed Design20 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”

21. ECE 491 Fall 2005Lecture 13 - Detailed Design21 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”

22. ECE 491 Fall 2005Lecture 13 - Detailed Design22 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  P6 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

23. ECE 491 Fall 2005Lecture 13 - Detailed Design23 Coming Up  Handshaking to synchronize multiple FSMs  Intellectual Property  Ethernet