System-level design is all about thinking early and implementing later. So why not apply what we already know? We even have statistics. Fifteen years ago, I was part of projects where we measured how effective methods like manual code inspection were in preventing bugs from propagating into the next project phase.
Everybody seems to know and agree that it becomes more difficult to find and fix defects the further a project has progressed. More recently, studies sponsored by NASA show that an embedded software bug introduced in the requirements phase is 130 times more expensive to fix during integration and 368 times more expensive after rollout of the embedded device.
From The Trenches
On a recent trip to Asia, a designer told me an interesting tale. The members of his team had completed a derivative design, adding more intellectual property (IP) to an existing chip targeted for a higher-performance range. They had used some Excel tables to assess performance, and everything looked fine. Two months prior to tapeout, they finally received a hardware prototype to bring up the software. Two months later, the software still did not work.
Fingers were pointed at the members of the software team. What was wrong with them? Why couldn’t they get the software to run? But then it turned out to be a fundamental flaw with the chip architecture. The project had to be reset. Of course, management wasn’t happy.
So what’s wrong with consumer electronic product design? Are we simply not disciplined enough to think first and implement later? It may well be a discipline issue, judging from some of the areas in which system-level design actually does work—the military! Together with aerospace applications, the military seems to have embraced system-level design better than other areas in electronic development. Taking the occasional mishap like flight 501 of Ariane 5 aside, this seems to work reasonably well.
For example, Lockheed Martin applied model-based design to the design of the F16 modular mission computer. More than 50% of the mission software is 100% automatically generated from xUML descriptions. This not only reduced the development cycle overall, it also produced higher-quality software with formal methods applied to the higher-level models.
Uncommon Wisdom
But the problem even runs deeper. There is a commercial issue as well. The value associated with tools to support system-level design is the reverse of what common wisdom dictates it should be. It hit me the other day over coffee with my first manager, who hired me to work in the U.S. more than 10 years ago. He had been a system-level veteran, but over the last 10 years he switched domains and was most recently responsible for product management of back-end layout products. So, he’s seen it all. And he stated it flat-out: System-level tools provide huge value because designers make huge decisions as they relate to architecture and functional partitioning.
These irreversible decisions largely determine project success or failure. Still, users aren’t willing to pay the price for those tools, or they often aren’t even willing to invest the time to use them. In contrast, two weeks to tapeout, a project manager easily will buy additional back-end tool licenses at a high price to save the project. I haven’t performed a detailed analysis, but from anecdotal evidence, the price issue definitely seems to be true.
The pricing of EDA tools seems to be much higher the closer a team is to silicon. I’m sure this isn’t for lack of trying to sell system-level tools at higher prices. The perceived value simply seems to be lower when it comes to tools supporting early design decisions, not even considering that the number of developers at that project stage is smaller.
Perhaps Colonel Nathan R. Jessep, Jack Nicholson’s character in A Few Good Men, is right when he yells “You can’t handle the truth!” Development discipline, which means holding off on implementation and spending more time up front in the design process, may well be one of the issues preventing system-level design from finding more widespread adoption.
It isn’t clear to me how painful the project failures have to be to change the minds of project managers. Certainly, the trend to put more functionality and differentiation into software has helped to delay the issue, as it allows designers to fix many defects even after hardware cannot be changed anymore. However, as the example of the project manager I met in Asia shows, even that temporary fix may not work much longer. Developers may have to become disciplined enough to adopt system-level design!