The app substitutes for the various paper, agendas and maps that you need to consult to find exhibitors, check up when sessions are and put them on your calendar. It’s not perfect (he ran out of time); for instance the booth numbers are not linked on the exhibitor map.

And yes, it’s only on iPhone so far, Android probably has to wait until DAC49.

At its heart, EDA360 is an acknowledgement that creating a chip from scratch is no longer the heart of electronic system design. Cadence describes this as chip design driven by apps (in the iStore sense). But I think really it is an acknowledgement that Software, IP integration and IP quality are the heart of designing a system today. Cadence has done a loud job of articulating this vision but in fact they have been behind both Mentor and Synopsys in terms of execution. Mentor is the only EDA company with a foot in the embedded world, they have the most successful high level synthesis in Catapult, they have FPGA synthesis and PCB tools. Synopsys has acquired a whole portfolio of IP, most recently including Virage, along with 3 virtual platform companies (Virtio, VaST and CoWare), high level synthesis (Synfora) and FPGA synthesis (Synplicity) to go along with their existing products in the IP and system space. Cadence has a lot less, and acquiring Denali for a ridiculous price is just a small piece of a solution.

But I don’t really understand the notion of “app driven design.” The further you get from the underlying silicon, the more independent the software is from the underlying hardware. Look how quickly apps written for iPhone can be moved to Android and Blackberry. Of course some apps require hardware support: you can’t do location-based services without some way to get the location, you can’t do a compass or even a clock in software only. The corollary is that the underlying hardware is almost completely independent of the apps, although it might be intimately bound up with lower levels of the operating system and communication stacks (think of power-down of the trasmit/receive function when a phone is not making a call).

At lunch for the press (broadly defined to also include everyone from Gary Smith to John Cooley to bloggers) John said that he’d flown to Europe last week sitting next to Aart de Geus. Now that would have been an interesting conversation to have eavesdropped on.

John is very enamored of the Google/Android business model as opposed to the Apple model because it allows hardware vendors to differentiate. But I actually think Google’s plan is to commoditize the hardware vendors in the same way as Microsoft commoditized the PC hardware vendors—the only people to make any real money in PCs were Microsoft themselves, and Intel who sold the one component not available from a wide range of suppliers. The Motorola Droid had some differentiation for a short time as the first Android handset, but now that many handsets are out there the carriers will play the suppliers off each other and I think that the carriers will be unable long-term to lock people into proprietary walled-garden style environments, which some are currently attempting. No user ever asked for differentiation in the form of being able to do less with their smartphone. Cost considerations and competitive pressure will eventually force the handset makers to ship the standard Google release of Android unchanged, and the carriers to accept it.

The Android business model is to go for market share by Google giving away Android and hoping to make the money back on search and advertising. Unlike Microsoft, Google doesn’t even bother to make money on the operating system and so even commoditizes that. In the meantime, Apple continues to make huge profits in the iPhone and iPad space, last time I looked almost 30% of the entire profit of the cell-phone industry and a huge percentage of the profit of the tablet industry. This is similar to how Apple is in the laptop business, where it has a relatively small market share by unit count but takes the lion’s share of the profits. Apple’s challenge is to keep forcing down the cost of the iPhone so that they can keep their price premium small enough that they have high margins without giving up too much market share.

My belief is actually that it is very hard to differentiate in silicon any more outside of the highest performance niche: high-end microprocessors and GPUs. The only purpose of an SoC is to run the software efficiently and provide the interfaces to the outside world (WiFi, Ethernet, Bluetooth, CDMA, GSM etc). Hardware has to be co-optimized with the software.

John also hinted at some sort of “app store” model for EDA connected in some way with cloud computing and SaaS. I’m not quite sure how this would work given the price point and the level of technical bandwidth needed to sell, let alone support, a leading edge EDA tool. It will be interesting to see, in any case.

The EDA360 vision is actually pretty close to a lot of the themes that I’ve talked about on this blog: the increasing irrelevance of chip design in the much bigger universe of electronic system design, the growing importance of software and so on.

