Jack Ganssle is the president of Softaid, a vendor of emulators and other embedded-systems tools. You can contact him via CompuServe: 76366,3333 or Internet: jack@softaid.com.
Or send mail to Softaid, 8310 Guilford Rd, Columbia, MD 21046.
Columnist: March 2, 1995
In a two-billion-dollar gamble, Ford's engineers designed the Taurus in record time. (Who says big companies are risk-averse?) The new car was revolutionary in many ways, but perhaps the most profound change was a new way to engineer cars. The Taurus project was one of the first major concurrent-engineering designs; that is, everyone having anything to do with the car was involved from the beginning of the design process. From day one, engineering, production, sales, and distribution all worked hand-in-hand to get a quality car to market as quickly as possible.
Now it's fairly common to flip through the pages of a design magazine and see at least a handful of references to concurrent engineering. The old model, where each department worked in isolation before hurling the project to the next group, is quietly fading away. It's impossible to forget the problems that production or sales face when representatives of these groups are staring over the designer's shoulders.
For example, now most every car generates a serial diagnostic stream from the system's master computer. Cars are simply too complex for the average mechanic (let alone most of us part-timers); these error codes use a very slow bit stream specifically tailored to the crummy equipment you'd expect to find in a repair shop. Hook up that slow VOM to ground and the test point and the computer deflect the meter five times for code 5, followed by a pause, then three times for a 3. Look up the codes in your service manual and voila! You'll know what to replace.
Though the big car companies now seem to be masters of engineering, far too many smaller operations still operate in the Dark Ages. It seems the wall between hardware and software development grows each year: Software engineering becomes ever more specialized, and hardware continues to evolve at its customary dizzying pace.
It's scary how many software groups receive a piece of "functional" prototype hardware from designers delivered with schematics-but nothing else. These schematics are usually incomprehensible to the software folks and are made even more obtuse by frequent use of PLDs and similar functional blocks (with perhaps hundreds of connections) plopped down on the page. These blocks are documentation black holes: every signal goes in, and presumably something comes out. But, without the designer's suite of design tools, even the brightest firmware person rarely makes sense of the design.
Where the hardware group's responsibilities end and firmware's begin makes for an interesting philosophical debate. Should the designers include device drivers? How do they know the logic works without writing some sort of code to check out each peripheral? Why not structure the development plan to make this test code part of the framework of the final software? I feel hardware tends to be so complex now that it's unfair to give "naked iron" to the software people. At the very least, deliver low-level drivers with a well-defined interface.
Talk to your software counterparts. You may be surprised to learn that all too often your cool new product makes debugging the code practically impossible. Poor design decisions may seriously impact the firmware schedule.
Smaller, faster, cheaper. Chant these words repeatedly, eyes closed, legs lotussed, spirit uplifted. It's the silicon mantra, and it drives electronics to phenomenal success-while turning industry practitioners' hair prematurely gray.
How are you going to connect debugging tools to that tiny new PCMCIA card you're working on? Don't just assume that the software crowd will "come up with something." Because if it doesn't, your clever design could bankrupt the company.
About a year ago, I visited a company in Canada that was facing exactly this problem. The card's CPU had whisker-thin TQFP leads no tool could grab. Because it wasn't a mainstream part, there were no software debuggers available, and, if there were, the ROM/RAM configuration was too tight to allow the extra code a software monitor needs. Their clever solution was to design the card with a rather large extra connector, a simple 100-pin header, with all CPU lines connected. Though the connector doubled the size of the board, it sat alone, the only component outside of the PCMCIA's form factor. Any tool could plug into it, yielding a complete development environment. When it came time to ship the product, designers used a bandsaw to cut the connector and the board down to size. Of course, without the connector, production versions were properly sized cards.
Have you ever worked on military equipment? The boards are usually crammed tightly together and are often conformal-coated. Far too often, an extender card won't work because the CPU becomes unstable driving the extra-long lines. I wonder how much these accessibility issues drive up the defense budget.
Card cages, military or not, are often a source of trouble. Debugging the hardware is difficult enough: try slipping a scope probe in between boards. It's not unusual to see a card with a dozen wires hastily soldered on, snaked out to where the scope or logic analyzer connect.
This situation is totally unacceptable. Why make life difficult? Either design a robust processor board that works properly on an extender or come up with a mechanical strategy that lets you put the CPU near the end of the cage (with the cage's metal covers removed), so you and the software people can gain the access so essential to high-productivity debugging.
One company I know of can only remove the "wrong" (that is, the circuit) side of the card-cage cover. The solution is to solder the processor socket on the circuit side of the board and then make a pin-swapping jig (using parts from Emulation Technology or EDI), to which the company's smart logic analyzer connects. Using a ROM emulator in a similarly tight situation? Consider the same trick of inverting one or more ROM sockets.
Back in the good old days, microprocessors were available in only a few package types, such as DIPs, PGAs, or PLCCs. These parts were designed for through-hole pc boards with the expectation that, at least for prototyping, designers would socket the processor. Isolating or removing the part for software development required nothing more than the industry-standard chip puller (a bent paper clip or small screwdriver).
There's no cheap cure for the purely mechanical problem of connecting a tool to those whisker-thin pins, but at least the industry's connector folks (Emulation Technology, EDI, Pomona) sell clips that snap right over the soldered-on processor. The clip translates those SMT leads to a pc board with a PGA or header array your tools can plug into.
Getting to the CPU's core is another problem. The Z80 processor, for instance, comes in many flavors. The 84C013 and 84C015 variants are nothing more than a Z80 core with integrated peripherals, all enclosed in a QFP. The Z180 derivative lives on as the core of the highly integrated Z182, also in a QFP configuration.
Zilog dedicated one or two pins (depending on the chip) to selecting "evaluation" modes. Your system drives these inputs to the default state, which lets the CPU fulfill its karma by operating like a normal processor. An emulator, though, can put the part into one of two evaluation modes.
Mode 2 completely tristates the part. It becomes little more than an anchor to connect the adapter and tool. The emulator must replace both the CPU core and the high integration peripherals. Mode 1 tristates only the core and reverses the directions of certain signals. The clipped-on emulator contains just a core replacement (a Z80 or Z180). The peripherals in the processor on your board respond to commands as if no tool were in use. A number of IC vendors use this approach on near-custom processor families (most of which are based on a standard processor core), because it lets the customer use a standard set of widely available development tools.
What does all this mean to the hardware designer? If you connect these evaluation-mode pins directly to ground or VCC to select the default "normal" mode, no tool will ever be able to overdrive these inputs. The evaluation mode will be inaccessible. Have pity on the software folks and use individual pullups and pulldowns instead.
The new 386EX has a similar requirement. One pin, FLT ("float"), tristates the entire device if asserted low. Again, be a sport and tie FLT to VCC through a 1k resistor.
Intel's and AMD's 188/186 processors let you tristate the entire device by overdriving one or more output pins to ground during reset. Good news: Because these are CPU outputs, your circuit cannot drive the pins. You need no provision for debugging-with one exception. If you'd like to be able to have an emulator reset the device under software control, be sure that it can overdrive RESET. Use an open-drain reset circuit, with appropriate pullup.
Embedded-hardware engineers can accidentally or maliciously design a system that will make software development an order of magnitude harder than it should be. Smart software gurus will bring donuts and coffee to their hardware partners' desks and listen attentively to extensive stories of the latest PLD battle. We can all learn from Ford's success with the Taurus by communicating frequently with our software counterparts.