General > General Technical Chat
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
Navigation
[0] Message Index
[#] Next page
Go to full version