So where does that put EDA? Perhaps the best place to look is the Design Automation Conference held a few weeks ago in San Diego. The venerable 48-year-old show played host to nearly 200 vendors, staged myriad panel sessions and technical papers, and attracted thousands of attendees. But as far as I could tell there were no earth-shattering tool breakthroughs portending to reverse the tide. Maybe you saw something I missed—let me know. Naturally, vendors announced plenty of new products, many of which will undoubtedly boost productivity. But none are likely to obviate the need for ever-larger teams, which is the current prescription for declining relative-productivity.

Engineers battling on design’s front lines know all too well that EDA advances aren’t keeping pace. But in many chip companies and businesses senior executives remain blind to it. A great many seem to be living in the past, neither seeing nor wanting to see that the tired strategy of just pushing the R&D organization a little harder won’t work.

Perhaps the situation is akin to the anecdote about the frog resting comfortably in a pot of cold water whose temperature gradually rises to a boil. The temperature climbs so slowly that the submerged amphibian never perceives the danger. The poor critter fails to jump out and is cooked to death. The story serves as a metaphor for what’s happening in the C-suites of many semiconductor companies and chip businesses. Their executives simply don’t perceive the danger. I’m not sure why, but perhaps they don’t want to hear that the water is getting very hot, so their trusted lieutenants don’t inform them? Maybe they hear but don’t want to acknowledge it? Maybe it’s a combination of the two? For whatever reason, many aren’t taking the necessary action.

I wouldn’t expect C-suite executives of large semiconductor organizations to see first-hand how challenging new product development has become. How can they? They’re busy running the company. Instead, they must rely on those under them. Only engineers and managers battling in the trenches truly see what’s happening. Enlightened executives foster cultures in which lieutenants are encouraged to speak up about hot water (and the limits of EDA)—and they’re heard. Other cultures, well, you know the story of the frog. Which one is yours?

Originally published at: http://www.eetimes.com/electronics-blogs/r-d-roi/4217278/Does-EDA-matter-anymore-#

Comments

KarlS

6/28/2011 5:45 PM EDT

The tools are based on those used some 25 years ago and the approach has been to just get a bigger hammer and hammer the HDL harder. HDLs are a description language based on the fact that logic can be described by a flow chart. So flow charting was used because programmers could follow the flows and do basic synthesis. Static timing analysis came along at about the same time so that functional(cycle accurate) simulation was used. But the process was modified to use HDL and timing simulation. I think that that was oversold so that it continues today. We just had a long discussion about which language really would be good for design. So far LabVIEW with hierarchical schematics which is based on a data flow programming language has a lot of traction. EDA that does not help the designer tie things together is not a tool — and we have too many of them floating around. The discussion is in the LinkedIn FPGA Group.

Related posts:

1. End of the Free Ride According to Pagemill Partners, a well-known Silicon Valley venture capital...

Related posts brought to you by Yet Another Related Posts Plugin.

In December, we were honored to participate in a Design & Reuse panel in Grenoble, France, titled “IP Reuse vs. IP Leverage: What’s the difference and what are the issues?”

Andrea Fortunato, our European director of professional services, represented us and gave an overview of the particular challenges that design reuse brings. He blogged about it right after the panel (Design Reuse: It’s Harder Than it Looks).

Our friends at D&R have just posted an audio Webinar of that panel. It’s definitely worth a listen if you’re designing with cores and trying to take advantage of reusability.

Have you had design reuse challenges recently? If so, feel free to comment on this post to let us know what they were and how you overcame them. Improving productivity in the semiconductor industry is a communal effort!

Related posts:

1. The Realities of IP Reuse Long touted as a silver bullet, IP reuse often...

Related posts brought to you by Yet Another Related Posts Plugin.

By Andrea Fortunato

How best can we leverage IP in an era of relentlessly increasing design complexity? That was the question on the table at this week’s IP-ESC 2009 conference here in Grenoble. I was honored to sit on a panel with Jasper Design Automation CEO Kathryn Kranen and Olivier Haller, who manages the design verification team in the Functional Verification Group at STMicroelectronics.

Our CEO, Ron Collett, described the IP situation in a post last week as the design reuse paradox, in that re-using IP is harder than it looks. In fact, there are dangerous consequences for any project leaders who think it’ll be a cakewalk.

During the panel this week, I made the point that most teams underestimate the complexity that the reused IP— adapting a particular block to a new context or adding particular features and then validating it—will add to their project.

This miscalculation is particularly dangerous for derivative designs, whereby the reuse level of their blocks is expected to be significantly high. Executive management loves derivative designs because they’re operating under the assumption that most of the work has already been done on the original design and the derivatives will be easier and deliver higher margin.

Truth and Consequences

But the reality is teams use ever-more IP blocks (including complete functions and sub-systems) on a chip. Underestimating the complexity at the block level is compounded at the chip level, and this creates unrealistic performance expectations from the development teams.

What happens?

• The project schedule slips

• Team members have to be pulled from other on-going projects to bring the project to closure, throwing the predictability of schedule in those other projects into doubt.

What are the consequences?

• The overall market window is reduced and peak time window for product introduction is reduced

• Development cost increases, exploding the project’s initial budget. ROI window is reduced

• Both time to market and ROI are affected!

The ripple effect of underestimating the effort needed to develop, integrate and validate the IP is far-reaching: The resource disruptions delay key projects because resources already involved on other developments are pulled in to salvage one development. The ripples turn into waves that slam the schedule and cause budget over-runs for the whole the project pipeline.

Remediation

There are two major ways to address this situation.

First, fact-based planning at the project’s outset helps avoid this turmoil. By measuring and quantifying project complexity and schedule risk, team leaders can see the gap that might result between their initial effort assumptions and the effort they’ll actually need based on the data. This helps them make fact-backed what-if staffing simulations and create aggressive—yet achievable—schedules.

Second, pick your design battles carefully. Analyzing projects in our extensive industry database, we see that best-in-class design teams show a lower amount of reuse than the average of their segment. This means that those best-in-class projects re-use IP where it is most appropriate to do so—for example in standard functions that don’t bring value add and real differentiation to the final product. But, best-in-class companies leverage their own innovation and fully engage their engineering resources in situations where the performances of specific functions are the key differentiating factors from the competition.

In the end, the key challenge for an IP user is :”Keep the ROI in the Product Development!”

(Andrea Fortunato is director of professional services for Numetrics, based in Grenoble).

Related posts:

1. The Realities of IP Reuse Long touted as a silver bullet, IP reuse often...

Related posts brought to you by Yet Another Related Posts Plugin.