Don’t listen to your customers

Posted on April 23, 2009 by paulmcl

There is a train of thought that the route to success in a business is giving a customer what they say they want. At some level this is obviously good advice. But there are two problems with it. Firstly, the customer always wants incremental improvement on what they already have, and rarely is imaginative enough to ask for what they really need. And secondly, this can lead to design by committee producing a product that has too many features to be usable.

A nice example of this is Apple’s design of the iPhone. Nobody knew they wanted it. In a vague sort of way they probably wanted a phone from Apple knowing it would be Mac and iPod-like. Luckily Apple didn’t simply go and ask all the carriers what they wanted, they designed what they wanted to and then found a carrier willing to take it largely unseen. Of course lots of people were involved in the iPhone design, not just CEO Steve Jobs and chief designer Jonathan Ive (another Brit, by the way, referring back to my post about the benefits of easier immigration) but it was designed with a conceptual integrity rather than a list of tick-the-box features. The first version clearly cut a lot of corners that might have been fatal: no 3G data access, no GPS, no cut-and-paste, no way to send photos in text messages, only a couple of applications honored landscape mode. The second version came with 3G and GPS. Most of the rest of the initial peeves are now fixed in the 3.0 version of the operating system (which, as a registered iPhone developer, I already have installed). But the moral is that they didn’t ask their customers to produce a feature list, and they didn’t make an attempt to implement as much of that list as possible.

When I was at Cadence we were falling behind in place and route. So we decided to build a next generation place and route environment including everything the customers wanted. It was to be called Integration Ensemble. We asked all our customers what the requirements should be. So, of course, it ended up as a long list of everything every group had ever wanted, with little conceptual integrity. In particular, for example, customers insisted that integration ensemble should provide good support for multiple voltages, which were just going mainstream at that time, or they wouldn’t even consider it. We specced out such a product and started to build it. With so many features it would take longer to build than customers would want to wait but customers were insistent that anything less than the full product would be of no use. Then these same customers all purchased Silicon Perspective since what they really needed was good placement and fast feedback, which was not at the top of their list. Silicon Perspective did not even support multiple voltage supplies at that point. The end of that story was that Cadence expensively acquired Silicon Perspective and Integration Ensemble was quietly dropped. The customers got what they wanted even though they never asked for it.

One area where marketing is especially easy is when the developer is the customer for the product, when they are “eating their own dogfood” as the saying goes. This is one of the factors driving success in open source software: the developers are usually their own customers. iPhone and other Apple products are also like this; the designers all will use the product. EDA software (and many other products from jet-engines to heart-pacemakers) are generally not like this, so marketing in the sense of product definition is required. Generally in this type of environment open source has been unsuccessful and a lot of the intellectual property (in the most general sense) of the product is not so much in the implementation but in the compromises around what to put in and what to leave out. Doing a good job of specifying products is one of the hardest parts of marketing, requiring a deep understanding of the customer problems and a deep enough understanding of the technology and engineering involved to deliver a solution.

Posted in marketing | Comments Off

Guest blog: Phil Moorby

Posted on April 22, 2009 by paulmcl

Today’s guest blog is by Phil Moorby who back in the 1980s at Gateway Design Automation was the inventor of the Verilog language, for which he was given the prestigious Kauffman award in 2006. Gateway was, of course, acquired by Cadence. Today, Phil is CTO of Sigmatix Inc.

Verilog:  A Name for Getting the Job Done

Verilog. Verification and Logic. Sometimes it’s all in the name.

When we set about architecting a language for next generation IC design at Gateway Design Systems in the 1980s, our overriding principle was “simple is powerful.” We wanted to create a language that an engineer could learn quickly and use easily, that covered exactly the necessary tasks and nothing more, that needed no relearning after a pause in use.

The success and endurance of Verilog is testament to this foundation. The original design considered the requirements of fast gate simulation, synthesis, timing analysis and test. Later, the language supported more advanced timing directives, and other necessary features. During this growth, it always retained its elegance-of-use, which ensured its survival and, eventually, its adoption as the industry standard, even as the public domain VHDL language gained prominence.

From the outset, the original Gateway team primarily targeted synthesis and verification (simulation only with behavioral directed testbenches). We soon partnered with another up-and-coming, small company, Synopsys, to ensure a synthesis path for Verilog, and engineers quickly realized the power of the approach. Fast gate level simulation was another key feature and the gate level representation of the language bore this out.

