1 Introduction↩︎

The design of modern computing systems is a challenging and labor-intensive endeavor. Architects, system designers, compiler engineers, and VLSI specialists must navigate enormous design spaces while reasoning across several abstraction layers, including software, architecture, microarchitecture, and physical implementation. Pushing the limits of co-design across these layers remains an important challenge and opportunity.

Recent advances in agentic artificial intelligence offer an opportunity to accelerate the pace of innovation in both hardware design and at the hardware/software boundary. For example, in November 2025, Gupta et. al. [1], [2] demonstrated the ability to harness AI to automatically generate new state-of-the-art microarchitectural components (cache replacement policies) using the context of established design championships. As another case-in-point, Krishna, et. al. [3], [4] recently demonstrated the generation of a 5-stage RISC-V microprocessor design from scratch using agentic AI. Computer architecture has clearly entered a new era, wherein humans, agents, and existing hardware design tools must all smoothly operate together [1], [3], [5]–[19]. This is a tall order, considering that constructively composing hardware design tools was a challenge even before the application of AI. Moreover, while the aforementioned studies show interesting achievements from applying AI to hardware design and HW/SW co-design problems, they present early and individual points in the space of potential AI-driven design flows. How to design the most effective AI-driven design flows remains a critical open question.

Naively deploying existing hardware design workflows is not sufficient to tackle this question. The quick-and-dirty approach of writing bespoke scripts that glue together the output of one tool into the input of the next tool (or AI model) breaks easily and does not scale well to large AI-driven design flows on hundreds of heterogeneous machines (CPUs, FPGAs, GPUs, etc.). Shifting from script writing to building a distributed and scalable implementation of each bespoke AI-driven design flow is error-prone and imposes immense engineering cost, even with AI-assistance. AI agents can also orchestrate design flows themselves, sometimes desirably so. However, relying strictly on agents to orchestrate the entire design flow (e.g., letting a coding agent “run wild” inside system-on-chip design frameworks [20]–[23] or microarchitectural simulators [24]–[29]) makes it challenging to enforce verification and validation requirements that are critical to successful hardware design while minimizing human review overhead. Though several design flows have been proposed (e.g., evolutionary coding agents, multi-agent collaborative environments, etc.), they still prescribe a single design pattern, rather than enabling the expression of arbitrary AI-driven hardware design flows. Altogether, there is no good option for productively expressing and reliably deploying new agentic AI-driven hardware/software co-design flows, which hinders the progress of the field.

We built CHIA¹ to address this problem. CHIA is an open-source, agent-forward hardware/software co-design framework built on the premise that the productive construction and scalable deployment of the co-design flow itself should be a first-class objective. CHIA enables agile and principled research on the application of AI to co-design by making complex AI-infused workflows easy to express, deploy, and study.

In CHIA, the expression of a design flow is called a "CHIA loop"², which is a directed cyclic graph whose nodes execute various system-on-chip design tools, microarchitectural simulators, software build systems, AI models, evolutionary coding agents, and more. The CHIA library includes node implementations for many widely used tools, including Chipyard, gem5, ChampSim, FireSim, Hammer (and thus several commercial ASIC CAD tools), Vivado, AlphaEvolve, AdaEvolve, and many others, allowing researchers to compose sophisticated flows from reusable components rather than from scratch.

Beyond composition, CHIA provides the features needed to conduct principled science around these flows. These include isolation between AI models and hardware tools, profiling mechanisms, and fault tolerance and reliability at scale across hundreds of heterogeneous systems. Together, these capabilities allow co-design experiments to be run reproducibly and at a scale that makes meaningful evaluation of agent capabilities possible.

To showcase CHIA, we present five example CHIA loops as case studies: (1) automatic, agentic generation of a representative gem5 model for BOOM; (2) LLM-driven implementation of microarchitectural features in RTL in an out-of-order superscalar RISC-V microprocessor, BOOM [30]; (3) agentic, IPC-aware critical path optimization; (4) evolutionary architectural discovery flows (à la [1], [2], [6]); and (5) maintainer-friendly automatic GitHub-issue fixing in the CIRCT compiler project [31]. Throughout, we hold the agents to a high standard of verification and validation. For example, when RTL changes are made, we show that RTL implemented by the agents delivers substantial performance improvements while successfully executing the entire 25+ trillion instructions of SPEC06-Ref within a complete out-of-order superscalar microprocessor (BOOM) in a RISC-V system-on-chip (Chipyard) [20]. These gains are achieved while meeting or improving frequency and area constraints in both open-source and commercial ASIC PDKs.

These case studies are not an exhaustive demonstration of what CHIA can do. Rather, we offer them as an instructive set of examples that illustrate the framework’s capabilities and that we hope the community will build upon. CHIA will be open sourced in the coming days and we are excited to see what the community builds upon it.

2 CHIA Design Goals↩︎

In this section we highlight the capabilities we want CHIA to provide to its users, to enable them to build productive, agile, AI-driven design workflows.

In an agentic loop targeting a task like the hardware/software co-design of a domain-specific accelerator, agents can significantly reduce the time to perform many relevant tasks, from profiling to RTL implementation. Moreover, agents, unlike humans, are able to perform these tasks at huge scale and can implement tens and even hundreds of designs in parallel. Such massive parallelism is what many LLM-guided search and optimization algorithms, including evolutionary algorithms, leverage. At such a large scale, brute force scripting or bespoke construction of an entire distributed design flow for each new approach becomes infeasible. CHIA’s graph-based loop abstraction must allow users to build parameterized, massive-scale design pipelines simply.

At this scale, classic distributed computing challenges such as task scheduling become important. Tasks in hardware design loops occupy a wide range of latencies, from milliseconds to days, and have diverse and strict resource requirements, such as FPGAs for simulation or GPUs for model serving or ASIC CAD tools. Similarly, node failures will impact jobs more frequently at this scale. The nodes in CHIA loops should be flexibly and fault-tolerantly scheduled onto a dynamic and heterogeneous substrate.

