Get email delivery of the Cadence blog featured here
Iqbal Arshad, corporate vice president of innovation
products at Motorola, slept in his office many nights when his team was
designing the Motorola
Droid smartphone. If he had had better tool support for system-level power
management, driver development, system integration, and software-defined
hardware development, maybe he could have slept at home.
Arshad spoke Thursday, June 17 at the Design Automation
Conference, and delivered one of the most riveting keynote speeches I've heard.
He not only provided an inside look at the design of the Droid; he spoke
eloquently about design challenges and frustrations, and called on the EDA
community to take notice and find a new approach.
"I don't think we need more tools for component automation,"
Arshad said. "I think the answer is something different - something we can
think about and all do as a community." Probably without realizing it, he went
on to describe some of the key points in the recent EDA360 vision paper, and called for
the kind of new thinking and collaboration that paper advocates.
A Bold Leap For
I'll skip over Arshad's comments about specifications and
features of the Droid, because you can get most of that on line. Suffice to say
it's a next-generation smartphone, a competitor to the iPhone, that's based on
the open-source Android platform. As Arshad frequently emphasized, it is not a
"mobile phone" so much as a platform for embedded computing and an ever-growing
number of applications, or "apps."
With the Droid, Motorola transitioned from being a "feature
phone" provider to a smartphone developer. To build the Droid, Motorola needed a
different core platform with different materials, components, tools and
methodologies than the company had used previously. That required a complex supply
and manufacturing chain. It was a "clean slate" effort "started from the ground
up," as Arshad said.
To add to the challenge, the Droid had to be produced in a
matter of months, not years. He commented later that the hardware team was of
"average" size and that the software team consumed most of the resources. "The
way we did it is good old engineering," Arshad said. "We did not have all the
automation tools we could have wished for."
What Didn't Work
Arshad said that Motorola had some good success with
customized simulation tools that looked at mechanical integrity, strain, and
thermal effects. But his discussion about what didn't work well was much
longer. One overriding problem is that no tools today comprehend an entire
"system." And as Arshad noted, "the system is not a chip, the system is the
product the end customer uses."
"There is no tool today that can do effective power
management for the entire product," Arshad said. "SoC suppliers think power
management is contained within their solutions. Nobody has a clue into what matters
to the end user - whether they can use their phones without recharging for a
couple of days. We had to come up with a proprietary setup just to measure
Arshad spoke with emotion about driver development. "We have
to rewrite every driver!" he said. "When we try to verify them on our board,
the logging is poor, we have to put specialized pokes into the code, and
there's interaction with system and timing issues. It literally costs millions
of dollars. It's a debugging nightmare." Then came the stories about nights
spent in the office.
Another problem is prototype development. "Everybody on our
team needs a prototype," he said. "It's so expensive to build these things when
it's not in a manufacturing state. I can tell you emphatically, if you design a
new chip or processor, it takes six extra months because you have to put it all
together." Not only is prototyping a "nightmare," but system integration is "a
trial and error thing," Arshad said.
Collaborate for a
Arshad's suggestion is to "think of the system as the end
product." He suggested a software layer he called a "universal device
management interface." This is a software protocol that will extract hardware
properties and provide standardized communication between the system software
and the hardware resources.
"If you have a framework all the vendors can implement, you
can have a unified debug and timing system," he said. "Think! This is a huge
opportunity! This is the kind of intelligent system we need to leapfrog embedded
computing. The other advantage is that you have a totally software-defined
hardware system. If I had had this with the Droid I wouldn't have had to sleep
in my office."
Then came a warning. If the EDA industry does not
collaborate to provide better support for embedded computing, "companies will
move forward on their own and create proprietary systems. And I think
proprietary systems hinder progress."
Which Direction Now?
We would do well to heed Arshad's warning. The EDA industry
cannot continue "business as usual" and thrive and grow as an independent
industry. The EDA360 paper describes an approach that starts with the
application instead of the silicon, and then constructs the optimal
hardware/software platform for the application. Any and all other thoughts are
welcome - but it's time to answer the Droid's "wake up call" and start the
Arshad's comments on the software/hardware relationship implies the need to evaluate options for software or hardware implementation during system design. This complements Gary Smith's latest presentation (see my comments on that). In the bigger picture with all possible Android-based systems, not just smartphones but things like smart appliances, there may be situations where certain functions will need to be supported in SoC hardware if software performance lags in middleware, and vice-versa. New EDA tools will be needed to carry out that sort of analysis. Right now, in nearly every ESL tool, evaluation is limited to hardware.
The video of the talk is available at: