My good friend Jack Ganssle knows more about good firmware design and development than anyone I know and he’s just written a short essay about Agilent’s DSO (digital sampling oscilloscope) design philosophy in his latest email newsletter, the Embedded Muse, which you’ll find on his Web site at www.ganssle.com. First, I’ll show you what he wrote in his latest newsletter (thanks for the permission Jack!) and then I’ll discuss why his observations go straight to the heart of the EDA360 Realization philosophy.
Here’s Jack’s discussion (with emphasis from me):
“Some years ago I visited Agilent’s oscilloscope division in Colorado Springs. They had just finished designing the “Infiniium” series of scopes. The product was—and is—impressive. Still more interesting was their development approach.
The engineers told me that every time they started work on a new product they’d first design the device’s computer board. But, Agilent is not a computer company. Why, they wondered, focus on endlessly creating embedded computers instead of zeroing in on the product’s application?
This minor revelation shaped the Infiniium’s entire development strategy. Instead of an embedded computer the scope uses an off-the-shelf PC motherboard.
Revelation number two: why spend so much time and effort getting a cranky embedded RTOS and complete environment going? The Infiniium runs Windows, starting the scope app once the OS boots.
These two decisions cut man-years from the development process. Designers immediately jumped into the meat of the product, building hardware to suck in analog data at astounding rates, and writing code to display and interpret this data.
Recently I looked at their new MSO-X-3XXX series of scopes. These, too, run Windows.
I imagine Agilent sells thousands of these scopes each year. Not millions – it’s not a high volume product like a cell phone. The average price is many thousands of dollars, so there’s room to increase costs – some – to shorten development time. That PC motherboard is surely not the cheapest solution, but cutting man-years of effort saves money over the product’s entire lifecycle.
In my job as embedded gadfly I look into the workings of an awful lot of companies building products. A phenomenal number never balance the NRE (non-recurring engineering) versus cost of goods equation. The math is simple: if it costs X dollars to develop a product, and Y units are sold, then the engineering cost per unit is X/Y. It’s a cost that is as real as the price of the chips and resistors, the RTOS licensing fees and the plastic enclosure.
NRE is a cost that must be amortized over the product’s lifecycle. To do otherwise means one cannot make intelligent engineering tradeoffs. Spend half a mil on an ASIC and, if volumes are low, the per-unit cost of that chip is thousands of dollars. Does this make sense for your product? Add these thousands to the production cost of the product—is it still profitable? If not, you’re going broke.
(Of course, there are cases where other factors intrude—size, power, and the like may overwhelm simple cost drivers).
Maybe you really do need to design that 8051-based board, but sometimes it’s far cheaper, in the long run, to use a more expensive solution like a Basic Stamp, or an Atmel or Microchip evaluation board. In low volumes I betcha you can’t beat what initially might seem like the high prices of these done, tested, working-today solutions.
To design, debug, respin, retest, document, and productize a not-terribly complex PCB will cost at least $25k. $100k is not out of the question.
If size, power and other factors aren’t a huge issue, and if volumes are low, how can a responsible designer not pick a COTS solution?”
Now, here’s the connection to EDA360. Jack’s discussion of the development of Agilent’s Infiniium DSO reflects one approach to System Realization. Similar decisions are made all the time. Even in the SoC space, Realization teams must decide which processors, architectures, and operating systems they’ll use as foundation blocks for their architectural decisions. Will we use an ARM processor or an 8051? Will be use Android or an RTOS? Increasingly, and for smaller and smaller end products, ARM processors and the Android OS are becoming the choices for a variety of sound reasons. For access to a large development-tool ecosystem. To plug into a growing population of developers. To leverage existing code blocks and apps. Many of the refined technical arguments of the past about the feature superiority of one approach versus another fall by the wayside in the name of reducing development cost and cutting development time.
There was a time when it really was important to cut the area on a silicon die—every square mm was precious—and to slice every possible byte from the memory footprint. That’s when hardware was relatively expensive and engineering hours relatively cheap. That’s when time to market was measured in years not months, weeks, or even days. Not any more.
Jack’s essay on the development of Agilent’s Infiniium DSOs also applies to System Realization, SoC Realization, and Silicon Realization.
The Realization teams like the ones working on Agilent’s DSOs—the ones that realize how true engineering economics work today instead of how they might have worked ten or even five years ago—are the teams that will succeed in today’s market.
That’s the EDA360 Realization philosophy.
Note: I’ve used Agilent’s products as an example of the EDA360 realization philosophy before:
EDA360 Insider 