ChipAgents Transcript: Accelerating RISC-V Design and Verification with AI Agents
May 28, 2025 - RISC-V International Presentation
The Growing Complexity Gap in Semiconductor Design
Mehir Arora: Can people hear my voice? Does this mic work? Okay, this mic works. Fantastic. All right. My name is Mehir Arora. I am from ChipAgents.ai. We are an AI electronic design automation, or EDA, company, really one of the first. We are focused on agentic AI for hardware chip design and verification, and I will explain exactly what that means during this presentation.
Our ultimate goal stems from a core problem that everybody is experiencing. 30 years ago, you might have been working with 10,000 logic gates, but today you are at least working with 10 billion logic gates. We have seen an exponential increase in the complexity of chips. We have seen an exponential increase in demands. Yet, there has actually been a shortage of hardware engineers. There is no exponential increase in hardware engineers to match the exponentially increasing expectations that are being placed upon hardware teams now producing full-size SOCs. These are really enormous systems, potentially reaching trillions of logic gates for the very largest-scale AI systems now being produced.
Our goal is that smaller teams using AI agents will be able to compete with teams that are 5 times their size. In about 1 year from now, that number will be more like 25 times the size. We are going to see teams of 5 really being able to go up against teams of 25, or teams of 20 to 30 or so going up against teams of 100 to 150. We have a lot of different use cases, all of which are enabled by agentic AI, which means that you can actually delegate an entire task in an end-to-end fashion to these systems. It will carry them out for you asynchronously.
Targeted Use Cases for Agentic AI in Hardware Engineering
Everybody wants to hear about the use cases, so I will demonstrate a couple of them for you in just a second. They do not take too long. Some of our core standout use cases stem from the fact that this is a very general product with a lot of different capabilities. One of the really interesting things is that you can do things like read your regression logs. Maybe you are running lots of nightly regressions. You can read the log outputs, your waveforms, your design under test, and your testbench, and the agent can actually determine autonomously the root cause of those problems.
There are also great things like reading specifications, be they internal specifications or very large protocols that are mature and openly accessible standards. You can take those specifications and then produce entire verification plans for the whole design. You can also read that verification plan and produce things like UVM coverage models, sequences, and checkers. Additionally, you can read the microarchitecture or a SystemC architecture, and then you can implement and integrate new SystemVerilog modules. We enable all of these new flows.
State-of-the-Art Benchmarks and Academic Foundations
Everybody is very interested in the performance, so I will briefly talk about the performance. Our team originally came out of academia. Our founders are professors and graduate students from UC Santa Barbara. I am also a UC Santa Barbara alumnus and came from the research side as well. The initial work was done on something called SWE-bench, which is a very famous benchmark for AI agents focused on Python programming. The verified version of this was put together with Princeton and OpenAI. Our founders set the leading results on this SWE-bench benchmark, and now we have moved over into hardware.
The slide on the screen shows a table talking about Verilog-Eval, which is a benchmark produced by Nvidia for agents working on register-transfer level, or RTL, tasks. We set the state-of-the-art results on this benchmark a couple of months ago. This is our task now: taking this academic work and productizing it. I am going to give you a quick demonstration of our system. Just to clarify exactly what the demonstration will be about, we are going to do a root-cause analysis, and then we are also going to talk about test plan and UVM coverage model generation.
Live Demonstration: Waveform Root-Cause Analysis and AXI Test Planning
For the demonstration, I have an Advanced Encryption Standard, or AES, module, which is an encryption module. It is currently broken, and we want to find the root cause from the waveforms. Concurrently, I also have an AXI protocol specification that I got from ARM, and I want to put together all of this verification collateral. I will do that for you right now.
On the screen, I have Visual Studio Code open. ChipAgents is our flagship product, and we deploy it as a command-line utility. While I am open in Visual Studio Code, we have a terminal open on both the left and right-hand sides. Since we only have 10 minutes, I am actually going to run these demonstrations in parallel.
The first demonstration I am going to talk about has to do with this AES encryption module. The problem we have is this AES module here, which is just the top module for it. There are a couple of other modules as well. I also have a testbench. This testbench is very quick. It has just this first testcase here and these second two testcases. The problem is that the first testcase passes, but the second one fails. It is a particularly nasty problem, but luckily, I have a waveform corresponding to the trace output of this run.
This is my interface to ChipAgents, which is entirely based on natural language. I will enter my command to ChipAgents in full natural language. Let me make sure I am in the correct directory. I will take this prompt and move over to the ChipAgents AES directory. There we go. I will open up ChipAgents and provide the prompt there, giving the agent the information that the first testcase passes and the second fails. I want it to use the waveform in order to figure out what is going on.
Concurrently, let us also take a look at this AXI protocol. This is a 300-page specification that I downloaded from ARM's website for the entire AXI protocol. What I want to do is read the protocol specification and write a markdown test plan. I also want to write the UVM coverage model and the UVM sequences, and I want a couple of different things about those sequences based on some general requirements. I am going to hit enter there as well, and it is going to kick off the entire process. I am running these two things in parallel because we do not have too much time, and this way, I get to talk about plenty of what is going on here.
Detailed Debugging of the AES Encryption Module
Let me first talk about the waveforms and their capabilities. You will see that the agent is examining testbench.vcd. One of the first questions we get is: what other waveform formats do you support? We support FSDBs, and many other different waveform formats are on the horizon. Right now, we support FSDBs through the Verdi waveform viewing libraries.
You can see that the agent is analyzing this waveform file. It is viewing a number of different signals involved in the waveform VCD, and it is also viewing a number of different files, including the actual core components of the AES encryption module.
While that is running, let me resolve a directory issue for the AXI specification. I was in the wrong directory for that one. There we go, that is the AXI specification. Now I will prompt it to read the AXI specification and write a markdown test plan, UVM sequences, and a coverage model. I swapped my directories there by mistake, but that is okay because the waveform analysis is actually already done. This result is very, very interesting.
Let us go through and look at the waveform analysis. To reiterate, what ChipAgents is actually doing is reading the waveform. It reads the different files associated with the AES, and from there, it actually executes a root-cause analysis. This is the waveform analysis that has come out on the other end. The main issue is actually in the state machine of the AES-128 encrypt module. In the add round key stage, when the round counter is actually equal to NR minus 1, which represents the final round, it correctly sets the ciphertext and correctly sets the done flag, but it incorrectly sets the stage to sub bytes instead of idle. That is the core problem.
The agent even gives me evidence within the waveform. It provides the exact picosecond timestamp of interest, where it tells me specifically about the done signal and also about the stage transitioning incorrectly. It tells me the other timestamps that I can look at as well to examine the ciphertext. Right here in the output, it is showing me how it is cycling 4, then 1, then 2, then back to 4 again, when it should be transitioning to stage 0. It highlights the actual root cause in the code between lines 80 and 90. The bug is shown quite visibly. This line here needs to be changed to 0, and then it tells me about the impact as well.
Finally, ChipAgents summarizes our results, and you can see that it has completed the entire root-cause analysis autonomously. This is very exciting to us. We have multiple commercial customers who are already using ChipAgents in this style—taking the regression outputs from nightly regression runs, feeding the waveform and the design under test files into ChipAgents, and then isolating the root cause.
Automating AXI Test Plans and UVM Sequence Generation
But that is not the only thing ChipAgents can do, although it is very exciting. Other things ChipAgents can do include putting together this entire test plan for me, which it has been working on in the background. Let me accept the creation of this file, and then I will walk through exactly what is going on. What ChipAgents was doing as we were going through the rest of this was working on the AXI protocol. It read this AXI protocol, checked the table of contents, checked the main AXI channels and their purposes, the AXI transition types, and the key aspects. Now, it has put together this very large-scale AXI test plan for me. In the meantime, I also asked it to create these actual UVM sequences.
In brief, I am going to talk about the actual AXI test plan. I am going to format it here in markdown for everybody to view some of the capabilities. You can see that what it has done for me is enumerated the test plan nicely in these markdown tables. That was my request; I wanted it to be in markdown. It captures all of the different specific details about the AXI interface. For example, here is all of the information about the channel handshakes and all of the different handshakes that are done on all of the channels. Here is clock and reset, the write request channels, and the write data channels.
I can scroll down a little bit to some more interesting things. We have got all these different burst types enumerated in the AXI as well, along with different memory attributes, different protection and security types, transaction identifiers, request orderings, and exclusive and atomic accesses. There is a lot of information that it had to pull out of this specification. This specification is 300 pages, and the agent has put together this verification plan for me right before your eyes. This did not exist before; none of the collateral existed before.
We have tested this system on arbitrary scales, arbitrary sizes, and arbitrary numbers of documents. You can provide it with thousands of pages; Ethernet has 3,000 pages, for example. ChipAgents handles that just fine and will produce test plans for you, or you can query against them to determine information about those specifications. This is also quite useful when you query other very long documents, potentially entire codebases. For example, on the verification side, a big bottleneck is understanding the RTL. You can feed hundreds of files into ChipAgents, and it will comb through all of them and return answers to you about dataflow.
At the same time, ChipAgents has put together this very long set of transactions for me. Let me scroll all the way up so I can find the path. Here are the UVM sequences. We can do all sorts of different parts of the UVM testbench, but I will just showcase the actual sequences. This is an 800-line Verilog file just produced for you, pulled out of thin air from nothing more than the specification and the test plan that was produced by it. It contains the base sequences, the write sequences with a number of different constraints, the read sequences, and so forth. I can continue to scroll through this, but you will see that all of these sequences directly align with the actual test plan that is in place.
The Future of Electronic Design Automation
ChipAgents is going off and doing plenty more as well. To summarize in brief, we are the only company in the world right now who is tackling this important problem in electronic design automation. The core problem in hardware is that there are exponential expectations on hardware teams. People need to be able to handle huge amounts of information and data, and then tabulate and convert it into huge amounts of verification collateral. They need to do a huge amount of debugging and a huge amount of design.
We built this system, and it helps teams feel like they are 5 times their size or 10 times their size. That is what we have been tasked with, and this is the progress we have been able to make so far. We have lots of commercial customers already utilizing ChipAgents. This is the future of EDA, and that is why we are excited to build it. Thank you very much.