In a recent feature article at Electronic Engineering Journal, Kevin Morris asks Why are Design Tools So Bad? Or...What? Another Bug? You will have to read the whole piece if you want to see the entire argument, but here's a sort of summary: What we have, then, is a situation where development costs and tool complexity are exponentially increasing, the audience consuming them is mostly shrinking or staying constant (far fewer teams are designing custom chips these days), and the budgets for tools are roughly static. This is a difficult environment in which to build a profitable software business. First, let me say that this is my own opinion and not some sort of formal response from Cadence to Kevin's piece. If you feel like taking issue with something, it is "Paul said" not "Cadence said." This blog does not go through any signoff process inside Cadence. If you have only been in the restaurant and listened to, say, an earnings call of a large company then you have no idea what it was like in the kitchen the couple of weeks before where every word (literally) is scrutinized. I've been there and I'm glad I don't have to go in that kitchen any more, it's hot in there on the line. This blog does not get that treatment, thank goodness. Size of Teams Kevin says: First, there is an unfortunate effect from economy-of-scale. In consumer products, the vast size of the potential market justifies enormous investments in product development. If you work in consumer software or hardware, you feel this every day. Making and selling millions of copies of a thing profoundly affects the amount of time, money, and energy you can (and should) spend developing it. Of course, something as big as Facebook at scale has a big team of developers. But the early versions of Facebook, the versions that allowed it scale, were developed by relatively small teams. The same goes for the early days of AirBnB. Famously, WhatsApp had a zillion users and a dozen developers when Facebook acquired them. Instagram something similar. The first version of Gmail was developed by a single engineer. So eventually the size of the market justifies larger teams, but the early products, the ones that the customers loved so much that they made the company successful, had small teams. And it's not as if a company like Cadence has small teams on their big products. Kevin also says: Even with prices jacked up to the six-figures-per-year range for a term license (which many EDA tools enjoy), the funds that find their way back to engineering development are meager at best. Err...how about 40% of Cadence's revenue. To say "meager at best" is just incorrect (it was 38.2% last quarter to be exact). This is way higher than most software companies, because in EDA you have to redevelop everything at a pace unknown in, say, enterprise software. Also, the price of the software has something to do with what makes a good business and how much you can spend developing it, such as how big an engineering team. It is not just the number of licenses aka customers. When I was VP of Engineering at Ambit, Gordon Bell was chairman of the board and worked at Microsoft Research in his day job. Our synthesis tool was called BuildGates (Bill apparently was amused by this). Gordon explained how much a copy cost. Bill Gates couldn't believe it. I think a copy of Windows for an OEM at that time was about $7. "We need my volume and your pricing," he said. It's not all about the size of the customer base. Size of Customer Base Kevin says: What we have, then, is a situation where development costs and tool complexity are exponentially increasing, the audience consuming them is mostly shrinking or staying constant (far fewer teams are designing custom chips these days), and the budgets for tools are roughly static. There is some truth in this. But the number of tools is largely driven by the number of engineers and that has not been going down. On the other hand we're not partying like it's 1999. Consolidation in the semiconductor industry has not, at least so far, led to mass layoffs of engineers. Of course, it remains true that no engineer can do any chip design without design tools. Also, the idea that less than a dozen companies would ever do FinFET designs was wildly off. At the CDNLive Boston keynote recently, Tom Beckley revealed that over 160 companies are using Virtuoso for advanced FinFET designs. Bugs This is one thing that Kevin didn't mention: What is the optimal number of bugs? Obviously zero. Well, that ignores when you get the software. Even if it were possible to guarantee bug free software by, say, running some ten thousand CPU cloud-based regression for two years, customers would want the software with some of the bugs a lot earlier. Bug-free software too late is not obviously better than software with some bugs a lot earlier. I guess this is the design tool equivalent of General Patton's famous statement that "A good plan violently executed now is better than a perfect plan executed next week." In this business, there is an optimum moment to release software. Too early, and you have stupid bugs like not being able to read the technology files correctly. But too late, and the customers would rather have had it earlier with more survivable bugs. They have to get started, too. But that's precisely one reason why tools are so buggy: on the leading edge, the customers want them that way (and way back off the leading edge, the tools are pretty solid). Test Cases Another thing Kevin didn't mention, that I think is important, are test cases. There aren't any. Sure, there are test cases for all sorts of things, but for true leading-edge designs, there are none. How can there be? Let's look at 5nm. How many 5nm designs have been done? None. But Cadence still has to develop 5nm design tools and test them somehow. Some stuff can be tested by doubling up 7nm designs, but some can't. At some level, full testing can't be done until designs have been done since nobody knows exactly how those designs are going to look. As a result, the early designs have to be co-developed with the EDA companies so that the tools can be used, despite the bugs, to produce designs that can be used to test the tools to fix the bugs. The Unicorn Kevin says: The unicorn we’ve yet to locate is the team who feels that their design tools truly empower them—making their design better, their jobs easier, their schedules shorter, and their professional lives less stressful. Granted, that’s a lot to ask from a pile of software, but the kind of rabid enthusiasm many people show for a wide range of commodity products and services on which they depend is virtually nonexistent in the world of engineers and their tools. The economist Thomas Sowell has an aphorism that you should always ask, "Compared to what?" So if life with EDA tools is not making people rabidly enthusiastic, what are they comparing them to? iPhones? Tiffany diamonds? Arizona Iced Tea? These all have their rabid fans but you can't design chips with them. So let's ignore feelings and look at the facts. Can you honestly tell me that there is actually a design team anywhere in the world whose EDA tools are not "making their design better, their jobs easier, their schedules shorter"? And if you think there is, compared to what? Sign up for Sunday Brunch, the weekly Breakfast Bytes email.![]()
↧