One of the powerful reasons for Verilog’s staying power was its sign-off status among numerous ASIC vendors. It was Motorola who first recognized the potential of Verilog-XL as a sign-off simulator, and the inclusion of timing capabilities and gate modeling methods to meet stringent constraints made this possible. Widespread ASIC sign-off for Verilog imposed a significant barrier to entry for other simulators and languages of the time.

In 1989, Cadence Design Systems acquired Gateway and the rights to the still proprietary Verilog language. The public domain VHDL language was gaining momentum with the backing of other large EDA Vendors, including Synopsys, several influential systems companies, and some government bodies. There is a lesson here regarding the timing of introducing a proprietary language into the public domain and its business impact. It was clear that VHDL gained prominence due to its open standard nature. The battle lines were drawn between the big EDA Vendors and, inevitably in 1991, the Verilog language was donated to the newly formed Open Verilog International (OVI), now part of Accelera, and released into the public domain. One could argue that this has lead to healthy and productive competition.

A key component that aided the creation of the language was a deep consideration of the problem for which it was designed and how it was to be used. It was more important to be able to create a couple of lines of code and immediately run the simulator, and not have to spend days planning configurations and writing superfluous statements before getting to the design functionality.

This core directive, carried over to Verilog 2.0 and Co-Design’s Superlog language, seems to have been diluted in the latest incarnation of the language, SystemVerilog. The driving requirement behind SystemVerilog was to address the compelling demand to solve the verification problem while raising design abstraction, the major verification components being formal analysis and testbench generation.

Although the principles behind the language requirements are sound, the fact that it is designed to be used by engineers from widely differing disciplines has driven it to become, essentially, a collection of several languages.  The simplistic sensibilities of the original Verilog have given way to an overarching family of languages, rendering it somewhat unwieldy. I would claim that an engineer needs to think in one language to drive a successful design.

Take the analogy with the European Union and its three primary working languages: English, German and French. Consider the subtle ambiguities that arise when important details need to be translated precisely and communicated between EU members. Some would argue that this has slowed down progress and added layers of bureaucracy. While this may be necessary when bringing together government bodies, the approach is questionable for a design system. Not just talking, but actually thinking in the same language, accelerates progress in many fields.

An interesting aspect of SystemVerilog is its name. Arguably, the one component not represented in the language family is systems. Maybe it is time EDA technologists stop designing overly complex languages and methodologies, and return to what made early solutions successful, a single minded focus on the problem.

Take ESL. The notion of Electronic System Level design suggests that what is required to provide effective systems methodologies is a new abstraction. Does this really match today’s reality? Are engineers going to solve multicore programming problems for advanced graphics or achieve 1Gbps wireless communication throughput only by working at a new level of abstraction? That would be surprising.

New thinking is required for system level design, just like we rethought RTL design in the 80s. Start with what the engineers are trying to do and work from this keystone. Provide something simple and effective that does the job.

In the past, horizontally oriented hardware description languages predominated. In the systems space, simplicity demands a vertically oriented, application-centric mindset, a blurring of the lines between tools and intellectual property, and a recognition that system design, once the purview of hardware engineers, will now shift to software designers as processors become the building blocks of the system.

Some companies are now taking a fresh look at systems design with interesting results. Let’s find a name to match!

Posted in guest blog | Comments Off

Bletchley park

Posted on April 21, 2009 by paulmcl

I spent a day last week at Bletchley Park, about an hour north of London. As I think is now well known, during the Second World War this was where a team of smart people, notably Alan Turing, broke the German Enigma codes. As a result, the allies got the U-boat losses to convoys in the North Atlantic under control, among many other tactical advantages that came from already knowing the German battle plans. The work at Bletchley is estimated to have shortened the war by two years.

They did the code-breaking by a whole mixture of techniques, the two most notable being the Bombes, which were electromechanical relay-based computers (although not programmable) and Colossus, which was really the world’s first electronic digital computer.

The story of Bletchley Park only came out in the mid-1970s when it first became known that through much of the war the British and Americans had been able to read a lot of the German traffic within a short time of its being transmitted. It also turned out that many of the people heading up computer science departments in the UK (such as Donald Michie in Edinburgh where I was at that time) had worked there secretly during the war but were not allowed to reveal anything about it.

