原创 What does typical mean? Take two

Last year, I wrote a blog on the folly about using “typical” specs when designing systems. My sense is that a lot of feedback were from older engineers. As one of those myself, I have to confess that eons ago, as a freshly-minted EE, I was a rather careless designer. Need a pull-up? Any old resistor would do. Capacitors? Sure, select one based on voltage and capacitance. I rarely thought about tolerances, temperature effects, and the myriad other factors that make a circuit reliable in production.

But sometimes there were problems, and I learned that between the lab and the manufacturing line lies a huge gulf.

Fortunately, a mentor appeared, an older engineer who was a complete pain in the you-know-what. He critiqued everything. We had to justify the smallest design decisions. He’d demand small changes to meet his notion of getting things reliable.

We all hated him.

But a strange thing happened. These carefully-reviewed designs worked. All the time. Customers weren’t ticked off. And it turns out that it’s actually interesting and rewarding to think through design decisions with care.

Another mentor appeared, a chemical engineer turned sailing bum. He taught me to apply the engineering method to building and maintaining ocean-going sailboats, where failures can be life-threatening. No fitting was too unimportant to think about from a stress, wear, and materials standpoint. Dan taught me to generalize the engineering mindset to life in general. Some politician makes an odd claim? Do the numbers. What’s likely to happen to the teenagers on that weekend at the beach? Do a worst-case analysis and develop contingency plans.

It drives my wife crazy.

In that article about typical specs I complained that the vendors spew “typical” numbers, but they admit that these aren’t tremendously useful for design. That thwarts any attempt to do careful engineering analysis when building a system.

Consider this excerpt from an ARM datasheet:
 

My mentor of yore is rolling is rolling in his grave. This dearth of hard data makes it impossible to create a reliable design.

As reader DaveSchabel replied in the comments to my earlier article “I'm not sure if the manufacturers realize that poor datasheets often eliminate an otherwise superior device from design-ins.”

It wasn’t always this way. Here’s an example from TI’s 1976 TTL Databook for the 7447A BCD to seven segment decoder/driver:
 

Note that all of the specs have a max or min number, and the data shows what conditions those numbers apply to (e.g., Vol is with Vcc-MIN, Vih=2, Vil=0.8, Ioh=-200 uA). The typical specs aren’t much different from the worst-case numbers. Compare that to some MCUs whose max sleep current, in those rare cases where one is listed, might be two orders of magnitude greater than the listed typical.

Admittedly, in the olden days just a few pages were enough to fully document a part. Today a thousand page spec isn’t uncommon, and that immense document commonly leaves out important information. Properly characterizing a component isn’t easy.

Here’s another datasheet – it’s from a box of Entenmann’s donuts:
 

These are worst-case specs. They are guarantees. Contractual terms between Entenmann’s and the buyer. You know what you’re getting.

Min/max specs, too, are guarantees. “Typical” is not. Why would one risk using a part that the vendor refuses to guarantee?

Just last month an FAE from a large vendor told me some of their typical numbers are really marketing tools. Does that mean they can change with the competitive landscape? “Our competitor just dropped their typ specs; we better do the same!"

Me, I want a guarantee.

What’s your take?