Copyright 1996, Jack G. Ganssle

Abstract

Prototyping is a critical skill - in hardware and software. This is part 2 of a two part series on the skill.

Published in Embedded Systems Programming, October 1996

Last month I talked about developing quick prototypes of software systems. Embedded systems are a unique nexus in computers where the hardware and the software are one. We can never stray far from the electronics that form the physical part of our products.

In many ways hardware is harder to prototype because you actually have to build something. It seems there are always a thousand reasons why something cannot be built in a reasonable time-frame: parts are unavailable (or, we forgot to order them), the PC boards were rejected by incoming inspection, the technicians can't seem to get the board modifications right, we forgot how to burn PALs, etc.

Planning

Engineers have managers, who "run" projects, insuring that resources are available when needed, negotiate deadlines and priorities with higher-ups, and guide/mentor the developers towards producing a decent product on-time. Planning is one of any manager's main goals. Too often, though, managers do planning that more properly belongs to the engineers. You know more about what your project needs than your boss ever will; it's silly, and unfair, to expect him to deal with all of the details.

There are lots of great justifications for a project to run late. In engineering it's usually impossible to predict all of the technical problems you'll encounter! However, lousy planning is simply an unacceptable, though all too common, reason.

I think engineers spend too much time doing, and not enough time thinking about doing. Try spending two hours every Monday morning planning the next week and the next month. What projects will you be working on? What's their status? What is the most important thing you need to do to get the projects done? Focus on the desired goal, and figure out what you need to do to get there. Do you need to order parts? Tools? Does some of your test equipment need repair or calibration?

Find the critical paths and do what's required to clear the road ahead. Few engineers do this effectively; learn how, and you'll be in much higher demand.

When developing a rush project (all projects are rush projects….) the first design step is a block diagram of the each board. From this you'll create the schematic; then do a PCB layout; create a bill of materials, and finally, order parts for the prototype.

Not. The worst thing you can do is have a very expensive quick-turn PCB arrive, with all of the components still on back order. The technicians will snicker about your "hurry up and wait" approach, and management will be less than thrilled to spend heavily for fast-turn boards that idle away the weeks on a shelf.

Buy the parts first, before your design is complete. Surely you'll know what all of the esoteric parts are - the CPU, odd analog components, sensors, and the like. These are likely to be the hardest and slowest to get, so put them on order immediately.

The nickel and dime components, like gates and PALs, resistors and capacitors, are hard to pin down till the schematic is complete. These should mostly be in your engineering spares closet. Again, part of planning is making sure your lab has the basic stuff needed for doing the job, from soldering irons to engineering spares. Make sure you have a good selection of the sort of components you company regularly uses, and avoid the temptation to use new parts unless there's a good reason.

PCB Issues

Time Magazine, Business Week, Fortune, and our upper management should all form a choir to sing the great hit of the 90's "The Time To Market Blues":

My market share is fallin' And the bank's come a callin'.

If we don't ship it promptly We're gonna be his-to-ry.

Chorus: We're gonna be his-to-ry

So design that schematic; Crank some code while you're at it.

But ship by tomorrow morn!

Chorus: But ship by tomorrow morn!

Ahem. Though we hear them singing, sometimes we continue to do things in the same old tired ways. One of these is the traditional wire- wrap breadboard.

In the bad old days we created wire wrapped prototypes because they were faster to make than a PCB, and a lot cheaper. This is no longer the case. Except for the very smallest boards, the cost of labor is so high that it's hard to get a wire wrapped prototype made for less than $500 to several thousand dollars. Turnaround time is easily a week.

Cheap autorouting software means any engineer can design a PCB in a matter of a couple of days - and, you'll have to do this eventually anyway, so it's not wasted time. Dozens of outfits will convert your design to a couple of PCBs in under a week for a very reasonable price. How much? We generally pay $1000-$1500 for a 50 square inch 4 to 6 layer board, with one week turnaround.

It's magic. Modem your board design to the vendor, and days later Fedex delivers your custom design, ready for assembly and test.

PCBs are much quieter, electrically, than their wire wrapped brethren. With fast rise times and high clock rates noise is a significant problem even in small embedded designs. I've seen far too many cases of "well, it doesn't work reliably but that's probably due to the wire wrap. It'll probably get better when we go to PC." These are clearly cases where the prototype does not accomplish it's prime objective: identify and fix all risk factors.

The best source for information about speed and noise issues on PC boards is "High Speed Digital Design (a Handbook of Black Magic)" by Howard Johnson and Martin Graham (1993 PTR Prentice Hall, NJ).