It is interesting to see the different attitude to secrecy and commercialization in Britain and the US. After the war, apparently under orders direct from Churchill, all the machines, all the drawings and everything connected with Bletchley Park were destroyed and everyone involved bound to secrecy for thirty years (some things were only declassified in 2002!). I only discovered recently, long after she died, that my great aunt had worked there. In the US, the military organized seminars for academics to propagate the knowledge of computing built up during the war. As a result, the central focus of computer science moved to the US, and the fact that at the time Britain was the world leader was squandered. The hounding of Turing for his homosexuality leading to his (probable) suicide is, of course, another blot against Britain and another setback for British computer science. Destroying the only digital computers in the world for no good military reason seems like pure vandalism.

Colossus is an interesting machine. It has 2000 tubes (or valves as they are known in British English) and a paper tape reader that runs at 5000 characters per second (that’s over 40 feet per second). The paper tape essentially forms the memory of the computer since at the time there was no viable memory technology. Acoustic mercury delay lines that would be used for the first digital computers such as EDSAC had not yet been invented. The tape contained the message to be decoded and was recycled through the machine every second or two. The sprocket hole on the paper tape was used to generate the system clock and keep the computer synchronized with the tape-reader.

Colossus was actually built using standard phone exchange technology of the day in the GPO (General Post Office, mail and telecoms still together at that point) laboratories at Dollis Hill by an unsung hero Tommy Flowers. The timing of building the replica in the 1990s was fortuitous. British Telecom (which the telecommunication part of the GPO had morphed into) was upgrading the last old electromechanical exchanges and discarding a lot of the right types of uniselectors, tubes and the like. In 2007, the rebuild was finally completed and a message was encrypted using an original German Enigma machine in Berlin, transmitted to Britain, and then decrypted using the rebuilt Colossus in about 4 hours.

If you are a computer scientist (or interested in military history) I highly recommend a visit to Bletchley Park. It is a couple of hundred yards from Bletchley railway station, which itself is about 45 minutes from London Euston station. So if you are in London it is an easy half-day trip. It also houses the British Computer Museum, the equivalent of the Computer History Museum in Mountain View.

There are also lots of books. I recommend Andrew Hodges’s book on Turing The Enigma and Gordon Welchman’s (unfortunately out of print in the US but not the UK) book on the details of the code-breaking The Hut 6 Story. There are dozens more.

Posted in culture | Comments Off

EDA startups: channel costs $6M

Posted on April 20, 2009 by paulmcl

I’ve put together several business plans for EDA startups once the product is ready for market. One question is always how much money needs to be raised. The answer always turns out to be about $6M.

When you put together a spreadsheet to show how the bookings will build up, there are two factors to which the amount of money turns out to be very sensitive:

  • How long after you hire a salesperson before they start to produce revenue?
  • How fast does a salesperson ramp up to “full power”?

The answer to these two questions governs how much you need to invest in a sales team before they are a net positive for the company, and the total and timing of that investment governs how big a hole you have to cover and thus how much money you need to raise.

You might think that how big you plan to get is a critical variable, but in fact the answer is about a $50M run-rate after 5 years. If you don’t have a plan like this then nobody will fund you (they probably won’t anyway at present, but let’s leave that to one side). You almost certainly won’t grow that fast, and everyone knows it, but they will “take a haircut” to any numbers you give them anyway, so you’d better play along and give them big ones.

Other assumptions you’d better bake in. Any bookings you have will come in the last week of the quarter. This means that any cash associated with that order will not come until the following quarter. So every quarter, for every sales team, you need to pay all their salaries without the cash from the business they are generating that quarter to offset those expenses.

Each salesperson needs two application engineers to be effective. Or at least 1½. This means that a sales team costs approximately $800K per year in salaries, travel and so on, which is $200K per quarter, perhaps a little less if you don’t have the full 2 AEs per salesperson.

As for sales productivity, at capacity a sales team brings in $2M/year. If you put in much more than this then you are simply being unrealistic. If you put in much less you’ll find that the business never gets cash-flow positive.