As a project progresses, an architect may use many different tools, each with different input and output shapes, and organize them in many different ways. A naive approach that pieces together different tools using bespoke scripts or programs becomes brittle at scale and increasingly difficult to extend as a workflow grows more complex. CHIA should be modular, and should provide plug-and-play support for many different co-design tools with various input/output formats.

Additionally, control flow in a design loop is not always easy to define statically. In an agentic loop, this may manifest as explicit conditional logic guiding the flow. But, as the capabilities of agents improve, their own ability to guide flows can be leveraged to adapt a workflow on the fly. CHIA must be able to express programmatic and agentic decision making, and as agents become more capable and potentially more trustworthy, the framework must be able to tune the agent’s decision making control.

AI-driven design brings new opportunities, with radically reduced time from idea to design, but also new challenges. A growing body of work investigates the capabilities of various agentic loops to tackle hardware/software design problems. However, we need principled methods to evaluate these loops. Metrics should be built into agentic platforms for trustworthy and simple data collection. In addition to introspection to improve the loop itself, data collection is also invaluable for evaluation of the design generated by the flow. CHIA needs data collection and profiling of both results and of the loop itself built in as first-class citizens.

Together, these requirements enable us to perform agile and productive experimentation on agentic loops targeting co-design.

3 The CHIA Workflow Abstraction↩︎

A CHIA project is called a workflow, and is composed of a CHIA cluster and a CHIA loop. Clusters are physical machines and software environments where work is executed, and loops are programs which orchestrate a pipeline of hardware and software design tasks. In this section, we illustrate the CHIA design abstractions which constitute loops and clusters, with the help of a running example.

3.1 Running Example↩︎

Figure 2 shows a simple example of one way an architect may use CHIA. Specifically, this workflow uses an agent to write a new hardware module in RTL which achieves higher performance than an existing reference implementation. The steps of the workflow are as follows.

1. Prepare inputs: The architect starts with a reference implementation whose performance they want to beat without losing functionality. Next, they write a prompt with the specification of the hardware module, and prepare a suite of unit tests that can be used to verify the functionality of the module.

2. Agentic implementation: The loop takes the user’s prompt and passes it to an agent. The agent attempts to write hardware matching the specification.

3. Simulation: The loop then compiles a Verilator simulator from the implementation, which is used to run the user’s tests. To maximize parallelism, Verilator runs are split across three workers, two of which run on public cloud machines. Some longer benchmarks are run in FPGA-accelerated simulations using FireSim [32].

4. Evaluation: An evaluator node examines the results of the simulations and determines if the performance threshold is met. If it is not, then the loop restarts. Feedback is provided to the agent, and it continues iterating until the evaluator determines that a stop condition has been reached.

We will use this example in the next few sections to understand CHIA loops and clusters more concretely.

3.2 Clusters↩︎

Each step in a CHIA workflow may require different physical resources, such as different amounts of memory and different types of accelerators. Similarly, each step may require different software resources, like credentials, dependencies, and isolation, necessitating different environments. CHIA clusters provide the functionality to support these diverse requirements simply and efficiently.

3.2.1 Physical Machines and Logical Workers↩︎

A cluster starts with a collection of physical machines onto which users plan to distribute the tasks in their CHIA loop. In Figure 2, these machines are numbered CPU1 through CPU3, FPGA1, and AWS1 and AWS2. These machines provide heterogeneous physical resources, including different amounts of memory, different processors, and in this example, one machine has an FPGA while the others do not.

On top of these physical machines, users specify a set of logical workers. A logical worker’s definition includes a set of resources which are virtualized representations of the hardware and software environment which a logical worker provides. Nodes in the CHIA loop specify the types and quantities of the resources that they need to run, and, using Ray [33], the CHIA runtime schedules these resource requests to logical workers in the CHIA cluster. This abstraction of resources allows users to abstract certain machine-specific information from the CHIA loop.

Concretely, the Firesim_Runner logical worker in our example workflow defines a resource called "FPGA", which the FireSim Sim node requests. Similarly, the LLM logical worker defines a resource called "claude_code", virtualizing a Claude Code binary and credentials, which the LLM API Call node requests.

3.2.2 Containerization↩︎

CHIA supports and encourages placing logical workers inside of containers. Containerizing workers provides a number of benefits to a workflow. Most importantly for an AI agent-forward platform, containers provide isolation between different workers. An LLM finding and copying from the example workflow’s reference implementation of the hardware module would violate the integrity of an experiment. Even worse, an LLM operating in an insecure environment could access privileged information like proprietary PDKs. Assuming a non-adversarial, but potentially erroneous or unreliable LLM, containerization provides this isolation. We do not account for malicious LLMs in our threat model.

Additionally, containerization streamlines first-time cluster setup. Containers front-load and automate a large portion of the one-time setup cost, allowing clusters to be brought up much faster than they otherwise would. For instance, setting up a fresh Chipyard environment for the Chisel Builder worker in our example workflow would normally take nearly an hour, but CHIA’s Chipyard container takes seconds to setup.

Containers also make clusters portable, so CHIA clusters can be deployed on a diverse set of physical machines. For instance, not all machines will have Vivado installed, but the example’s Bitstream Builder worker can build a bitstream in a container with Vivado on any machine with sufficient computing resources.

3.2.3 Public Cloud Machines↩︎

CHIA clusters can be split across on-premises/owned computing resources and remote/rented computing resources from the public cloud. This way users can leverage the compute resources they own, while still scaling their experiments. In our example loop, we leverage AWS to run Verilator on more tests than we otherwise could with just on-premises machines.

3.3 CHIA Loops↩︎

