Lessons Learned from the 44th DAC
Gary Smith
Founder and Chief Analyst
GarySmithEDA
When I left the semiconductor industry to become an EDA analyst, I was struck by two things. The first was the professionalism of the PR firms handling the EDA accounts, and the second was DAC.
As a semiconductor executive I would have given my right arm for a conference like DAC. What we had to deal with was a hodgepodge of regional shows that sucked up time and resources with an often-questionable return on investment. (By the way, in those days regional meant, Chicago, Denver, Boston, Atlanta, and Dallas. Not the somewhat romantic trips to Paris, London, Tokyo and Hong Kong.) DAC, on the other hand, had become the linchpin of the design world. It was Christmas and New Years all rolled into one. For Christmas you received the new EDA tools needed to solve the problems generated by Moore's Law's merciless march. That was followed by the parties, the New Years part of DAC, which announced the beginning of another design year. Everyone was there: designers and CAD managers. And of course if you were an EDA vendor and not in the very early start-up stage, your absence from the exhibit floor was tantamount to saying that you were in the process of going out of business. It was an EDA marketing manager's dream. The conference set the rhythm of the EDA Industry.
Today, the entire EDA communications infrastructure is in question: EDA analysis, EDA coverage in the press, and even our conferences. At the 43rd DAC the air was filled with talk about the lack of commitment from the major vendors, especially Cadence, to the conference. There was the specter of all EDA vendors going out on their own. Those with the biggest marketing communications budget would win: often over those with the best tools. The most refreshing take-away from the 44th DAC is that the conference is doing quite well, thank you. Cadence had a significant presence and the other large EDA vendors showed no signs of abandoning the show floor.
Still we have other problems. Above all we are going through the ESL/DFM Inflection Point. I think we are handling DFM pretty well. Conversations have dissipated, if not disappeared, about how DFM is really a semiconductor equipment market sector, or possibly, a market to be served by mask making vendors. Speculation has subsided about the potential threat that the large Semiconductor IDMs or Consortia would enter the IC CAD market, and monopolize the research necessary to move to the next semiconductor manufacturing nodes. This fear has diminished especially following Cadence's new emphasis on DFM.
We have yet to solve the ESL problem. There was still the same lack of software engineers at the 44th DAC. Since most of the vendors on the exhibit floor sell to IC Designers, the lack of attendance by software engineers wasn't noticed that much. Still there was talk by the ESL vendors, targeting the software problem, of taking another look at the opportunity to exhibit at the Embedded Systems Conference. We cannot address hardware and software at separate venues: DAC is the proper place.
Keep in mind that there are three separate design groups now moving into ESL. The first group includes the SoC designers that are moving up from RTL to become System IC Designers. They go to DAC and they are fairly easy for EDA vendors to reach. Unfortunately this is also the smallest of the three groups totaling only 14% of the ESL seats. Fortunately they do have the highest Average Selling Price (ASP) so financially they represent a good market in spite of the group's size. System Design Engineers constitute the second group. This new group has evolved from the ranks of System Engineering. They do have an EDA connection, but it is generally with vendors of PCB tools, and DAC has almost completely dropped its technical coverage of PCB design. They comprise 33% of the market and their ASP is lower than that of the System IC Designer. The third group is the swing factor. They are the Embedded System Designers. They amount to 53% of the ESL seats; however, their low ASP is a problem and yet these are the attendees DAC needs to attract.
In many ways the highlights of the Technical Conference were a panel called "Corezilla: Build and Tame the multicore Beast" and a Special Session called Thousand-Core Chips. Both hit at the core (pun intended) of today's major design problem. Both concentrated on Embedded Software; in fact, when the moderator of the Thousand-Core session tried to get the panel to talk about the hardware design issues, the response was, "We know how to put 1,000 cores on a chip, we just don't know how to program them !" These are the types of sessions needed to attract software engineers to DAC.
DAC always makes you walk away with many impressions. Sometimes one stands out more than the others. Last year we were happy to hear that "It's the Software Stupid" resonated with many engineers. This year the one that stuck in my mind was a statement made during the Thousand-Core Chips panel by Professor Wen-mei Hwu from the University of Illinois at Urbana –Champaign. He said, "Threads are dead."
[Contacted by our editorial team Prof. Hwu clarified the statement as follows: "Threads are not suitable as a programming model to be used by average programmers. However, threads will likely continue to be well alive as implementation vehicles as long as they are not exposed to the typical programmer." Ed.]
For those that haven't been following the move to multicore and multi-processing there are two issues that affect the EDA community. First is the design issue; this year the cost of software development for a SoC is passing the cost of the actual IC design. This is actually a major opportunity for our industry as the designers are turning to the EDA vendors to solve the problem. But, to take advantage of this opportunity, EDA vendors must solve an implementation problem.
Design Cost by %HW and %SW
Source: Gary Smith EDA July 2007
At the 45nm silicon node we are seeing more and more designs reaching and exceeding the one hundred million gate mark. These designs are breaking the present IC CAD tools. In order to handle files of that magnitude the EDA vendors are being forced to develop tools capable of parallel processing. So far parallel processing has relied on threading. Unfortunately, unless you have an embarrassingly parallel problem, threading runs out of steam at four processors. Therefore vendors must investigate new methods for developing IC CAD tools. One possibility is to use API or library based programs. Replacing present algorithms with concurrent algorithms is another possibility. Some believe the final answer is replacing C with a concurrent language. Not having found a solution is a major factor in the inflection point that is affecting the IC CAD world.
Looking for a solution puts EDA software development on the leading edge of applications software development technology. We are developing some of the most sophisticated and performance-demanding applications in the world. Today that leading edge is shifting from the dominant Von Neumann computing model to multicore, multi-processing parallel computing. Highly specialized supercomputing is going mainstream and EDA is on the leading edge of that shift. The design community is looking to the EDA vendors to solve the Parallel Processing problem.
Considering all this, I started thinking that we may have a terminology problem. We've been talking about Embedded Software design. Actually the Embedded Systems Conference does an outstanding job of covering that topic. However, as the ESL vendors found out five or six years ago, the standard embedded design is a PC Board design that has a processor, possibly an FPGA and maybe a DSP on the board. That isn't the problem we are talking about. What we are trying to solve are parallel processing problems - the multicore, or really multi-processing general programming problem. Eighty percent of the embedded designers won't run into that problem. Perhaps the success of the DAC sessions was based on the fact they were named multicore sessions, not Embedded Software sessions.
The bottom line is that DAC must broaden its technical reach to include material that attracts the Systems/PCB Engineers and the programmers who have taken on the name of Software Engineers. These are the people attacking the concurrent software development challenge. This isn't just embedded software -- it's much bigger than that. This is software engineering and it includes everything from super-computers to cell phones. If you use multiple processors or multiple cores you face the same architectural and programming problems. EDA is gaining the concurrent software development expertise and hopefully coming up with the tools to address the concurrent software design challenge. DAC, as the conference for the Design Community, will be there to help lead the way.