For Cadence to move up to the system design level they lack a number of things. Firstly, they have no virtual platform technology to provide to the software developers. They do have high level synthesis, the CtoSilicon (curiously Synopsys is the one that doesn’t but I expect them to buy one of the existing companies, if not immediately then whenever it is clear who the winner in the space is). They don’t have FPGA synthesis, which is a problem since most designs are FPGAs. And they don’t have anything for the embedded software space. Of the big EDA companies, only Mentor has although they’ve struggled to grow it as much as they’d like.

Cadence also announced a couple of specific programs. The first is an attempt to plug the virtual palatform hole: a partnership with Wind River around Simics (the software from Virtutech that Intel/Wind River acquired earlier this year). If that’s Cadence’s strategy I’m not sure why they didn’t buy Virtutech (reputedly they tried to by CoWare for nearly $100M and Virtutech sold for only $45M).

The other thing they announced was the Cadence Verification Computing Platform. I’m not 100% sure what this is. I think it is the latest product in the Quickturn line of accelerators and there was certainly an impressive looking box among the wine and appetizers. But in an attempt to position this as the second significant step in EDA360 they layered it with so much marketing smoke that you couldn’t see through to the mirrors.

EDA360 is a four-legged stool. The basic premise is that there is a tectonic shift going on in the semiconductor industry. Instead of just delivering systems they need to deliver a complete value stack with a lot of software too. I still think that one of the big challenges there is that semiconductor companies only know how to sell margined up square metres of silicon, and treat software as a marketing expense. That was fine when there was only a bit of it, but when there is more engineering effort in the software than the chip, and a lot of the differentiation is in the software then this is inappropriate. So leg number one of EDA360 is that there needs to be a shift towards focusing semiconductor companies more on integrating hardware and software IP, and less on design creation, in order to get their profitability up.

The second leg is application-driven system realization. I think this is close to what I call software signoff. Instead of developing a chip and then worrying about writing some software to run on it, conceptually it is the other way around. The software comes first and the only purpose of the hardware (which may or may not be a chip) is to run it fast enough, and at low enough power, and provide the required interfaces to the outside world (wireless, 3G, optical etc). From a practical point of view, though, it is not enough just to provide the hardware since a lot of software may well be provided by the end-user. So the software ecosystem must be fed with drivers, development kits, simulators and so on. Think of what Apple provides for iPhone developers.

The third leg is software-aware SoC realization. I think this is really a subset of the second leg for designs where the system is actually (mostly anyway) a single chip. SoC design, of course, is Cadence’s comfort zone. But tying into software really increases the importance of transaction-level modeling, virtual platforms, and generally realizing that the software is often master over the chip design requirements.

The fourth and final leg of the EDA360 stool is silicon realization. This needs to be made more efficient by pushing up the level of abstraction, building appropriate links up to the software world (especially for power consideration) and so on. This is sustaining and updating the existing product line in a way that Cadence would have had to do anyway.

I think Cadence is trying to go in the right direction and it will be interesting to see what specific things they do to flesh out the vision with real products. One of the big challenges is that their focus and revenue comes mostly from IC design, moving up into the system space is disruptive (in the Innovator’s Dilemma sense). I think success would be when Cadence is making serious money selling to people who do no chip design, just build systems with FPGAs, boards and standard products (plus lots of software). The challenges are largely on the business side rather than the technology side. As the old joke about a guy asking for directions in rural Ireland goes, “If I were you, I wouldn’t start from here.” It’s not clear whether Cadence’s IC heritage is the right base upon which to build this vision.

Magma have kept this development insulated from their general turmoil over the last couple of years. A year ago Magma seemed like it was coughing up blood and might not recover. Now they are clearly back. Rajeev apparently asked lots of CEOs of other companies how to cope with the downturn. “Slash R&D until the recovery comes and milk the existing products.” I’m not sure that ever works in EDA where the next process is coming down the track anyway, and Rajeev wisely ignored the advice, if anything doubling down on R&D since the stock market couldn’t punish him any more anyway.

