Even when specs define all supported configurations and features, you need to verify with prototyping early enough in your project.
Unless you welcome surprises at the worst possible moment when the time pressure builds to a boil and no amount of money is able to justify a new tape out of Silicon.
We had a case of complex telephony ASIC that was documented as supporting 8,16 or 32 bit wide flash memory. Unfortunately for us the smallest configuration was never tested by vendor!
Reminds me of testing a portion of the Space Station. One requirement for one of the boxes was to test the RS-422 signal for squareness with an oscilloscope. My lead engineer had it all setup through the switching matrix, but got ugly waveshape. Then, when manually debugging the test, the waveshape was perfect. Not knowing the history and not yet understanding the objective of the test, I asked why he had the scope probe tied to ground and also being switched to the other side of the RS-422 pair. The answer hit him like a lightning bolt. We cured the problem with a differential probe that measured the two data lines without pulling one of them to ground. Simple mistake, simple change, and a dramatic change in waveshape.
Even reading the datsheet doesn't help sometimes. It was/is a little-known fact that the CD4538 monostable is different from the MC14538 monostable. That's right:- same chip, different vendors, standard logic family. One chip can retrigger before the pulse ends and the other can't; sometimes that REALLY matters! For all I know that is still the case with SM descendents and derivatives, depends on if RCA or Motorola were the design ancestor, e.g. NXP triggers like RCA, AFAIR. Never seen this quirk discussed or documented anywhere.
To further underline your "thoroughly" assertion, one should also cover all of the fine print footnotes into which some vendors seem to take pleasure in hiding certain functional...er, let's just call them "distractions".
Your story seminded me of a problem I ran into with an HDLC controller chip from the same era. In that case, however, even a close study of the datasheet and application notes (including the footnotes) would not have revealed the cause, although this does not diminish the valid point you make.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...