20 Comments
User's avatar
The RF Architect's avatar

This seems like a good thread to share what Robert Fennis has been doing with EMerge. Ton's of amazing Python libraries out there, but for electromagnetic numerical methods I didn't find any success with the open source libraries. EMerge is open source and an efficient finite element method (FEM) solver that I've found good agreement with Ansys HFSS: https://www.emerge-software.com/. EM simulation is one key aspect of RF chip design.

Expand full comment
Vikram Sekar's avatar

Open EMS is pretty popular.

https://www.openems.de

For HPC-level EM, AWS Palace is quite capable though hard to use.

https://github.com/awslabs/palace

Expand full comment
The RF Architect's avatar

I tried open EMS without much luck in accuracy. I think many of us tend to stick with tools we trust and given the expense of fabrication trust is paramount. It also doesn't seem like it's being updated - though I've seen some people try to carry the torch with updates. I'll have to check out AWS palace.

Expand full comment
CitizenSleeper's avatar

Awesome conclusion. I have been saying again and again that the tools are the biggest hindrance to make "thousand startups bloom". Also the mindset of people in the traditional chip industry is horrible.

For eg: I have rarely seen any of my colleagues "complain" about the tools being used or even thinking that there needs to be a change. All they do is grind through the issues or "workaround". All these workarounds ends up being tribal knowledge. So you can see that this grind ensures their job security and safety. Working with such people is really suffocating. Not accepting the status quo was what made the American chip industry boom!

Also the crap hardware tool workflows leak into software. Seeing horrible unmaintainable perl scripts to automate and validate, it really takes the interest out of development.

I thought the new graduates who enter into the industry would at least feel that a change is needed but no. All they do is embrace the grind! They accept that the tools are sent from God and use it unquestionably without thinking twice that there can be an alternate solution. Mind you, I am not asking them to write one, just to think which does not cost any money!

Also working in Embedded software in a traditional chip company is a sure shot way to kill your skills. The only thing they do is iterate on the existing IP, drivers etc. with very little innovation. It is much better to work in companies which actually use these chips to solve a problem who will anyway discard all the BS firmware and write their own to have better control.

Who will make the next "mkBoom"? I am betting on Chinese companies. With all the tariffs and sanctions, I see industry and research institutes collaborate and invest in developing their own EDA tools with their own fab ecosystem. Many of the tools are also open source too. Also writing EDA tools is not the most difficult thing, the ecosystem around it and all the validation is the difficult and painful part. So actual usage of alternate tools rather than the traditional ones will force this ecosystem to take notice and accept.

Expand full comment
Natasha Jaffe's avatar

Are the software tools all 3rd party? Is anything developed in house?

Expand full comment
Vikram Sekar's avatar

Almost entirely third-party from the big three companies: cadence, Synopsys, and Siemens.

Expand full comment
Natasha Jaffe's avatar

Does anyone actually startup new chip companies? It almost sounds like creating a new company and following Boom’s embedded model would be more likely to succeed then convincing existing, entrenched companies to buy new 3rd party products?

Expand full comment
Vikram Sekar's avatar

6 reasons why its hard to induce change in the EDA industry:

1) the foundry design kits which these tools are built around are secretive, which makes it hard to design good workflows. there is no standardization between design kits.

2) companies have built up infra in the "standard" tools for decades, they are reluctant to change unless absolutely necessary.

3) the big-3: cadence, Siemens, Synopsys either buy smaller tool makers and integrate it into their workflows (often shoddily) or simply sue them.

4) chip design is inherently complex, and requires retooling of multiple sub-domains (thermal, electrical, electromagnetic, process,...) for things to really change.

5) chip designers are surprisingly opposed to change, and are willing to grind with the old ways. they also consider their skills are trade secrets, even if the tool is outdated.

6) if it isn't broken, why fix it? chips going wrong is an EXPENSIVE affair. if its over a choice of tool, its not worth it.

