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.

Then Wally told me,  “I immediately sent a copy to Carl Icahn.” So the EDAgraffiti book is up there with poison pills and the rest as an anti-takeover device!

To get your own copy, just click on “book” at the top of the page.

I met with Bob Smith of Magma late last year, and coincidentally I ran into Hamid Savoj, the CTO, at a conference on 3D chips a few days later. They have successfully done one of these changing the wheels without stopping exercises recently.

Magma’s engineering team have swapped out the old timing and extraction engines from Talus and replacing them with the Tekton timing engine and the QCP extraction engine to create Talus Vortex 1.2. This can place and route over one million cells per day with all the modern requirements for crosstalk, metal migration, multi-corner etc. It can handle up to 3M cells flat, which is important since probably one of the biggest wishes of the semiconductor customers is to be able to handle designs flat, or with as little hierarchy as they can get away with. Ideally today they would like to be able to handle 20 million cells or more flat. All hierarchy added in any design tool due to capacity limitations of the tool tends to cause design efficiency to drop, sometimes dramatically if the number of blocks grows large. But wait, there’s more, as the old ads say.

Along  with some further infrastructure work they have also created Talus Vortex FX which is the first distributed place and route solution. This pushes up the performance to over 3 million cells per day, and the capacity up above 8 million cells, which more than triples designer productivity. It analyzes the design, then partitions it into pieces that can be processed separately on their own server, and then eventually combines all the results back together (they call this Smart Sync). Some design tools are fairly easy to distribute (for example, DRC can be run on different parts of the chip in parallel and then stitched back together), some are very difficult (simulation, because there is a single global time-base so it is hard to find things that are independent) and some in between like place and route, although clever algorithms are needed to decide how to divide up the design amongst the computing resources.

As an irrelevant aside, in 1952 a car was driven across the US and back without stopping; of course it needed to have facilities to change a wheel without stopping. It can be seen today in the San Diego Automotive Museum.

I got two things wrong, that I’d like to correct here. The first goes back a long way to the mergers of Virtutech, VaST and CoWare when I listed the other virtual platform companies that are still independent. I omitted Carbon since I didn’t actually realize they had acquired the virtual platform technology SOCdesigner from ARM when they did the deal to take responsibility for creating and selling ARM’s cycle accurate models.

SOCdesigner was originally a product from a company called Axys, based in southern California. I believe that they had technology pretty similar to VaST at the time, but it was hard to know since they were very secretive. Despite rules against doing so they would throw us out of their presentations at DAC and ESC (so we sent over our finance person to see what she could find out…but they even spotted her). ARM acquired Axys, which I never understood the reason for. Even ARM- based designs typically involve lots of models not from ARM, so it never seemed likely that ARM would be able to make SOCdesigner a successful standalone business, it seemed like a business for someone independent of the processor companies. After all, you can’t imagine MIPS putting much effort in to make their models run cleanly in SOCdesigner. At VaST we considered it less of a threat post-acquisition than before.

Anyway, Carbon got SOCdesigner (still called SOCdesigner) and used their own technology for turning RTL into fast C-based cycle accurate models to solve another problem ARM had, namely the cost of creating, maintaining and distributing cycle-accurate models. ARM had always had fast models of their processors and many peripherals, since that is what software developers required, and these are relatively cheap to produce (they only need to be functionally accurate so there are many corners that can be cut, for instance it is not usually necessary to model the cache or branch prediction since the only difference is the number of cycles used).

The second error was that I didn’t really realize that in the Carbon world there are now 3 speeds of models. RTL, cycle-accurate models, and fast models.

RTL models aren’t really in the Carbon world, actually. But cycle-accurate models are automatically generated from the RTL which means that they are correct by construction. These models are not fast enough for software development, and in fact it is impossible to create models that are fast enough for software development and simultaneously accurate enough for SoC development. However, given their RTL provenance they tie the software and the SoC design together accurately, which is really important because increasingly it is only possible to validate the software against the hardware and vice versa.

Fast models usually either come from the vendor of the processor or IP, or are created by the end-user. Processor models are not actually models in the usual sense of the word, they are actually just-in-time (JIT) compilers under the hood, converting instruction sequences from ARM, MIPS or whatever instructions into x86 instructions that run a full native speed. Fast peripheral models again are created by cutting lots of corners, but this is not something that can be done automatically since it is not clear (and often depends on the use to which the model will be put) which corners can be cut.

The remaining piece of the puzzle is the capability for the virtual platform to switch from fast models to cycle-accurate models. Boot up the system until it gets interesting (or perhaps just before to give the cycle-accurate models a bit of runway), then suck out all the state information from the fast models and inject into the cycle-accurate models. This gives the best of both worlds, fast models when you don’t care about the details of what is going on in the hardware, and complete accuracy when you do, either because you are responsible for verifying the hardware or debugging low-level software that interacts intimately with the hardware.