A CHIA loop is a Python program which orchestrates a sequence of tasks required to achieve some hardware or software design-flow related goal. We represent a CHIA loop as a graph, where nodes are the tasks that need to be performed and edges are the data and control flow between tasks. The loop for our running example is described by the graph in Figure 2.

3.3.1 Nodes↩︎

A CHIA node is a Python function that performs a step in a hardware/software design pipeline, often by invoking some underlying hardware or software design tool. Each node in our example flow executes an application and performs some postprocessing. For instance, the bitstream build node runs Vivado and collects build logs and results.

When a node is defined, it is tagged with the resources that it requires from the worker it executes on. Nodes are scheduled and dispatched when all of their inputs are ready and there is a logical worker with sufficient resources to satisfy the node’s request. Once the node can be scheduled, its arguments are serialized and sent to the worker where the node will execute.

Nodes can return control immediately to their callers with a future which can be used to collect their results later. This makes it easy to parallelize work and can be seen in our example workflow, where we can start building a FireSim bitstream at the same time as kicking off multiple Verilator simulations.

Nodes are the basic unit for retry, caching, bypass, subprocess tracking, and profiling, as described later in Section [sec:runtime].

3.3.2 Edges↩︎

Edges represent data and/or control flow in a CHIA graph. Depending on whether the caller of a node is an AI agent or a line of code in the CHIA loop’s Python orchestration program, an edge can either be agentic or programmatic. Any data/control flow that is explicitly specified in the orchestration program of the loop is termed a programmatic edge, such as the edge between the Build Chisel and Verilator Sim nodes in our example. An agent using a tool call to run a node, instead of the node being explicitly initiated by the orchestration program, is called an agentic edge. In our example workflow, the edge between the LLM and Chisel implementation nodes is an agentic edge. CHIA provides first-class primitives for executing nodes from both programmatic and agentic edges, and users can define any node to be run both programmatically and agentically, or only one or the other. By supporting these two types of edges, CHIA generalizes across a broad spectrum of agentic design patterns that vary in the amount of control and decision-making entrusted to the AI agent.

4 Design↩︎

5 Case Studies↩︎

We demonstrate CHIA’s capabilities through a series of case studies that showcase the flexibility and productivity advantages of the framework. These case studies cover a wide variety of workflows that are critical to research and development in computer architecture and systems. These include:

1. Generating a representative gem5 microarchitectural simulator from RISC-V BOOM RTL.

2. Implementing RISC-V ISA extensions in an OoO core

3. Automated critical path optimization in an OoO core

4. Agentic discovery of microarchitectural structures with evolutionary coding agents

5. Addressing GitHub issues in the CIRCT compiler in a maintainer friendly way

5.1 Automatically generating a representative gem5 microarchitectural simulator from RISC-V BOOM RTL↩︎

High-level microarchitectural simulators like gem5 [24] are widely-used tools for exploring architectural ideas. Unfortunately, there is no easy way to accurately map a full RTL description of a processor to a microarchitectural simulator. Large teams dedicate many engineer-hours to keeping simulators up-to-date and validating alignment with their microprocessor implementations [18], [34]–[36]. For small teams and academia, this maintenance is not feasible, and microarchitectural simulators either fall out of alignment, or do not exist for RTL implementations.

We developed a CHIA loop for deriving a gem5-based microarchitectural simulator from an RTL description of a processor, as described in Figure 3. Our pipeline gives an agent (Claude Code with Opus 4.6) access to the source of a gem5 processor core and a gem5 configuration file (where parameters and constants are specified for the core). In each iteration, the agent is asked to modify the architecture and microarchitecture of the gem5 core (not just parameter tuning) to align its performance more closely with a target processor’s RTL.

The agent’s updated gem5 implementation is executed, and its results are compared to RTL simulation results collected in Verilator. Results are saved into a database, and the parent for the next iteration is chosen based on the most aligned entries in the database. In each iteration, the agent is provided access to this database, including pipeline traces and performance counter results from previous gem5 runs and RTL simulations. We include in our prompt instructions for how to analyze these pipeline traces and performance counters the way a human architect would.

As shown in Figure 4, over 202 iterations (about 10.5 days of wall-clock time) our CHIA loop modeled a Chipyard SoC [20] with a 2-wide MediumBOOM (Berkeley Out of Order Machine) core [30], [37] in gem5 to within 3% cycle count error on a training suite of 36 benchmarks taken from the Microbench suite [38], each designed to stress different parts of the core. We hypothesized that a large suite of small benchmarks requires a more accurate alignment to reach performance parity than a small suite of large benchmarks, since performance overestimates and underestimates cannot cancel each other out. In reading the LLM’s chain of thought, we find that its success arose from comparing pipeline traces and performance counters between the Verilator results and the gem5 results. It was able to use the diverging metrics to correctly identify misaligned structures and align them. The final aligned core has a diff of 1520 lines of code (excluding comments and blank lines) relative to the baseline gem5 RISC-V OoO core.

None

We used the Embench IOT 2.0 benchmark suite [39] as a withheld and hidden test set to evaluate the quality of our alignment—the agent in the loop does not know Embench is used, cannot see the Embench suite’s source, and cannot see its Embench results. In Figure 5, we show that average misalignment is less than 7% in our best iteration on the holdout benchmarks, though there are a few outlier benchmarks.

None

We attribute these outliers primarily to two effects. First, we see instances of overfitting to some of the training set of microbenchmarks. For example, one of the later iterations introduced a parameter kSuppressThreshold{.c++} which suppresses a branch prediction penalty in the gem5 core after a certain number of times the penalty is applied. The agent explicitly stated that the parameter was tuned "with a threshold calibrated to [training benchmark]’s inner loop," to more accurately align that one benchmark. This is the same iteration which introduced a sharp degradation in alignment for the Embench Wikisort benchmark, as can be seen in the bottom right of Figure 6. The second effect is that our suite of training benchmarks does not capture all potential states of the core. For example, only one of our benchmarks exercises the core with a working set of code larger than the instruction cache. We plan to explore different benchmarking strategies to improve alignment on withheld benchmarks.³

