I was recently sourcing an op-amp from a major vendor. This was a pretty nice part: a chopper-stabilized CMOS op-amp in a really tiny SMT package with a built-in charge pump for true rail-to-rail input operation. I was using it as part of a precision analog integrator circuit, so naturally I was very interested in the input bias current.

According to the 11-page datasheet, the maximum input bias current was around 5 mA. Wait, what? Even the very obsolete LM709 has an Ib of around 1.5 μA. I would expect a CMOS opamp to be in the double-digit nanoamps at worst. 5 mA is a lot of current, you can almost go to the moon on that these days. There was another obvious error, as well: the phase margin was provided in degrees Celsius.

Okay, so an intern had probably been responsible for writing the datasheet and got the units wrong. That's fair - it takes a while to develop a good feel for what the parameters for a real op-amp are, and a second or third year college student probably isn't there yet. But it was pretty shocking that this error hadn't been caught by the engineer reviewing the datasheet (which, after all, was only 11 pages long), and it was equally shocking that the error hadn't been reported to the vendor and fixed yet. At the time I found the error, the datasheet had been up on the vendor's website for nine months.

I reported the issue to the vendor, who confirmed that the input bias current was in fact 5 nA rather than 5 mA, and promised to fix the datasheet. It took them another three months to do so.

I have to wonder how closely engineers are scrutinizing their parts selections these days, since presumably this op-amp was being purchased by customers. Input bias current is one of the most critical op-amp parameters for designing any sort of high input impedance circuit. Do engineers really just slap a part on the board and hope it works without reading the datasheet?

Your paragraph about datasheets hits a sensitive nerve with me since I have been in many a battle over writing them.

I find that as a a quality conscious engineer a datasheet should constitute a guarantee. If not, what is the point? There are documents called 'Product Briefs' which are more or less a teaser or a dream about a part currently in conception. There you can claim to reach the moon and the stars. Not in datasheets. Datasheets should be full of what? Data. Not marketing.

Datasheets, like many other forms of company communication, tell you something not only about the part but also about the company. If the datasheet you are reading feels like an afterthought, it's an alarming sign of the vendor's processes, design documentation and quality setup.

Especially in a market with fierce competition where parts sell on a headline spec or set of specs, one should be extremely careful to be sure to compare apples with apples.

Having worked at several silicon companies I've seen various styles of documentation:

- some companies employ dedicated technical authors who write datasheets and Appnotes. They report NOT to marketing but rather to quality departments. Other companies require designers do it themselves where it is not uncommon that values specified for silicon come straight from the simulator.

- some companies will design to 4x stricter tolerances than those written in the datasheet so that no customer will ever find anything purported in the datasheet that is violated in practice, over temperature, silicon corners, elevation, aging, and traveling to parallel universes. Great as that may seem, this can however seriously impact the competitiveness of the product.

- all companies will try to represent data in the most positive way possible, which is why the measurement conditions always should be inspected carefully. There is nothing intrinsically wrong with this, however some will actively encourage / require people to 'write data a bit more creatively' to cover up snafus. That's crossing the line. In case of doubt, always try to re-create the specification or graph, and when you find you have to bend over backwards and keep your tongue at the right angle to come even close to the datasheet values, you know you are in touchy territory.

When trying to find the golden middle between those extremes you need a clear headed team of design and application engineers that is communicating properly, understands the influence of every parameter on the final application and has a sense of quality in their work. This is why the datasheet is so indicative of the company's maturity.

I have experienced plenty of cases where a part not meeting the datasheet specification has been the cause of pretty serious escalation between vendor and customer. Often enough the silicon customer are system suppliers with requirements from their customers. They have to rely on the specification given to them by the silicon vendor, not in the last place because the part often doesn't even exist yet (in volume) when the system design starts.

Datasheets are not signed off by lawyers, but the consequences of not meeting the specs can get very costly very fast, from missing an existing of future socket opportunity to reimbursing customers for returns of systems whose cost by far outweighs the part integrated in them, to eventually having your reputation fatally tainted.

And before all, whatever you do, don't make the summer student write the datasheet...!

Engineers:  Consider using fewer product families

A new datasheet is typically published when a product development team completes a project and brings a series of closely-related items to market.  The datasheet typically lists a set of orderable part numbers, each of which identifies a single variant of the product.

Digi-Key currently lists 6.7 million distinct part numbers. For every part there is a datasheet. But the total number of unique datasheets is much smaller than the total number of unique parts.

Here is a nine-page datasheet which characterizes the Vishay PLZ series of Zener diodes:

http://www.vishay.com/docs/84830/plzseries.pdf

The datasheet lists 97 distinct part numbers, so in this case the ratio of parts to datasheets is nearly 100 to 1.  Most of the information in the datasheet applies to all of the variants.  Consequently, any errors in the datasheet would probably apply to all of the variants described by the datasheet.

