Move up to software

I gave a dinner keynote at the Electronic Design Process 2009 meeting in Monterey last week. However, I’d already made the mistake of giving the secret recipe for any keynote speech (and, by way of confirmation, I received an email from Aart assuring me that his keynotes had rigorously followed the outline for the last fifteen years!). I would have to come up with something different.

So this is my current keynote. I focused on what I thought were the four big opportunities right now. In fact, in a funny sort of way, they are different facets of the same opportunity.

The first is that semiconductor companies now ship a lot of software along with their silicon, but by and large have not found a way to turn that into premium margins. They still ship margined up silicon and regard software as a marketing expense that is required to be in place for anyone to buy it. Semiconductor companies now have more software engineers than design engineers so this is backwards. It is the silicon that has little value and should be thrown into the deal.

The second opportunity is what I call “Coore’s law.” Just as with Moore’s law described how the number of components on a chip was increasing exponentially, the number of cores on a chip is increasing exponentially. We are still at the fairly flat part of the curve so it’s not that obvious yet. But, as I’ve said elsewhere, the semiconductor industry has taken their power problem and dumped it on the software industry in the form of multi-core. But they completely underestimated the impossibility of software solving this problem in a reasonable timeframe, and some people contend it will never be solved (the existence of our brains as a counter-example notwithstanding).  And that is for new code written in new languages with new tools. Most code is legacy code, and legacy code is often what I’ve heard called “stiff ware.” Technically it is software and malleable. In practice, nobody understands it well enough to make extensive changes (and in the worst cases, not all the source code has been properly preserved). Anyway, incremental improvements to solving the multicore challenge are the next opportunity.

The third opportunity is that EDA business models (sell lots of expensive licenses) don’t scale into the software world, or even the ESL world for that matter. In the same way, IBM had to learn the hard way that mainframe business models don’t scale into the world with ubiquitous computing and ubiquitous networking. A lot of ESL has the problem of “Intel only needs one copy” and the software world suffers from open source killing innovation. Open source is clearly the most effective approach to software development, but it does best at copying things and has a poor track record of true innovation (if you are writing for yourself or copying, then the spec is easy). The obvious analogy here is with music. There will never be another Michael Jackson (and there’s some upside to that too, of course) and Thriller will forever be the best selling album. Nobody will make serious money selling music  itself and they can only make money by selling stuff associated with music that is harder to copy: clothing, concert performances and so on. In just the same way, hardware companies ride on products like Linux, recovering any development they do for the community (if any) through their hardware margin. Nonetheless, the opportunity is to move EDA from just plain IC design up to these higher levels and find a business model that makes it work.

Finally, the fourth opportunity is to look still further afield and take in the entire design process, in a similar way as PLM companies like IBM, PTC and Dassault do for mechanical, but with considerably less technology on the design side. Take the “E” out of “EDA”. By taking the entire design problem, the business model issues associated with software might be side-stepped. And all four challenges are really about software.

In summary, the challenge is to expand from EDA as IC design (which is the most complex and highest priced part of the market) to design in general, in particular to take in the growing software component of electronic systems. It’s a technology problem for multicore, but most of the rest is a business challenge

This entry was posted in methodology. Bookmark the permalink.

Comments are closed.