On average, each iteration of our loop cost $11.72 in Claude API credits, as seen in Table ¿tbl:tab:gem5stats?. We split reporting according to whether the agent could use the "Run & Compare MCP" tool as described below, as the token usage changes significantly based on whether that tool was used.

The Power of CHIA: We see the power of CHIA around entry 110 in Figure 4. At this point in the flow, we were not satisfied with the amount of iterations which were regressing overall alignment. To remedy this, we gave the agent the "Run & Compare MCP" tool, as shown in Figure 3, which gave it the ability to test its gem5 changes on its choice of our training benchmarks. This tool, which was implemented in a single hour, allowed the agent to empirically determine whether its changes were helping and adapt on the fly, which dramatically increased the number of iterations that improved alignment. Not visible in the final results, however, is how easy it was to try many different remedies to address the plateauing results in parallel. In the course of a single day, CHIA’s flexibility allowed us to try multiple different strategies for parent selection, prompts for the alignment agent with different selections of information, LLM effort levels, new MCP tools (the "gem5 Build MCP" was introduced shortly before the "Run & Compare MCP"), and more, before we introduced the "Run & Compare MCP", which ended up being the most effective.

5.2 Automatically implementing RISC-V ISA extensions in an RTL OOO superscalar core↩︎

Proposing and evaluating microarchitectural improvements is a fundamental part of computer architecture research. Cross-stack approaches often propose new ISA extensions backed by additional microarchitectural features. In either case, implementing these features in RTL and evaluating them on substantial benchmarks in FPGA simulation while collecting ASIC quality-of-result data is the gold standard for evaluation in architecture research. However, despite recent advances in agile hardware design [20], realizing this evaluation loop can be challenging for both small chip design teams and pathfinding teams in large companies.

To tackle this challenge, we develop a CHIA loop to implement ISA extensions in RTL for the 4-wide MegaBOOM core in the context of a complete Chipyard SoC. We target the RISC-V Bitmanip [40], Crypto [41], and Zicond [42] extensions.

First, we demonstrate that in each case, the loop produces a correct implementation, as validated by successfully running substantial benchmarks.

For Bitmanip and Zicond, this includes all 25.5 trillion instructions of the SPEC06 [43] reference suite, while demonstrating substantial speedups (5% and 3.8% respectively). For Crypto, we demonstrate 10x speedups on OpenSSL benchmarks (200 billion instructions). We also demonstrate that these implementations do not cause critical path regressions in either the SkyWater 130nm process [44] or a commercial 16nm process, and add only modest silicon area in both cases.

The CHIA loop takes the specification of a given extension and a formatted list of all of the new instructions and produces a functional and verified implementation with area and timing results. CHIA allows us to make the loop’s target highly customizable: a user could implement any extension specification on any core. To do so, the loop only needs to be provided with two pieces of verification collateral: a golden reference functional ISA-simulator implementation (e.g., Spike for RISC-V) for co-simulation and the set of instructions that the core can execute, including the ones to add. The latter collateral will be used by a random test generator to produce a set of random mixes of instructions for functional verification. This collateral is straightforward for the user to implement and provides the basis for verifying the generated RTL.

It is important to note that, within the CHIA loop, verification is as rigorous as in any other open source or academic flow. While the LLM is in charge of implementing and debugging the RTL, the user is still responsible for providing the golden references. CHIA lets us completely isolate the LLM from the verification infrastructure, preventing the agent from modifying the verification infrastructure in any way that would be considered cheating. In fact, the LLM knows nothing about this infrastructure, it only receives the necessary traces and information to debug the RTL.

The loop logic is divided into different stages as depicted in Figure 7.

5.2.1 Stage 1↩︎

The first stage consists of a loop with an LLM node in charge of producing the main RTL implementation of a given extension. The LLM uses the user specification to iterate on the RTL. A small set of generated tests that covers the entire repertoire of new instructions is run before moving to the next stage. In parallel, the loop initiates generation of random tests and synthesis of the initial RTL implementation. These random tests consist of long mixes of instructions generated by riscv-dv [45] and constitute the basis of Stage 3 verification.

5.2.2 Stage 2↩︎

In this stage the loop checks for any major regression of the base ISA. It relies on the upstream RISC-V ISA tests [46] and in case of an error it goes back to Stage 1 with a trace of the failing test.

5.2.3 Stage 3↩︎

Only when all instructions execute correctly does the loop move to stage three. It relies on numerous random tests, which were generated in parallel to Stage 1 and 2, that stress the new instructions in combination with the existing ones. In case of divergence it goes back to Stage 1 with a different debugging prompt and the failing test to iterate on an RTL fix. The loop also launches ASIC synthesis of the RTL implementation in this stage.

With this CHIA loop we automatically implemented and evaluated three new RISC-V extensions in MegaBOOM [30], [37]; Bitmanip (Zba_Zbb_Zbc_Zbs), Crypto (Zbkb_Zbkc_Zbkx_Zknd_Zkne_Zknh) and Integer Conditional (Zicond). Figure 8 represents a summary of the loop evolution constructed using data collected with the CHIA profiler. The timelines show how different nodes were launched and executed while running the loop, and the pie charts on the right show the share of total machine-time per node. Note that some nodes such as simulation and generation run on many machines, while others like synthesis and the LLM run on just one.

