Every DAC brings a new wave of AI announcements. The harder question comes after the keynotes: who actually controls the data, the tools and the workflows that AI agents need to do real engineering work?
Our Co-Founder and CTO, Sirish Kumar Munipalli, took on that question in a post-DAC conversation on Wearing Flip-Flops, a semiconductor podcast for chip designers and verification engineers hosted by industry veteran Ronen Laviv. The episode covers where EDA and AI are heading, what independent AI tools still need from the big EDA vendors, and whether simulation, UVM and the waveform viewer will survive the next two years.
This was Sirish's second appearance on the show. In his first, AI in verification, build vs buy, he discussed when it makes sense for a DV team to build its own AI agents and when that turns into a second product nobody wanted to maintain. Below are the highlights from round two. You can watch or listen to the full chip design podcast episode here.
[H2] Meet our CTO
Sirish leads technology at Moores Lab AI, at the intersection of AI software and semiconductor systems. He brings more than 15 years across software, silicon and AI, with engineering roles at Qualcomm, Intel and Microsoft, including hardware emulation and SoC development at Intel and production-grade hardware and system validation at Microsoft. He began his career on FPGAs and also writes for the Forbes Technology Council. Meet the rest of our founding team.
[H2] Do the big EDA vendors have an AI edge?
Ronen opened with the obvious question. Synopsys, Cadence and Siemens control the simulators, and with them a huge amount of engineering data. Does that give them a head start in AI that nobody else can match?
Sirish did not dodge it:
"They have a very significant advantage, and I don't think anyone should underestimate them."
The big three have spent decades building world-class simulation, verification, synthesis and debug tools, and those tools generate exactly the data AI needs. They are naturally positioned to embed AI into their own environments.
But a real chip project does not live inside one vendor. It moves from specification to architecture to RTL, then into verification planning and regression, and those workflows routinely cross multiple tools and vendors. AI embedded in a single vendor's environment helps, but it cannot see the whole flow. That cross-vendor gap is where a workflow-level AI layer earns its place.
[H2] What AI agents need from EDA tools: feedback and waveforms
So what would make the ecosystem work better? Sirish's answer was specific: expose more of the tool data through MCP or APIs. Two examples stood out.
Coverage closure needs a feedback loop. Writing a new cover group or sequence is not the end of the task. The agent has to modify the testbench, rerun the tool, check the output and confirm that coverage actually improved. Without that feedback, agents cannot do a good job.
Debug needs the waveforms. Logs get you most of the way, but tracing a failure back to where it really started is better done with waveform data. It also builds trust: when an AI agent shows its result on the waveform, the engineer can judge it quickly. The missing piece today, in Sirish's view, is a proper waveform interface for third-party tools. Whether the big vendors have a business reason to open it up is a separate question, and Ronen raised it on the show.
[H2] How Moores Lab AI plans to stay ahead
Ronen asked what we are doing to stay ahead one, two and three years down the road. Sirish laid out four principles:
- Stay laser-focused on one domain. Today that is verification, extending into design and firmware. Every day our team thinks about specifications, RTL, coverage, regression, waveforms and debug. That depth is hard to replicate without a strong multidisciplinary team.
- Stay lean and iterate fast, while keeping the customer experience high on both support and tooling.
- Orchestrate, do not just automate. "Most AI products today automate individual tasks. We focus on orchestration," Sirish said. The goal is a platform of agents where teams pick the stages they need, from writing tests at the testbench level to running debug, with full end-to-end automation as the destination. He was candid that we are not there yet, and that we have a plan to get there.
- Be open by design. Our tools run inside the customer's own environment, on-premises, and never on our cloud.
[H2] Partnerships and the long-term vision
Chip development already depends on many vendors: design tools, verification tools and a long list of IP providers. Sirish sees partnerships as essential to delivering a strong result for customers, across both the semiconductor and the AI ecosystems. He pointed to our partnership with Breker Verification Systems to build an AI-driven PSS (Portable Stimulus) solution for SoC verification, with more partnerships in the pipeline at the time of recording.
Looking further out, Sirish shared an ambitious goal: to eventually operate as an AI-native fabless product company alongside our tools, so that more companies can build their own chips by bringing a product idea to us. The focus today is digital design, with analog on the roadmap.
[H2] Will UVM survive? Predictions on languages and testbenches
Sirish debates this one regularly with our advisor Tom Fitzpatrick, a long-time leader in SystemVerilog and UVM standardization. His view: as LLMs become more capable, the choice of language matters less, but UVM is not going away. Too much verification IP is built on it.
"UVM will exist in parallel with any new hardware languages that evolve. It won't go away."
Python and software-style testbenches will grow where the chip calls for them. At an earlier AI accelerator startup, Sirish's small team bridged Python and SystemVerilog to verify an image-detection pipeline whose AI models were written in Python, with tests written on both sides. Open-source approaches such as Chisel and Scala are gaining popularity too, partly because LLMs understand software-style code better. He explored the same theme in his Forbes Technology Council article, Evolving Hardware Languages in the Age of AI and LLMs.
On the design side, Verilog and SystemVerilog will stay. Sirish expects design to be the hardest area to transform, because RTL has to be translated into a netlist with many optimizations further down the flow.
[H2] Debug, waveforms and the case for an open standard
Sirish's wish for debug is industry-wide: a consortium and an open standard for debug data. Today the biggest challenge for anyone building AI debug tools is getting data in a structured form, feeding it to the LLM and correlating it across sources. Debug is never just one log file. It means matching failures against the RTL and against the intent in the spec. An open interface would let everyone build AI solutions faster.
Will engineers still need the waveform viewer? Sirish agreed there will be fewer waveforms for humans to review, and that for AI, simulation and waveform data will likely be transformed into representations LLMs handle better. Engineers will still want to look at high-level waveforms to see the system working. The viewer becomes mostly a tool for humans, not for AI.
[H2] Will we still need simulation? Yes, and more of it
Ronen pushed the provocative version: could an LLM simply read the spec and the RTL and report a bug on line 20, with no simulation and no formal verification at all?
For complex SoCs, Sirish's answer was a clear no. Simulation may become less critical for small blocks, but in the end you are verifying code, and:
"The way you can verify code is by running it."
Unless an AI could analyze every path through a design, simulation stays in the loop. And here is the twist: better AI makes simulation more important, not less. The more simulation runs an agent can execute and learn from, the better it gets at debugging and the higher the quality of the final code. Asked about the future bottleneck in verification, Sirish was direct: simulation speed. A faster simulator lets LLMs run many simulations, gather more information, reanalyze the data and even fix the design.
[H2] What productivity gains should chip teams expect?
Today, the biggest gains come from removing tedious manual work: searching for data, correlating results with specs and going through waveforms. Debug that used to take days or weeks can come down to hours or even minutes.
Across a full project, the answer depends on the chip. For IoT-class designs built mostly on standard interfaces, Sirish believes AI that has learned those standard protocols could help teams finish a chip in roughly six months. For something as complex as a high-end GPU, the gain shows up differently: more testing in the same schedule, and a higher-quality chip at the end.
[H2] Protecting customer IP
Security came up, as it always does with chip design data. Our position has been the same since day one: we never train on customer data. Our products run on the customer's premises, with no communication back to our cloud or services. The only external piece is an LLM API key hosted on the customer's own cloud infrastructure, under the customer's compliance, and customers can also run models on their own GPU clusters. Every interaction and every piece of generated data stays within the customer's environment.
[H2] Listen to the full episode
Wearing Flip-Flops is a hardware and verification podcast covering chip design, EDA, AI and the semiconductor industry, with guests from across the ecosystem. If you work in design verification or chip design, it is worth a subscription. Sirish also promised Ronen a live walkthrough of our flow in a future episode, so stay tuned.
- Full episode: Who owns the AI chip design stack? on Wearing Flip-Flops, also on YouTube, Spotify and Apple Podcasts.
- Round one: AI in verification, build vs buy.
- See it in practice: book a demo with our team.
[H2] FAQ
Do EDA vendors have an advantage in AI for chip design?
Yes. Synopsys, Cadence and Siemens own decades of simulation, verification and debug tools and the data they generate. But real chip flows cross multiple vendors, so no single vendor's embedded AI sees the whole workflow. That leaves room for independent AI that orchestrates across tools.
What do third-party AI verification tools need from EDA vendors?
Structured access through MCP or APIs, especially a feedback loop on coverage results and an interface to waveform data for debug. Sirish also called for an open industry standard for debug data.
Will UVM be replaced by AI or Python testbenches?
Not anytime soon. Most verification IP is built on UVM, so it will exist in parallel with Python-based and other software-style testbenches, which will grow where the chip calls for them.
Will AI remove the need for simulation?
Not for complex SoCs. AI agents improve with more simulation runs and feedback, which makes simulation speed the next bottleneck in verification.
Does Moores Lab AI train on customer data?
No. Our products run on-premises at the customer, with no communication back to our cloud, and the LLM endpoint is hosted on the customer's own infrastructure.
Where can I listen to the episode?
On Wearing Flip-Flops, the semiconductor podcast hosted by Ronen Laviv, and on YouTube, Spotify and Apple Podcasts. Episode #009, 28 minutes, published August 4, 2026.