The second part of the article looks at the implications for the EDA and IP industries of the changes that we outlined in the first part of the article.

Pat, who was at Bell Labs, started DAC (then called SHARE, the Society to Avoid Redundant Effort) 1964 along with a co-conspirator from IBM. The first conference was in Atlantic City in 1964. This eventually became DAC. When the availability of commercial EDA tools made DAC too big to manage as an all-volunteer organization as it had been, Pat left the technical side of design automation to form MP Associates along with his wife Marie. I think that the history of DAC has been well-covered elsewhere so instead, I asked Pat, what was “design automation” back when he started in the business. After all, transistors were fairly new, printed circuit boards hadn’t been invented, integrated circuits were in research and so on.

He told me about the design system he worked on, known as BLADES (for Bell LAbs DEsign System). It ran on an IBM704 with 32K of memory. Think about how little that is: 32 gigabytes (too big for a notebook but not for a high-end server)  is a million times as much. The computer had 32 tape-drives (disks were another thing that hadn’t yet been invented). They built the design system to work on a specific project, the Safeguard anti-missile system for the DoD. It was an electronic system so large it occupied 3 buildings.

The system was built like this. At the lowest level were modules which contained 3 or sometimes as many as, dramatic pause, 4 transistors with wire-wrap terminals (if you are too young to know what wire-wrap is, then more than you want to know is here). Boards 33″ by 24″ were covered in these modules with gaps in between to run the wires (because if you ran wires over  the tops of the modules you’d never be able to open them again for maintenance). Originally there were 8 different kinds of modules but eventually they ended up with about 30 (that sounds familiar in libraries today). Initially these modules were hard-wired into the code but Pat came up with the idea of putting all the components into a file on a magnetic tape and extracting them from there (the first cell-library I guess). The design rules, for example no wire could be longer than 12″, were on another tape.

These boards were stacked into refrigerator-sized units called frames with more wire-wrap to construct what today we’d call a back-plane. Then lots of these units would then be connected together with manually labeled wires until you’d filled 3 buildings.

Before Pat’s design automation it took 4-5 months to design one of these boards and then another month for the board to be wire-wrapped by hand. Afterward, using the design system, the time was cut to around a month but it still took another month for the hand wire-wrapping.

Then Gardner Denver developed an automatic wire-wrap machine. Pat designed a controller for this (complicated by the need for ‘dressing fingers’ since they couldn’t route point to point and had to avoid wires going over the modules). Now the design automation system could (effectively) directly manufacture the board. That got the time down from a month to a day or two.

This is one example of how manufacturing used to be much more connected to engineering, and delivering a system would often involve people needing to work in all sorts of areas. Software engineers today don’t have to change the design of the semiconductor manufacturing equipment!

The wires that connected the frames were manually labeled. But hand-written labels aren’t always legible, and the glue wasn’t good so they would regularly fall off leading to obvious problems. Pat decided they needed a new way of labeling where the labels could be printed automatically and would stick on the cables properly and never fall off. The only material he could find that seemed like a good starting point was the plastic sheet that 3M used to make band-aids. So he got band-aid material from 3M and would attach it to paper and print the labels using a standard line-printer. But the adhesive still wasn’t good enough so he got the chemical department at Bell Labs to invent a new super-strong adhesive and, further, to develop a coating for the plastic that would accept the ink (so it could be printed) but not dirt so the labels would stay clean and legible. They still needed 3M to supply the original plastic material and to do the die-cutting afterward. Finally, Pat modified a manual wire-wrap gun with a new chuck to create a tool that attached the labels to the wires, inspired by having seen cigarettes being made on a factory tour. These were the first ever machine-prepared labels.

3M actually branched off that part of the business to form a label-making subsidiary called Avery. Yes, the same Avery as makes labels for your inkjet today.

So what happened when three buildings worth of electronics was shipped out to an island in the Pacific? Safeguard was constructed because the US figured that they couldn’t build enough interceptors to destroy every incoming missile. But  they also figured out that the USSR couldn’t afford to build that many warheads so that they would use decoys too. Safeguard analyzed the incoming missile trajectories looking for tiny differences in flight path to decide which were real and which were decoys. Pat was invited out to the Pacific for the first test and it was a complete success. The system picked out the one real missile from the five decoys and knocked it down.

