DAC 2020: Open-Source EDA

The Department of Defense (and actually much of aerospace in general) is in an especially difficult place as regards access to silicon. Their production volumes are so low. This means they don't get great pricing from foundries, especially as most of the time they need to go to "trusted" foundries. But their production volumes are low so the math comes out in a good way. But for the cost of design, the numbers are moving in the wrong direction. If you are an automotive company and want 10M chips per year, a $60M design cost amortizes to $3 over three years. In a weirdly specific number, the US has announced it will buy 2,443 of the joint strike fighter JSF. That's less than a Front-Opening Unified Pod (FOUP) of 25 wafers for any one chip (wafer lots used to be 12 wafers, and for DoD in 200mm fabs probably is). 

One presentation at DAC this year was by DARPA program manager Serge Leef giving a pavilion (remember that?) Tech Talk on Can Open-Source Community Drive EDA Innovation?

The abstract for the talk says:

The EDA industry has always been led by the three big vendors with intense focus on the biggest and most sophisticated semiconductor and system companies who have historically benefitted for volume-based discounting. Midsize and small design houses don’t represent enough business to influence technology direction or get attractive pricing and are increasingly looking to open-source EDA as a potential alternative to the big three. While the academic community is enthusiastically pursuing technical advances in open-source design technologies, their incentives are different from what it takes to drive their innovative solutions into mainstream use cases. Are there strategies that can translate open-source EDA into viable solutions for the underserved user communities? Can open-source revive technology advances that have arguably been slowing in the last two decades?

I think that states the case too strongly. In any business, if you are buying tens of millions of dollars of widgets, be they design tools or cans of soup, then you'll get a better price than the company only needing $1M worth.

But it's not like "small and medium" companies doing design don't exist. After all, we are in an era when approximately a zillion deep learning fabless chip startups are designing chips with tools. As Wally pointed out in his own talk, there are over 500 electric car companies (and no, they are not all in China) and over 250 autonomous drive companies. Many of them are designing chips, and many are small, although to be fair, some are big well-known automotive names (OEMs or Tier-1s in the jargon of that business). Of course, with so many companies in what is a delayed market (partially due to technical safety challenges and partly because most of us are not using our cars much and unlikely to buy a new one soon) I think that the volumes for many of them are going to be lower than DoD levels, namely zero.

Serge actually talked about the market being divided into four:

• Huge semiconductor and system companies
• Startups
• Large commercial and defense companies
• Government ecosystem (FFRDC stands for Federally Funded Research and Development Centers)

One of the challenges is actually the way government contracting is done. For example, large defense companies "need to control costs". Well, at one level that is a truism for all businesses, but to say that a major defense company is too poor to purchase the tools it needs doesn't really pass any test. What is going on is that they can't bill the government unless they buy tools and IP on a per-program basis. Further, "lengthy negotiations through complex contracting" seems to sum up doing business with governments.

Open-source EDA development has taken place in academia for decades. SPICE was released in 1975 and other names like MAGIC or Timberwolf have been around almost as long (although I've not dug into the details of what is still open sourced). More recently, Jim Cherry's OpenSTA and the capitalized-challenged placer RePlAce are more modern open-source EDA tools. I wrote about these in my post OpenROAD: Open-Source EDA from RTL to GDSII. And there is a DARPA connection since this is a DARPA program led by Andrew Kahng of UCSD.

Serge talked about various programs that go under the name IDEA (Intelligent Design of Electronic Assets) and POSH (Posh Open Source Hardware). OpenROAD is actually part of the IDEA program. DoD actually has some unique problems, since they want to have their cake and eat it, too. They love open-source EDA because it is free, but at the same time they want to:

keep adversarial nation states from benefitting from this technology

There are lots of reasons that it makes sense to run EDA in the cloud, around scalability and control of access. But in another "having your cake and eating it too" scenario, Serge said that they need to be able to add plugins to open source tools, perhaps secret ones, without requiring to give them back to the community, to keep them away from our adversaries. This actually goes right against the philosophy of open-source tools that modifications get updated back into (today) Microsoft-owned Github.

Serge listed many of the challenges of adopting open EDA tool flows:

• Most academic tools are standalone or only connect to other academic flows
• Product quality is absent, tools only tested on demo designs
• Customer support/training nonexistent since grad students move on
• No channel to generate awareness that the tools even exist or deliver them

And I'll add a fifth bullet. There is very limited access to process design kits (PDKs), test designs, and all the other infrastructure needed to do a "real" design, not an academic one.

So who would do the work? DARPA does not do infrastructure. Linton Salmon, one of Serge's predecessors pointed out:

please don’t ask me why DARPA doesn’t do that. We don’t do infrastructure. If we did then we would still be stuck on some old infrastructure 30 years ago

So who is going to do the infrastructure? Who will put the flows together, test them, provide support, fix bugs in a timely manner? DoD has its own secure cloud (run by "a third party") so it has infrastructurer.

This slide is difficult to read (click on it to get a bigger version that is still hard to read). I'll list Serge's main suggestions:

• Small EDA PCB company
• Major cloud provider as an operator
• Major defense contractor
• Specialty design services company
• DoD domain specialist company
• Open-source distributor (think RedHat)

Here's the big challenge I see with all of this. If you look at a company like Cadence today, we spend close to 40% of our revenue on engineering. Even if you assume in the open-source world that most of the engineering is done for free by grad students, government employees, and others who are already paid, that still means that 60% of our revenue goes on the other stuff. While I'm sure there are lots of things we could do better, you might get it down to 50% on other stuff.

Finally, Serge's last suggestion was to attempt to disrupt the entire EDA industry from below. To follow Clayton's prescription, you disrupt from the low end with low-quality use (like using hydraulic excavators to replace people with shovels, not big state-of-the-art excavators for open-cast mining). In this context, "low-quality use" means the government (Serge's words, not mine!). That's the pink oval in his graph. Let me give you another quote from Linton Salmon:

Another challenge is that design teams in DoD are small, and they only do one design every few years. That means that they never get good.

That sounds like a problem, too. All our military electronics are designed by people who "never get good." Meanwhile, there are many people who "got good" and tun out smartphones, ADAS, servers, AI chips, heart pacemakers...but don't do defense work. As I said above, one of the challenges is the way we do our government procurement. Thirty years ago, on a visit to Lockheed in Sunnyvale, a guy told me that they make more money on the paperwork than actually doing electronic design. It seems they got good at that bit.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.