Connect with us

Best Practices for Hardware Engineers

Discussion in 'Electronic Design' started by [email protected], May 31, 2006.

Scroll to continue with content
  1. Guest

    Hello, I have a list of Best Practices for Hardware Engineers that I
    would like anyone to look over and tell me what you think or what
    should be added to the list.

    Here is my list in no particular order

    1. Always have a top block diagram, in your schematics and in your FPGA
    2. Follow the System Engineering Design Process Model
    3. Document, Document, Document your work
    4. Modularize your work
    5. Try a Top Down design approach instead of Bottom Up
    6. Ask for Peer Reviews and code walk throughs
    7. If a standard exits then follow it.
    8. Manage time, don't let time manage you.

    The list serves two purposes for me. First I believe it will permit one
    to handle a complex task and increase the success of the task. Second,
    I would like to get my co-workers to follow some sort of common design
    process. I work for the government in a small Research and Development
    branch of 30 people. A few people practice some of the items on the
    list, but many don't. I don't have any experience in private industry
    and I would want to know if design teams in private industry follow a
    set of best practices or design processes? When a new person joins the
    team does he/she get introduced on how the design teams develop
    projects? I'm just trying to determine what's it like in a private
    company, are there a set of rules one must follow? I'm always trying
    to think of practices that can help me manage complex tasks and hope to
    hear from others how they do it.

  2. John  Larkin

    John Larkin Guest

    Yes, sheet 1 of each schematic (fpga's are schematics, too!) but it's
    usually created last, just before the drawing is archived.
    What's that?
    Yes, yes, yes. On the schematics and source code, not to the side.
    Meaningless, or maybe dangerous.
    Definitely dangerous.
    Sure, but it's mostly casual, walkaround stuff, not scheduled
    Or break it, whichever works best.
    Oh, please.
    I think a good design process consists of hundreds of good habits, not
    just a short list of rules. It evolves over years and is hard to write

  3. Luhan

    Luhan Guest

    I don't get much out of your list, here is mine...

    1. Make sure your client knows what he's getting into - time, money,
    problems, etc.
    2. Dont use any parts that the sales reps say are replacing the current
    3. Document only as much as you need for yourself, offer extensive
    documentationt to the client after the project is done. Let them pay
    for as much as they want.
    4. Check out the convetional solutions, use only as they apply.
    5. Dont take on any project unless you have it mostly designed already.

    All projects consist of parts, these parts fall into the following

    I. Stuff that you have done before.
    II. Stuff that you have not done but others have.
    III. Stuff that nobody has done before.
    IV. Stuff that is commonly regarded as not possible.
    V. Stuff that violates laws of physics.

    Do the project starting with the worst rated parts, that way you can
    fail early and save your client time and money!

    Luhan ;)
  4. Jim Thompson

    Jim Thompson Guest

    I like that one ;-)


    ...Jim Thompson
  5. John  Larkin

    John Larkin Guest

    6. Write the manual first.

  6. I always start by imagining the final bill of materials, then put item by
    item into a spreadsheet, then add detail as each component is visualized,
    designed and detailed including make/buy decisions, manufacturing processes
    and estimated costs. When the final design is sent to the shop/vendors the
    documentation is a done deal. Communication to all team-members is easy as
    expanding the spreadsheet to a Gantt chart for weekly reviews or the like.

  7. Luhan

    Luhan Guest

    Hey, thats a good one. I wrestled back and forth with one client for
    weeks as they gave me vague and conflicting functions for the product.
    Maybe, let *them* write the manual first!

  8. I've usually (almost always) found that a top-down design ends up being

    It will have all kinds of pretty layers and boxes and lines and

    But quite often:

    (1) You don't know ahead of time how many layers are adequate.
    (2) You end up with a design that's "logically" correct, but may be
    several powers of ten too slow.
    (3) You have to break up the design anyway in order to delegate
    ther parts to people that can implement them.
    (4) The final design doesnt mesh at all well with the available IC's
    or modules.
    (5) the cost of the interfaces, wires, cables, connectors will exceed
    the cost
    of everything else.

    Your mileage may vary.
  9. Nico Coesel

    Nico Coesel Guest

    I'm missing an important one:
    Test whether each module you make works as expected with any input
    combination. Design modules to deal with faulty input properly
  10. Luhan

    Luhan Guest

    Conceptualize top down.
    Develop bottom up.

    Its like a skyscraper, you gotta build it from the bottom.

  11. Jim Thompson wrote...
    If it exists, then follow the exits, yes.
  12. EE123

    EE123 Guest

    I'll include the first couple of lines from
    "Calender for a RUSH JOB!"

    Day: Gen Fri Fri Thu Wed Tue Mon
    8 7 6 5 4 3 2
    16 15 14 13 12 11 9

    1) Everybody wants his order delivered yesterday. With this
    calender, you
    can order on the 7th and have delivery on the 3rd.
    2) All customers want their orders on Friday, so there are 2
    every week.
    3) There are no unproductive Saturdays, Sundays or holidays.


  13. If it is for academic research, allow an order of magnitude tolerance on
    every specified parameter (if any).
  14. This same question, in the last couple of years has turned up twice.
    It reeks of residence within some management diploma course module.
    Specifically, that module that that dreams it can teach up and coming,
    thrusting, young pointy haired managers, how to enforce structure and
    organisation onto those bolshie, engineering slob types.
  15. John Larkin

    John Larkin Guest

    An 8-item list of how to do engineering would be like an 8-item list
    that tells you how to replace a kidney or how to land a 747.

    Besides, good engineering usually involves breaking rules.

  16. Luhan

    Luhan Guest

    Hey, don't hold back, tell us what you *really* think!

  17. Is that a rule?
  18. John Larkin

    John Larkin Guest

    The only rules you can count on are conservation of energy and
    conservation of charge, and I'm not sure about that last one.

  19. Aside from my grumpiness, I really think all good engineering boils down to
    one single point of note ... it's the old Scottish adage, "Look after the
    pennies and the pounds will look after themselves" :)
  20. If you look at almost any innovation you will see the new idea or method
    came from outside the normal established procedures. Look at the transistor.
    It took years for vacuum tube engineers to realize the true potential of the
    transistor. Sony is the one to recognize it and licensed it and look what

    The best example ever of this paradigm paralysis is to be found in Geneva,
    Switzerland in the late 60's when the research team presented the idea of
    quartz to the factory owners and big wigs in the time-keeping industry.
    These managers/owners were so in love with their gears and jewel bearings
    that they did not even patent the idea their own researchers had come up
    with. Texas Instruments and Casio saw the idea at a technical conference and
    the rest is history.

    So yes... a lot of great engineering comes from braking the rules.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day