Home >
Systems & Design >
From Tool Agents To Flow Agents

Systems & Design

From Tool Agents To Flow Agents

The industry has already demonstrated gains using AI in tight iteration loops, but how does that evolve to cover larger portions of the development flow?

April 30th, 2025 -

By: Brian Bailey

Experts At The Table: AI is starting to impact several parts of the EDA design and verification flows, but so far these improvements are isolated to single tool or small flows provided by a single company. What is required is a digital twin of the development process itself on which AI can operate. Semiconductor Engineering sat down with a panel of experts to discuss these issues and others, including Johannes Stahl, senior director of product line management for the Systems Design Group at Synopsys; Michael Young, director of product marketing for Cadence; William Wang, founder and CEO of ChipAgents and professor at the University of California, Santa Barbara; Theodore Wilson, a verification expert pushing for this development; and Michael Munsey, vice president of semiconductor industry for Siemens Digital Industries Software. What follows are excerpts from that conversation. Part one of this discussion can be found here. Part two is here.

L-R: Cadence’s Young; Synopsys’ Stahl; Siemens’ Munsey; ChipAgents’ Wang; Theodore Wilson.

SE: What’s the path forward toward a digital twin for the design and development flow? How do we get to the dream of having AI able to do the mundane tasks, or being able to optimize the design and the productivity of development teams? Does the industry need interfaces? Does it need standards? Is this something that EDA companies can handle, or does this need to be developed outside of EDA? What are the next steps?

Munsey: A combination of all of that. EDA vendors cannot provide everything. They can provide tools and interfaces, but it’s a combination of all because customers are trying to create systems that are differentiated from their completion. The EDA vendor will not have all the knowledge to provide what the end customers are trying to do. There will be some in-house development, as well as a combination of the models they are getting from their end customers. It is a combination of in-house development and putting together the methodology and the process, which will be put together by customers.

Young: It comes back to motivation and connecting that to a business model. The business model has to work. Otherwise, it would just fall apart naturally. The challenge is because of different organizations, different companies. There’s non-EDA and there’s EDA. You look at some of the companies out there that have a trillion-dollar market cap, while EDA has a much smaller market cap. I also would argue that not every company wants to share their secret sauce. If Company A can do something much better than Companies B and C, they probably don’t want to share that and put that into a standard. They want to be able to control those outcomes so they can have an edge in the market. In the pure sense, I love the idea because it means there are people thinking like an engineer should. The motivation is very clean, very pure. It’s hard to cut through that layer. How do you make that motivation and the business model drive across the industries?

Stahl: There’s no general answer across the industry. Every company will build their own methods of optimizing the overall flow, because it really depends on the problem space, their teams, team compositions, many different factors. History shows that they are driving the EDA industry with the most pressing problems as part of the overall flow. They put pressure where the cost pressure really manifests itself. As an example, many companies will say, ‘We can go into the cloud. We can expand our compute capacity. That’s not really our problem. Our problem is, how can we help them quickly find that bug in the software? How can I optimize something faster?’ They say to us, ‘I’m willing to spend the money, but help me to find that faster.’ Our customers will tell us where it is pressing. They probably will continue to tell us that we have to optimize the mundane tasks for the individual tools, and maybe across a few tools, like in the area of coverage. But the big optimization loop that exists inside the company, they will do that themselves. Maybe they’re asking us to improve the interface from this tool to this other tool, but they will want to build it themselves. They cannot share their differentiation in how to get things to market. It’s really part of the differentiation.

Munsey: The path forward certainly comes down to interfaces and standards. However, developing a standard can take decades. What’s most important is maintaining an open infrastructure — one that allows for experimentation with different tools and methodologies. Ensuring access to data that can be mined for multi-objective optimization is crucial. This ties back to the concept of a digital twin for the product. The decisions being made involve multi-domain solutions. Consider any software-defined product. You’re dealing with software, semiconductors, ECAD for PCB design, wiring harnesses, and mechanical design. It’s one thing to optimize semiconductors, but what about optimizing the relationship between software and semiconductors within a larger product? For example, how does this impact product design, whether it’s hydraulic systems in a car or a plane, or cooling strategies based on PCB layout and overall product structure? These decisions span multiple domains, requiring a solution that integrates all aspects of design to enable true optimization.

SE: One of the problems that has been reported is that every tool vendor puts out error messages slightly differently. They’ve been writing large language models in Perl to try and get the necessary data out of the tool before they can do something. Surely this is low hanging fruit for an area where interfaces and standards would be helpful? Let’s get natural language out of the interface and make it a direct interface to AI agents or tools that can directly work on, and get unambiguous data, rather than looking at a report.

Stahl