Leveraging CHIA’s scalability, the loop runs on several heterogeneous machines and enables us to harness as much compute as we need from the cloud, in addition to our local cluster. Bitmanip and Crypto have been implemented on a shared cluster that contained 28 machines (a total of 1024 cores) distributed across both our machines and AWS’. While the LLM implementation phase is lightweight, proper functional verification requires significant compute power to run all the spike co-simulation nodes. In fact, as we can see in Figure  8, co-simulation represents between 50% and 66% of total machine usage and test generation between a quarter and a third. Zicond was implemented on a smaller cluster of 12 machines and 256 cores, yet its implementation and simulation run considerably faster given that it is the simplest of the three extensions.

The loop synthesizes both the MegaBOOM [30] baseline and the LLM implementations on top of the baseline using the same CHIA synthesis nodes as the loop in Section 5.3. The area overhead when synthesizing in SkyWater 130nm [44] is around 2% for Bitmanip, less than 5% for Crypto, and is negligible for Zicond. When using a commercial 16nm PDK, the area overhead for Bitmanip is 3%, for Crypto is 6%, and for Zicond is 0.8%. We see no regressions in timing with either PDK.

We have evaluated these extensions on different benchmarks, all of them booting Linux and running in FireSim[32].

1. Bitmanip: We evaluate Bitmanip’s implementation on the entire SPEC06 reference suite [43], executing over 25 trillion instructions. Compiling SPEC with gcc 13.2 we obtained an overall speedup of 5.6% over the baseline, as seen in Table 1.

2. Crypto: Crypto is evaluated using OpenSSL Speed [47], a benchmark designed to test the performance of different cryptographic algorithms’ performance. The metric used in these benchmarks is throughput—given an input size, it measures the amount of times it can execute a given algorithm. Figure 9 shows the speedup over baseline for different input sizes (x-axis) for different OpenSSL algorithms. The reason for us not to use SPEC06 reference [43] is that it contains no Crypto instructions.

3. Zicond is evaluated against SPEC06 ref.[43] too, compiled with gcc 16.1 provided that previous versions do not emit Zicond instructions. Table 1 shows the per-benchmark breakdown improvement and an overall geomean speedup of 3.8%.

Finally, we have also collected the cost in dollars and tokens of running the loop for the three implemented specifications. The results can be found in the Table 2.

The Power of CHIA: CHIA enables us to leverage LLMs for specific tasks (processing the specification, making an implementation or debugging) without losing any control in phases where we cannot tolerate the LLM making mistakes (performing verification and performance evaluation, or collecting synthesis results). CHIA also allows each stage of the workflow to be designed using the most suited approach. An example of this can be found in our 3-stage division (see Figure  7) where each stage has been constructed with different goals and principles. Still, they all integrate seamlessly in a single functional workflow. Another aspect of CHIA that has made this loop feasible is its ability to harness compute resources from across different physical clusters. In this specific case we have used a mix of on-premises and cloud machines. Verification is computationally intensive, as seen in Figure  8, so we have divided it across clusters, while other tasks depend on specific licenses that only exist on-premises. CHIA handles the complexity of making these clusters appear as a single pool of logical resources that the user can employ to run the nodes of any loop.

5.3 IPC-aware automated critical path optimization in an out-of-order superscalar RISC-V core↩︎

A processor’s maximum operating frequency, and thus its maximum performance, is most directly limited by the longest latency (critical) path which must be traversed by a signal within a single clock cycle. For this reason, optimizing a processor’s RTL to minimize the length of this critical path is an important engineering problem. However, breaking down a single long chain of logic without affecting the functionality of the processor can take days of focused human effort, requiring a complex understanding of the signals involved and how they interact with the processor at large.

We developed a CHIA loop to take on this task for the 4-wide MegaBOOM core [30], [37] in Chipyard [20]. Our loop is described in Figure 10. The loop takes a timing report from running a parent iteration’s final BOOM core through a commercial gate-level synthesis tool on the open-source Skywater 130nm PDK [44], and provides it to the Claude Code CHIA library node using Opus 4.6 as the underlying model. For the first four iterations we asked the agent to reduce critical path with no impact on IPC, but after results plateaued, we changed the focus to iron-law performance (asking the agent to reduce the critical path with as small an IPC reduction as possible). This meant writing a new prompt and turning on IPC collection in the CHIA Verilator nodes, only a few lines of code in CHIA. The LLM in our loop is provided a bash shell in the Chipyard codebase for exploring and editing BOOM, a tool to confirm that BOOM rebuilds correctly, and a tool to run synthesis on small modules within BOOM as a way to test its ideas. Once the LLM is satisfied with its changes, the loop (without AI involved) rebuilds BOOM, and runs it through a large suite of benchmarks in Verilator to verify functionality is unchanged, and to estimate impact on IPC. In parallel, we synthesize the modified BOOM core for area and timing estimates. At the end of each iteration, we persist our results in a SQLite database.

We ran our loop until it reached a frequency plateau (less than 5 active days, at less than 8 hours per iteration on average), and during that time it more than doubled the frequency at which we could run the MegaBOOM core in Sky130 [44], from around 47MHz to around 95MHz in our best iteration (iteration 7, see Figure 11).

For our final measurement of how much IPC was lost, we compare the IPC of iteration 7 with our baseline on all 25 trillion instructions of the SPECint 2006 reference benchmark suite using FireSim [32] (not shown in Figure 10).

The IPC reduction on the SPEC06 ref. suite between the baseline and iteration 7 was 3.28%, which is very similar to the IPC reduction we see while running the flow with smaller benchmarks in Verilator (3.20%). This yields a net Iron-Law speedup of 1.97x, nearly a doubling in overall performance. Additionally, we use the SPEC06 runs (over 25 trillion instructions) as validation that the optimizations implemented by the agent did not degrade the functionality of the core. Table 3 shows the token usage and cost for running this loop per iteration and in total.

