June 19, 1997

Read the fine print or suffer the consequences

Read the data sheet--each and every page, each and every table, each and every note and testing condition.

You've spent weeks or months on your design--verifying the desired functions and timing, writing and optimizing the software, and carefully laying out the system board. Now for the defining moment: You turn on system power, hit the reset button, and stare at the monitor with your fingers crossed and hope in your heart.

The bad news: You see nothing or--just as bad--a display full of garbage. Or, your de-sign works, but performance is much slower than expected. Or, one system works, but the next five don't. Or, systems start coming off the manufacturing line DOA six months after you move the design to production. What went wrong?

Your problem could be a bad chip or faulty interconnection; misbehaving software; or noisy supply voltages, ground, or signals. But, before you fire up the soldering iron, emulator, oscilloscope, and logic analyzer (or chuck everything out the window), I suggest you step back, take a deep breath, and reread the device data sheets. Odds are that in the rush to complete your design, you overlooked something or forgot to read the errata (which you might not even know existed) or additional documentation to get the big picture.

When chip manufacturers set out to document their latest and greatest devices, they assume a specific operating environment. Boundary conditions often reflect the characteristics of their expensive chip testers, whose rock-solid power supplies and noise-free signals don't come close to matching a less "silicon-friendly" real-life system (see "Demystifying ADCs," EDN, March 27, 1997, pg 26). Also, a vendor's marketing group sometimes takes an overenthusiastic role in influencing the data sheet, highlighting perceived strengths while relegating both qualifiers and shortcomings almost to the point of invisibility.

In other words, read the data sheet--each and every page, each and every table, each and every note and testing condition. Get the errata. Make sure you get the latest documentation versions. Keep asking about documentation updates as your design goes through prototyping, initial production, and then full production (and don't rely on your sales rep; check the vendor's Web site to be sure). Look at the revision history for any "enhancements" that could cause you sleepless nights. An ounce of prevention is worth a pound of cure.

Next time, I'll share some examples of "data-sheet distortion."

| EDN Access | Feedback | Table of Contents |