Ed's an EE, PE, and author in Poughkeepsie, NY. Contact him at ed.nisleyieee.org with "Dr Dobbs" in the subject to avoid spam filters.
Aglance at a hardware engineer's bookshelves used to provide valuable status information. If the serried databook ranks showed a date less than a year old, then he (rarely she) was still doing useful work. A three-year lag marked the jump into management hyperspace, with lingering technical knowledge of the current project. If the most recent databook dated back five years, then either a good engineer had undergone a spinal net strip and was now a fully committed manager or he was an old-tech info junkie.
Nowadays, you simply cannot tell what's going on because databooks have largely gone the way of the dodo and there's no cubicle room for bookshelves, anyway. The same information, digitized and tucked in PDF files on vendor web sites, leaves no traces for hallway sociologists.
Whether paper or PDF, databooks provide hardware engineers with a resource largely unavailable to software designers—specific information about how a device will perform under a variety of conditions. Datasheets applied without engineering judgment, however, lead to designs that work only in Datasheet Space: that ideal universe where things behave the way they should.
Let's investigate what a hardware datasheet has to say, what it doesn't say, and why software must play some serious catch-up before it can even think of leaving Datasheet Space.
By the Numbers
If you're not familiar with the datasheet genre, the LF411, a classic operational amplifier, will serve as a good introduction. Fetch the complete datasheet from http://www.national.com/ds/LF/LF411.pdf. Because datasheets don't include pronunciation hints, here's how I say it: "ell eff four eleven."
A good datasheet begins with a narrative description of the device and an explanation of why it's better than another device you might also be considering. The LF411 is an operational amplifier, an analog building block that amplifies the voltage difference between its two input terminals, with (for its day, perhaps two decades ago) low bias currents and decent bandwidth.
A good datasheet has a bulleted list of key specifications on the first page so that you can quickly decide if this device is the right one for the job. Those specs, however, may be "typical" numbers, not absolute limits, and have suckered generations of newbie engineers into producing some truly marginal designs. I'll have more to say on that subject a bit later.
The same silicon chip may appear in different packages, as shown in Figure 1, and the datasheet maps functions to pins. You can buy an LF411 in a familiar 8-pin DIP (dual-in-line) "caterpillar" package or a hermetically sealed Mil-spec metal can. Other op-amp chips come in 8-pin SOIC (small outline integrated circuit) packages, 5-pin SOT23 (small outline transistor) packages, or even smaller chip-scale packages that resemble pepper flakes.
You must pay attention to such details, as I know of one case where the same IC in the same package from two different manufacturers had two different pin assignments. One chip used wire bonding and sat face-up in the package, while the other used flip-chip bonding and faced down, resulting in mirror-imaged pins. Oops!
Transistor datasheets show the pinout looking at the bottom of the package and IC datasheets show the pinout looking at the top of the package. I think this dates back to the days when transistors replaced vacuum tubes: You hand-wired tube sockets from below the chassis so tube pinouts always showed the bottom view. When ICs took over digital logic, however, the circuits were debugged from the top of the board. Some datasheets have a 3D perspective drawing that eliminates any possible misunderstanding.
Next comes the Absolute Maximum Ratings section, which tells you how much applied voltage and power dissipation the chip can withstand, the maximum (and minimum!) operating temperatures, the chip's thermal behavior, and the time-and-temperature limits you must observe while soldering it to the board. You're generally cautioned that these are the maximum survivable values: While the device may not work correctly at the extremes, it won't be damaged.
The DC Electrical Characteristics detail the steady-state parameters you must either supply to or expect from the device. Voltages, currents, gains, temperature coefficients, and noise levels appear in this section. This is where you find out just how nonideal the chip will be in your circuit.
An ideal operational amplifier, for example, has infinite gain, zero input current, and unlimited output power. Real op amps have very definite restrictions that aren't the limiting factor for most circuits. Evaluating the specs with respect to your circuit will tell you whether that's true in your situation. Neglecting that evaluation is the mark of a newbie.
Some datasheets have three columns of numbers: the minimum, typical, and maximum values. Key parameters may be measured at three temperatures, producing nine different numbers for what's overtly the same thing. Your job is to figure out which numbers apply to your situation.
For example, the LF411 has an input bias current, the nonideal current flowing through the input pins, of 50 pA. That's the typical value at 25 degrees Celsius: The mean bias current of a large sample will be about 50 pA. There's no indication of the standard deviation or the range, though, so you use the typical value at your own risk.
If you're designing a sample-and-hold circuit (for which you wouldn't use an LF411, but work with me on this), the bias current creates an error voltage by charging the circuit's input sampling capacitor. The error depends linearly on bias current and inversely with capacitance. The sampling time depends linearly on the capacitance, so the capacitor will be as small as you can get away with, making the op amp's bias current an absolutely vital specification.
The LF411's maximum input bias current is 200 pA at 25 degrees C, a factor of 4 worse than the typical value, and jumps to 4 nA at 70 degrees C and 50 nA at 125 degrees C. Because the input bias current increases by a factor of 1000 from room temperature to the maximum allowed operating temperature, the holding error for your S&H circuit also increases by a factor of 1000. A typical voltage error of, say, 1 mV balloons to a maximum error of 1 V—enough to invalidate your design.
Perhaps you think your circuit runs at room temperature? The datasheet temperatures refer to the chip, not its surroundings, so you must extract the package's thermal resistance from the Absolute Maximum Ratings section, multiply it by the chip's expected power dissipation (which depends on the load you're driving), and add the result to the ambient temperature.
Get the picture? You must know how to put all the numbers in the datasheet together to figure out whether the device will work in your circuit. Actually, all the numbers may not be present, in which case you should become somewhat suspicious of the datasheet.
The AC Electrical Characteristics section specifies the chip's frequency limits, speeds, slew rates, and other values that define its response to changing signals. One key value for op amps, the gain-bandwidth product, relates the signal frequency and the overall gain: You can increase one only by decreasing the other.
Suppose you must amplify a microphone signal by a factor of 1000, from 1 mV to 1 V. The LF411's gain-bandwidth product is typically 4 MHz, which limits the maximum bandwidth to 4 kHz=4 MHz/1000. This device won't emit high-fidelity audio, particularly when you realize the minimum GBW is only 3 MHz.
Producing reasonably hi-fi audio requires a 20-kHz bandwidth (or much more if you have Golden Ears), which limits the maximum gain to 150=3 Mhz/20 kHz. You must build up more amplification by cascading several lower-gain stages.
The Typical Performance Characteristics section includes graphs that show how key parameters vary with voltage, temperature, load, time, and frequency. These are typical values, not minimums or maximums, but they give you a feel for the changes. For example, knowing that the Power Supply Rejection Ratio drops from 120 dB at 10 Hz to under 40 dB at 1 MHz tells you that you must have a very quiet supply when you're working with high-frequency signals. Conversely, knowing how much the output impedance increases at those frequencies tells you that the load-driving capacity isn't what you might think from that first-page bulleted list.
The Application Hints section is where the chip's designers tell us how to actually use the thing and what to watch out for when we do. Very often, a single sentence can reveal a potential oops that appears nowhere else in the datasheet.
Consider this: "Exceeding the negative common-mode limit on either input will force the output to a high state, potentially causing a reversal of phase to the output." When you dig back through the DC Characteristics and the graphs, you find this means that an input voltage within a few volts of the negative supply will jam the output high, even if the differential input voltage calls for a negative output voltage. Oops!
This section may also have sample schematics that give a broad-brush overview of its applications, while omitting vital components like transient suppressors and current limiters. You must apply general engineering knowledge to the examples, although I've seen them make their way directly into production, with sometimes dismal results.
The last page of the datasheet generally sports disclaimers about not using the device in life-support products and high-reliability applications. Most of us aren't affected by those restrictions, but the very-fine-print section about the lack of patent licenses should get your attention, particularly in this day and age.
Now that you've seen the National Semiconductor LF411 datasheet, you'll understand why the Texas Instruments version at http://focus.ti.com/lit/ds/symlink/lf411 .pdf leaves a bit to be desired. The two devices may be essentially identical, but which would you rather use—one with full disclosure or one that tempts you into Datasheet Space? A clue for product managers and documentation writers: More information sells!
Software Datasheets?
If you're a software maven and you're still with me, you should have a bad feeling in the pit of your stomach. Those hardware folks have problems in places where software folks don't even have places: There is no software equivalent to a hardware datasheet.
Yes, we have functional descriptions and high-level specifications and UML and so forth and so on. What's missing is the range of information in even the simplest semiconductor datasheet: how it behaves under specified conditions, what to expect over a range of conditions, and why you might want to apply it in a particular manner.
Software is remarkably fragile in comparison with even the most trivial hardware. Some years back, Red Hat absorbed an amazing amount of flak for shipping gcc 2.96 rather than, oh, gcc 2.95.3. It seems that a 0.00.7 version increment broke existing code in strange and mysterious ways and produced strong opinions on both sides of the issue. The actual issues are beyond the scope of this column, but suffice it to say, nobody really expected the extent of the problem and none of the affected code came with a compiler caveat.
The linkage between even a trivial software module and the system running it is far more complex and subtle than the eight pins of an LF411, so perhaps it can't be distilled down to a few comprehensible pages. However, we seem so far from being able to characterize software, that we're not even close to living in Datasheet Space, let alone in the real world.
Our view of software is so idealized that the possibility of, say, a buffer overflow isn't even worth documenting. We ignore error conditions (do you check printf's return value?), blow by numerical issues (quick: What's the difference between affine and projective infinity?), and handwave around security (should we trust electronic voting?). Even if you don't have those problems, the industry at large sure does!
There's money to be made for putting a dent in this problem, much less solving it. I suspect progress will require a change in attitude, more than a change in practices, but the languages and methods we currently use surely aren't helping. If this tirade inspires you to crack the code, send me a check every few months, okay?
Reentry Checklist
Where do you put information you won't need again? The classic Signetics Write-Only memory datasheet is once again available at http://www.ganssle.com/misc/wom.html. A collection of more practical datasheets lives at http://www.datasheetcatalog.com/, as well as individual manufacturer web sites. Searching for just the part number using Google will generally produce enough hits to keep you occupied for days.
Red Hat's side of the gcc 2.96 issue is at http://www.redhat.com/advice/speaks _gcc.html, with another view at http://gcc .gnu.org/gcc-2.96.html. It's old history by now, but remember the lesson for your own code.
If you're interested in this electronics stuff and want to learn more, get a copy of Paul Horowitz and Winfield Hill's The Art of Electronics (Cambridge University Press, 1989; ISBN 0-521-37095-7). Even if analog isn't your main gig, you'll know more than most hardware engineers by the time you work your way through the commentary and examples. Highly recommended!
DDJ
