For novel ideas about building embedded systems (both hardware and firmware), join the 40,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.

Typically Typical - Take Two

Summary: Jack has some more thoughts on "typ" numbers.

I wrote last year about the folly about using "typical" specs when designing systems here: My sense from reading the comments is that a lot of responses 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:

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:

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:

data sheet from 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?

Published May 6, 2014