Interestingly, in the early days there were big problems getting acceptance of this new technology. Designers didn’t want to use the design system since they worried it would obstruct their creativity. And the manufacturing people were worried that the automation  would lose them their jobs. When Pat moved to Denver in 1969 it was the first time AT&T had both design and manufacturing under the same roof.  When he arrived the manufacturing manager told him “I hate computers.” Back then the design methodology was that Bell Labs would design the system and build prototypes, then the design would be transferred to Western Electric (the manufacturing arm) who would completely re-lay it out. With the design system this became unnecessary, the prototype could be transferred direct into manufacturing and this became a model for the rest of Western Electric. The system produced cost savings of $2M per year immediately. Since AT&T was a regulated utility, the only way for them to increase profitability was to reduce their costs since they didn’t really have any way to increase their prices. So this was a big deal and the manufacturing manager changed his tune.

Since DAC is 50 years old in a couple of years, I suggested that it would be interesting to have some other people talk about what design automation was in the 5 decades since it started. Now we are in the age of billion transistor chips it is hard to remember the time when 10,000 gates was a huge design, let alone all the automation necessary to create even earlier systems.

The lead investors were Evans and Sutherland (the graphics and flight simulator company in Salt Lake City) and Hambrecht & Quist (one of the earlier VCs).

VLSI had an incredible, especially given its limited size, team of software engineers who put together an entire design system in a relatively short time. We were the first generation of PhDs who had learned the Mead-Conway methodology, so the first generation of computer-scientists rather than electrical engineers, who knew how to design a chip. For several years I think we had clearly the best design tools that you could buy. Of course you had to use VLSI to build your silicon to get your hands on them, which was a good business model when VLSI started out but became less tenable as the DMV (Daisy, Mentor, Valid) got going and promoted the idea of software coming from a 3^rd party EDA industry with libraries as the link to manufacturing. When it was just DMV, largely used for simple gate-arrays, VLSI was still in good shape since more complex designs required more powerful tools. But when ECAD and SDA merged to form Cadence we suddenly had a whole lot more competition. Every semiconductor manufacturer, especially in Japan but even Intel (I bet you’d forgotten they were in ASIC for a while) entered the ASIC business.

Since they didn’t know what they were doing initially, they could only compete on price. In practice, they weren’t very competent for many years. We would often end up bidding on designs where our price (and LSI Logic’s, the other company founded at almost the same time focused on gate-arrays) were twice the Japanese. “Come back when they fail,” we’d say and usually they would.

I think it was Wilf Corrigan, CEO of LSI Logic, who pointed out that the EDA industry stole all the profit from ASIC. They shipped tools that, in the early days at least, really weren’t very good. But the ASIC manufacturers only made money when the design got through so they ended up incurring all the costs of support. If you look at VLSI Technology over the years, it made money some years, lost money other years but it never generated enough cash to grow organically when you took its capital requirements (we had 2 fabs) into account. At one point, as the ultimate vote of no-confidence in the ability to generate profit, VLSI’s book value was less than the cash in the bank.

I joined VLSI about 18 months later. I think my hire date was June 28^th 1982 (and we all got a $100 bonus for July 4^th that year, so not a bad start. $100 was worth something back then). I stayed for 16 years eventually sawing off the branch I was sitting on. By then I was running Compass and we were acquired by Avant! I stayed there for 8 hours after the deal finally closed, resigning on a Friday afternoon and starting at Ambit on Monday morning. Good decision.

The non-Compass part of VLSI was eventually acquired by Philips Semiconductors (now NXP) in a hostile takeover in 1999 for $1B.

By some measures, VLSI was a big success: we invented an industry, pioneered various design tools, were successful in PC chipsets, early into wireless and grew from nothing to a $600M (I think) business. But the stock price never went anywhere in 15 years, spending most of its time lingering in the $11 to $15 range. In fact from my personal financial point of view, the most important event was the 1987 stock market crash when all our options were repriced to $4. So once the stock went back to its usual range there was a nice profit.

But I learned an incredible amount about silicon, software development, management. Compared to most people in EDA I like to say I have silicon in my veins. I’m often disturbed by how little about semiconductors EDA people know. It was a great ride.

The basic transition is that we are going towards very large technology companies that operate on global scale to supply other large organizations with as much as they can, as opposed to the recent decades when we have had specialized companies (Microsoft for operating system, Dell for hardware, Oracle for database  etc). They will be much more vertically integrated. For example, Oracle bought Sun and has said they are looking at semiconductor companies. They want to supply not just databases but the entire computing environment to their customers.

Here’s an interesting statistic: the largest 12 technology companies are sitting on so much cash that they could buy all of the other publicly traded technology companies. Their stock prices reflect this power: they have been rising much faster than the smaller technology companies, which have languished. The giants are truly giant: Apple has a market cap of nearly $300B as I talked about recently and over $40B of that is in cash.

Any company not doing billions in business and operating on a global scale is in play and a target for acquisition. Note that in EDA, although they do operate globally, none of the “big” EDA companies is really big by this standard and so they are all in play. Synopsys has a market cap of about $4B. ARM has a market cap of $8B. There have been some rumors that Apple might buy ARM. I’m not sure that would make much sense, but they would barely notice the dent in their bank balance.

