Follow Us QUESTION:
How do I make sense out of a data sheet?
Answer:
With some difficulty. The ostensible purpose of a data sheet is to provide the user and potential user with the fullest possible information about the functions and technical characteristics of the device concerned. But the realities of the industry practically ensure that there are too many cooks involved in concocting these documents, producing spoiled broth indeed.
The IC designer who writes the first draft of a data sheet wants to emphasise the genius of his or her creation. The marketing manager wants to stress competitive advantages of the product while soft-peddling any drawbacks. The test engineer wants to minimize the time and cost of production testing, and tries to remove all maxima and minima from the table of characteristics, instead replacing them with "typical" values. Corporation lawyers want to make certain that potential (mis)users of the device have no grounds for suing the Corporation. Corporate communications wants the document shrunk from 60 pages to four. And applications engineers (ahem!) want the data sheet so clear and simple that even a software engineer can understand it and they can sleep away their afternoons without the applications enquiry phone ringing. The final product is a . . . compromise, and not always as helpful as it could be. And because data sheets are always produced in a hurry when the product is ready for release they always have some mistakes.
What's an engineer to do? First, know which specifications are most important to your application. If you don't know, consult design guides or screw up your courage and ask someone who does. Second, conduct parametric searches among manufacturers to find candidate devices. Third, despite your misgivings, read the d***ed data sheets. (I really did once have someone call to ask how many pins there are on an 8 lead mini-DIP. I was polite to him!)
When reading data sheets, at the very least watch out for: "Vdd ≥ Vss" or, better "|Vss| ≤ Vdd." These are subtle ways of saying that if you supply the negative supply before the positive, the device will destroy itself. Specifications which appear similar on two data sheets but are not – such as small signal bandwidth versus full-power bandwidth, or settling time to 1 lsb (12-bits) versus settling time to 1 percent. "Typical" versus maximum and minimum specifications. Who's to say what a typical application demands?
The "compromises" involved in meeting a data sheet's conflicting requirements mean that much more can be learned from a data sheet than simply the overt facts and specifications. The website below analyzes these things in considerable detail. It would be a wonderful thing if the industry could agree on a standardized uniform format for data sheets and they all told the truth, the whole truth, and nothing but the truth. But I'm not holding my breath until it happens. Caveat emptor!