It is always interesting watching established EDA companies bring completely new products to market. Far fewer of them are successful than you would expect. I think this is primarily due to the risk-averseness of their sales forces who make most of their money re-selling the same tools as last time and don’t want to risk delaying the renewal by introducing untried new products into the mix. This makes it impossible to mature the product and means it will die on the vine. In fact the only completely new products that I can think of that you would call successful are Calibre from Mentor, FineSim from Magma and, perhaps, PrimeTime from Synopsys (although they cheated there by buying Viewlogic and then shutting down Motive, the then market leader). All other products were either developed when the company was a startup (most notably Design Compiler and Magma’s original BlastFusion), came through acquisition, or were/are only marginally successful.

PrimeTime is now about 15 years old and so is perhaps vulnerable. Its basic architecture seems to make it hard to keep its performance in the top rank. Back then a full analysis was about 1 million instances and four process corners. Now a full analysis is about 50-100 million instances and 400 process ‘corners.’ The only way to do this with PrimeTime is to set up a huge farm and run lots of jobs in parallel on dozens of licenses. For example, one run of just 1.3M cells in 3 modes with 9 process corners (so 27 scenarios) required 27 machines and 65 minutes to do the analysis.

Tekton can apparently (and remember I was having lunch with the marketing guy not a hands-on user) do everything on a single 4 CPU machine in less than 30 minutes, and do a crosstalk analysis on the side. If these sorts of numbers hold up across the board, and if the correlation with PrimeTime (still the signoff standard) is nearly perfect then this will be an interesting battle to watch. Even though the product is only just being announced, Magma have already closed some customers and have several other high-profile evaluations in progress.

John Cooley managed to find some rumors about Tekton, including the product name, and correctly surmised that Magma would announce it at Music, their users conference, taking place this week.

Going forward, of course, Magma will be integrating the Tekton timing engine into their other timing-driven tools, such as Talus, to replace the older engine. This should speed up their other tools and also keep them on the capacity ramp necessary to handle sub 30nm designs.

The takeaway is that Tekton can time any design on a single machine in under an hour with just a single license. I think PrimeTime does over $100M in business so there is plenty of upside available for Magma to steal if the technology is as good as described. Let the battle begin.

I was talking to an architect yesterday evening who was familiar with AutoCAD ($3K/seat!) for 3D design and she was asking how similar that was to IC design.

The usual analogy I use for designing an integrated circuit is that it is like designing the Boeing 787 except doing it in 12 months using a manufacturing technology that has never been used before, on a design system that has never been used in production for that manufacturing technology. And by designing a 787 I mean all the parts, every part of every jet engine, every part of every seat, pump and instrument.

Of course some subassemblies might have been used before, such as the seats or the fuel-gauge (hey, IP-based design). But most things, such as the landing-gear, will need at least some change. Actually in terms of the count of parts this is underestimating things but it’s not quite fair to compare a complex turbine blade with a single transistor and count both as one part.

But here’s the thing I thought of last night that I’ve never articulated before. Having designed the 787 on the computer, you press a button and an amazing automated assembly plant take a couple of months to manufacture one. And then you put it on the end of the runway, put the throttles up to full and expect it to take off first time, using engines that have never run before and flight surfaces that have never flown before. Which it had better do, since it is already scheduled to come into service in November ready for the holiday market.

Then, unlike Boeing, the plane will be obsolete in 6 or 12 months. Next Christmas the 797 will be required, even bigger and more complex. But it will need to fly first time too.

Optimization means that your tool produces a better result than alternatives. A place and route tool that produces smaller designs. A synthesis tool that produces less negative slack. A power-reduction tool that reduces power. This is the most compelling value proposition you can have since the result from using your tool as opposed to sticking with the status quo shows through in the final chip affecting its price, performance or power. The higher the volume the chip is expected to run at, the higher the value of optimizing it.

Productivity means that your tool produces an equivalent result to the alternatives but does it in less time. My experience is that this is an incredibly difficult value proposition to sell unless the productivity difference is so large that it is a qualitative change: 10X not just 50% better. Users are risk-averse and just won’t move if they have “predictable pain.” It may take an extra week or an extra engineer, but it is predictable and the problem is understood and well-controlled. A new tool might fail, causing unpredictable pain, and so the productivity gain needs to be enormous to get interest. Otherwise the least risky approach is to spend the extra money on schedule or manpower to buy predictability.

