ChipAgents Transcript: How Agentic AI is Revolutionizing EDA and Chip Design Workflows
June 11, 2025 - Semiconductor Engineering Interview with ChipAgents
Understanding the Transition From LLMs to Agentic AI
Ann Mutschler: I am Ann Mutschler, Senior Executive Editor at Semiconductor Engineering. I am here at ChipAgents with Mahir Arora to discuss Agentic AI. Mahir, thanks for joining me today. Can you explain what agentic AI is and what it means for the chip designer?
Mahir Arora: Large language models, or LLMs, are an extremely recent technology, and AI agents are an even more recent technology. Neither has really fully propagated through the EDA landscape yet. To really talk about the difference between AI agents and LLMs, you kind of have to go back to exactly what LLMs are, some of their deficiencies in the hardware space, and then we can talk about AI agents and how that improves things ultimately downstream for hardware design engineers and verification teams. I think most people are familiar with LLMs from a practitioner perspective. Everybody has used something like ChatGPT to do things like draft emails, for example.
[Visual Description: Mahir stands in front of a whiteboard where he has sketched diagrams explaining the mechanics of large language models and the iterative feedback loop of agentic AI.]
Mahir Arora: I have written a little bit down on this whiteboard, basically explaining some core concepts about LLMs and AI agents. You will have to apologize a little bit for my handwriting here, but the core idea with LLMs is that they do something called autoregressive token prediction or autoregressive sequence modeling. The specifics of what that means are fairly straightforward. If you have a strong LLM, like GPT-4o for example, you can provide to it a question. The way you will provide that question is something like, question, what is 2 plus 2? This will then be tokenized. The exact method of tokenization is not too important, but the input is broken down into parts that the LLM can actually understand. Once you provide this input, you can also provide a little bit of a preamble, like, answer 2 plus 2 is. What LLMs are fundamentally trained to do is to fill in this end blank token here. There is some sort of unknown, a sort of mask, that is placed at the end, and they are trained to try and predict this token.
Mahir Arora: Concretely, mathematically, what LLMs do is predict a probability distribution. Given all the prior input tokens that we have, we want to try and predict what the value of the unknown is. Because you are going to get a probability distribution that comes out of the other end, and since we have a strong LLM that is good at this token prediction task, for 2 plus 2, it is going to strongly suggest that the output is 4. In my toy example here on the whiteboard, it is showing roughly a 99% chance of 4, a 1% chance of 5, and then a 1 in a billion chance of something like Madagascar coming up, because that is just a random word from the English language, or any other language in the case of multilingual LLMs. This is great for answering one particular question in this kind of contrived form where we have a prompt and just want to fill in the blank. But what if we want more than merely filling in the blanks?
Mahir Arora: In order to do that, we get to autoregressive sequence modeling. Auto means self, and regressive is basically going back to itself, which is why this is called autoregressive. The idea is that if I want my LLM to actually fill out an entire function for me, output a page of text, a whole essay, or a whole codebase potentially, I actually want it to go through the same process of modeling the potential output distribution of one token, but doing it many, many times. Here on the whiteboard, I have prompted my model with a couple of input tokens for a function called add, with an open parenthesis. Now I have the same problem as before. I have to predict this missing token here, which I have called mask. There are a couple of possibilities for the outputs. For example, we could have the token num1 come out the other end, or we could have a token like a come out. There is a probability assigned to each of these outputs. The magic actually comes from the sampling. Based on this probability distribution, we can sample a potential output token. For example, we could sample num1, or we could sample a. In this case, let us say we sample a. Now we take this token a, push it back into the input, and continue the process again. In step two, we have function add, open parenthesis, a, and now the problem repeats itself. We can just pump this straight back in to autoregressively model the next sequence.
The Power of Self-Reflection and Feedback Loops
Ann Mutschler: I was also going to ask you about self-reflection. How is that involved with this?
Mahir Arora: That is a great question. In order to talk about self-reflection, we have to talk a little bit about what happens once you go through n repetitions of this process. Once we have gone through n repetitions, we actually get to the full output, which might look like, function add, a comma b, return a plus b, and then it predicts a stop token to end the autoregressive process. What you will notice in this process is that when I make a decision, which is the sampling process where I choose to include a as my output, I have to live with that decision. When I am actually returning something later in the sequence, I cannot suddenly change my mind. I have to say return a plus b. I cannot say return num1 plus num2. Basically, past decisions can inform my future decisions, but the reverse is not true. What if I made a mistake in my sampling process? What if instead of a, maybe I just outputted a closed parenthesis? Well, now I am stuck. I am fundamentally going to output something incorrect. Information cannot flow in the other direction. How do you go from future decisions and impact past decisions? The direct consequence of this is that if I have incorrect past decisions, I guarantee incorrect future decisions, which guarantees an overall incorrect output. This directly ties us to self-reflection, refinement, and self-correction. That is what we really get into next, and this is where we can start to talk about agentic AI.
Mahir Arora: The first thing you have to understand about agents is that they sit on top of LLMs. They are a technology derived from LLMs, but agentic AI is about a whole process, not merely a single utilization of an LLM. To talk about agents, self-correction, and how they solve this problem fundamentally, we have to sort of set the stage.
Ann Mutschler: Can you go into more detail about what agents are?
Mahir Arora: Absolutely. In order to understand exactly what agents are, you have to understand that agentic AI is a process. It is not one single utilization of an LLM. What you are really going to see with agents is that they are LLMs coupled to a search process and, most critically, feedback. They use feedback to self-correct, to self-stabilize, and to actually execute and succeed where LLMs would normally fail. Let us walk through a little bit of a worked example. With an agentic process, you might have as an input to your agent an entire task. For example, I want to write a Verilog module, something like an asynchronous FIFO. The particulars of the module are not too important, but what we are going to do is proceed through a number of turns.
[Visual Description: Mahir points to the whiteboard illustrating a multi-turn agentic process featuring feedback from compilers, linters, testbenches, and waveforms.]
Mahir Arora: In the first turn, the agent is going to call an LLM to produce a potential output. It is going to produce a file for me, fifo.sv, in SystemVerilog, containing this module. But we still have all the problems with autoregressive modeling from before, which manifest in this first turn. The agent may set a set of input pins and decide on that, but later on, it might use a new input. It might not have defined a wire somewhere, but now it wants to use that wire. What is it supposed to do? If it is just an LLM, it will output this code, hand it to you, you will try to compile it and run it, it will not work, and that will be the end of the story. That is not what we want. We actually want reflection and feedback. The next thing that happens after turn one is feedback. Feedback can come in a lot of different forms. It can come from your compilers, your linters, or your testbenches. Assertions might fail, tests might fail, or there might be difficult outputs in your logs that suggest something is wrong, including waveform outputs. All of these things are outputs that the agentic process will examine. You feed this feedback back into the agent. The agent is going to examine this in the context of its prior output and synthesize that something is wrong. It will go about debugging it, figuring out how to fix that process, and then it repeats. We go through turn two where it fixes these problems, and then potentially we get more feedback. For example, there are more tests that are failing, or there are some waveforms that are inconsistent with what we expect from our golden reference model. The agent will go through and continue to fix that process. The ultimate end goal is that you do not just get one instance of attempting to produce a module, but you have a system that self-corrects and self-stabilizes through the process of feedback, ultimately producing a working, correct implementation.
AI Agents in EDA and the Verilog-Eval Benchmark
Ann Mutschler: How are agents going to show up in EDA tools?
Mahir Arora: That is a great question. At ChipAgents, we produce a product which is specifically designed for EDA, utilizing agents as part of your everyday EDA flow. The specifics of how they show up span all sorts of different use cases. One thing that is really important to note about agents is that the performance of LLMs in hardware compared to the performance of agents in hardware is dramatically different. There is a very common benchmark that is utilized called Verilog-Eval, which was built by Nvidia. What you will notice is that when you utilize a standard LLM on these benchmarks, where the task is to go from a natural language description to a functional Verilog module output, the performance is really abysmal. You can use a strong language model like GPT-4o, which does extremely well on Python software tasks, but it does abysmally poorly on Verilog tasks, getting approximately a 50% accuracy rate. A 50% accuracy rate is terrible. That is a failing grade, and we do not want to use technology like that. But it turns out that once you begin to wrap your LLMs in an agentic process, the performance shoots up enormously. You start to get closer to the 80% and 90% range. The system that I have been describing here represents these processes in their simplest terms, but you can do quite a lot to improve upon them. Ultimately, we can push the performance up to the 99% or 99.7% level. Through the use of agents, we have ended up saturating these benchmarks. While LLMs are not capable of this on their own, agents are.
Mahir Arora: This explains why LLMs have not shown up in hardware engineers' day-to-day flows, because standard LLMs are not reliable enough to be utilized in the sort of tasks engineers are interested in. AI agents, however, are reliable enough to be used in these situations. The most common way we see our customers utilizing AI agents nowadays is to do very rapid prototyping. If you are a design engineer, you want to explore a number of different microarchitectural decisions and evaluate power, performance, and area on all of them. You want to find the Pareto frontier and pick whichever one works best for your use case. But there is a lot of effort that goes into setting up those experiments. You have to handle build scripts, build harnesses, and simulation harnesses, and you have to integrate your module with the existing apparatus that exists to run these tests. Agents actually do a fantastic job here. You can provide your microarchitecture description to an agent, and it will go out and autonomously collect information from your repositories, documentation, specifications, and other modalities. It will extract that information and make a long-term plan about how to execute it. It will handle the implementation of the module utilizing the self-correction and self-stabilization we talked about to make sure that the module is high quality, and then it also does the hard work of integration. It will set it up so that it actually aligns with all of your existing infrastructure, run those tests, extract information from those logs, and then report back to you.
Streamlining Verification and System Analysis
Ann Mutschler: Mahir, you mentioned verification earlier, and that is a big challenge for every verification and design team. How will AI agents play a role there?
Mahir Arora: That is a great question. On the verification front, the reason why verification is so difficult is because of the exponential increase in the complexity of the chips we are interested in verifying. We are dealing with trillions of transistors at this point, billions on an individual System on Chip, or SOC, and trillions in the whole overarching system. How are you supposed to wrangle and maintain that complexity? The big problem that verification engineers have is that they must go out and build a mental understanding of everything about the subsystem they are working on verifying. You are not just verifying one module; you are verifying a whole subsystem at a time, and potentially a large subset of your SOC at a time. How do you extract all of that information in the first place? While it is very hard for a human to go through and read tens of thousands or hundreds of thousands of lines of code, that is something AI agents are very capable of. You can set an AI agent on an open-ended task, such as figuring out exactly how data flows through a complex system. That agent will make a hierarchical, long-horizon plan about how to go and find that information. It will look in all of these different locations, and even if it goes off and does not find information in a certain location, it will self-correct its own plan. It will use the gathered information to find where else to look, pull all that information together, and explain to you how data flows through the system. From that point, now that you know how data flows through the system, you have a much better idea of how to actually verify it, which edge cases you need to consider, and what stimulus you need to provide to the system as well.
The Day-to-Day Impact on Design and Verification Teams
Ann Mutschler: How is that going to look for the design and verification engineer today? What will they see in their day-to-day?
Mahir Arora: More broadly, this is really impactful for teams. AI agents work great in the hands of one person who has too many tasks on their plate. If you are on the design side, your main task might be putting together some sort of microarchitecture. If you are on the verification side, it is putting together a verification plan and trying to figure out how to intelligently navigate your system into all of these interesting conditions, constraints, and edge cases. But you also have so many additional tasks. You have to set up your testbench, set up the harness, and take your test plan and write it in terms of, for example, UVM, which requires writing a lot of UVM sequences. With AI agents, you can dispatch all of these tasks asynchronously in the background. You can have AI agents work on all of these tasks simultaneously.
Mahir Arora: For a verification engineer, the flow that we are often seeing today is that they will take the verification plan they have and an existing testbench, perhaps from a prior generation processor. They will provide those pieces of information to the agent and ask it to extend the testbench with the new sequences or features that need to be verified as specified in the verification plan. This is going to allow smaller teams to feel like much larger teams, and that is really exciting. We are a startup ourselves, and we work with lots of startups as well as very large corporations. Smaller teams are going to feel a huge force multiplier from the use of AI agents. Suddenly, a couple of senior engineers are going to feel like they are a team of senior engineers supported by a bunch of junior engineers to help them out, which is going to be very exciting.
Accelerating Onboarding for Junior Engineers
Ann Mutschler: I did want to also ask about junior engineers. How can this help them come up to speed more quickly?
Mahir Arora: That is a great question. The big problem with onboarding someone who is particularly green is that there is an enormous amount of code to actually work through. They have to build a mental model of everything about the codebase to figure out how to even begin to extend it or verify it. Understanding where everything is represents an exceptionally difficult task for a human being. We have human-sized eyeballs and we read at human-like speeds. LLMs and AI agents can read at far faster speeds, thanks to the underlying technology of LLMs which allows them to process things in parallel. Because of that, you can ask an agent how exactly the system works and have it do something like build a block diagram of how a particular data path works. AI agents can go off, find all the requisite information they need, and produce that documentation for you. That is a very common task that we see our customers do. It really does help with on-ramping newer engineers, making sure they have a solid mental model for how these processors and large systems work.
Addressing IP Security and Compute Constraints
Ann Mutschler: Security is an issue with AI. How does that look for AI agents and ChipAgents?
Mahir Arora: Security is always an important point. Everybody's IP is extremely critical. How do you actually maintain that IP security while still leveraging the huge productivity improvements of AI agents? This definitely depends enterprise to enterprise and customer to customer, because if you really want to use AI agents, you have to use a lot of compute. The best AI agents work with the best, largest base models that are subsequently fine-tuned on a large amount of agent training data, and those require really beefy servers. There will be some organizations that have that spare computing power laying around that they can use for agentic AI, but there will also be enterprises that need to go to the cloud in order to rent server time on very large GPU servers.
Mahir Arora: For ChipAgents in particular, we cater to all sorts of different customers. Some customers are more comfortable using our deployments in the cloud where we procure GPU time. We do inference for them, and the guarantees we provide are that all data is encrypted in transit and encrypted at rest, or only ever processed ephemerally in memory and then passed back to them. That is a compromise that works great for lots of different customers, including public companies. There are some very large companies that have very particular constraints, and they often ask us to deploy into their own cloud. It is very common for us to go to a customer who has an AWS account, for example, and they will provide us access for a brief period of time to set all of this up for them so they can utilize it internally.
Ann Mutschler: Mahir, thank you for all of these explanations.
Mahir Arora: Thank you very much for your time.