R&D ROI
Comment
KarlS
The tools are based on those used some 25 years ago and the approach has been to ...
Does EDA matter anymore?
Ron Collett
6/27/2011 5:30 PM EDT
Of course electronic design automation (EDA) matters! It's indispensible to chip design. However, the more important question is whether EDA is keeping pace with increasing IC design complexity. In most cases, the answer is no. Design complexity is increasing much faster than productivity. How do I know? Average development team size continues to grow.
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?
Ronald Collett is president & CEO of Numetrics Management Systems, Inc.
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?
Ronald Collett is president & CEO of Numetrics Management Systems, Inc.
|
|
|
|
|
Navigate to related information
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.
Sign in to Reply