The third value proposition is that you get the same result in the same time but the tool is cheaper. For something mission-critical this is just not a very interesting value proposition, sort of like being a discount heart surgeon. Only for very mature product spaces where testing is easy is price really a driver: Verilog simulation for example. The only product I can think of that strongly used price as its competitive edge was the original ModelSim VHDL simulator, and even then it was probably simply the best simulator and the low price simply left money on the table.

Another dimension of value proposition is whether the tool is must-have or nice-to-have. By must-have I don’t mean that customers must buy your tool (nice work if you can get it) but that they must buy either from you or one of your competitors or roll their own. Nice-to-have means that a chip can be designed without a tool in that space, doing stuff by hand, creating custom scripts, having a longer schedule or whatever. It is almost impossible to build a big business on a nice-to-have tool.

Moore’s law makes must-have a moving target. Signal integrity analysis ten years ago was, perhaps, nice-to-have. Then for designers in leading edge processes it became must-have. Eventually the technology got rolled into place and route tools since everybody needed it.

That is actually a fairly typical route for technology. Some new wrinkle comes on the scene and somebody creates a verification tool to detect the handful of fatal wrinkles that can then be fixed by hand. A couple of process generations later, there are 100,000 fatal wrinkles being detected and so it is no longer adequate to have just a verification tool. It becomes necessary to build at least some wrinkle avoidance into the creation tools so that fatal wrinkles are not created, or are only created in manageable numbers again. So the tool goes from nice-to-have, to must-have to incorporated into the main flow.

First, note that this is not just about designing integrated circuits. It’s about the big strategic issue of how you design products. Those of us in EDA think that it is a fascinating industry with a strange combination of deep technology and a sufficiently large market to be an interesting business. As opposed to, say, TCAD, the software used to design semiconductor processes and develop process models without building silicon. I mean I’m sure it’s interesting and there’s a market but it’s not EDA. It is a market of 5 PhDs in each fab in the world or about $20M/year.  Certainly necessary but not at the top of anyone’s list of problems on any given day.

Unfortunately, how we view TCAD is how the rest of the world views EDA: an esoteric geeky thing that some people need to get their job done but it’s not solving the real business problem. Rocket science for rocket scientists.

There were always rumors that Cadence or Synopsys would buy Wind River, the leader in embedded operating systems and tools for embedded software development. I’m pretty sure discussions took place but obviously no deal was ever done and Intel bought them recently (as an interesting aside, that means that the PowerPC guys, primarily Freescale, are largely dependent on Intel for their RTOS and tools). So Wind River is on the verge of becoming Intel’s captive embedded software capability. However, EDA companies thinking about acquiring Wind River was at least thinking in the right kind of way. How does the E get dropped from EDA? How does it just become Design Automation, encompassing everything from software to silicon, boards, packages, supply-chain management. In short, how does EDA achieve the Sony vision of inventing products and then implementing them using automated processes.

How many people in EDA know what a BOM is? It is a bill of materials, a list including the price, of every component in a product. In most consumer industries, design is getting the BOM right because otherwise the product cannot be built for a price that the market will support. Design costs figure into the equation to some extent, but in the end for a volume product the final price of all the components is what matters. DA without the E is at least somewhat about BOM optimization.

RIM, the Canadian company that sells Blackberry, didn’t actually design it. I don’t know the details but I assume they came up with the basic concept and presumably wrote a lot of the higher-level software, both on the phone and on the server systems that implement the push mail. But then they used an “automated process” to get the guts designed. They subcontracted it to TTPcom in Cambridge England who put a lot of experts in software and phone design on the job. They wrote all the Verilog, and the call processing stack and designed the radio. RIM stayed focused on the user experience and how to deliver that in software applications.

But that’s not the true “automated process” Sony wants to have access to.

The transistor layout level is really about the interface between EDA and semiconductor process. There are two things that make it a challenge. One is the changes in lithography which have complex effects on what can and cannot be put on a mask in a form that will print. The second is that EDA largely operates with a pass/fail model, whereas process is actually statistical. It is like the way we regard signals as digital, which works most of the time except occasionally the analog nature of signals breaks through when a signal changes too slowly or some other unusual effect causes the illusion to break down.

