But still, something seems a little off. That nifty micro hits its published performance specs, but unexpected little things pop up. Maybe the (almost) free tools from the vendor don’t seem quite right, or the chip has some spurious behavior that you can’t find documented anywhere other than on a developer’s blog where some other hapless soul is begging into the void for help. Or, the part just stops working until it’s reprogrammed. Here it comes again, that sinking feeling as those minor nuisances start piling up and milestones start slipping.

Before long, what was a well-oiled process starts to fall apart. After initial periods of disbelief, hardware and firmware people get together and start working the problem, but soon realize that some of these problems completely invalidate key architectural elements in your design. Worse, you’re getting the sneaking suspicion that it’s time to update your resume as your manager begins to wonder why you can’t just make it work like the vendor’s marketing team promised it would.

But it doesn’t end there. Because of long lead-times, now commonly six months or more, and to get guaranteed volume discounts, your company had to order parts months before you had a chance to find these problems. Switch parts now, and your company faces a lawsuit for breach of contract. Guess how well that’s going to play with upper management.

The only way out of this mess is to not get into it in the first place. How do you do that? By paying attention to those little tingles that kept your caveman ancestors alive. Here are a few examples that trigger these tingles:

1. Does the vendor seem more like a marketing company than a silicon manufacturer? Often, vendors will grow their product line by acquisition rather than by organic development. This is often a warning sign that their core competency lies in areas other than the engineering.

2. Do the vendor’s apps engineers look like they’re working on their senior projects? What are their backgrounds and experience? Do they understand the difference between nifty and solid? Have they ever been on a real development team?

3. Do vendor demos simply show that a feature works (which should be a given), or do they show production awareness (such as thread safety) on the part of the author? Is the demo a “straight-through” with nothing else going on? This is often a warning sign that the demo has been tuned to avoid known, but undisclosed, issues.

4. Does the vendor make claims about power consumption or other features that seem too good to be true? These claims can bite you in other, less obvious ways. For example, skimping on gate charge reduces dynamic power consumption, but does the part become more susceptible to EMI? Physics requires energy to do real things, including holding memory state.

5. Do the silicon version numbers seem strangely high? This is a warning sign that silicon configuration management is out of control. Frequent version changes also cause problems down the road during production. What if they fix a silicon bug that your firmware has already coded around? It’s far better to pick a vendor who simply documents what the silicon is and recommends how to handle this reality, rather than chasing changes and causing configuration management ripples in your product.

Please share your experiences and your favorite warning signs that keep your projects from falling into marketing pitfalls. And ask your manager to read this article the next time you’re trying to make a case against a part which looks too good to be true.

Tom Baugh is a product development consultant with SoftBaugh Inc. [email protected]