Best Practices for Hardware Engineers

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 meetings.

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 down.

John

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 ones.
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 catagories:

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 ;)

[snip]

I like that one ;-)

[snip]

...Jim Thompson

-- | James E.Thompson, P.E. | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona Voice:(480)460-2350 | | | E-mail Address at Website Fax:(480)460-2142 | Brass Rat | |

| 1962 | I love to cook with wine. Sometimes I even put it in the food.

1. Write the manual first.

John

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.

Wayne

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!

Luhan

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

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

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.

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

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Conceptualize top down. Develop bottom up.

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

Luhan

If it exists, then follow the exits, yes.

--
 Thanks,
    - Win

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

Notes: 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 Fridays every week. 3) There are no unproductive Saturdays, Sundays or holidays.

etc

Dave

If it is for academic research, allow an order of magnitude tolerance on every specified parameter (if any).

--
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

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. john

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.

John

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

Luhan

Is that a rule?

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

John

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" :) john

message

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 happened.

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.