The classic design methodology was built on an assumption that design today is roughly: write the RTL, automatically reduce it to layout, then write a little software for the control microprocessor. But now, for most SoCs, this is completely backwards: 80% or 90% of the design is pre-existing IP. The software load can be enormous but most of it isn’t being written for this specific SoC, it is inherited from earlier designs. This changes the whole nature of design and potentially causes one of those re-jigging of the supply chain and a re-jigging of who realized the most value.

One implication of all of this is that system companies like Apple can design their own systems without having to share so much of the margin with others, as they have done with the iPad A4 chip.

So Jim and I wrote a piece and it is running in EEtimes. I’m not sure how heavily it is going to end up being edited. I’ll put stuff up here that got cut for space reasons. The first part is here.

Any attendee to DAC can’t fail to have noticed that the amount of space on the tradeshow floor is decreasing every year. In fact it has almost halved since 2005. Tradeshow floorspace translates almost directly into dollars so this is a big financial impact. The number of exhibitors is not down nearly so much, by about 20% (there are still nearly 200 EDA companies attending). The biggest difference is probably that the big companies no longer have huge booths with 50 or 60 demo suites, and small companies basically just have one or two demo suites and a reception desk without a real booth. Attendance of visitors to the exhibits is also down from a peak of over 4000 people in 2006 (admittedly in San Francisco which is always anomalous) to less than 2000 this year.

What about the technical conference? Submissions of papers for DAC continue to be strong at around 800 papers per year. It hasn’t seen the falloff of other conferences like ICCAD and clearly remains the pre-eminent conference in EDA. But attendance is way down. In 2000 there were 4500 people paying for the whole conference, now only 1500. In fact it is worse than that since there are about 700 people who get to go free (or at reduced prices) since they are speakers, session chairs, on the DAC organizing committee and so on. So true general public paid attendance has gone from 3800 to 800, a reduction of 80%.

So what is to be done to increase the value of attending DAC to the exhibitors, the exhibit attendees and the technical conference attendees.

One desire is to broaden DAC into neighboring spaces, in particular embedded systems and software. Having been in that business I’m not sure that will work. Embedded systems already have their own conference ESC (actually several although only the main one in San Jose is on a DAC-like scale). And embedded systems companies there sit around and grouse that their customers don’t all show up, that it is not clear that their customers even think of themselves as being in the embedded software business. If they won’t attend ESC I think it is a stretch to think they’ll attend DAC although there are always some people who straddle the divide (virtual platforms, register management etc).

There is a big push in the conference to increase interaction. Technical presentations, which have always been 30 minutes, will now be 15 minutes with a poster session outside immediately afterwards for people who are especially interested in the material. There will also be a reception at the end of each day (free beer is always an idea worth trying). This will replace the DAC party (not the Denali party which Cadence said they would continue). This was always a weird hybrid: exhibitors not invited, a dance band when the audience is about 95% male, music too loud to talk over, uninspiring food.

DAC is a curious hybrid of an academic conference largely attended by people who are not working in the EDA industry, and a tradeshow largely attended by people who don’t go to the technical sessions. It wasn’t always that way. Ten or twenty years ago EDA companies would send large numbers of engineers to attend the sessions. I’ve been to every DAC since Albuquerque and for the first ten or fifteen years I was an engineer and went to technical sessions. But now budgets are so much tighter and the utility of going seems have decreased. Synthesis was perhaps the last big area where EDA broadly commercialized and extended work from academia.

I still go to DAC but mainly I go to meet people. As a blogger I get a press pass for free so it costs me very little to go, and I usually end up getting at least one consulting gig out of going which more than covers the airfare and hotel (and when it is in San Francisco it is a ten minute walk from where I live so I don’t even have those costs). Most people in EDA who go are either exhibitors or manage to get a free pass anyway.

Tradeshows are clearly not dead in general. One problem in our business is that the big companies (EDA companies like Cadence, IP companies like ARM and foundries like Global), have decided that it makes more sense to organize their own one-company tradeshows. After all they don’t get leads out of DAC in the same way as a small unknown company does. Nobody discovers TSMC makes wafers or Synopsys does synthesis by going to DAC. I suspect it is cheaper too.

Perhaps the model for DAC (and conferences in general) is going to turn out to be TED. People go to the TED conference itself in Long Beach to interact with others. But most people experience TED for free through the videos as they get edited and released in the months following the conference. That’s the paradox: people are paying $6000 to experience the same material they can watch for free. But people pay good money to see, say, Arcade Fire live when they can download the album for $9.99. How to achieve that balance is a huge challenge: making DAC the ultimate must-attend industry/academia networking event, and providing a lot of the content to non-attendees by web-based video.

DAC is June 6-10^th in San Diego next year. I’ll be there.