EDA tends to have a 6 month sales cycle. So normally  a new salesperson won’t close business in less than 6 months, and probably 9 months (3 months to understand the product and set up initial meetings, 6 months of sales cycle). I like to use a ramp of $0, $0, $250, $250, $500 for the first 5 quarters, which assumes a salesperson sells nothing for two quarters, is at half speed for two quarters and then hits the full $2M/year rate. Later this may be conservative since a new salesperson can inherit some funnel from other existing salespeople in the same territory and so hit the ground if not running then at least not at a standing start. In the early days it might be optimistic since I’ve assumed that the product really is ready for sale and it is just a case of adding sales teams. But realistically it probably isn’t.

So those are the variables. In 5 years you need to be at $50M which means about 25 sales teams at the end of year 4 (because only those sales teams really bring in revenue in year 5). Some may be through distribution, especially in Asia, but it turns out not to make all that much difference to the numbers.

In the meantime, the rest of the company has to be paid for and don’t directly bring in revenue. So if you ramp sales too slowly, the rest of the company will burn more money in the meantime. This makes the model less sensitive than you would expect to the rate at which you hire sales people, within reason.

If you hire people too fast on day one, then the hole gets huge before your first teams start to bring in any money to cover the cost of the later guys. You need to get to about $7M of bookings before things get a bit easier and the early salespeople are bringing in enough to cover the costs of the rest of the company. However, if you bring in people too slowly then you will not get to a high enough number in the out years. The trick is to hire in a very measured way early and then accelerate hiring later. This will give a hole of about $4-5M meaning you should raise about $6M to give yourself some cushion to cover all the inevitable delays.

Posted in eda industry, finance, management, sales | Comments Off

Systems: it’s turtles all the way down

Posted on April 17, 2009 by paulmcl

According to Steven Hawking, Bertrand Russell once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: "What you have told us is rubbish. The world is really a flat plate supported on the back of a giant turtle." The scientist gave a superior smile before replying, "What is the turtle standing on?" "You’re very clever, young man," said the old lady. "But it’s turtles all the way down!"

Electronic systems are a bit like that. What is a system depends on who you talk to, and a system to one person is built out of components that are themselves systems to someone else.

In the EDA and semiconductor world we are used to talking about systems-on-chip or SoCs. But the reality is that almost no consumer product consists only of a chip. The closest are probably those remote sensing transport fare-cards like Translink now creeping around the bay area (finally, well over 10 years after Hong Kong’s Octopus card which was probably the first). They are self-contained and don’t even need a battery (they are powered by induction). Even a musical birthday card requires a battery and a speaker along with the chip to make a complete system.

Most SoCs require power supplies, antennas and a circuit board of some sort, plus a human interface of some sort (screen, buttons, microphones, speakers, USB…) to make an end-user product. Nonetheless, a large part of the intelligence and complexity of a consumer product is distilled into the primary SoC inside so it is not a misnomer to refer call them systems.

However, when we talk about ESL (electronic system level) in the context of chip design, we need to be humble and realize that the chip goes into something larger that some other person considers to be the system. Importantly from a business perspective, is that the people at the higher level have very little interest in how the lower level components are designed and it is technically hard to take advantage of in any case. The RTL designer doesn’t care much about how the libary was characterized; the software engineer doesn’t care much about how the language used for the RTL and so on.

At each level some model of the system is required. It seems to be a rule of modeling that it is very difficult to improve (autopmatically) the performance of a model by much more than a factor of 10 or 20 by throwing out detail. Obviously, you can’t do software development on an RTL model of the microprocessor; too slow by far. Less obviously, you can’t create a model on which you can develop software simply by taking the RTL model and reducing its detail and speeding it up. At the next level down, the RTL model itself is not something that can be created simply by crunching the gate-level netlist, which in turn is very different from the circuit simulation model. The process development people model implants and impurities in semiconductors but those models are not much use for analog designers; they contain too much of the wrong type of detail making them too slow.

When I was at Virtutech, Ericsson was a customer and they used (and still do, as far as I know) Virtutech’s products to model 3G base stations, which is what the engineers we interfaced with considered a system. A 3G base station is a cabinet sized box that can contain anything from a dozen up to 60 or so large circuit boards, in total perhaps 800 processors all running their own code. Each base station is actually a unique configuration of boards so each had to be modeled to make sure that that collection of boards operated correctly, which was easiest to do with simulation. Finding all the right boards and cables would take at least a couple of weeks.