The datasheet mentioned above has a revision date of 08-Feb-2017.  This reflects the fact that as errors and omissions are discovered, datasheets evolve.  It takes time and effort for engineers to check for new revisions to datasheets or new errata sheets.  Some manufacturers provide ways for engineers to request notifications of revisions or errata (e.g. "update service").  But this information does not always arrive at times when the engineer is able to read and digest it.

The amount of time and effort required to learn about products and keep up to date on revisions and errata is directly proportional to the number of product families (datasheets) that an engineering team is using.  A team can reduce this overhead and its exposure to "surprises" by selecting parts from a limited number of well-documented and well-supported product families.  In some cases, this approach may result in using a part that is a little less powerful or efficient than an alternative part claims to be.  But the only way to be certain that the alternative part lives up to its claims is to invest time and effort in testing samples of that part and learning all of the important things that the datasheet left out.  If the alternative part lives up to its claims and is selected for use, the engineers will now have the ongoing burden of keeping up to date with future revisions to yet another datasheet.

If a company selects the "ideal" part for every design, without seeking to limit the number of product families used, then it will be very challenging for the engineers to keep up to date on all of the datasheet revisions and errata sheets.

There is a way to quantify this problem.  Look at the Bill of Materials for each product that a company sells and compile a list of unique part numbers.  For each part number, list the datasheet ID.  (e.g. manufacturer name and document ID)  Print a hardcopy of each unique datasheet and stack them up.  The height of the stack represents the amount of datasheet content that the company's engineers are dealing with.  The number of revisions and errata is proportional to the height of the stack.  In order to reduce the company's exposure to datasheet errata and "surprises", you need to reduce the height of the stack.

Manufacturers:  Form a consortium to establish a system of universal datasheet identifiers

The International Standards Organization (ISO) has defined numbering schemes to uniquely identify books, serial publications such as magazines, and printed music.

ISBN - International Standard Book Number  (13 digits)

ISSN - International Standard Serial Number  (8 digits)

ISMN - International Standard Music Number  (13 characters)

ISMN - International Standard Music Number  (13 characters)

A consortium of electronic device manufacturers could establish a consortium to set up a system of datasheet identifiers, and this standard could be submitted to the ISO for adoption.

ISDN - International Standard Datasheet Number   (proposed)

I would propose that a datasheet number be identical for all revisions of a datasheet.  A revision number could be appended or simply treated as a separate piece of information.  But the main datasheet number should be consistent across all revisions.

How this would help:

1. Component retailers, such as Digi-Key, could allow engineers to search and sort using a datasheet number (ISDN).  If you search for an ISDN, you will instantly see all of the part numbers associated with that datasheet.  If you search using other criteria and then sort by ISDN, parts will be grouped by product family (i.e. by datasheet).

2. Internet search engines (e.g. Google) could allow people to search for datasheet numbers. Google Advanced Search currently allows users to search for ISBN and ISDN numbers. This type of search would not only locate the manufacturer's datasheet, but would also locate articles and discussions in which a datasheet number was referenced.

3. Someone could develop an app that would automatically search for revisions to the datasheets you are using.  You would just need to provide a list of datasheet numbers.  This would make it easier to determine which, if any, of the products you are using have new revisions or new errata sheets.  This would probably require some coordination with manufacturers, but a standardized numbering system would greatly simplify things.

4. An engineering team could keep a master Bill of Materials listing all of the part numbers used in their products.  An ISDN column in the Master BOM would provide the datasheet number for each part.  A separate lookup table could provide the page count for each datasheet number (ISDN).  A simple computer algorithm could then determine the total number of datasheet pages that the team is dealing with.  (i.e. the height of the datasheet stack)  This would be a useful metric for determining the team's exposure to datasheet errata and "surprises".  If the "datasheet stack height" was observed to be increasing over time, this could help to justify additional hires.

I haven't thought this through.  It's more of a suggestion than a plan.  Lots of details would need to be worked out.

In my experience, the easiest vendor to meaningfully communicate with seems to be Microchip. Specifically they do not need you to prove to them what a great customer you are before they help you, and they genuinely do respond to suggestions & errata reports in a generally friendly & helpful manner.

Example - Ages ago I suggested their C code examples should be amended to use <stdint> rather than arbitrary type names. They actually did this - they took me up on that suggestion. I have other examples of similar things, for example with respect to IDE bugs or enhancements.

Obie came to the realization that it was a typical case of American Blind justice, and there wasn't nothing he could do about it, and the Judge wasn't going to look at the twenty seven eight-by-ten color glossy pictures with the circles and arrows and a paragraph on the back of each one explaining what each one was to be used as evidence against us.

Alice is looking for someone with a red VW microbus to pick up half a ton of garbage.