After iteration 7, we see that results generally were flat or regressed. Analyzing the synthesis reports, we find that this plateauing occurs because at this frequency the core is somewhat balanced, with many distinct paths with the same latency, with endpoints spread across the frontend, the load-store unit, and the data cache. On the other hand, we find that our two large regressions share a common critical path, which is unrelated to the agent’s changes, and likely emerged because certain synthesis heuristics, for example SRAM macro placement, gave significantly different outputs due to small changes in the inputs.

Invisibly to the agent, we also ran each of our designs through synthesis in a commercial 16nm process. The first of the agent’s timing optimizations (restructuring linear-depth structures in the issue queues to log-depth) improved the critical path in the commercial process by about 70%. However, that was the only improvement in the commercial process from our loop’s changes. Put another way, our Sky130 results do not generalize to the advanced commercial node beyond the first optimization. As the 16nm process is proprietary, we could not use it in this case study, since information from the PDK cannot be given to public frontier models. In section 7, we will discuss this problem in more detail, and its implications for assessing QoR in AI-guided hardware design.

The Power of CHIA: This case study heavily leverages the reusability of CHIA’s library nodes, and the ability to carve out pieces of one workflow and incorporate them into another. Many of the nodes used in this case study, including building BOOM’s Chisel, simulation in Verilator and FireSim, and gate-level Synthesis, rely on CHIA library nodes. Furthermore, this case study was able to share many of its application nodes with the previous case study (implementing new RISC-V ISA extensions in the BOOM core) because the two are operating on the same core, meaning much of the pre- and post-processing required for each of the library nodes is the same, despite the goals of the two case studies being very different.

This case study was also able to heavily leverage CHIA’s support for public cloud services. In particular, we used cloud machines to run Chipyard Build, Verilator, Hammer/Synthesis, and FireSim, and we also used CHIA’s AWS S3 [48] support to keep our database backed up in the cloud.

5.4 Agentic Architectural Discovery with Evolutionary Coding Agents↩︎

AI techniques such as evolutionary coding agents have shown significant promise in the discovery of novel ideas and approaches across scientific domains and across the computing stack  [49]–[51].

Within computer architecture, ArchAgent [1], [2] combined AlphaEvolve with a highly distributed simulation cluster and discovered novel cache replacement policies outperforming prior human-designed state-of-the-art policies in a competition setting while far outpacing their estimated development times.

While ArchAgent shows success in using AI for microarchitectural discovery in a constrained competition setting, it points to significant challenges with the realizability of generated policies due to a lack of actionable hardware realizability feedback from microarchitectural simulators. Furthermore, ArchAgent is a point solution in the space of agentic approaches to microarchitecture discovery and the broader composition of agents for problems in computer architecture (as shown in our other case studies) remains underexplored in the context of evolutionary discovery.

Rather than showing a specific result in this section, we demonstrate how flows like ArchAgent can be expressed in CHIA and how CHIA enables addressing many of the challenges faced in conventional evolutionary coding agent flows.

First, CHIA provides extensible interfaces and a rich library of tool nodes:

• Evaluator Nodes: CHIA enables the composition of diverse evaluation backends such as functional models, microarchitecural simulators, RTL simulators and emulators, and physical design tools which can be used to provide rich actionable feedback to evolutionary coding agents.

• Evolver Node: SkyDiscover [52] is a flexible framework for AI-driven scientific and algorithmic discovery with support for widely-used large language models and a variety of evolutionary coding agents such as AdaEvolve [53], EvoX [54], GEPA [55], and OpenEvolve [56] and the Claude Code coding agent. CHIA ships with an Evolver node providing flexible interfaces around SkyDiscover and allowing it to interact with the rest of the framework.

• AlphaEvolve Node via SkyDiscover: We provide support for AlphaEvolve [50] via the AlphaEvolve Early Access Program API [57] as an external backend to SkyDiscover inside the CHIA Evolver node.

Thus, CHIA enables users to experiment with a variety of evolutionary flows targeting discovery across the computing stack with the ability to span multiple levels of representation such as C++ software programs, microarchitecture models, RTL implementations, and circuit designs.

To demonstrate this by way of example, in Figure 12 we show an illustrative CHIA loop that evolves an L2 cache prefetcher described in the ChampSim microarchitectural simulator using the AdaEvolve evolutionary coding agent in the Evolver node.

The user selects configurations for their evaluators and evolutionary coding agent(s) and provides a few lightweight Python functions. Here, ChampSim Build nodes are configured as shown in Table ¿tbl:tab:champsim-config?. The user defines builds using the function build_fn and built binaries are passed further into evaluation. For evolution feedback, ChampSim Run nodes are set up to execute the 10 fastest-running unique workloads traces from the DPC-4 cite AI/ML workload suite for 12.5M warmup instructions and 50M detailed simulation instructions. This configuration is defined by the user in the function run_fn. Metrics such as instructions-per-cycle, coverage, and accuracy are aggregated and provided as feedback using the function run_mapper_fn. We select AdaEvolve as the search algorithm in SkyDiscover and configure it as shown in Table ¿tbl:tab:adaevolve-config?.

The Power of CHIA: CHIA not only addresses gaps regarding hardware realizability and the ability to explore the space of evolutionary discovery flows, it also addresses the significant user effort in delivering a successful discovery flow. Users of such flows regularly report challenges in configuring and operating such flows, especially in the presence of long-running evaluations (often observed in hardware/software co-design research) that can cause errors to materialize at timescales of hours to days. Machine errors and downtime become an increasingly relevant concern, and flow interruptions can discard hours to days of valuable intermediate results. Such issues are directly addressed by CHIA’s ability to cache and bypass nodes and its flexible management of large clusters minimizing downtime.

5.5 Automatically addressing GitHub issues in the CIRCT compiler in a project maintainer friendly way↩︎

