ECE 491 Senior Design I

1
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 NestorECE DepartmentLafayette
CollegeEaston, Pennsylvania 18042nestorj_at_lafayet
te.edu
2
Where we are

• Last Time
• Metastability
• Today
• Detailed Design

3
Detailed Design Overview
BLOCK A Detailed Design Implementation Debug and
verify
System Spec.
System Integration And Test
Prototype
BLOCK B Detailed Design Implementation Debug and
verify
Project Plan
BLOCK J Detailed Design Implementation Debug and
verify
Req. Spec
Test Plan
S R Fig. 6.1
4
Block Design Activities
Manufacturing
Detailed design documentation
BLOCK A
System Spec.
Project Plan
System integration And test
Detailed design
Implementation
Debug verification
S R Fig. 6.2
5
Testing Verification

• Key to successful design
• Finding bugs early is key

Cost of fixing flaws
During design
During manufacturing
After sale
S R Fig. 6.4
6
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
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
Colwell Ch. 3 - Refinement (contd)

• Engineering Change Orders (from last time)
• The Bridge from Architecture to Design
• Product Quality - covered in Verification
• Design Reviews
• Anecdote the P6 Bus

9
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
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
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
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
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
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
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
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
Realization Phase Success Factors

• Balanced decision making - who makes the call on
  design decisions?
• Cant 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
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
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
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
Managing Realization

• Adding headcount doesnt 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
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
Coming Up

• Handshaking to synchronize multiple FSMs
• Intellectual Property
• Ethernet