Do semiconductor datasheets suck?

[16bitanalogue]

Title is a little tongue-in-cheek.

I have the responsibility to write datasheets - or perhaps a better say to state it is that I clarify, add, and update the datasheet after it is passed off. Even then additions are committee approved; although, I "own" the datasheet. I am currently updating a datasheet with the approach of EILI5. If the descriptions confuse me, then I know they will confuse customers. I have access to the actual IC design and the design review documentation, but I need to strike a balance with descriptions being clear while not providing competitors with the secret sauce.

Over the years and across product lines, common issues are:
1. Where is the performance curve for this test? or performance curves not easy to read
2. Block diagrams are not detailed enough
3. Design equations are scant, wrong, or doesn't consider <x>
4. Electrical characteristics do not match what is seen on the bench
5. Explanations of features don't provide details

From a customer perspective, what are your gripes? I am purposely leaving particular products (amplifiers, little logic, power electronics, data converters), and leaving it open for a general discussion.

[ataradov]

As a customer, I understand that it is impossible to create a document that would answer all possible questions anyone would ever have. So, having a decent datasheet (and I personally consider 99% of the datasheets out there decent), and having accessible and responsive support channel that can answer clarifying questions, is a way better deal.

And I've seen the side of the datasheet creation. And after seeing that, I no longer want to put as much information as possible. Doing so helps a few qualified people, but invites A LOT of idle questions from inexperienced customers.  Sometimes things don't matter for the 99% of designs, but if you put some "strange" characteristic, you will get questions about that and you will have to clarify stuff. And all that for low volume customers.

If you have a structure where there is no support unless someone buys $100k worth of product, then this might work. But if you have an accessible support, it is better to limit the information to what majority of people will need. And adjust things based on the questions you get though the support channel.

[dmills]

When specifying things like the bias setting resistor for a PHY or such, give us a range of acceptable values that will meet the appropriate spec.
Specifying such things as Rbias = 4.56k is spectacularly unhelpful when it comes to BOM optimisation as you have no way to know if it is really a +-10% thing, and thus a 4.7k (which is already on the P&P machine) is acceptable, it is just annoying. The old Nat semi stuff was much better then the modern TI datasheets from this perspective.
 
Graphs on datasheets have a bad habit of being typical values, but error bars are a thing, please use them so that we can see what a few standard deviations look like.

Same idea, but graphs characterising the limits at more then just 20c would be NICE, power device SOA curves looking at YOU!

Please can we have mosfet current (Worst offender!) and Rds(on) ratings at 100c as well as 20c on the front page of the datasheet, yea I can work it out, but approximately nobody cares about how many hundreds of amps the bond wires will survive at 20c Tcase, give us that (Marketing will insist of the irrelevant number), but also the limits at the point we might actually be running the stupid thing under load. Expect marketing pushback on this one.

Opamps (and things containing them), it would sometimes be useful to know which supply pin the Vas integrating cap connected to, you can sometimes infer this from differences in PSRR between the rails, but it would be good information for a designer to have directly. If your part utilises 'Bias current compensation' please specify levels of correlated current noise, far too many of them don't, and it is a nasty surprise when the input impedances are unequal and suddenly excess noise appears.

On that subject, and chance of beating the guys who write the spice models of opamps until they start treating them as proper 5+ terminal devices and not three terminal ones, it is annoying when doing things like bootstrapping the power rails for improved CMRR that the spice deviates big time from the reality. 

On a general note, if you are using some totally standard bus like say I2C, I am probably very interested in the address and register map, but if you are going to describe the protocol itself, please do it in an annex, Microchip are horrible for this. They include a full description of I2C or SPI, with the one interesting bit of information (The address) hidden in the middle of 10 pages of guff you really want to just skip over.

Footprints, especially non standard ones, can we just OMIT the bottom view? Way too easy to screw up that way, and I think we have all done it, makes some sense on a mechanical drawing, but is just a trap for the EE.

On the subject of footprint drawings, ECad generally thinks in terms of pad centres and pad dimensions, but the ME crew like pad dimensions and inter pad gap, they also sometimes produce drawings where you need to do significant arithmetic to derive spacings and offsets (Connector manufacturers looking at YOU, also TIs weird DFN voltage regulator packages). It made sense to not over dimension back when it was done on paper with a drafting table, but nobody does it that way now, so please show us the stuff we need and not just the stuff that lets us derive what we need (1/2 A+B-C/2 +...., just tedious and error prone). On that subject, include the table of dimensions, but a drawing with the actual dimensions and not just the letter references would make checking footprints less annoying.

Oh if you can find a way to make it clear when something is a 'short form' datasheet (Aka a marketing glossy) before we download it that would be nice, ADI looking at you, with some HDMI chips.

Now despite all the moaning, most datasheets (with the exception of connector manufacturers) do not suck, and you are never going to be able to fully specify everything, but improving the mechanical drawings, giving ranges on required passives, and showing range bars on the graphs would all make me very happy. Adding performance data at realistic operating temperature for power devices would make me very happy indeed.

Not on the datasheets themselves, but on the CMS configuration, having the errata PDFs listed along with the datasheets would be nice, and when adding an errata item, doing it by publishing a new errata (and leaving the old one in place) would only be polite (At least two companies are guilty of quiet changes to errata and worse app notes).

[Siwastaja]

Some suck, some do not. Get someone to design a demo board or something using your existing datasheet and then work together to improve it. Good old plain text is pretty good; instead of extensive performance graphs, it's more important to know what the damn thing is supposed to do. For example, if your gate driver has a random tens-of-microseconds of delay after enable pin is activated, unlike any other gate driver IC, you have to mention this. Write a clearly titled paragraph about each input pin / control register / feature, and cross-reference to other such sections whenever needed.

Additionally to absolute maximum ratings, give explicit "recommended operating conditions" section. Show "typical application circuit" and use some time (ask around) to come up with the actually most common use case, not something esoteric, and not your test circuit.

[JPortici]

My gripes are usually with diagrams not providing useful enough information.

Case in point: i'm reviewing voltage regulator X.
Voltage regulator X only shows the PSRR up until a few hundred Hz's
Who gives a damn? It's a given fact that the PSRR for 50/60Hz and relevant are going to be good. What I (we?) care about is how it performs at much higher frequencies, usually because the LDO is a postregulator to a much more efficient DC/DC. I've seen things crash by putting a cellphone near them and taking a call, changing the LDO solved the problem for good.

Of course, if there is not a diagram is because the performance is dogshit, at least 99% of the time
Diagrams are almost on the top of my list for try or reject, as i don't have time or energy to test every single product in the catalog

[16bitanalogue]

This is some good feedback, so I will try to summarize rather than quote-reply.

Recommended Operating Conditions