I was at a cell-phone conference in the mid-1990s where I talked to a person in a different part of Ericsson. They had a huge business building cell-phone networks all over the world. He did system modeling of some sort to make sure that the correct capacity was in place. To him a system wasn’t a chip, wasn’t even a base-station. It was the complete network of base-stations along with the millions of cell-phones that would be in communication with them. He thought on a completely different scale to most of us.

His major issues were all at the basic flow levels. The type of modeling he did was more like fluid dynamics than anything electronic. The next level down, at the base-station, the biggest problem was getting the software correctly configured for what is, in effect, a hugely complex multi-processor mainframe with a lot of radios attached. Even on an SoC today, more manpower goes into the software than into designing the chip itself.

And most chips are built using an IP-based methodology, some of which is complex enough to call a system in its own right. So it’s pretty much “turtles all the way down”.

 

Posted in methodology, semiconductor | Comments Off

Guest blog: Doug Fairbairn 2

Posted on April 16, 2009 by paulmcl

This is the second of two guest blogs from Doug Fairbairn about Lambda magazine (which became VLSI Design) and the early days of VLSI Technology. The first blog is here.

VLSI Design, VLSI Technology

Amazingly enough, Xerox agreed to underwrite the second issue of LAMBDA, even though I had left the company. But that was the end of their largesse and I was on my own. Even though I was part of a new startup, VTI (VLSI Technology) was still in fund-raising mode and I had lots of time on my hands. I set about learning what it meant to be a magazine publisher, a business I had no clue about at the time.

Lambda coverFirst step—put the magazine on hold while I figured out a business plan. I journeyed to Anaheim CA, home of Disneyland to attend a magazine publisher’s conference. There I attended a seminar given by a guy I found was the guru of magazine startups. Following the Anaheim conference, I flew to New York City to meet him on his own turf…in a penthouse condo on Fifth Avenue. What was I doing here? He still sported the tan and shorts he was wearing when I saw him in California. He welcomed me into his home and gave me the instant course on starting a magazine…must have cost me thousands of dollars. But that was nothing. He told me I had to go see some marketing guru on Madison Ave. and have them put together a glossy promotional package aimed at determining if there was a market for my new publication. You know…the fancy envelope that comes in the mail with all sorts of full color promotional material and that letter signed in blue ink (the blue ink is important…generates more responses!) And don’t forget the sticker you have to remove from one piece and put it on the return postcard. A final complication was that it would take weeks to develop the package and there was no use mailing it during the summer as the return rates are too low… have to wait until September when people are back to work. OK – I’ve spent $20,000, been forced to wait until the fall, and I still don’t know if I have a business or not! I obviously didn’t know what I was doing. Then fate took control.

I was sitting in my home office, keeping myself busy while my magazine business was on hold when the phone rings. Some guy from Harris Semiconductor in Florida wanted to place an ad in the next issue! Uh… call you back! Now what? I don’t know if there will be a next issue! But wait, maybe this is it! A quick calculation shows I need $15,000 to pay the printing bill. If I sell 15 pages of ads for $1,000 each, I’ve got it covered. I called him back – sold him the back cover of the Fourth Quarter issue (never was a Third Quarter issue that year) and went to the work on the phones. I called all my friends and non-friends who I knew in the industry, and after 6 weeks of working the phones, I had it! Exactly 15 pages of ads! And what an issue! 80 pages of ads and quality editorial. Advertisers included Calma, Applicon, Sperry-Univac, Harris (of course) and many others. Jim Clark, Ron Rivest, Randy Bryant, Ed Cheng, and others who in the subsequent years would make major contributions to the field, authored eight featured articles. We were off!

Oh, what about the Madison Avenue circulation test? It went out in September, with results back in October and November. About the time our blockbuster issue hit the streets, Madison Ave. told me I had a loser. I hardly noticed. Had to get busy on the First Quarter 1981 issue!

About this time, VTI finally got funded, so I had two full-time jobs. There was never any doubt I knew silicon and design better than the magazine business so I gradually added staff to take over my duties at the magazine while I poured myself into the VTI startup. I had hired my assistant from Xerox back in 1980, added an ad sales rep by the beginning of 1981 and finally replaced myself primary technical editor in 1982.

