will be under maintenance from Friday, Oct. 3rd at 6pm (PST) thru Sunday, Oct 5th at 11pm (PST). login, registration, community posting and commenting functionalities will be disabled.
Home > Community > Blogs > Industry Insights > dac keynote 3 eda gets wake up call from motorola droid
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Industry Insights blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

DAC Keynote 3: EDA Gets Wake-Up Call From Motorola Droid

Comments(2)Filed under: Industry Insights, DAC, EDA360, Motorola, Droid, Android, Arshad

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 Motorola

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 those things."

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 Better Solution

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 discussion.

Richard Goering




By Jason on June 18, 2010
The video of the talk is available at:

By Gary Dare on June 20, 2010
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.

Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.