• A recommended operating range (voltage, current, frequency, etc.) should be listed and explained in the characteristics table. It may be a good idea to have a note that explains this range is where the electrical characteristics hold (MIN, TYP, MAX) and if outside of this range but remaining under ABS MAX is permissible; although, specifications are not guaranteed. This particular question has been around forever.

Passive component values

• I think tolerance is omitted or not explained well; e.g.,  if a resistor is used to set an internal oscillator's frequency. There is either an equation buried in the applications section, a performance graph, or both. Tolerance is often left as an exercise to the reader. If you are given an equation, then it is left to the system designer to develop a sensitivity analysis based on initial tolerance, drift, aging, tempco, etc. and map that to standard values in the E96 range if 1% is needed. I tend to err on the side of 1% in most cases and state that in my design section to provide some kind of guidance.
• No one mentioned it, but depending on the product specific part numbers are mentioned. Say for a buck converter a datasheet may state 4.7uH, but that is too general. Often the actual part number will be included since this answers all the "Isat, DCR, AC losses" requirements. If it is just a value mentioned, then it is presume the system designer will have the knowledge to look for they passive specs outside of the inductance value.
• Values may be shown in a typical applications circuit or the evaluation board schematic and BOM for all the specifics

Performance Graphs

• These are almost always typical over a small group of parts, even only 1 part! The electrical characteristics table is covered by ATE characterization; i.e., 200 to 300 parts to gather statistical data. Find the +/-6 sigma then wrap that inside the MIN/MAX shown in the electrical characteristics table. I do have former colleagues that will show the typical curve with 1 and 3 sigma error bars, but only for particular data.
• I still struggle with 3 items: 1) appropriate information on how the data was captured (# of parts, manufacturer passive component #, test circuit), and 2) readability when there are multiple curves. Readability is broad - could be colors used (I do consider friendly colors for color blindness), and scales, and 3) If a typical is included in the characteristics table then that particular data point better match the typical graph too.
• If there is no graph then 1) the data was not taken, or 2) it looks like shit and not included.

In general:
1. I add details to the performance curves: 1) color blind palettes, 2) be mindful of axis scales, perhaps a reference to a test circuit setup, and passive component numbers.
2. EILI5 - for pin functions, feature functions, tables required when functions interact
3. Register Maps - I try to cross reference datasheet text from feature functions to the actual register in the register map. I am not sure if that is useful.
4. Mechanical  package drawings are usually created by the internal packaging group, and they service all product groups within the company. This means it would be hard for them to consider some rando apps guy out of a 3000 offering feedback, but I understand the frustration.

I may have missed some points. There are battles that can be fought since I am in control, but other issues (package drawings) is one of those battles that is honestly not worth to fight.

I get questions all the time from external and internal customers. Since I operate within the product group, I want to, at the very least, make things clear to the field and sales organizations, so they get the joy of clearly explaining features.

[ebastler]

May I propose one more rule of thumb?

EILI5

Avoid acronyms unless they are really standard terminology. If you have to use them, define them. 
I had to Google that one. Maybe it's a common meme in the US, but I had not come across it.

[T3sl4co1l]

Pet peeve: leakage current missing from inputs. So often I've seen regulators with ~1k resistors when 100k+ would do; why waste power unnecessarily?!

Conversely, if it's not documented, then give some justification why: for example is there an internal impedance to model?  (Example, internally voltage-mode compensated regulators. Some, the impedance between pin and error amp is itself a transfer function; others, it's the summing node so you need to size the divider resistors appropriately, or any other pole-zero elements as needed.) In that case, give the equivalent circuit (typically RLCD level, or maybe the first row of transistor(s) connected to it).

Alternately, are components of recommended type and range connected to it, and, just don't worry about the pin characteristics, do as you're told?

It doesn't have to be explanatory; I can settle for an instruction, an order. But it needs to be broad or flexible enough to cover the possible range of application for the device; I'll most likely keep shopping if I find something too limited and opaque.  Conversely, trying to account for every possible application (within reason), is a lot of up-front work, and you probably don't want to go to those lengths (or have the department budget and resources to do so).  In that case, give enough information that one can reasonably figure it out.

Classic era TI datasheets were pretty good about this (or maybe I'm thinking of National?), like with equivalent diagrams.  Whereas they've been pretty shite about both of these in the modern era.

...Do manufacturers do research and prototyping labs anymore?  I mean of the sort like the classics played around with.  Like how the LM13700 datasheet has dozens of applications, because, well it has to, it's a somewhat unusual part (it's not your bog standard op-amp), but also those were well-known and practical applications for the function at the time.  Ditto the LM393 and such, lots of ways you can use a comparator.  Some of those were well-known from earlier application (LM13700 is an integrated OTA, improving on discrete circuits used through the 60s), some of them are just, hey put some techs and engineers into a room, here's the functional schematic, here's some functional behavior, go nuts, figure it out, use it, abuse it, see what works.  Come up with ideas, cull the more ludicrous ones for practicality ("let's use the inputs as an ESD array!"), parameter variance / ratings abuse (plausible functionality but not part of design / process optimization), or conversely if something of sufficient interest is found, maybe back-propagate it to the spec, and design and test for it; etc.

...This probably goes well beyond scope of your position, but to the extent you can effect such change, or promote such ideas to the higher-ups that can, maybe some good can come of it.  If nothing else, just to say: to open your own perspective to wider applications, and how many things need to be known about each pin for example, and thus guide what kind of specifications, descriptions and applications go into your documents.

...Also the perennial: Why do Application Notes suck SO BAD?

And yeah, this is definitely a tricky writing problem; I sympathize.  Helps to have fresh or blank eyes on the project; bring in beta testers (as it were) who don't know much of anything about the chip you're working with.  Ask them to make a design, then you review it and see how well they did.  Adjust documents, test again -- retesting with the same people may provide different insights to testing with new "blank" people, but I would guess generally prefer blank.  And yeah, that's going to be a lot of work, maybe call this the belt-and-suspenders method, and maybe it can be "cheaped out" to varying degrees, but getting more eyes on it in any case will definitely help you see what biases and assumptions you were writing from.

Tim

[T3sl4co1l]

May I propose one more rule of thumb?

EILI5

Avoid acronyms unless they are really standard terminology. If you have to use them, define them. 
I had to Google that one. Maybe it's a common meme in the US, but I had not come across it.

It's pretty over-the-top for the most part, but every once in a while it comes in handy -- TDK datasheets I think it is?, almost always come with a glossary in the back.  It's cheap copy in the electronic era, and saves the effort of inline definitions, at least of the most common terms that can be assumed known by most engineers.

Also a good place to put symbols and units, if you're using a particular symbology as standard for circuit analysis (or physics or geometry related things).  Mostly that's going to be inline, because it's dealing with pin voltages/currents, or nodes in the reference circuit, but things like transformer design come to mind, everyone uses slightly different symbols and units (cgs vs. mks, *rarely* something else), and a common description helps clarify that.

Tim

[T3sl4co1l]

BTW regarding "typ", is there an industry standard for how this is determined?  Some kind of mean, I'm sure (most often arithmetic, but maybe others depending on statistics), but nobody and I mean NOBODY ever gives σ, or histograms or anything, unless it's something very particular (e.g. precision op-amp Vos histograms aren't uncommon).  Is variance literally prohibited?

Case in point, say a pin characteristic has to do with a semiconductor resistor, so maybe it's a 40-70k pull-up, fine, but that's something I have to know, but maybe it's actually CrSi or something and unexpectedly precision and it's just another 34.7k typ. parameter but they didn't happen to characterize min/max and it's actually like 5% or better, and now I don't have to guard band the huge range I had assumed.

I get if it's a process indicator, you don't want to be giving away even something as basic as... well I mean, sigma really doesn't say much, and it could be rounded up or down to crush some of its informational value, as a compromise between information vs. usefulness.  I don't know.  I can see the excuse that it might carry contractual obligations.  It almost seems like a conspiracy -- whether that's because of standards on the front end, or the paucity of fabs on the back end.  And no it's not like it's a big deal, we've been designing for decades without it, we'll continue to... but it's that one little nice-to-have that would improve everyone's life a definite amount, and it's just another sign of the world that we can't have nice things...

...Or maybe it's not something that can go on a datasheet at all, because it's by definition not something a device test can tell?

Also showing how min/max is calculated ("guaranteed by design" vs. 6σ vs. test limit range) would be nice.  Maybe that's something else assumed (industry standard), I don't know.

Industry standards, I know basically nothing about; they pop up on the internet basically never (it's uncommon enough to even see a reference to e.g. JESD-something or other).  Aside from satisfying these curiosities, I have absolutely no reason to purchase them ($$$!).  Sometimes manufacturers discuss these in a quality section, but a lot don't, or at least a publicly available document.

Case in point, I looked at a custom ASIC a couple years ago, that I looked up and down the datasheet, the brochure, the appnotes, searched their website, couldn't find a single reference to ESD anywhere, am I gaslighting myself?  Surely they have it documented somewhere, everyone does?  Finally got a ticket through support, they had to check with the design team... who said it's standard 1kV HBM.  Well how in the hell would I know that without the industry st--!...

Y'know?

Tim

[magic]

Include complete absolute maximum ratings.

I have seen 21st century chips whose datasheet fails to mention the existence of some clamping diodes
It's also nice if diodes are specified to survive X mA of clamping current rather than just "VCC+300mV".

[magic]

Opamps (and things containing them), it would sometimes be useful to know which supply pin the Vas integrating cap connected to, you can sometimes infer this from differences in PSRR between the rails, but it would be good information for a designer to have directly. If your part utilises 'Bias current compensation' please specify levels of correlated current noise, far too many of them don't, and it is a nasty surprise when the input impedances are unequal and suddenly excess noise appears.

Actually, why would you want to know the compensation thing if not for the reason of PSRR difference?

Hard to disagree about bias cancellation. Plenty of confusion out there and occasionally outright lies, i.e. noise specified using creatively designed test circuit which makes it look lower than everybody else's specs.

The crown goes to Microchip for their auto-zero opamps with 1pA bias and 100pA offset. What it means is that bias is ±50pA, but opposite polarity on the two pins.

[PlainName]

I would like to see a typical application circuit. And a description is what the thing is used for, not just what it does.

[16bitanalogue]

Pet peeve: leakage current missing from inputs. So often I've seen regulators with ~1k resistors when 100k+ would do; why waste power unnecessarily?!

As a general rule, reading through the ABS MAX will provide a clue for diode clamps. If ABS MAX on an op-amp input pin is VSS + 300mV and VDD - 300mV then that indicates a diode clamp, and I would expect leakage. Many digital I/O pins should have it in the EC table,  along with other specific pins (BIAS, an LDO style input on many converters/controllers). If you do not see it listed it is usually not considered important for most customers.

Generally speaking, a product is defined for a customer and their application in mind. There is a back-and-forth with that driving customer over the entire datasheet. First release just considers their needs. Of course as other customers gain interest, they may have other questions, use cases, and limits that the datasheet may not currently include. In most cases, I and my team will update the datasheets with new requests.

For pole/zeros, zener style clamps, what the input structure looks like: you are preaching to the choir. There are instances where information is purposely vague, because we only target specific vertical markets and we want 1) customers to ask those questions, 2) keep info out of the hands of our competitors.
#2 is debatable, there is nothing to stop a competitor from ordering a sample and an evaluation board. So 

Do manufacturers do research and prototyping labs anymore?  I mean of the sort like the classics played around with.  Like how the LM13700 datasheet has dozens of applications, because, well it has to, it's a somewhat unusual part (it's not your bog standard op-amp), but also those were well-known and practical applications for the function at the time. 

I been around a while. Different companies, different groups within the same company. In one sentence: "Is there a business justification for this?" I have always had to justify why I want to write an application note, create a design sheet, or create interesting circuits. It really depends on the type of product and if there is a justifiable need to tinker in the lab. Most tinkering is with tools (programming, hardware) to help make our lab testing easier, but this is specific to us and not a customer. I blame the MBA's.

Also the perennial: Why do Application Notes suck SO BAD?

Depends on what you mean by sucking so bad. The reality is app notes (many, not all) are conceptual and tied to a release of a product to help promote it. The other reality is the authors will have varying levels of education, experience, and practical knowledge. This is all very generic, but if someone expects an appnote to be some 6-sigma design over PVT (process, voltage, temperature) for the device and passives, you are looking in the wrong place. They are not meant to be "copy this and you will have no problems". This is a long winded way of saying, app notes (modern app notes) are MARKETING material.
At least the designs are simulated to help bolster the concept, then some may actually be built in the lab and tested. TI and ADI have circuit designs to this affect.

[16bitanalogue]