Design your prototype PCB with room for mistakes. Designing a pure surface mount board? These usually use tiny vias (the holes between layers) to increase the density. Think about what happens during the prototyping phase: you'll make design changes, inevitably implemented by a maze of wires. It's impossible to run insulated wire through the tiny holes! Be sure to position a number of unusually large vias (say, .031") around the board that can act as wiring channels between the component and circuit sides of the board.

Add pads for extra chips; there's a good chance you'll have to squeeze another PAL in somewhere. My latest design was so bad I had to glue on five extra chips. Guess who felt like an idiot for a few days…

Always build at least two copies of each prototype PCB. One may lag the other in engineering modifications, but you'll have options if (when) the first board smokes. Anyone who has been at this for a while has blown up a board or two.

I generally buy three blank prototype PCBs, assemble two, and use the third to see where tracks run.Though sometimes you'll have to go back to the artwork to find inner tracks, it sure is handy to have the spare blank board on the bench during debug.

Design For Debug

Though it might be interesting to get into a philosophical debate about the nature of man, suffice to say we're all less than perfect, as manifested in our less than perfect designs. Whether we're writing code or designing a board, perfection is an elusive (impossible?) goal.

Knowing this, why do we design systems that are so hard to work on? Face it: you're going to spend a lot of time troubleshooting your creations. Design the system from the outset for ease of access and to simplify debugging.

Not many designs include a ground point, yet there's no question that we'll spend a lot of late nights wielding a scope probe. With high density SMT it's almost impossible to get a decent ground by soldering a resistor lead to the corner of a chip. Include a convenient ground point. On a big board scatter several around, as you'll want to keep the ground lead short.

Include other test points as appropriate. Make sure critical signals you always use for triggering test equipment are easily accessible. We've started adding a special connector, that is not loaded on production versions, for the logic analyzer. It's designed so the analyzer we're standardized on here plugs directly into the socket, giving us immediate and complete access to the most important nodes.

If you plan to use an emulator, is the CPU socket covered by another board? Ditto for the ROM sockets when a ROM emulator is the debugger of choice.

Many of Motorola's CPUs have a "BDM" port, a simple debugging interface that's built right into the chip. Connect this to a small 10 pin connector and you've got a cheap and effective software debugging tool. No matter what sort of debugger you plan to use, include this connector. If you don't load it on production PCBs the costs will be vanishingly small, yet the debugger will always be there, ready for action if needed.

The 186 family (from AMD and Intel) has a feature that allows you to tri-state surface mounted CPUs, easing the pain of connecting an emulator. The emulator will drive RESET to tri-state the CPU… as will your logic. Design your logic so both sources can effectively drive RESET, otherwise your debugging options will be severely limited.

If your budget is tool-poor by all means add a simple debug port - an 8 bit I/O port with LEDs or a scope connection - that the code exercises as it runs. You'll get at least some indication of what is going on. Without insight into the system's operation debugging is all but impossible.

Making Changes

After spending a couple of months writing code it's a bit of a shock to come back to the hardware world. Fixing bugs is a real pain! Instead of a quick edit/compile you've got to break out a soldering iron, wire, parts, and then manipulate a pin that might be barely visible.

PALs, FPGAs, and PLDs all, to some extent, ease this process. Many changes are not much more difficult than editing and recompiling a file. It is important to have the right tools available: your frustration level will skyrocket if the PAL burner is not right at the bench.

FPGAs that are programmed at boot time via a ROM download usually have a debugging mechanism - a serial connection from the device to your PC, so you can develop the logic in a manner analogous to using a ROM emulator. Be sure to put the special connector on your design, and buy the little adapter and cable. Burning ROMs on each iteration is a terrible waste of time.

PLDs often come like EPROMs, in ceramic packages with quartz erasure windows. These are great… if you were clever enough to either socket the parts, or to have left room around the part for a socket.

On through-hole designs I generally have the technicians load sockets for every part on the prototype. I want to replace suspected failed devices quickly, without spending a lot of time agonizing over "is it really dead?"

Sockets also greatly ease making circuit modification. With an 8 layer board it's awfully hard to know where to cut a track that snakes between layers and under components. Instead, remove the pin from the socket and wire directly to it.

You can't lift pins on programmable parts, as the device programmer needs all of them inserted when reburning the equations. Instead, stack sockets. Insert a spare socket between the part and the socket soldered on the board. Bend the pins up on this one. All too often the metal on the upper socket will, despite the bent-out pin, still short to the socket on the bottom. Squish the metal in the bottom socket down into the plastic to eliminate this hard-to-find problem.

Conclusion

With a bit of careful planning, an admission of our lack of perfection, and a clever approach to debugging, prototyping hardware will still be hard! Practice and invention will make each project easier than the last. Be creative.