There was one more magazine industry lesson I learned in 1981 – don’t be too clever when it comes to a name. In early 1981, I received a letter from Lambda Electronics saying that I was infringing their copyright and that I should cease using their name for the magazine. I had already discovered that although LAMBDA might seem like a clever name, it’s meaning was far from obvious to those who weren’t already “in the know”. People commented that they saw the magazine and assumed it was a power supply catalogue (that’s what Lambda Electronics made at the time). As I looked around, I discovered that magazines were normally pretty up front with their names: Newsweek, Playboy, House and Garden, Electronics, Electronic Times….you get the idea. So we took the opportunity to get off Lambda’s “sue ‘em” list and changed the name to “VLSI Design”.

The second form of outside recognition in 1981 was a little more positive. We were awarded a “Maggie” by the Western Publisher’s Association as the best Electronics and Data Processing Magazine. We joined the big time! The actual Maggie award is a true door-stop quality block of lucite which was a welcome recognition of the hard work we had put into launching the magazine.

In January, 1983 I woke up one morning and said to myself, “I can’t do this anymore!” Two startups are killing me! Again, fate played its hand. Within a week or two of this self-realization, I had two parties interested in buying the publication. By then it was a well-known, and well-respected industry magazine with a circulation in the 30,000 range. In February 1983, VTI went public. In May 1983, I sold the magazine to CMP Publications, the most respected electronics industry publisher of the day. We’ll put that down as a good year!

Outside of the excitement and learning around building a startup in an industry I knew nothing about I’m most proud of the impact the magazine had on the industry. It really did provide not only a communications vehicle, but a sense of community around these new ideas and helped speed their understanding and adoption. To this day I still run into people who have kept all their LAMBDA/VLSI Magazines. There clearly was something there beyond being another technical rag.

Posted in guest blog | Comments Off

Competing with free EDA software

Posted on April 15, 2009 by paulmcl

Chris Anderson (editor of Wired, owner of TED, author of The Long Tail) has a new book called Free coming out in July. One thing that he emphasizes (at least in his articles on the subject, I’ve not seen the book itself) is that “free” is very different from “really cheap.” If you are an Amazon Prime subscriber, whereby you get free 2-day shipping once you’ve paid an annual fee, or if you are an iPhone user whereby you get unlimited data access, you know that this changes your behavior. People instinctively know this when they sign up for monthly gym membership; most people would be better just paying the one-time fee each time they go but they know (or at least hope) that “free” will change their behavior and they will use the gym more.

Websites are increasingly “free,” meaning either that they haven’t yet found a business model, like Twitter; or that they are advertising supported, like EDN or plentyOfFish; or that they don’t attempt to make money on the website and exist for some other reason, like Wikipedia or Moveon.org.

Alternatively, many websites use what has become known as the “freemium” business model. A large part of the website is free, but if you want to get to the best stuff or want more then you have to pay. For example, flickr is free but if you want a lot more storage you have to pay; almost all games have some initial levels free so that you can start playing and only need to pay once you get in deeper.

One challenge in EDA is that the big companies bundle a lot of tools together for a single price, so effectively all of the tools are free (in the same way that going to the gym is free once you’ve paid the subscription). As planned, this makes it hard for small EDA companies to compete. Their tools haveto be so much better that customers will pay for similar tools that they already own.

I had lunch with Paul Estrada (a.k.a. Pi) a couple of weeks ago. He is COO of Berkeley Design Automation (which is obviously located in…Santa Clara). They produce a SPICE-accurate circuit simulator AFS that is 5 to 10 times faster and has higher capacity than the big company SPICE tools. For designers with really big simulations, that is a pretty compelling value proposition (over lunch instead of overnight). But for designers with smaller simulations and access to unlimited big company SPICE simulators, it is harder to convince them to even take a look, never mind open their wallets. However those slow big company simulators still tie up hardware (and circuit simulators are both CPU and memory intensive, so need the good stuff) and they keep expensive designers busy waiting.

So Berkeley recently introduced a block-level SPICE tool, AFS Nano, that sells for only $1,900. This literally saves customers enough in hardware to justify the purchase, even if they have a pile of big company SPICE simulators stacked up on the shelf. Oh yeah, and those expensive designers can get back to work. It is not quite the freemium business model (which would require giving AFS Nano away) but it is close. Like with the other models, Berkeley hopes the near-freemium AFS Nano will get customers interested in their big tools.