The architectural level is where chips and software intersect. Chip design people tend to think of the architectural level as somewhere that the system designers make a start on chip design. But a better way is to think of the software as a specification of the system and the only purpose of the chip is to run the software. Why would you not just run code on one of the on-chip microprocessors? Only for 3 reasons: to do so would be too slow, to do so would consume too much power, or you can’t do it in software without a special peripheral (for example, analog). Increasingly SoCs are processors, buses and memory, along with specialized IP blocks (which may themselves contain processors) for performance, power or analog reasons.

The big challenge in a system like that is getting the software right. I keep waiting for the virtual platform concept to really take off, since I’m convinced it is a better way to do development. Look at all the complaints about inaccuracy in the iPhone simulator (since it just cross-compiles) or the difficulty of doing performance analysis since you need to do it on the real phone. SoCs are much more complicated since typically they have multiple processors with different architectures since code running on (say) a Tensilica or ARC processor optimized for audio processing has very different characteristics from running the same code on an embedded PowerPC.

But the block diagram of the virtual platform is actually the chip specification as well.

I think that moving up to the architectural level should focus on this virtual platform level. Like Goldilock’s porridge, it is just right. It contains just the right amount of detail. By using the platform to run code, the software development can be done much more productively. By using the virtual platform as a specification on how to integrate all the processors and IP, the chip can be created. It is like using RTL but at a much higher level. With RTL we can simulate it to get the chip functionality right, and we can use it as an input to a (fairly) automatic process to create the silicon. The virtual platform has the potential to play this role.

That would mean that the architectural virtual platform level would become a handoff between the engineers creating the systems and the lower level implementation. With synthesis timing was the unifying thread across the handoff; with this sort of architectural handoff it is communication within the software, which interacts with timing, functionality and power, of course, making it possible to optimize the SoC implementation.

People looking at ESL only as behavioral synthesis I think are missing the point. It is like software engineers arguing about details of language syntax. The hard problems are all about writing large scale software or integrating dozens (or even hundreds) of IP blocks quickly and getting the software working. Yes, behavioral synthesis has its place as the ultimate in “inlining” functions with extremely high performance and low power, just as in the software world people occasionally hand craft assembly code and sometimes measure cache hit-rates.

As Yoshihito Kondo, general manager of Sony’s design platform division said, "We don’t want our engineers writing Verilog, we want them inventing concepts and transferring them into silicon and software using automated processes."

That one sentence is a vision for what EDA should aim to become.

I had lunch last week with Mark Gogolowski and I asked him how the party came about. It started 11 years ago in 1999 at DAC in New Orleans. Denali wanted to have a party for their customers, but they faced a couple of constraints. They couldn’t compete with the big Cadence and Synopsys parties of that era, but on the other hand they knew that parties weren’t much fun unless they felt crowded. So they’d better invite more than just their (few) customers, especially since they needed to partner with all the simulation vendors, which meant all the big guys anyway. So invite everyone. Denali was under 10 employees in this era, not well-known, so they were more worried about holding a party and nobody coming than the opposite. But never underestimate the gravitational attraction of an open bar.

They expected about 100, maybe 150 people, would attend. One thing that they hadn’t anticipated was that the AEs from the big guys weren’t able to get into their own parties (the execs and sales guys went with their customers; AEs need not apply). So they showed up in large numbers. In the end well over 500 people came for at least some of the evening. At midnight the venue management told them they had to stop the party since the entire night’s alcohol budget was already gone. So they gulped, wrote a large check, and kept the party going for another hour. Shutting down a party as early as midnight in New Orleans and throwing their customers out didn’t laissez les bons temps roulez.

They realized that the party had been something special, and not just for their customers. The entire EDA community had shown up since Denali was neutral ground. Nobody from Cadence went to the Synopsys party and vice versa. But Denali, as the Switzerland of EDA, welcomed everyone. So next year, it seemed like it would be a good idea to do it again. And so it has been for many years.

I think it has turned out, somewhat fortuitously, to have been a great way to market themselves. We are in an era when it is really hard to get your name out in front of customers and partners. Denali doesn’t have that problem, plus it has a lot of goodwill from the entire EDA community since the Denali party isn’t exclusive. You don’t have to be a customer of Denali to get in; you can even be a competitor.

