If you could tell us what your current expertise is, you may get better advice on what you can do from here. My own collage experience (University of Illinois, Urbanna), is that little of any practical experience is gained taking Electrical Engineering. My expertise is
---------------- I like to view electronics an art. Not knowing where to begin is a special time in a project.. It's kinda like jumping in bed with a new girlfriend. Would you like it if somebody was coaching you while you in bed with a girlfriend.. Probably not..Go for you our style and explore... Make a choice... :) Or course...knowing what others have done can save a lot of time.
Electronics, like just about anything else, can be a job, a skill, or an art - depending on the person doing it. I most enjoy designing things with 'hardly any parts' that look like 'they shouldn't work'.
There is an enormous body of technique and lore that is widely accepted in industry but virtually unknown in academia. And difficult to pick up on your own. If you can, get a junior-level job in a small or medium-sized company as an engineering aide or whatever, try to be as helpful as you can, and learn from the experienced guys. If they aren't helpful, or it looks like they're not doing good stuff, go somewhere else.
For example, I've never heard of a college course mentioning, much less teaching, documentation standards and control; well, maybe one course taught by a former co-worker who spent time in the real world.
Here's a typical very simple design flow and note that each and every stage requires thorough documentation:
Get requirements from customer / marketing.
This is more difficult than it sounds; you can't just say 'I want to sample some signal and then control something else based on it' - there has to be a specific link. That a *very* simplistic example, incidentally. There's a lot more - power requirements, battery operation?, chargers, size, weight - there's a thousand and one things (per the old saying) that have to be thoroughly _defined_.
Choose the architecture to meet the requirements. This is 90% experience at least. A simple design can be easily found (at least architecturally) on the web, but as things get more complex (and customised) the chances of finding what you need already done lessen (as they should - if it's already been done why are you doing it unless to make something cheaper / better?)
Choose the parts to implement the architecture. Again, more difficult than it sounds. Make sure the parts are actually available and not vapour-ware, and are reasonably affordable.
Start schematic capture. Notice how far along we are before this even starts? Of course, you'll need to make the parts and symbols yourself (lots of threads on this both here and on sci.electronics.cad) so be prepared to do a lot of paperwork and checking.
Have the parts and symbols checked thoroughly by someone other than yourself if possible (this is a matter of not always being able to see your own errors).
If you are doing anything with constraints (anything non-trivial in other words) then make sure you enter the constraints at the schematic level if possible - I well remember setting the constraints for a single sub-system (DDR at 200/400) where setting the constraints took longer than the schematic capture phase - and that was but a small part of that board. Once more, document thoroughly what those constraints are and why they are set that way.
Run the various error and warning checks on the schematic; once you have zero errors and zero warnings (well, there are some warnings that are ok, rather like the output of lint), run the netlist.
Choose a PCB stack - this is, to a great extent, experience. How many layers, what each layer is (signal, ground, power etc) and make this before even considering importing the netlist. Also, define the board outline and any breakaways (necessary in manufacture) that may be needed.
Export the netlist and then import it into the layout tool. You'll need to make sure you have all the device symbols and padstacks set up prior to this. At this time, you should also generate the PCA BOM - note that this is not the final BOM! Again, lots of documentation.
Now, and only now, do we get to layout. This is a subject in it's own right, but here's a typical simple flow:
Place the components as required by the various schematic set rules (see above) and anything else that may be relevant (power distribution, signal distances, decoupling devices - again, there's huge numbers of variables)
Hand route the power - this can be *very* difficult depending on how many power domains exist. The highest number I've personally done on one board was 27 separate power domains (because I was switching the power to many devices) and set up the power and ground planes (but we'll have to return to them)
Hand route any critical signals - autorouters, in general, suck for critical signals, and it's best (usually, imo, ymmv) to route the critical stuff and mark it as fixed and then let the autorouter do it's thing.
Now go back and iterate steps 9 to 11 until it's all done and meets the rules.
If any pin-swapping was done, go and back-annotate the schematic.
Set up the documentation layers and so forth on the layout.
Generate gerbers and assembly prints - this is usually known as a fab-pack.
Generate the final BOM (including housings, clips, plug-in modules, whatever) and remember to check the PCA BOM - if you are lucky, you can ship it off to be made :)
Note I left out some pretty common steps because they aren't always done, but every single step has to be documented, and there must always be a master document - in my case, that's the spec - from which the design had to flow. This is the absolute minimum.
In addition, I did not introduce the _very_ common issue of an updated netlist in the middle of layout (may my PCB guys forgive me ;) ).
Practical design requires a lot of documentation as well as design skills ;)
As I and others (especially John) noted, there's a lot to it that is usually never encountered in college.
PeteS provided an excellent flow guide to this process. PCB design is partly Art and partly Science. I use PADS-Logic and PADS-PCB (with their Blaze autorouter), and it is very good, although the parent company Mentor Graphics has an unreasonable annual maintenance/support scheme (scam?) that would have me advise anyone not to purchase their package. Cadence is probably now a better option for high end packages of this type ($5000 to $20,000+).
For your own use and education, you can download from
their complete latest version which is fully usable for very small designs, and it is a good place to start. They have some good tutorials and sample designs. Another very valuable resource for users of this product is a very helpful and friendly forum you can read and join to post questions:
Board design breaks down into electrical design and mechanical design (PCB layout). My experience is from the electrical side of things. The electrical designer is responsible for the electrical schematic, the net list, the BOM and the acceptance test procedure. He has project responsibility, in other words if the board fails to work, it's the electrical designer's fault. Since this is so, it behooves the electrical designer to establish a tight working relationship with the mechanical designer and to understand as much as possible about the mechanical design process. Electrical design starts with the specification writing. As designer you are faced with the "don't know squared" problem, the customer does not know that he doesn't know what he wants. Typically the designer writes the specification and then coordinates it with the customer. The spec needs to be a "requirements" spec, that spells out what the board is supposed to do, how fast it has to run, all the inputs and outputs, the operating environment, the size, weight and power consumption, the case work, the temperature and air pressure range, and anything else that the customer or the designer cares about. Limitations (can't work with USB 2.0, reprogramming requires desoldering parts, no support for rotary dialing, what ever) should be spelled out and agreed to by the customer. The spec MUST be written in language meaningful to the customer, otherwise the customer's eyes glaze over and eventually he signs off on something he doesn't really understand just to get the project moving. This can lead to disaster later in the project when the customer is shown the first working breadboard and says "Oh I didn't mean for it to work that way." The spec has a strong effect on the cost of the product. Each feature called out in the spec raises the cost of the board. As designer and manufacturer you want to get the cost down. On the other hand if the board lacks the features customer's truly need then it won't sell either. Specs should put numbers on as many things as possible. For instance say the product runs on 120VAC +/- 30 volts 50-60 Hz rather than "runs on line voltage". Always spec size and weight because cost is dependant upon size and weight. Spend a lot of time to get the spec right. The wrong spec will kill the project before its finished. Get senior management, both yours and the customer's, to sign off on the spec. Get real signatures, in ink, on paper. Keep the signed copy yourself if possible, otherwise keep a Xerox. Make sure the spec has a date and a revision number on every page. Change both the date and revision each time a change, no matter how small, is made in the spec. Be sure no one can change the spec without your knowledge. Remember, at the end of the job, you won't get paid if the product fails to meet spec. While the spec negotiations are ongoing, consider the microprocessor. Nowadays most boards contain one or more microprocessors. Any digital logic running at less than a few kilohertz can be done by the microprocessor in code which is economical to manufacture. A lot of your development cost will go into the programming of same. Get the software guy[s] on board early, make sure they attend the spec reviews and understand the product. Select a microprocessor that's easy to program AND that the software guy[s] like. Easy to program means a C compiler, a symbolic debugger, and a software testbed so the software guys have something to work on before the first board is built. Don't get stuck in assembly language programming. The Intel 80186 runs the same code as the PC's, which means the software guys can test their code on a PC long before a test board becomes available, which makes it my favorite choice. If the software guys want to use this micro or that micro go along with them. They are indicating the micro upon which they have a lot of experience , which means they can get the product up and running faster than if they have to learn a new processor. Figure out how you are going to test the product. If you are lucky you will have the volume to afford to build bed-of-nails test fixtures for Genrad board testers. More likely you don't have the volume to afford either the fixturing ($25K?) or the Genrad machine ($100K?). More cost effective is to have the on board micro processor run a built-in-self-test upon power up. For this to work the board needs to be able to stimulate its inputs and monitor its outputs. In some cases provision of feedback paths from output to input will serve both purposes. In this day of surface mount it is nigh on impossible to hand probe chips, you have to provide test points that allow observation of key signals with scope or logic analyser. Much of the electrical designer's time is spent testing and verifying the prototype, don't paint yourself into a corner for lack of test points. Parts selection comes next. You should be able to find large scale integration (LSI) chips to handle most general purpose tasks A/D, D/A, serial I/O of various sorts, audio and video compression, oscillators, voltage regulators, parity generator, filters and so on. Any digital tasks that lack LSI, and run too fast for the micro to handle are done in programmable chips, PALS or FPGA's. PALS are simpler, and the design tools are cheap to free. FPGA's are larger, more powerful, but the programming tools are pricey ($20k) and tricky. Both parts can be programmed "schematically" or "programmably". I prefer "programmably" because a short program listing is easier to read and debug from than a 50 page schematic. PAL and FPGA programming tools allow to user to specify test vectors and exercise the design in software before burning chips. I always write test vectors and run the chip simulator to see that the programmable chip design works in simulation. It's much easier to debug a simulation than to debug a live board with a scope. Side by side with programming the PAL's and FPGA's you start doing your schematic. There are a lot of schematic capture packages out there. If you have a choice, go with ORCAD. It's very dependable and fool proof. You can hit the R-for-Repeat key and get a data bus drawn with the signal labels (D0, D1,D2..Dwhatever) automatically assigned. Each press of "R-for-Repeat" draws another bus entrance. Saves a lot of work and avoids the common error of labeling two bus leads with the same label creating a short in the net list. ORCAD supports hierarchical design. Circuits used in many places (say rows in a memory array) can be drawn ONCE but used repeatedly. This feature saves a lot of errors (the number of errors is proportional to to the size of the schematic). It also permits changes to be done once, on one sheet and be implimented thru out the design. Schematics are easiest to read if they are all on ONE page. Offpage connections are an abomination. Use the biggest possible paper size to reduce the number of off page connections. ORCAD will, if asked, find errors such as two outputs connected together or a pin not connected to anything. Always ask, and then clean up all the errors. Then with a clean error free schematic that looks like it will work electrically, have ORCAD create a net list. Get an assistant and compare the net list with the schematic run by run, yellow out the runs on the schematic and on the net list as you go. You will probably find a few things on the net list the do not match the schematic. Fix the schematic and re run the net list until they match perfectly. Have ORCAD prepare the BOM. Check same and assemble the manufacturers data sheets for each and every part in the BOM. Many parts come in many different ppackage styles (DIP, PLCC, various types of surface mount). Decide which package style you are going to use and make sure the mechanical designer (PC layout guy) understands what your choices are. Get with the layout guy and make sure he understands about board size (outline) and the location and size of all the mounting holes, otherwise the board won't fit into the casework. Make sure nothing sticks up too high, otherwise the board won't fit into its slot. Hand check the pin out of every IC, make sure that pin 1 is where it ought to be. Intel chips usually put pin 1 on a corner. Most other makers put pin 1 in the center of an edge. If the layout mixes this up, the board won't work. Make sure the surface mount passives are of the proper size, otherwise they won't fit. Use at least four layers, two routing layers, power, and ground. Insure that every part has a reference designation silk screened on the board and that the ref des can be read AFTER the parts are soldered down. Without the silkscreen the board won't get stuffed right, and it is extremely tedious to trouble shoot it.