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.

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.

VHDL is, of course, one of the two main hardware description languages dating back to the 1980s. The history of Verilog and VHDL is quite interesting. Verilog was originally created by Gateway Design Automation. Gateway was subsequently acquired by Cadence for what seemed like a very high valuation at the time, although of course it has probably been one of the most successful acquisitions Cadence did when you think of the sales of Verilog that they have made over the intervening years. VHDL, which is actually one of those nested acronyms since it stood for VHSIC Hardware Description Language, with VHSIC further parsed down into Very High Speed Integrated Circuit. The VHSIC program was run by the US DoD and VHDL looked for a time that it might become the dominant standard, since Verilog was a proprietary language owned by Cadence.

But Cadence opened Verilog up and let other people participate in driving the language standard. As Gordon Bell once said, the only justification for VHDL was to force Cadence to put Verilog into the public domain. But having two languages has been a major cost to the EDA industry for very little gain. VHDL was a very powerful language but in many ways was less practical than Verilog. For instance, you could define your own values for any signal. But that meant that gates from one library wouldn’t necessarily interact properly with gates from another library (sounds like some of the problems with TLM models in SystemC that are finally being resolved). So that required a new standard, VITAL, so that gate-level signals were standardized. The richness of VHDL abstractions meant that it was and is used for some of the most complex communication chips. Model Technology (now part of Mentor) had probably the best VHDL simulator that they sold cheaply, and that helped to make VHDL more standard in the FPGA market than Verilog. Despite the fact  that a Verilog simulator is easier to write than a VHDL simulator, it sold for a higher price for years. This has led to an odd phenomenon where some of the most advanced chips are done in VHDL, and many of the simpler ones.

Anyway, the dual language environment (and, of course, SystemVerilog has arrived to make a third) continues to exist. Almost all tools have, over the years, bitten the bullet and provided dual language support for both VHDL and Verilog. Often the front end for VHDL, which is a complex language to parse, comes from Verific (as does the VHDL front-end for Oasys’s RealTime Designer).

If you are a technologist of some sort then it seems like the challenge of getting an EDA company going is insurmountable. After all, there are probably only a couple of dozen people in the world who have deep enough knowledge of the esoteric area of design or semiconductor to be able to create an effective product. That seems like it should count as a high barrier.

But, in fact, technology is the lowest of barriers if you are in a market where technology counts for something. Designing and building chips is something that races along at such a breakneck pace that the whole design ecosystem is disrupted every few years and new technology is required. It has to come from somewhere. As a result, brand-name counts for very little and small companies with differentiated important technology can be successful very quickly.

Other industries are not like that nowhere else does technology move so fast. What was the last big innovation in automotive? Probably hybrid powertrains. Most cars still don’t have them and it is now ten year old technology.

Let’s think of an industry with just about the least amount of technology, so pretty much at the other end of the scale from EDA and semiconductor: bottled water. Do you think that your bottled water startup is going to do well because you have better water technology? Do you think that the customer who chose Perrier rather than Calistoga could actually taste the difference anyway? Bottled water is selling some sort of emotional aspirational dream.

You’ve obviously noticed that if you go to bar and get upscale water then you typically end up with something from Europe (San Pellegrino, Perrier, Evian) and not something from California (Crystal Geyser, Calistoga). It has to be bottled in Europe and shipped here. Why don’t they ship it in bulk and bottle it here? For the same reason as wine is bottled before it is shipped: nobody would trust what was in the bottle. One thing that surprised me when I was in Japan a couple of years ago is that the Crystal Geyser water we turn down as being insufficiently upscale is what they drink over there. It comes from California, the other side of the Pacific, how exotic is that? I don’t know if the third leg of the stool exists, people in Europe drinking water from Asia: bottled from a spring on Mount Fuji, how zen is that?.

In between are lots of companies and industries where there is obviously a technical component, and an emotional component. BMW may be the ultimate driving machine, but most people who buy one couldn’t tell you what a brake-horsepower is, even if they know how many their car has. And almost nobody actually uses all that horsepower, running their car at the redline on the tacho all the time. Yes, there’s technology but mostly it’s an emotional sell.

