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