Expand full comment
Natasha Jaffe's avatar

😞

Expand full comment
Vikram Sekar's avatar

But yes, there are many chip startups but they mainly use the major tools anyway, because thats what engineers use — and they need to ship product fast — so they just go with the software tools they know.

Expand full comment
Vikram Sekar's avatar

Very well articulated. I agree on all accounts. It is incredibly frustrating to work with IC design tools.

Expand full comment
Engrvip's avatar

EDA tools today feel overly complex and tightly controlled by few big vendors. What the industry really needs is a breakthrough like when iOS and Linux shook up the operating system world. That shift pushed Windows to modernize. Without a similar push in EDA, we’ll keep using tools that feel stuck in the past, like old Windows software from 90s, while everything else around us has moved forward.

Expand full comment
Vikram Sekar's avatar

Yes, all tool interfaces in EDA are extremely outdated and pose significant obstacles in getting the job done quickly. There is very little motivation for new players in the market due to the large market share from the big three EDA vendors.

Expand full comment
Engrvip's avatar

Do you see potential for major disruption or breakthrough in EDA industry? Could open-source EDA tools be developed to a point where they rival commercial EDA in capability and reliability? Dominance of commercial EDA players seems even more entrenched than that of foundries at one time considering that fabrication now has multiple options, except at cutting-edge leading nodes held by tsmc.

Expand full comment
Vikram Sekar's avatar

With the rise of AI, there are many EDA start-ups who are focusing on the use of LLMs for the chip design, and it is a great time for the EDA industry compared to the several decades before.

However, I don't see anybody completely rethinking the way we do things from the ground up. I would imagine it is going to be met with a lot of resistance by the chip industry due to the large amount of design lock-in into older infrastructure.

Expand full comment
Engrvip's avatar

I agree, but think real starting point has to come from foundries. Unless they release more PDKs publicly or make them open-source without NDAs, it's hard for developers to move forward. Right now, biggest challenge is that most developers don’t have access to foundry PDKs, which limits their ability to build or improve EDA tools. If PDKs were open, AI could help convert them from commercial SKILL or Python-based PyCells format into usable forms. Then EDA developers could use these PDKs to build tool features from ground up. At the moment, the tight embrace between foundries and commercial EDA vendors is the biggest roadblock.

Expand full comment
The RF Architect's avatar

Yes there is a very tight embrace between EDA vendors and foundries. Though, I think the foundries would need to release details about the process and circuit models rather than the PDKs specifically. Generally the EDA vendor creates the PDK (at least in my experience developing PDKs though it may differ by industry) because it is so tightly integrated into their specific software (geometry creation, circuit model, EM simulation, fabrication files). Essentially the foundries "let" the EDA vendors develop kits for their processes - mutually beneficial but prevents EDA innovation. Further complicating some U.S. based processes are ITAR restrictions, etc.

Expand full comment
The RF Architect's avatar

Perhaps my experience of the EDA vendor creating the PDK is not the norm. It was with a "smaller" though not new RF/Microwave EDA tool which unsurprisingly is now part of one of the larger EDA vendors. Either way the foundry or EDA vendor likely needs to share information (potentially proprietary) and likely have a team maintaining and developing the PDK. If this is the case, this could be a play for a disruptive EDA tool. Make a better tool that also makes the experience of actually creating and maintaining the PDK easier.

Expand full comment
The RF Architect's avatar

I appreciate the concept of leveraging software and hardware engineers to help solve problems and to encourage all engineers to code. However, having used LLMs for coding problems seeing them confidently give incorrect answers, it's scary to think an aircraft manufacturer is encouraging every engineer to leverage AI. Might be great marketing, but safety is paramount and how much would you trust that safety critical things aren't broken?

Expand full comment
Vikram Sekar's avatar

Whether the code is AI-generated or not, there always needs to be safety checks in place for all aspects of engineering before shipping. This applies to both hardware and software domains alike.

Expand full comment