In the commercial world, think of Oracle. Do you think you are going to displace Oracle because you’re little startup has some superior relational database technology? No, there’s a whole ecosystem around Oracle, they largely sell to people who don’t understand technology (CFOs) and so brand-name counts for something. They are partially making an emotional decision and buying peace of mind.

Brand name still counts for a lot in the consumer market space, even if less than it used to. This is measured by the increase in price for the brand name that consumers will pay compared to the no-name. Many of the top brand names in the world (Coca-Cola, Kellogs, Colgate) are very old going back a century or so but the premium, especially in the current downturn, that people will pay to get a Sony rather than Best Buy own-brand is shrinking.

So brand name or ecosystem are really high barriers to entry. Technology not much. A few smart guys and a two or three years of writing code is a lot easier than recreating the ecosystem around ARM, never mind making your cola as well known as Coke.

AEs have a lot of options in their career path. As they become more senior and more experienced they have four main routes that they can take. They can remain as application engineers and become whatever the black-belt AEs are called in that company, be the guy who has to get on a plane and fly to Seoul to save a multi-million dollar renewal. They can become AE managers, and run a region or a functional group of AEs. They can move into product marketing, which is always short of people who actually know the product. Or they can move into sales and stop resenting the fact that when the deal closes, for which they feel they did all the work, the salesperson makes more than they do (and usually discover sales is harder than they expected).

In a startup, in particular, the first few AEs hired can be the difference between success and failure. The first release of a product never works properly, never quite matches what the market need is and is simply immature. The AE has to keep the customer happy by substituting their own expertise for the deficiencies of the tool while at the same time conveying back to engineering the improvements that are required. Most startups are attacking some sort of walled city, in the sense that there is an incumbent tool/methodology that is already in use, and the startup has to prove that they are better. In fact, not just better, compellingly better. The initial value proposition for most startups, when you look from the 10,000 foot level, is that it is riskier to stick with the existing methodology rather than trust the startup and try the new technology. Getting the customer decision-maker to that point is a mixture of technology (it has to work well enough) and trust in the AE (whatever happens, this guy is going to be there for me). Both factors have to be there to close those so-important initial orders because no matter how good the technology looks, the customer knows that the tool is not mature and might fail at any moment.

It’s been interesting looking at the downsizing of GM and Chrysler’s dealer network. It seems that part of the reason that car companies sell through independent dealers is that in the early days, nobody would buy a car from halfway across the country without a local guy in-town they trusted (and the situation got locked in place because those local guys became the richest people in town and got the states to pass laws that they could never be designed out; it almost every state it is illegal for GM to sell you a car directly). But that trust issue is just like the AE issue. Customers wouldn’t buy a car (tool) from a startup without a dealer (AE) too. It didn’t matter how good Ford’s car appeared to be in the showroom; in 1930, nobody trusted it not to break frequently (a good assumption) and they needed to trust that their investment was going to continue to be good.

AEs are really hard to find for a startup. Good AEs are pretty highly compensated, and so it is hard to match their salary, so it takes a lot of stock to makeup the difference. I did some consulting for a semiconductor equipment company once and they had an EDA product but they failed to hire a good AE since their own AEs were paid a lot less than a black-belt EDA AE and their salary policies were too inflexible. Good AEs are like gold and if you don’t have them you don’t get any gold.

One other thing I was interested in was the extent to which software productivity tools had improved. We all know that IC design productivity has improved by about a million times since the early 1980s when you would do well to design and layout a single gate in a day. Software development hadn’t seemed to be on the same sort of track when I was a programmer. Now, mainly through the libraries that are now available, applications need a lot less new code. Knowing how to program the iPhone is more about knowing the library calls than it is about writing code in Objective-C. Once you don’t need to run to the help files every time you want to call a procedure, you get very productive. With infrastructure like openAccess now available, EDA tools have got more like that too, but that is a bigger topic for another day.