AI tools have enabled an increase in outside contributions to large open source GitHub repositories, including new issue reports and pull requests. As noted in the LLVM project’s AI tool use policy, when these contributions are done entirely by AI in an unprincipled way and without human review, this "extracts work from [maintainers] in the form of design and code review" [58]. While CHIA cannot force a human contributor to review the work of their agent, it can be used to force the agent to develop contributions in a more principled way. To demonstrate this, we built a CHIA loop, as seen in Figure 13, to solve issues for LLVM’s CIRCT project, which compiles high-level hardware description languages into SystemVerilog and RTL simulators. Notably, CIRCT is used in Chipyard for lowering its Chisel-based generators down to System Verilog. To reduce maintainer burden rather than increase it, we focus our efforts only on issues that demonstrate bugs, and where the conversation surrounding the issue has left no ambiguity about the correct resolution for the bug.

The loop works as follows. First, a GitHub issue is triaged heuristically, filtering out issues with no code blocks, and those with an open PR referencing the issue (which implies a solution to the issue has already been proposed). Additionally, since we limit our scope to bugs and not feature requests, we avoid any issues labeled as feature requests. An issue is then assessed by an LLM to determine whether (1) the issue is actually a bug and (2) there is a single clear solution to the issue. We do this to make sure that any changes align with our narrow scope of bugs with a single, clear resolution. For issues where this is the case, an agent then tries to reproduce the bug (outputting a bash file which, when run, reproduces the bug) and if successful, another agent tries to fix the bug. These agents are given tools to modify and build CIRCT source, and run tests using CIRCT binaries to validate their changes. After this, we take control back from the agents, and without any AI involvement, the loop verifies the fix by running CIRCT’s full suite of regression tests, and the reproduction bash file, to ensure the bug is fixed.

While we do have the LLM write up a PR for the issue, to minimize extractive work and to comply with LLVM’s AI policy, we had a human review each change in detail to ensure quality and hand-write pull requests to submit to the upstream CIRCT repository. It took a graduate student with novice-level familiarity with CIRCT an hour per issue to review the agents’ changes and ensure they were high enough quality to submit pull requests. It took about 10 more minutes per issue to prepare the pull requests. Additionally, in compliance with CIRCT’s AI usage policy, we did not submit pull requests for any issues marked as "good first issues". We also built a loop for addressing reviewer comments, which follows a similar pattern, first assessing comments for action items, and taking action where necessary, before validating in an environment with no agents. We used this loop to privately address comments we expected to receive, and to address actual comments from maintainers.

To minimize extractive work, we discussed closely with maintainers of the project to ensure our contributions were of a reasonable quantity and quality. In the end, we ran the loop on 16 randomly selected GitHub issues, and its results are outlined in Table 4. Of the 16 issues the loop examined, 11 were determined to be bugs, four of which did not have unambiguous solutions, leaving seven issues entering the reproduction phase. In this stage, two of the seven could not be reproduced, indicating that they had already been fixed in upstream CIRCT. Our loop successfully fixed the remaining five bugs, and we submitted pull requests for the three of them that were not labeled as good first issues. Table 5 shows the token consumption and cost of each phase of our loop for solving CIRCT issues. Our loop considered all 16 issues in parallel, leveraging CHIA’s scalability, and finished in less than 45 minutes.

Each of these three PRs received feedback from reviewers, and we used our loop for addressing reviewer comments to handle their requested changes. All three of our PRs have been merged into the main branch of the CIRCT repository.

We agree with the loop’s conclusions for each of the 16 issues. However, as we were prototyping the loop, we came across a situation where our assessor agent determined that issue #8508 had a clear solution, and our fixer agent successfully fixed the issue, but the assessor and the fixer disagreed about the correct solution. To remedy this, in our final loop, the assessor was required to enumerate all good solutions for a given issue and, if more than one could be described, declare that issue did not have a clear and unambiguous solution. After making this change, the assessor agent reliably declared issue #8508 had no clear solution.

The Power of CHIA: We see the power of CHIA in a few major ways for this workflow. Firstly, we were able to prototype our flow at a very small scale, with only a single agent and CIRCT instances. Then, only changing 3 lines of code across the cluster configuration and Python parameters, we were instantly able to run as many issues in parallel as we wanted. We also see, in this case study, CHIA’s ability to balance agentic orchestration with programmatic orchestration. In each agentic step, the agent is given runway to orchestrate complicated sequences of tasks in order to make decisions about the issue it is fixing. But, to ensure fixes are principled, programmatic orchestration is used to connect the narrowly-scoped agents together, and more importantly, to verify that the changes work as well as the agents claim.

6 Related Work↩︎

Applying artificial intelligence in the context of hardware design is a booming research area. In particular, many papers have explored using agents to generate RTL [3], [4], [7], [8], [59]–[64]. Strategies for this vary greatly, from e-graph rewriting [59] to multi-level summarization [61]. Each of these works uses a bespoke design loop, making their work difficult to compare and impossible to interoperate. Performing these experiments in CHIA would be easier, allow for fairer comparison, and streamline merging successful ideas together.

Discovery of novel architectural ideas is also a subject of growing interest in the architecture community [1], [2], [6], [17]. Some recent works used evolutionary algorithms to discover novel microarchitectural techniques to optimize performance in out-of-order superscalar cores [1], [2], [6]. Similarly, one work explored GPU architecture design space exploration by composing DSE rules with LLMs  [5]. One work sought to develop a unified sandbox for connecting search algorithms to architectural simulators, in order to streamline ML-aided design space exploration [65]. Another work uses an LLM to guide multi-objective black-box optimization towards the Pareto-frontier, significantly reducing time wasted exploring infeasible points [66].

Multiple papers have demonstrated the strong capabilities of LLMs to generate high-performance kernels for GPUs and accelerators [67], [68]. Likewise, LLMs have been used to provide humans with better understandings of kernel [13] and CPU cache performance [69]. LLM-based oracles like this can easily be built in CHIA.