Another interesting book is What Would Google Do? by Jeff Jarvis. He examines lots of businesses and wonders what they would look like if you largely gave away everything to make the user experience as good as possible, and then found alternative ways to monetize the business.

EDA software is notoriously price-inelastic. It doesn’t matter how cheap your tool is, it has a relatively small number of potential users. You might steal some from a competitor, but overall the number of customers is not driven by the price of the tools in the same way as, say, iPods. So a free business model is unlikely to work unless there is a strong payment stream from somewhere else such as a semiconductor royalty. There is also a high cost to adoption in terms of training, setting up technology files and so forth meaning even “free” EDA software isn’t really free once you get it into use. So it is unclear what Google would do in the EDA space, other than not enter it since it is too small to be interesting to them.

Posted in eda industry, marketing | Comments Off

Economist on semiconductor

Posted on April 14, 2009 by paulmcl

Jerry Sanders, the erstwhile CEO of AMD, was famous for saying that “real men have fabs.” So of course it was interesting that AMD should be just about the first integrated device manufacturer (IDM) to go fabless when it sold off its fabs to Middle Eastern private equity that renamed them Global Foundries.

There’s an interesting article in last week’s Economist on the state of the semiconductor industry. They also have the view that there will primarily be three fabs, Samsung in memory, Intel in microprocessors and TSMC for foundry. The rest will be “nationalistic” ventures in need of regular government bailouts.

For instance, they open with a look at Saxony (Dresden) where there are two main fabs. Qimonda (bankrupt and unlikely to resurface in anything like its original form) and Global Foundries whose German fab I would describe as “not closed yet.” Part of the problem with fabs is that they have got too expensive even for governments to simply pour money into. Fabs are a capital-intensive business with long-leadtimes so they tend to be feast or famine. And right now in the current downturn they are famine. DRAM spot prices are a quarter of what they were a year ago; good money then, not so much any more.

One comparison that I hadn’t thought of is that fabs cost a couple of times as much as a nuclear power station. They are increasingly automated so don’t even create much employment, and with electronic systems increasingly removed from their manufacture, the high value part of the chain isn’t helped by having a fab nearby. “Designed by Apple in California and manufactured in China” as it says on the iPhone box. With, I believe, an Infineon chipset presumably made in Germany.

Europe, in particular, is in bad shape in semiconductor since it has so few fabless semiconductor companies (except in Israel, traditionally treated as part of Europe for the electronic market). European technology has always suffered from big company syndrome, especially in France and Germany. I once asked a senior executive at Bull (then a large not-dead-yet French computer manufacturer) why there were no equivalents of Sun Microsystems in Europe. “Because the European governments would pour money into Siemens and Bull to build workstations, and we’d be successful enough to kill off any small companies but not successful enough to win,” was the gist of his reply. Semiconductor is like that: it’s all NXP (the old Philips Semiconductors), Infineon (the old Siemens semiconductor division), and ST Microelectronics (a merger of French Thomson Microelectronics with Italian SGS). All European champions who have consumed any Euros available for investment without actually achieving a world-class scale (ST being far and away the most successful of the three).

With 18” wafers maybe on the horizon (but with the semiconductor equipment manufacturers balking since they haven’t even yet recovered the investment they had to make for 12” conversion) the price of entry into the fab world is only going to go up. Semiconductor delivers chips incredibly cheaply, but it is a mass production process. And the required mass is going up not down, meaning greater and greater returns to scale. Intel talks of only requiring a single fab for their entire production and wanting separate fabs mainly for risk reduction (fire, political instability, losing the process etc).

Posted in semiconductor | Comments Off

Lambda magazine issue #1

Posted on April 13, 2009 by paulmcl

For anyone who would like a copy, Jim Rowson has put up the historic first issue of Lambda magazine (all 36 pages) so it is available through print on demand at  http://magcloud.com/browse/Issue/13162. It is an interesting time capsule of the thinking when computer scientists first got their hands on the levers of IC design.

Posted in book review, silicon valley | Comments Off

Move up to software

Posted on April 12, 2009 by paulmcl

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

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

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

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

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

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

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

Posted in methodology | Comments Off