I wrote some toy applications and got them running on my iPhone. Of course I bought a couple of books (at the time, that was all of them, there seem to be lots more about to come out in the next month or two). Having tried several of them, if you too are interested in writing an iPhone app then easily the best book I came across for getting started is the aPress one Beginning iPhone Development. Other books are probably better once you are up to speed; as with any domain, what you want as a tutorial to get started is different from what you want as a reference once you are up to speed. Stanford has also put online the course materials for CS193P on iPhone programming.

However, it never occurred to me to write an EDA application for the iPhone. However, it did occur to Michael Sanie (disclosure: Michael is a friend and he has worked for me as both employee and consultant in the past). Obviously nobody is going to be doing place and route on their iPhone. Michael has written a tool iWafer for estimating die size, estimating how many die fit on a wafer, and estimating yield. Not all that different from a workstation-based tool I wrote back in the mid-1980s called the DesignAssistant. It did die size estimation and would have done yield estimation too, except that data was considered commercially sensitive back then. iWafer is a handy calculator for working out how big a die you are likely to need for a certain number of gates, how many will fit on various sized wafers, and how many of those die (dice) are likely to turn out good. Various foundry salespeople are already finding it to be a useful tool to have in their pocket (pun intended).

Anyway, everyone always complains that EDA tools cost too much. But this one doesn’t merit that criticism, it’s just $9.99.

Every EDA startup, at least the ones that get that far, goes through a difficult emotional transition with engineering when the first product finally starts to ship.

In the early days of a startup, almost the entire company (maybe everyone other than the CEO) is in engineering. The focus of every review meeting is engineering schedules. The focus of any HR activity is hiring that next great engineer. Everyone is waiting for that first release of the product. Every small slip of the product, every minor change of specification, is minutely analyzed.

Finally the big day arrives and the focus of the company switches very quickly to sales. How is the funnel? What is the booking forecast? How are we doing hiring that critical application engineer? How long to cash-flow neutral? To the extent that management pays attention to engineering it is more focused on when showstopper bugs that are impacting sales will be fixed. Nobody seems to care nearly as much about release 2.0 as they did about release 1.0.

Anyone who has more than one child has seen something similar. Their first child is an only child, the center of their parents’ attention. Until that second baby arrives and suddenly they are no longer the center of attention. Firstly, there are now two children so attention would naturally be halved. But secondly, babies have an extremely effective strategy for getting all the attention they need: make an unpleasant noise and don’t stop until their needs are satisfied.

When sales start, engineering is like the first child. They go from having all the attention to having to share it. And to make it worse, the second child, sales, has a very effective strategy for getting all the attention they need: explain the reasons they are not closing business until their needs are satisfied. To make things worse still, the reason they are not closing business is probably related to deficiencies in the early immature product, which means that what little attention engineering does get is negative.

This is a very tough emotional transition. Engineering is on the start of a path from being almost 100% of the company declining to 20% of the company as it moves towards maturity. Engineering will hold headcount relatively flat as other parts of the company seem to explode. Engineering goes from being the star of the show to a supporting role.

The most important thing to do about handling this is to make sure everyone understands that it is going to happen, like telling your 4 year-old about the new baby. And, what is more, make sure everyone realizes that it is a symptom of success, a rite of passage. When all that anyone cares about is engineering, it means that the company isn’t selling anything. When management cares about other things, that’s the first taste of victory. It’s engineering’s job to get out of glare of attention as quickly as they can, and let sales start taking the heat.

After all, how much fun was it when the CEO was analyzing engineering’s embarrassingly inaccurate schedules in great detail. Every day.

In the early 1980s VLSI design techniques were being disseminated outside a handful of semiconductor companies where the priestly knowledge had previously been secreted. VLSI Technology and LSI Logic (primarily) invented ASIC design, whereby customers did part of the design and the semiconductor company (we called them foundries then, but they were not exactly the same as what we call a foundry today) did the rest. A lot of design tool development was internal. There was a good reason for that, namely that there was no 3rd party EDA industry providing the necessary tools, and so no tools meant no product to fill the fab. Remember that if you have a fab you are like an hotel; every wafer start slot with no actual wafer to start is like a plane with an empty seat. Once the slot has passed or the plane takes off, it’s gone for ever.

