Tuesday, November 3, 2009

#EDA and iPhone envy

The International Conference on Computer-Aided Design (ICCAD) is being held in San Jose this week. The program is predominantly geared toward presentations of academic research with relatively little industry representation, especially when compared to the (much larger) Design Automation Conference (DAC).

With the EDA sector still struggling to pull out of a six-quarter long decline in revenue, the ICCAD organizers broke from the academic theme in a session titled "What EDA Needs to Change for 2020 Success" - presented by industry veterans Jim Hogan and Paul McLellan, where industry analysts, bloggers and journalists were invited to participate.

Some of the topics put forth for discussion were:
  • What will be the silicon platform for complex chip design in the next decade?
  • Software signoff why do we need it?.....or do we?
  • Where is the highest value area for EDA vendors given the requirements of the electronic systems designer and platform provider?
The graphic above illustrates a prevalent view within EDA that growth will come from addressing the semiconductor design process at higher levels of abstraction; primarily system-level software models. One of the statistics put forth at the session was a claim that software now represents >50% of system-on-chip (SoC) design cost, leading to the (somewhat vague) notion of software signoff.

In my opinion, repeating the same EDA paradigm at yet another level is no solution for industry growth. At best, it can only help recover some of the lost revenue that will continue to result from pervasive commoditization of older generation tools. Where's the innovation?

EDA has for far too long reflected upon the success of logic synthesis, perhaps the last true innovation in design methodology, and searched in vain for a repeat performance - i.e. ESL or electronic system-level design. The real problem with this idea revealed itself only towards the closing part of the Q&A, in a perhaps rhetorical question: "how many EDA companies can handle total SoC integration?" The answer is none.

This is not to be taken entirely as a criticism of EDA. Only a company that actually does SoC design, such as Intel or Texas Instruments, is capable of developing comprehensive knowledge of the entire process. I have written before of the need for greater collaboration between EDA and semiconductor companies. However, EDA has made the problem worse by developing fragmented views developed within point tool silos, exacerbated by artificial barriers. There have been no shortage of abstraction levels developed for use in IC design flows. What is lacking is the 3rd axis for the chart above - the links across abstraction levels to connect the hierarchical SoC design process.

Here's one example. When the introduction of hardware-description languages (HDLs) enabled replacement of transistor-level simulation for logic, it took years to build links between the two levels of abstraction such as the IEEE 1364 Verilog PLI. Yet to this day, some vendors refuse to support VPI, offering only proprietary interfaces in an attempt to lock users into a single company's products.

There are numerous other examples where abstraction levels are, at best, poorly linked:
  • separate (and proprietary) physical databases for analog and digital flows
  • no closed loop between SPICE and analog behavioral abstraction, such as Verilog-A or MATLAB
  • lack of connection between design verification and ATE
The iPhone envy comes from the success of Apple's application store. For the first time in the cell phone market, software drove hardware sales. EDA is not alone in this envy, all of the wireless operators and cell phone manufacturers are jealous as well. But let's not be confused here. EDA does not serve the consumer market. EDA can serve the application software component of SoC design, but that is but one more link to be made with the rest of the flow. In and of itself, it is not the answer to turning around EDA.

We can see the problems in 2020 if we just look closer at the problems at hand today. Without breaking down barriers in the flow, in ten years they only get worse.

-Mike



3 comments:

Martin said...

Hi Mike,

Nice post! Good to see you wrote a blog on EDA and AMS again...I missed that a bit the last couple of months ;-)

Back to your topic. I fully agree with observations on the poorly linked abstraction levels and associated tools, which only handle a subset of the actual design problem. Clearly the view how to build a complete and consistent EDA/ESL eco-system is missing; anno 2009 we are still trying to glue point-tools together.

Here an additional observation: most of the languages you mention are developed in the pre-SoC era. I could even say they are all invented in the 80s and 90s and clearly offer insufficient 'hooks' to develop complex AMS SoCs.
Furthermore, they are all "point-languages" for algorithm, RTL, ESL, or Verification...so that will not help us either.

Would it be possible to define a modern language which covers HDL/HVL/ESL/SW/… aspects? If so, would it help to resolve the gaps in the flow and design abstractions?

Regards,
Martin

Mike Demler said...

Thanks Martin,

It's nice to be missed! :-)

Since I have not been employed in EDA for the last year, I have been working more in my other areas of interest. Thanks for continuing to follow, and your comments are much appreciated.

You make more excellent points. Obviously, I could have gone much further regarding disconnected point tools, and I am glad that you highlighted the plethora of disparate special-purpose languages.

Before EDA goes off to create yet-another abstraction level, I hope someone is listening. IBM presented their verification flow and methodology for an 8-core Power processor at ICCAD, and it was staggering. Same goes for an Intel presentation on their power management scheme that I saw at IDF. The complexity and effort required to develop solutions for these leading edge SoCs is so much more than any EDA company is prepared to address. The suggestion that creating another abstraction level is a solution is beyond me.

But then... my world is analog. ;-)

Kevin said...

Having designed the parts of Verilog-AMS that actually span the digital/analog divide (in the 90s), I can say I was not done as a "point language", and I had SoC in mind.

SystemVerilog on the other hand is a conglomeration of point languages (excluding analog) that only really addresses testbench level hardware verification issues.

After working on rev 2 of SV I was fairly convinced that it was not an ESL solution. I was also convinced that SystemC was sufficiently broken and ugly that it wasn't either.

I decided the solution to the problem was to extend C++ so that it has the same basic constructs as HDLs (Verilog/VHDL), and the right abstractions to handle AMS too.

So "yes": a modern language that covers HDL/HVL/ESL/SW (and AMS) is possible, and I have an alpha version of it. As a plus the extended C++ can be used for multi-core/distributed parallel programming too.

However, so far no-one I've talked to in EDA circles has shown much enthusiasm for my approach. Maybe it's too disruptive :-)