EDA idol is back again this year, along with a new “Community Superhero” contest. Another new thing this year is that they will be presenting an award for “EDA’s Next Top Blogger.” Of course, I have my own idea of who that should be. When I know how you can vote I’ll let you know!

So here we are a decade later. Everyone knows who Denali is, and they are a much bigger company now. They are still private, so just how big is largely a guess. But nobody cares about their revenue, the financial answer everyone wants to know is “how much does the Denali party cost?” I slipped a shot of vodka into Mark’s Diet Coke but he still wasn’t talking.

This year’s party is on Tuesday 28th July at Ruby Skye, 420 Mason Street. If you want to go you need to go here to pre-register. You won’t get in if you just show up at the door. A word of warning to out-of-towners looking at maps: there are two widely-separated Mason Streets in San Francisco. If you go to Marina Green you’ll have a nice walk but you won’t find any party.

Most of these problems are not directly with the license key manager (the most common, almost universal, one is FlexLM). Sometimes there are direct issues because customers want to run a single license server for all the EDA tools they have from all their vendors, something that the individual EDA companies have a hard time testing since they don’t have access to everyone else’s tools. More often license problems are simply because licenses are much more complicated than most people realize.

All sorts of license problems can occur, but here is a typical one. The customer wants some capability and discusses with the salesperson who provides a quote for a particular configuration. Eventually an order gets placed and a license key is cut for that configuration. At this point, and only then, it turns out that the configuration doesn’t actually deliver the capability that the customer thought he’d asked for, and that the salesperson thought she’d provided. Something is missing. The customer calls support to either to report a bug or, if they realize what is going on, to try and get the specific license added. Often an option has been omitted from the configuration (such as a special parser) that everyone assumed was included, or assumed that it wasn’t needed, or that turned out to be bundled with some other capability in a mysterious way.

Digital Equipment, in the heyday of the Vax, actually had an AI program XCON salespeople had to use to configure Vax computers since otherwise they always had similar problems, although in the hardware domain. The order omitted a required cable, or overloaded a power supply or left out a software driver. Without this error being corrected, the delivered system could not be assembled in a way that would run. This is worse still in the hardware world since it takes from a couple of days to a couple of weeks to get a missing cable to the customer site. It can’t simply be fixed over the phone.

The fundamental problem is that it is hard to map capabilities that marketing wants to sell and price, into the actual control points in the software that permit or deny certain activities, and the ways in which the different components interact. Few people have a good understanding of this, and there is no correct answer to many of the questions.

Here’s an example. Should a long-running tool claim a license when it starts for an optional feature that might be required later? Or should it wait until it has run for hours and then fail if a license is not then available? Which inconveniences the user less? There are pressures on the vendor side to want to claim licenses as early as possible (so the customer needs to buy more licenses) which at least means that if a tool is going to fail due to lack of licenses, it does so immediately without having done a lot of wasted work, and in a part of the code where it is easy to handle. There are pressures from the customer side to want to claim licenses as late as possible (so they don’t get held for long periods when they are not being truly used) but also to expect that the tool will behave gracefully when their paucity of licenses comes to light and the run is deep in the innards of the tool when it finds out it cannot continue.

Interactive tools are worse still. Do you claim a license in order to show the capability on a menu? Or do you show a menu item that may fail due to lack of a license when you click it? Do you behave the same if the customer has licenses but all are currently in use, versus the customer not having any licenses to that product at all?

None of these problems typically affect the engineers developing the product or their AEs. Usually all employees have a “run anything” license. The licenses issues often only come to light when customers run into problems. After all, they may be the only site in the world running that particular configuration. Some testing can be done easily, but exhaustive testing is obviously impossible.

EDA companies want to create incremental revenue for new capabilities, so they don’t want to simply give them to all existing customers even though they may want to make sure that all new customers are “up to date.” This drives an explosion of license options that sometimes interact in ways that nobody has thought of.

Until some poor engineer, in the middle of the night, tries to simulate a design containing two ARM processors. That’s when they discover that nobody thought about whether two ARM simulations should require two licenses or one. The code claims another license every time an ARM model is loaded, in effect it says two. Marketing hadn’t considered the issue. Sales assured the customer that one license would be enough without asking anyone. Nobody had ever tried it before. “Hello, support?”