So VLSI Technology and LSI Logic (and HP, Intel, TI and everyone else) had a large amount of internal CAD. It was differentiation to some extent, and there wasn’t really an alternative. The CAD teams were staffed with top rate engineers, many of them M.Sc. and Ph.D. students from the first cohort of people from universities starting to teach and research VLSI design.

Then came the first wave of EDA companies, the DMV—Daisy, Mentor and Valid. They provided systems for doing some front end design, basically schematic capture and simulation. The standard ASIC methodology was to do design to netlist, ship the netlist to the semiconductor vendor who would do place and route (either as a standard-cell design or a gate-array) and provide back annotation of capacitance values (we didn’t worry about resistance back then, timing was dominated by capacitance) for resimulation and signoff.

This design flow didn’t work very well at first. Wilf Corrigan, CEO of LSI Logic famously complained that the EDA industry took all the profit from ASIC. Customers would buy tools but the semiconductor company would only get their money once a design could get through the flow. So much of the heavy lifting to mature the flows and make them workable was done by the semiconductor companies not the EDA companies. The next generation of EDA companies was SDA and ECAD who merged to form Cadence (this was long before Synopsys). The Japanese semiconductor companies adopted 3rd party EDA vigorously, since they had very limited internal development and this allowed them to get into the new markets that ASIC was opening up.

The writing was on the wall for internal EDA, at least in the long term.

So the EDA part of the business split into an external part, the EDA industry, and an internal part, the CAD groups. By and large the CAD groups were training grounds for entry level engineers, some engineers with deep design experience and, usually, first rate management (often drafted in from the design side of the company to keep the internal politics calm). They knew how to use tools but not how to create them. The internal tool developers migrated from the semiconductor companies into the EDA companies.

The two exceptions to this, companies that kept large internal development groups, were Intel and IBM who still, to this day, develop significant amounts of EDA software for their own internal use. But it is very expensive to do this, and even they don’t know how useful it is. I once asked someone in Intel’s Design Technology (their internal CAD/development group) whether their routers were better than the EDA industries. He admitted they didn’t have a clue; they had no bandwidth to even take a look at what was available externally.

So I don’t see internal development being a major force since the economics don’t work very well. However, that could change with consolidation of both EDA and semiconductor companies, and especially if a semiconductor company jump-started internal development by acquiring one or more EDA companies.

The best rule for this that I’ve ever come across was created by Paul Gill when we were at Ambit. To report a bug, an application engineer must provide a self-checking test case, or else engineering won’t consider it. No exceptions. And he was then obstinate enough to enforce the “no exceptions” rule.

This provides a clear separation between the AE’s job and the development engineers job. The AE must provide a test case that illustrates the issue. Engineering must correct the code so that it is fixed. Plus, when all that activity is over, there is a test case to go in the regression suite.

Today, most tools are scripted with TCL, Python or Perl. A self-checking test case is a script that runs on some test data and gives a pass/fail test as to whether the bug exists. Obviously, when the bug is submitted the test case will fail (or it wouldn’t be a bug). When engineering has fixed it, then it will pass. The test case can then be added to the regression suite and it should stay fixed. If it fails again, then the bug has been re-introduced (or another bug with similar symptoms has been created).

There are a few areas where this approach won’t really work. Most obviously are graphics problems: the screen doesn’t refresh correctly, for example. It is hard to build a self-checking test case since it is too hard to determine whether what is on the screen is correct. However, there are also things which are on the borderline between bugs and quality of results issues: this example got a lot worse in the last release.  It is easy to build the test case but what should be the limit. EDA tools are not algorithmically perfect so it is not clear how much worse should be acceptable if an algorithmic tweak makes most designs better. But it turns out that for an EDA tool, most bugs are in the major algorithms under control of the scripting infrastructure and it is straightforward to build a self-checking test case.

So when a customer reports a bug, the AE needs to take some of the customer’s test data (and often they are not allowed to ship out the whole design for confidentiality reasons) and create a test case, preferably small and simple, that exhibits the problem. Engineering can then fix it. No test case, no fix.

If a customer cannot provide data to exhibit the problem (the NSA is particularly bad at this!) then the problem remains between the AE and the customer. Engineering can’t fix a problem that they can’t identify.