BTW regarding "typ", is there an industry standard for how this is determined?  Some kind of mean, I'm sure (most often arithmetic, but maybe others depending on statistics), but nobody and I mean NOBODY ever gives σ, or histograms or anything, unless it's something very particular (e.g. precision op-amp Vos histograms aren't uncommon).  Is variance literally prohibited?

I do not know of an industry standard. There is a team that oversees quality which includes how devices are tested to help with wafer yield. I can only tell you how I have seen it done over my many years, and there is variance (no pun intended,  ) from company to company.

1. One company would take worst case skew lots (https://en.wikipedia.org/wiki/Process_corners) and a few hundred parts and test them all over voltage, and temperature to gather statistical data.
2. Another company only looked at a typical lot of a few hundred samples over voltage and temperature to gather statistical data.

Which is better? Above my pay grade. I trust the engineering PhDs.

The production test limit is wider than the 6-sigma limit, and in turn the datasheet MIN/MAX is even wider than the production test limit. Statistically, you should never see a part anywhere near the MIN/MAX limit in the datasheet. You are either measuring wrong or the part is damaged. Rarely, and the most dreaded fear of any company, it is a test escape. Code Red.

Now, you will always here "Design to the MIN/MAX which is worst case." But we all know now that MIN/MAX limits are often well beyond 6-sigma, so what gives? Depending on who the customer is, we may provide characterization data, so the customer can use their own judgement on their design corners from our data. We still tell them we will not guarantee it - and I have seen on a few occasions a process shift. It may still be within final test limits, but that could still be a problem for the customer.

This may not always be true. Say for example, a group may get a waiver to have MIN/MAX only be 4-sigma and accept the yield loss.

I do believe it is beneficial to add sigma limits around the typical in the performance graph, but that is just me.

Also showing how min/max is calculated ("guaranteed by design" vs. 6σ vs. test limit range) would be nice.  Maybe that's something else assumed (industry standard), I don't know.

Hopefully, my previous answer helps with this as well.

[16bitanalogue]

Include complete absolute maximum ratings.

I have seen 21st century chips whose datasheet fails to mention the existence of some clamping diodes
It's also nice if diodes are specified to survive X mA of clamping current rather than just "VCC+300mV".

10mA is my rule of thumb. And, barring typos, the ABS MAX should always have VDD+300mV. If it does not then presume there is not a clamp. Some of my datasheets are like this.

[David Hess]

If block diagrams are given, then input and output circuits should be shown in detail.

The test circuits used to measure parameters should be published.

[CatalinaWOW]

I don't want to have to perform sensitivity analysis to determine equations for values of associated components.  Not because it is a lot of work (though that is true too), but because I don't know if those equations will apply to the next lot I buy from you.  I don't want an analysis/redesign cycle baked into each year, or quarters new purchase order.  If you don't know how your part is intended to work I'm not sure why I would want to buy it.

Similarly, typical readings are wonderful if they really represent mean performance.  But historically that has rarely been true.  I would much rather have the pass fail test setup and conditions for your production line.  And yes I know that treads pretty heavily on the competitive information line.  But it is what I really need to do a proper design, and could become a competitive advantage.  A way to set your company apart from the many clone vendors whose clones only match a couple of parameters.

Finally, your part is intended to solve a market problem.  That is the whole reason it exists, instead of some similar product from you or another vendor.  Your data sheet should clearly show what that purpose is, and any special conditions required to achieve it.  Even if price is that reason you should show that you achieve parameters X,Y and Z at that price point.

[16bitanalogue]

If block diagrams are given, then input and output circuits should be shown in detail.
The test circuits used to measure parameters should be published.

Depending on the product, yes. Older op-amps TI/NatSemi used to show the transistor level design, but even this was sanitized.  More complex products that would be a negative, Ghost Rider. That ESD clamp? We show a Zener, but it's not really a Zener. It simply acts as one. We would not show the logic on how PFM mode is activated in a buck converter mode pin; there would simply be a "PFM Logic" block. It's simply too complex.

I don't want to have to perform sensitivity analysis to determine equations for values of associated components.  Not because it is a lot of work (though that is true too), but because I don't know if those equations will apply to the next lot I buy from you.  I don't want an analysis/redesign cycle baked into each year, or quarters new purchase order.  If you don't know how your part is intended to work I'm not sure why I would want to buy it.

This is true with any part. Do you take this approach, let's say, with an non-inverting op-amp? The signal gain is 1 + Rf/Rg ignoring non-idealities (and there are alot, even academically that are ignored), so what would not apply to the next lot into perpetuity?

This is why customer's are always directed to design to MIN/MAX in the datasheet. As I mentioned earlier, some manufacture's can send you the characterization data, but it will always be up to your design team to do their own due diligence. I spearhead that all tests completed on the ATE should show MIN, TYP, MAX in the electrical characteristics table. TYPICAL being the mean of the lot(s) at +27C. The goal being to include as much data as I can to mitigate questions.

If you will, TYP is based on initial characterization of the lot(s). Over time that can certainly shift; however, as long as new die are tested are within MIN/MAX limits set by design after review of the characterization data and there is not some large shift in the distribution after for all other production lots into perpetuity, all parts will pass.

Similarly, typical readings are wonderful if they really represent mean performance.  But historically that has rarely been true.  I would much rather have the pass fail test setup and conditions for your production line.  And yes I know that treads pretty heavily on the competitive information line.  But it is what I really need to do a proper design, and could become a competitive advantage.  A way to set your company apart from the many clone vendors whose clones only match a couple of parameters.

You still have +/- 6-sigma around the mean, so it would be beneficial to understand what you mean by it being "rarely true." And I have shared the characterization data with customer's before. The P/F happens to be the final test limit. The final test limit is lower than the MIN/MAX shown in the electrical characteristics table.
Given the FT and EC limits are often much wider than +/- 6-sigma if I were to provide that data to you, it is on you to review your design if you chose to tighten your system requirements below MIN/MAX.
There is a give and take here. Either design to MIN/MAX which is the 'legal' answer, or take the characterization data and complete your own analysis; a.k.a the 'engineering answer'.

Even the largest volume, strategic customers follow this philosophy. This is my very professional and cordial way of saying, "Who the hell do you think you are, buddy?"

[Smokey]

Every product is different, and every use cause cannot be anticipated.  No one process will make a perfect datasheet for every product.

I've said this elsewhere, but the only path to great documentation I know of is through feedback and revision.

So give it your best shot based on what you think the user will need to know, and get that document in front of users and see what they have to say.  Then revise the document as fast as possible!

Maybe a first pass would be having some internal engineer not associated with the part production actually try to use the part in a real design. 
Then release for public.  It would be amazing to have a direct link to give datasheet feedback for that specific document.  Maybe a mechanism for checking if the datasheet revision is the newest?

Most of all, Listen to the questions your users ask about that specific part.  Monitor the web forums.  Talk to your FAE.  See what is giving people a hard time or is confusing and figure out how to add that information into the datasheet.

[ataradov]

Then release for public.

By the time things are released to the public, there are typically multiple real designs by early access / lead customers. They find far more issues than an in-house engineer ever would. This is still a very small number of issues compared to what happens during mass availability.

It would be amazing to have a direct link to give datasheet feedback for that specific document.

It would be very hard to do, especially as products mature. A lot of TI documents for old parts are poor quality scans of paper data books. Those things are not going to change no matter how much feedback you give.

I still receive requests to make changed to the documents that were last updated in 2011. This is simply not happening. I don't know if anyone even have source for those documents.

See what is giving people a hard time or is confusing and figure out how to add that information into the datasheet.

There are common and real issues,. which could be addressed. But in practice for established documents, majority of requests are something that is in the datasheet already. People just don't read or can't use search. And then everyone thinks that the issue they faced is the most obscure one (they can't be at fault., of course) and demand that their specific use case is addressed as soon as possible in the chapter.

It is impossible to make everything be the first thing in the chapter. If it is 1000 page document, some things will be deep.

And as far as fast iteration goes, it is also not easy. You are looking at one document, the company looks at 100s. And the number of technical writes is limited.

[Smokey]

The scans of old datasheets are the worst.  That has to hurt sales at some point.  I'll try to skip using a part with a scanned datasheet if there is a viable alternative. 

There are always going to be the users that put in zero effort to read the datasheet.  But from my experience there are still a significant number of people who put in the effort but the datasheet just wasn't clear on some point or another so they have to ask for clarification.  Go check out the TI E2E forum.  It's a lot of the same questions.  This is the stuff that needs to be revised, or rewritten, or put in big bold text or something. 

[T3sl4co1l]

Jesus. Well, that explains why -- well, fortunately no one has to design systems with it anymore, but logic gates for example show an impossibly wide margin.  The best 74HC might supposedly outperform the worst 74LVC.  Which just doesn't make any fuckin' sense.  Add up say three max gate delays, and you're already over the timing constraint at 10, 20, 30MHz? And practical logic circuits (say you were building an ALU) need way more than three delays.  Real 74HC builds (there are a few out there these days, though I don't have any links handy) achieve over 10MHz clock rate I think, flagrantly violating datasheet constraints.  But the datasheet is a lie.  But does that make it "ok"?...

Depends on what you mean by sucking so bad. The reality is app notes (many, not all) are conceptual and tied to a release of a product to help promote it. The other reality is the authors will have varying levels of education, experience, and practical knowledge. This is all very generic, but if someone expects an appnote to be some 6-sigma design over PVT (process, voltage, temperature) for the device and passives, you are looking in the wrong place. They are not meant to be "copy this and you will have no problems". This is a long winded way of saying, app notes (modern app notes) are MARKETING material.
At least the designs are simulated to help bolster the concept, then some may actually be built in the lab and tested. TI and ADI have circuit designs to this affect.

In this case I mean regards to factual accuracy, or theoretical understanding; indeed, I wouldn't expect them to do much if any statistics, appnotes should be more about practical embodiments than ongoing process variables.

The average appnote looks written by interns.  Maybe reviewed by engineering staff, maybe not.  My favorite one to rag on is probably this,
https://www.ti.com/lit/an/slpa010/slpa010.pdf
the author(s) clearly lack fundamental understanding of the dynamics they're attempting to control.  No equivalent diagram is given; Fig.20 finally adds an inductor to the loop, but only to illustrate gate-loop coupling; Fig.18 is basically their smoking gun, and they've failed to eliminate the symptom, only reduce it -- at expense of efficiency; no units are ever given (they've essentially measured Ls but stop short of actually writing it down); the test case isn't described (it's a sync buck, but what V, I, Fsw? -- they eventually say 12V in, 1.3V 40A out, 1MHz); component selection isn't discussed; only two layouts are tested, leaving still-better ones on the table; the PCB stackup isn't even mentioned (it's probably 4+ layer); there's even a dimensional error in an equation (page 12, \$L_p\$), though surprisingly the subsequent equations are correct, so this seems a typo.

I suppose it's interesting that this article was produced in regards to their NexFET technology; they do have remarkably low Crss, and perhaps one should read into this that the most effective reduction strategy would be to put some back? (An R+C from D-G is something I should try more often, honestly.)

But that's just one very particular example.  The most galling of all, to me, is probably the absolute unbridled confidence with which appnotes present their ideas.  I would dare say you could train a GPT on technical documents, and end up with merely sub-par copy (which I'm sure would impress the corpos..).  There is never any presence of mind, any checking of confidence, nor review of resources or references (they do occasionally give references, indeed this one gives two, though I haven't noticed where if at all they're referenced in the text).  The biggest sin therefore is that readers assume they are authoritative.

Like 60% of relevant questions on the internet are "I did it following the appnote so it must not be that" (with the correct answer: "appnote is wrong do it this way"), compounded by 60% of other answers being "do it according to the appnote".


Thanks by the way for hanging out!

Tim

[magic]

It would be very hard to do, especially as products mature. A lot of TI documents for old parts are poor quality scans of paper data books. Those things are not going to change no matter how much feedback you give.

Ehm, any example currently on ti.com?

Say what you want about TI, but they are nuts about reformatting datasheets to their latest internal standards. Sure, some old and almost forgotten parts haven't received an update in over 20 years if there is nothing interesting happening to them, but even if they look like vintage databooks they are cleanly rendered PDFs with real text and vector graphics. High profile parts receive regular updates and look like any new part's datasheet. See LM317 for example, the current version has colorized typical characteristics plots and all the typical TI stuff: recommended operating conditions, "device functional modes", typical applications, board layout example, and so on. Some of it came from vintage LM317 datasheet, some of it had to be added.

Datasheets of products acquired from BB and NS haven't looked like the originals for years.

[T3sl4co1l]

Not hard to find examples; https://www.ti.com/lit/ds/symlink/cd4011b.pdf perhaps surprising that it's not been updated for such a basic datasheet, when others have (4013 for example).

Oh heh, another gripe, but this is more of a historical baggage and appnotes thing -- parts like TL494 always, only and ever show voltage-mode configurations. Even though objectively better current-mode operation is possible, and hardly any added complexity.  I expect this comes down to, it's easier to repeat old material, even if it's bad (read: performs worse, or rarely actually is actively harmful).  Also a bit less topical, as it's a phenomenon which affects everyone everywhere, from oft-archived and repeated schematics floating around communities since the printed era, to original authors repeating material at least as a baseline (if you're repeating what was previously accepted as valid, surely you're not doing any worse than previous work did), but also perhaps limited for other reasons, like not being aware of alternatives, or not being able to demonstrate them given constraints (show value proposition + work to design and build it + document it, etc.).

Tim

[magic]

Not hard to find examples; https://www.ti.com/lit/ds/symlink/cd4011b.pdf perhaps surprising that it's not been updated for such a basic datasheet, when others have (4013 for example).

You win, I guess.

But it says "acquired from Harris Semiconductor" so maybe TI never had this document in any sensible digital format and can't be bothered to recreate it.


And by the way, I'm no TI fanboy and their datasheets aren't exactly perfect. When they came up with "recommended operating conditions" they retroactively added them to most existing datasheets, usually something generic like "±15V supply" for opamps, regardless of actual abilities of given model. They shuffle sections around and occasionally mess something up, like the OP07 which had its schematic replaced with a 741 during datasheet overhaul. There are datasheets like TL431 consisting of numerous copy-pasted tables differing in a few digits here and there. There is the TL072H shoved into TL072 datasheet even though all its specs are separate from the latter.

[David Hess]

If block diagrams are given, then input and output circuits should be shown in detail.
The test circuits used to measure parameters should be published.

Depending on the product, yes. Older op-amps TI/NatSemi used to show the transistor level design, but even this was sanitized.  More complex products that would be a negative, Ghost Rider. That ESD clamp? We show a Zener, but it's not really a Zener. It simply acts as one. We would not show the logic on how PFM mode is activated in a buck converter mode pin; there would simply be a "PFM Logic" block. It's simply too complex.

When required, simplified schematics are usually good enough, and often better because they are easier to follow.  For instance they are indispensable when understanding what clamp, compensation, and offset null pins do in operational amplifiers.

For some newer operational amplifiers from Texas Instruments, it is impossible to know the differential input range because there is no input schematic, and the specifications either do not say or are conflicting.  And which way does the input bias current flow?  You just have to measure it.

And by the way, I'm no TI fanboy and their datasheets aren't exactly perfect.

It is not a matter of being perfect.  In the past Texas Instruments sometimes misled or deliberately lied on their datasheets.  When you read the articles from Bob Pease talking about someone publishing misleading datasheets, he is referring to Texas Instruments.

[schmitt trigger]

Not hard to find examples; https://www.ti.com/lit/ds/symlink/cd4011b.pdf perhaps surprising that it's not been updated for such a basic datasheet, when others have (4013 for example).

But it says "acquired from Harris Semiconductor" so maybe TI never had this document in any sensible digital format and can't be bothered to recreate it.

This datasheet has a long lineage.

I still have an original RCA COS/MOS data book, published on 1980, and the TI datasheet posted by T3sl4co1l is identical to the one on my book.

Harris acquired it from RCA Semi, via a brief detour from GE, and I believe Intersil.

[magic]

For some newer operational amplifiers from Texas Instruments, it is impossible to know the differential input range because there is no input schematic, and the specifications either do not say or are conflicting.  And which way does the input bias current flow?  You just have to measure it.

TI's new precision bipolar opamps seem to use bias cancellation.
Maybe it's different with the cheaper LMVxxx stuff.

[Kleinstein]

There is the TL072H shoved into TL072 datasheet even though all its specs are separate from the latter.

The mess with TL072H is not just a data sheet problem. It starts with naming that is causing more confusion than good.  It is still another bad step to have a combined datasheet, as the old TL072 and new CMOS TL072H have not much in common. Not hat the TL072H is a bad part, it just got a bad name.
Combined datasheets that handle multiple parts are often a good thing, if the parts are really the same core  (e.g. 1/2/4 fold OP-amps or different voltage regulators).

For the OP-amps it would be good if they directly write if the use bias compensation or not. At least the newer DS give the signs and one finds out.

The main 2 points where I have seen repeatedly wrong values is with the current noise of AZ OP-amps and the DC SOA of MOSFETs. The wrong SOA curves are especially nasty, as this can (but one may be "lucky" with a prototype) cause failures that cause additional damage.

[T3sl4co1l]

There is the TL072H shoved into TL072 datasheet even though all its specs are separate from the latter.

The mess with TL072H is not just a data sheet problem. It starts with naming that is causing more confusion than good.  It is still another bad step to have a combined datasheet, as the old TL072 and new CMOS TL072H have not much in common. Not hat the TL072H is a bad part, it just got a bad name.
Combined datasheets that handle multiple parts are often a good thing, if the parts are really the same core  (e.g. 1/2/4 fold OP-amps or different voltage regulators).

For the OP-amps it would be good if they directly write if the use bias compensation or not. At least the newer DS give the signs and one finds out.

The main 2 points where I have seen repeatedly wrong values is with the current noise of AZ OP-amps and the DC SOA of MOSFETs. The wrong SOA curves are especially nasty, as this can (but one may be "lucky" with a prototype) cause failures that cause additional damage.

This is probably the most egregious example, being same-source.

Similar hazards can be found with new substitutes from other companies.  A recent one that comes to mind:
http://file.3peakic.com.cn:8080/product/Datasheet_LM2903A-LM2901A.pdf
The things that most jump out to me are:
- Input bias current is greatly improved
- Output current and saturation voltage are improved
- Response time is a little slower
- Waveforms are far too symmetrical: response time looks like a double-pole CMOS amp (decomp'd, of course), output is clearly CMOS type
- Input ESD diodes include supply (original allowed "over the top" inputs!)

It's a lie; it's definitely a completely different type, design, architecture.  It does look pretty good, in and of itself -- aside from the somewhat slower response, I don't have any particular problems with its specs, though it would be nice to have more performance graphs.  They also specify input reversal conditions (one input beyond Vicm still gives correct result; both outside, indeterminate).  It's literally just one thing: an LM2901/3A, it is not!

I had looked at a few other products of theirs, I think which seem alright mostly, but catches like this can be as simple as tripping up the less-careful employees in purchasing.

Tim

[magic]

There are similar LM358 coming from China too.
It will be particularly "fun" when it breaks and somebody replaces it with the original part, but the design relied on lower bias or something.

Thankfully, nobody repairs anything anymore

[T3sl4co1l]

There are similar LM358 coming from China too.
It will be particularly "fun" when it breaks and somebody replaces it with the original part, but the design relied on lower bias or something.

Thankfully, nobody repairs anything anymore

Or relies on the class C output stage to...

wait.

([further?] implying that random CMOS versions are likely to be, if not universally, then in most respects, a strict improvement upon the original)

Tim

[coppice]

There are similar LM358 coming from China too.
It will be particularly "fun" when it breaks and somebody replaces it with the original part, but the design relied on lower bias or something.

Thankfully, nobody repairs anything anymore

This happens all the time. None of the look alike parts work exactly like the originals. Usually they work a little better than the original, as they were designed not to cause trouble as a substitute. If you design and test around the second source part, the original may cause some nasty surprises. The snag is often trying to find which of the alternatives has the worst spec in its data sheet, so you can design around that.

[VK3DRB]

Most Chinese datasheets suck. Missing key information in almost every datasheet, but providing useless manufacturing inspection pass/fail criteria. You have to contact the Chinese manufacturers to get the info you need. Recently, after asking for 3D step files and pricing for a connector, the female sales person hunted my phone number down on WhatsApp and seem to want to set up a relationship as friends. Not bloody interested, I don't care how pretty she looked. I just want data, not a date.

American datasheets are pretty good generally. But not long ago I found a subtle bug in a Texas Instruments datasheet where they had cut and pasted info from another datasheet and forgot to change the data. Just this week, I found TI has been shipping a certain IC with the WRONG part number on them. One of the recipients has been Mouser. The chips don't work because they are in fact a different part! TI has quality assurance problems which seem to have been getting worse in recent times. Lets' hope things improve within TI.

Worst American datasheets by far are Honeywell sensor datasheets. Wrong data causing fatal damage to the device when used as instructed. A company that has no competent documentation QA. Sensirion is a far safer company to use and they have excellent datasheets and sensors.

[EPAIII]

Well, I have lived in the US for almost 80 years and this is the first time I have heard that one.

Way back in elementary school I do remember one of my teachers telling the class that you should ALWAYS explain what an acronym means the first time you use it in any place. It is just common courtesy.

May I propose one more rule of thumb?

EILI5

Avoid acronyms unless they are really standard terminology. If you have to use them, define them. 
I had to Google that one. Maybe it's a common meme in the US, but I had not come across it.

[tooki]

I’m American too and I’ve never seen that acronym before, either. I don’t think it’s very common.

[magic]

It's reddit slang, which means not knowing it is probably a good thing. Too late for me

[VK3DRB]

Well, I have lived in the US for almost 80 years and this is the first time I have heard that one.

Way back in elementary school I do remember one of my teachers telling the class that you should ALWAYS explain what an acronym means the first time you use it in any place. It is just common courtesy.

May I propose one more rule of thumb?

EILI5

Avoid acronyms unless they are really standard terminology. If you have to use them, define them. 
I had to Google that one. Maybe it's a common meme in the US, but I had not come across it.

It's not an acronym. It is an initialism. Know the difference.

Datasheets generally appropriately use acronyms and initialisms if they are from a reputable company like Analog Devices and many others. Know your audience. IBM overdid abbreviations to the extreme without necessarily defining them. I know because I worked there for 18 years.

I do find the excessive use of initialisms and acronyms in embedded code or net labels on schematics, incredibly annoying, especially when some "programmer" or "engineer" with tunnel vision decides to run them together. One can only assume people do this out of laziness, incompetence, or to protect their employment.

Now SDA and SCL are fine, because the audience should know what they are. Because most datasheets refer to the Philips (NXP) I²C standard.

I have spent the last three months ploughing through a maze of embedded code for an STM32 written by someone who didn't know how to write code properly. One intermittent bug took me about two weeks to find. If the author he had written the code to be readable, I would have nailed in under two hours. It is a nightmare with many thousands of lines of gobbledegook. It is barely commented throughout. The author died in August, so there is no point asking him what or why things are done in his code.

Here are some initialisms he used: iia (index in array), idx (index) - yes he mixed the abbreviations up. sn (sensor) and sno (serial number) - ambiguous nonsense. Ready for this one? P. Oh, that means pressure and I could only work that out from the datasheet. Of course there hardly any comments, and poor and illogical code structure... it all needs to be to be rewritten.

The bottom line: You are writing code and creating a schematic primarily for other humans to read, not decode. Second to that, the code should work.

ANDDNTOVRUSEABRVS_whenHumanReadibleWordsAreSoMuchBetterEvenIn_camelCase.

[PlainName]

Datasheets generally appropriately use acronyms and initialisms if they are from a reputable company

Off-hand I can't recall a reputable datasheet using initialisms. Can you think of an example to illustrate? I may have led a sheltered life, but initialisms just don't strike me as something proper sources would use.

[thm_w]

Datasheets generally appropriately use acronyms and initialisms if they are from a reputable company

Off-hand I can't recall a reputable datasheet using initialisms. Can you think of an example to illustrate? I may have led a sheltered life, but initialisms just don't strike me as something proper sources would use.

Open a charger or DC/DC datasheet you'll probably see 10 or 20 of them: PWM, MPPT, OCP, VDD, LED, DCM, etc.

[PlainName]

Duh! You are quite right - they are everywhere and my eye just coasts straight over them 

[VK3DRB]

Datasheets generally appropriately use acronyms and initialisms if they are from a reputable company

Off-hand I can't recall a reputable datasheet using initialisms. Can you think of an example to illustrate? I may have led a sheltered life, but initialisms just don't strike me as something proper sources would use.

Open a charger or DC/DC datasheet you'll probably see 10 or 20 of them: PWM, MPPT, OCP, VDD, LED, DCM, etc.

and SCL, SDA, I2C, EIAJ, TCP/IP, SPI, I2S. they are all initialisms. UART, USART, FIFO are acronyms. EEVBLOG is a hybrid of an initialism and plain text. Its academic, but we all know what we mean. One thing I do frown on is when an engineer or technician who might say "50 Hertz" also says something like "It is one Hert off". I have heard this a few times over the decades. I don't want to hurt Mr. Hert too much, so usually I just gently tell him he is first class submoron

[CatalinaWOW]

Datasheets generally appropriately use acronyms and initialisms if they are from a reputable company

Off-hand I can't recall a reputable datasheet using initialisms. Can you think of an example to illustrate? I may have led a sheltered life, but initialisms just don't strike me as something proper sources would use.

Open a charger or DC/DC datasheet you'll probably see 10 or 20 of them: PWM, MPPT, OCP, VDD, LED, DCM, etc.

and SCL, SDA, I2C, EIAJ, TCP/IP, SPI, I2S. they are all initialisms. UART, USART, FIFO are acronyms. EEVBLOG is a hybrid of an initialism and plain text. Its academic, but we all know what we mean. One thing I do frown on is when an engineer or technician who might say "50 Hertz" also says something like "It is one Hert off". I have heard this a few times over the decades. I don't want to hurt Mr. Hert too much, so usually I just gently tell him he is first class submoron

And he might return in kind because the usage was intentional punnage.  Last word chosen to annoy language purists.

[TimFox]

Here is the list of accepted abbreviations (mostly initialisms) allowed for publication in American Institute of Physics (AIP) scientific journals without further definition:
https://www.carleton.edu/physics-astronomy/major/integrative-exercise/comps/style-manual/appedix-d/
Otherwise, in scientific publications, the abbreviation should be spelled out on first introduction.
This made for interesting titles when 7,7,8,8 tetrathiafulvalene-tetracyanoquinodimethane (TTF-TCNQ) was a very active research topic in the 1970s.

[shapirus]

Here's a fresh example, the one I'm reading right now.

TI's CD74HCT132: https://www.ti.com/lit/ds/symlink/cd74hct132.pdf

It's either that I don't know how to read and understand datasheets, or it has not been QA'ed and is a result of some quick copy-pasting.


section 9.2.1.2 Input Considerations

The CD74HCT132 has CMOS inputs and thus requires fast input transitions to operate correctly, as defined in
the Recommended Operating Conditions table. Slow input transitions can cause oscillations, additional power
consumption, and reduction in device reliability.

Fair enough. Now, how fast should "fast" be? Let's see the mentioned table... only to find that it does not contain any specifications on the required input transition timings.

And the very next paragraph says:

The CD74HCT132 has no input signal transition rate requirements because it has Schmitt-trigger inputs.

Of course, the Schmitt-trigger inputs are in the product title. But... why does the first paragraph that I quoted above state that the device requires fast input transitions? Looks very much like an overlooked copy-paste from another datasheet to me.


Next,

Unlike what happens with standard CMOS inputs, Schmitt-trigger inputs can be held at any valid value without
causing huge increases in power consumption. The typical additional current caused by holding an input at a
value other than V_CC or ground is plotted in the Typical Characteristics.

...unless I fail to see it there, the mentioned plots are not present in the Typical Characteristics section.


Finally,

Refer to the Feature Description section for additional information regarding the inputs for this device.

But there is no section named Feature Description (do the datasheet writers not use tools such as LaTeX that can substitute the section names, links, and page numbers dynamically, referenced by internal id?).

Additionally, there is no specification for the minimum time during which an input must be held high or low to be registered as such, whereas it is one of important characteristics of logic ICs.

This one is definitely not among the better part of the datasheets that I've ever read.

Curiously, it does contain a "submit document feedback" link. I'll try it!

[SiliconWizard]

Yes, it definitely looks like some half-baked copy-pasting from other datasheets. (And to be fair, for people who have written many datasheets, who has never done that, and forgot to adapt/remove some sentences that would not apply?)
Reviews should catch that though, but given the budgets allocated to technical documentation these days, not too surprising they haven't.
What sucks is when there is no real feedback channel from customers that would allow fixing documentation when it's incorrect. Often there is very little of that, and still for the same reason, budget.

But yeah, it's hard to write 100% correct technical documentation without any strong process to check for correctness. At least when it comes to "bugs" that lead to a tangible defect (software or hardware bug), observing the issue is not hard (fixing it may), but when it comes to strictly abstract design (which a doc is), it's very hard to catch unless you have a strict process for that. Imagine writing software code that never gets compiled or tested, shiping it to customers and aiming for 100% correctness. Nobody would expect that. Just to give some perspective.

So let's just give design teams some budget for proper docs.

[T3sl4co1l]

What's funny is, the ancient datasheet (databook scans) that they replaced, probably contained all that, and more if you include the logic family introduction (which is basically what the application section is doing now).  Actually, they may well be rewriting (OCR, copy-paste, transcribe, whatever) that content, into the new format, and just not parsing it to find discrepancies like this.  Which, yeah, all comes down to department budget (and responsibility of management given that budget).

On the upside, NXP is a prominent competitor to TI in the logic space, and I haven't noticed gross defects in their documentation.  Sounds worthy of awarding some design wins eh?

Tim

[SiliconWizard]

Which is Nexperia actually, isn't it? Yeah, same boat. And yes, their datasheets are usually clean. And most of their parts have Schmitt trigger inputs, by the way.

[T3sl4co1l]

Ah yeah, it is Nexperia with logic. Think NXP datasheets still turn up quite often...

Tim

[shapirus]

On the upside, NXP is a prominent competitor to TI in the logic space, and I haven't noticed gross defects in their documentation.  Sounds worthy of awarding some design wins eh?

Yeah I actually like their datasheets. The colors are more pleasant too .

[magic]

Here's a fresh example, the one I'm reading right now.

TI's CD74HCT132: https://www.ti.com/lit/ds/symlink/cd74hct132.pdf

It's either that I don't know how to read and understand datasheets, or it has not been QA'ed and is a result of some quick copy-pasting.

That's what I wrote about TI being nuts about keeping datasheets up to their "standards". They clearly have certain internal rules about various sections and tables which must be included in all datasheets so that almost everything you might want to know about the part can be found there. Those things are highly repetitive within product families or even whole types of products (e.g. almost every CMOS opamp has the same pattern of ESD diodes) so certain texts or diagrams are written once and reproduced in countless datasheets.

...with a varying proofreading effort, as you found


For example, if you ever wondered why everybody specifies NE5534/5532 as good for ±3V but TI's recommendation is ±15V, the answer is that TI also used to advertise ±3V on the front page, but in the '90s somebody added a copy-pasted "recommended operating conditions" table with the generic ±15V, and then somebody noticed the conflict and removed the front page spec. I think the same happened to some other parts too, but I don't remember specific examples now.

BTW, input and output ranges may get uncomfortably restricted at low supply, and maybe other performance characteristics not as good as at 30V. But we are talking parts which used to be advertised (also by TI) as at least "usable" at low voltage...

[tooki]

What sucks is when there is no real feedback channel from customers that would allow fixing documentation when it's incorrect.

TI does: the footer of every datasheet PDF has a “submit document feedback” link, and TI has responded promptly when I’ve used it. There’s a link on the product web pages, too, which includes the parametric data.

Analog Devices is the same, the link in the footer is simply titled “document feedback”.

Infineon lists a feedback email address on the last page of its datasheets.


Of the four manufacturers I looked at, only ST didn’t have any obvious feedback method.

[Vincent]

I never had major problems finding the information I'm looking for in datasheets, either because:

A) I happen to be wonderfully skilled in data retrieval in documentation, or

B) I'm still to such a noob skill level in electronics that I actually ever hit the wall.

I would bet it's most certainly B).

Application notes however are a different story. Let's say that circuit descriptions aren't always the most insightful. 

[Kleinstein]

The example ciruits given can be good but some are also odd, using the chip for something strange, where much better/cheaper solutions exist. Some of those are at least funny, but a beginner may actually use them.
Separate appl. notes are usually better in that respect and some (especially for more complicated chips) can be seen as an extension of a data sheet.

For finding the data wanted it helps that many chips are from only a few companies and use a similar format. It can still sometimes be a long time to find out that a value is not there or only partial in a graph. An anoying example in older datasheets for OP-amps is that instead of the supply current the power is given - one may miss that on the first scan for a mA / µA value.

[Someone]

An anoying example in older datasheets for OP-amps is that instead of the supply current the power is given - one may miss that on the first scan for a mA / µA value.

mA per amplifier, another trap when copying over to design documentation.

[coppice]

What sucks is when there is no real feedback channel from customers that would allow fixing documentation when it's incorrect.

Every vendor has an effective feedback path. Inform one of their sales people that an error in a datasheet is affecting your decision to place a large order, and you'll be amazed how quickly it gets fixed.

[SiliconWizard]

What sucks is when there is no real feedback channel from customers that would allow fixing documentation when it's incorrect.

TI does: the footer of every datasheet PDF has a “submit document feedback” link, and TI has responded promptly when I’ve used it. There’s a link on the product web pages, too, which includes the parametric data.
Analog Devices is the same, the link in the footer is simply titled “document feedback”.
Infineon lists a feedback email address on the last page of its datasheets.

Yes, they have email addresses. I like that.