I’m sure you've never seen or heard an argument in the lab. OK, let’s be politically correct and call it a ‘heated debate’. Maybe you’ve heard about one or two of these or even taken part in a few.
Often these debates occur at a certain crisis point in development or after the delivery of first prototypes of a board design. All too often these ‘friendly discussions’ take place between a hardware designer and firmware developer during board bring-up. The typical scenario goes like this: the hardware engineer has completed board check-out and believes the design is rock solid and ready for firmware integration. So he flashes the firmware into the board’s flash memory, but, unfortunately, after power-up it doesn’t completely boot. After hours of probing the prototype and a lot of head-scratching, the hardware engineer calls the firmware developer and tries to engage in a civil conversation about what might be wrong. As a result of the stress of not having a functional board yet and a recent visit from the boss, the first comments in this conversation might go something like this: “Your software is crap.” Immediately, the software engineer dismisses this comment with his own set of pleasantries, stating that if the hardware design had been any good, the code would have worked fine the first time. It worked perfectly on the simulator.
Often, after this initial heated exchange, the hardware and software developers get down to brass tacks. The hardware engineer looks at the schematics and fires up his oscilloscope and logic analyzer. The software engineer starts up the debugger, assuming it will work on the hardware. If it doesn’t, no problem, he’ll use a hardware simulator and start poring over the code. A little more quibbling ensues and eventually the software engineer lobs another verbal salvo at the hardware engineer to the effect that the prototype works just fine on the simulator. “See,” he says. “I told you it was your design.”
Have you ever wondered why two engineers dealing with the same problem — a prototype board that’s not booting — will employ totally different sets of tools and each adopt seriously divergent viewpoints? Sure, they come from different engineering disciplines but it is certainly a shame they can’t effectively collaborate on solving the problem. Rarely have I seen a software engineer reach for the probe on an oscilloscope and start probing a target board. Maybe it’s because if he did, the hardware engineer probably would freak and smack him a time or two. Perhaps your lab is different and the engineers actually swap tools. The software engineer might look at the trigger point setup on the logic analyzer while the hardware engineer jumps on the debugger to check the register base addition of a variable. Somehow, I doubt it.
If you think there’s got to be a better way — especially during board bring-up — check out a product that provides the hardware engineer a similar view and the functional control that even a software engineer can appreciate. Click on http://www.asset-intertech.com/registrations/piRegVideo-PCT.cfm?lnk=PCT_Overview_HD