With good test infrastructure, all the test cases can be run regularly, and since they report whether they pass or fail it is easy to build a list of all the failing test cases. Once a bug has been fixed, it is easy to add its test case to the suite and it will automatically be run each time the regression suite is run.

That brings up another aspect of test infrastructure. There must be enough hardware available to run the regression suite in reasonable time. A large regression suite with no way to run it frequently is little use. We were lucky at Ambit that we persuaded the company to invest in 40 Sun servers and 20 HP servers just for running the test suites

A lot of this is fairly standard these days in open-source and other large software projects. But somehow it still isn’t standard in EDA which tends to provide productivity tools for designers, without using state of the art productivity tools themselves.

On a related point, the engineering organization needs to have at least one very large machine too. Otherwise inevitably customers will run into problems with very large designs where there is no hardware internally to even attempt to reproduce the problem. This is less of an issue today when hardware is cheap than it used to be when a large machine was costly. It is easy to forget that ten years ago, it cost a lot of money to have a server with 8 gigabytes of memory; few hard disks were even that big back then.

And with perfect timing, here’s yesterday’s XKCD on test-cases:

In an informal setting, that is to say over a beer rather than in front of a large audience, I tell such CTOs that if they want more reliable software then they can simply use an old version of the tools that has been shipping for years. Tools like that get pretty solid. Of course that is simply a glib response since I know that they can’t design 65nm designs with 130nm tools.

So my next suggestion is that the EDA industry could delay shipping new tools for an extra year or so to allow extensive testing. Another glib response since we all know that the tools are already late and even if it were possible to test them extensively without shipping them (what would we use for test data?) the delay would be unacceptable.

There are two reasons for this state of affairs, one technical and one economic.

The technical reason is that it simply isn’t possible to know everything necessary about a new process node far enough ahead of time to allow for a robust development cycle. For example, even with a huge team of people ready to go it is impossible to develop a full suite of technology for 22nm design. We just don’t know everything we need to know to get started and neither do the semiconductor companies and their equipment suppliers. Inevitably the tools will be later than desired and customers would rather have buggy tools now than better tools in six months. It is the EDA version of MacArthur’s dictum that a good plan violently executed now is far better than a pefect plan executed next week. In fact, whatever schedule is chosen, there are always customers lining up to be beta sites, so that they can get their hands on technology earlier, and pressure to ship even earlier even though the tools will be buggier still.

There is also the fact that it is not really possible to develop an EDA tool in a vacuum. There need to be libraries and designs in the process node to be used to test and wring out the code. A new tool is often rock solid on old designs, it is the new bigger more complex designs that break the tools in new ways.

The economic argument is that EDA has to support several process nodes at once and recoup its investment in a timely manner. Those same CTOs who berate EDA companies for not being aggressive enough, work at the same companies that have CAD managers who insist that resources be diverted to back-patching bugs. They want fixes that are already available added back into obsolete (and no longer officially maintained) versions of the software because their design groups haven’t got round to switching. And those CTOs have finance managers who don’t want to increase their budget for leading edge tools only used by the small number of advanced groups.

The effect of all of this is that EDA companies make their money and recoup their investment on processes only when they become mainstream. They cannot afford to make that investment too far ahead of the mainstream for economic reasons as well as technical ones. The fact that the mainstreaming of the most advanced processes is slowing is already starting to strain this model somewhat since it delays the time to payback.

One way to improve the quality of EDA software would be open source. But if undertaken by the major suppliers, this would also destroy their business model and probably thus result in no software at all. However, EDA moves too fast for open source to simply clone the successful products in parallel. The Econtalk podcast with Eric Raymond pointed out another industry that moves fast and where open source has little impact: games. By the time a game is clearly a hit it is too late to start an open source project to clone it. The gaming community will have got bored with that game and moved onto something else by the time the open source free version is complete and widely available.

Other industries don’t have this problem because they don’t move so fast. Technologies in automotive are adopted in decades not a year or two. CAD for automotive has a lot of time to adapt. But EDA is stuck with a very short reaction cycle and even if the ROI was richer, it is not clear that much would change.