Building off of the success of benchmark suites evaluating the ability of LLMs to generate software [70], [71], and noticing the proliferation of work targeting LLMs for hardware design, many hardware focused benchmark suites have been developed. Some of these suites emphasize evaluating agentic co-design [14], [72], RTL generation [19], [73]–[75] and high-level synthesis [76]. Building these benchmark suites on top of CHIA would streamline the process of comparing different design loops, and we are interested in integrating these suites into CHIA.

Recent work has focused on LLM guided usage of EDA tools [15], [77]–[79]. These ideas range from MCP EDA tool servers  [79] to standardized execution frameworks for EDA [15]. We also hope to encapsulate tools like this into CHIA.

A growing body of work targets general agentic frameworks. CHIA is built on top of Ray [33], and adds customizable profiling as well as fault tolerance and testing features through the bypassing and caching capabilities. CHIA also adds easy setup for hetereogeneous clusters that have multiple different workers per machine as well as clusters split across on-premises and cloud compute. Other distributed agent frameworks lack expressive control flow semantics that encompass cyclic workflows [80], distributed fault tolerance support [81], or resource-aware scheduling [81]. Agents and agent platforms designed for a single machine generally lack support for distributed execution [82]–[86].

The CHIA framework is the first of its kind. As we note, CHIA synergizes well with many of these new tools like benchmark suites and EDA frameworks, by providing a substrate for easily developing loops which interoperate these tools with others in complex ways. Furthermore, CHIA provides a simple, efficient, and streamlined substrate for running the experiments performed in much of the work discussed above.

7 Discussion and Future Work↩︎

While developing and using CHIA, it has become clear that the bottlenecks in hardware design pipelines have shifted. As the process of turning an idea into a preliminary implementation speeds up, evaluating the performance and QoR of that idea as well as verifying the idea takes the bulk of the time. CHIA on its own attacks this problem with parallelism, but Amdahl’s law tells us that parallelism alone is not enough. Rapid, high-fidelity evaluation and verification of hardware designs will be key to taking full advantage of the capabilities of agentic AI. This means we need shorter representative benchmarks, faster simulation methods and PPA estimation tools, and rapid verification methods without sacrificing fidelity and reliability.

Our field also faces challenges with privileged information. Since proprietary data usually cannot be fed to public frontier model-based agents, open PDKs [44], [87], [88] are used in CHIA loops in this paper to demonstrate the power of having PDK data in-the-loop in an agentic flow. Unsurprisingly, these PDKs do not always serve as predictive guides when the ultimate goal is to produce a chip in an advanced process. Therefore, it is critical to develop methodologies to sufficiently abstract quality-of-result and other relevant data before passing it to the largest frontier models. Alternatively, having capable, small, locally hosted models could solve this problem, since sensitive data remains private. CHIA already supports local model hosting and will continue to improve support for it moving forward.

Finally, we are actively dogfooding CHIA across a variety of projects and we plan to continue developing and supporting CHIA in the open-source.

8 Conclusion↩︎

CHIA reframes the central challenge of AI-driven hardware/software co-design: rather than treating each application of AI as a bespoke, one-off experiment, it makes the construction, deployment, and rigorous evaluation of the co-design flow itself a first-class concern. By expressing agentic design flows as CHIA loops and backing them with infrastructure for isolation, profiling, evaluation, and reliable execution across hundreds of heterogeneous systems, CHIA lowers the barrier to conducting principled, reproducible science at scale. The five case studies presented here demonstrate the capabilities of CHIA, spanning evolutionary architectural discovery, LLM-driven RTL implementation, automatic simulator alignment, IPC-aware critical path optimization, and automated GitHub-issue fixing. Across the case studies, we hold the agents operating within the CHIA loops to a high standard of verification and validation. For example, the RTL implemented by agents delivers substantial performance improvements while successfully executing the entire 25+ trillion instructions of SPEC06-Ref in the context of a complete out-of-order superscalar microprocessor in a RISC-V system-on-chip. These agent-written implementations achieve their improvements while meeting or improving frequency and area constraints in open-source and commercial ASIC PDKs.

We emphasize that these case studies are illustrative rather than exhaustive. CHIA is designed as a foundation: our goal is to give the architecture, systems, compiler, and VLSI communities a shared, open-source substrate on which to build, compare, and extend AI-infused co-design workflows. As agentic AI continues to mature, we believe frameworks like CHIA will be essential to translating that progress into durable, verifiable advances in hardware/software co-design, and we hope that CHIA serves as a useful platform for the community upon which to build new AI-driven co-design flows.

9 Acknowledgments↩︎

We thank Schuyler Eldridge and the CIRCT code reviewers for their help in shepherding the merging of our CIRCT pull requests.

The information, data, or work presented herein was funded in part by the Jean and Hing Wong Foundation Faculty Fellowship, Samsung Advanced Institute of Technology (SAIT), and SLICE Lab industrial sponsors and affiliates. Any opinions, findings, conclusions, or recommendations in this paper are solely those of the authors and do not necessarily reflect the position or the policy of the sponsors. This material is also based in part upon work supported by the National Science Foundation Graduate Research Fellowship Program under Grant No. DGE 2146752. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.

References↩︎

---

1. CHIA originally stood for Chipyard Intelligent Agents (or: the Chipyard Intelligence Agency), but was retroactively renamed as we realized its reach was far beyond a single RTL/system-on-chip (SoC) design framework. CHIA now stands for Co-designing Hardware/software with Intelligent Agents, and supports many common design flows.↩︎

2. CHIA Project Website: https://chialoops.ai↩︎

3. We do not include the SPECint suite for this case study because it is difficult to execute the full SPECint suite in gem5 without SimPoints. In other case studies we are able to do so because we can easily run the full suite on 12 FPGAs in parallel in FireSim.↩︎