---
title: 'MAHL: LLM-Guided Chiplet Design'
url: https://www.emergentmind.com/topics/mahl
type: topic
---

# MAHL: LLM-Guided Chiplet Design

MAHL, short for **Multi-Agent LLM-Guided Hierarchical Chiplet Design with Adaptive Debugging**, is an LLM-based framework for automatically generating, validating, and optimizing chiplet-based **2.5D integrated hardware IPs** for AI workloads such as **BERT, GPT, and LLaMA**. It is designed around the claim that direct LLM-driven chiplet design is limited by **flattened designs**, **high validation cost**, and **imprecise parameter optimization**, and accordingly decomposes the task into a hierarchical, tool-in-the-loop, six-agent workflow spanning AI-to-hardware mapping, hierarchical description generation, retrieval-augmented RTL generation, adaptive debugging, design space exploration, and physical-layout configuration [2508.14053].

## 1. Problem setting and design objectives

MAHL is situated in the broader context of LLM-assisted hardware design, where earlier success in small RTL generation does not directly transfer to **modular, reusable, PPA-optimized chiplet systems**. The framework targets the generation of chiplet designs for large AI workloads under **Power, Performance and Area (PPA)** objectives, with particular emphasis on **2.5D chiplet integration** and modular IP reuse [2508.14053].

The motivating diagnosis is threefold. First, vanilla LLMs tend to emit **monolithic RTL blocks**, whereas chiplet systems require **modular, hierarchical, reusable IPs**. Second, generated HDL often fails validation, and manually creating testbenches and repair loops is costly. Third, pure LLM generation is weak at precise numerical tuning over large architectural spaces, so direct optimization of **array sizes**, **memory hierarchies**, **interconnect bandwidth**, and related chiplet parameters is unreliable. The framework therefore treats chiplet generation not as one-shot code synthesis but as a staged pipeline from **AI algorithm → hardware module graph → chiplet RTL → validated PPA-aware implementation → layout configuration** [2508.14053].

Within the workloads studied, the mapping layer is explicit: `Conv1D`, `Linear`, and `Conv2D` are mapped to **systolic-array-based compute chiplets/units plus buffers**; activation layers map to activation modules; and chiplet interconnect is modeled using **AIB 2.0** for NoP and NoC links. This suggests that MAHL is neither generic HDL prompting nor classical high-level synthesis, but a library-grounded mapping framework specialized to reusable chiplet components [2508.14053].

## 2. Six-agent architecture and phased workflow

MAHL is organized into four phases—**Phase I: Design specification**, **Phase II: Behavioral modeling**, **Phase III: DSE + final RTL implementation**, and **Phase IV: Physical layout**—implemented by six collaborating agents [2508.14053].

| Agent | Phase | Core role |
|---|---|---|
| AI-Hardware Hierarchical Parser | I | AI layer extraction and hardware mapping |
| Hierarchical Module Description Generator | I, III | Structured module descriptions and PPA-aware refinement |
| Retrieval-Augmented Code Generator | II, III | Bottom-up HDL generation and code reuse |
| Diverseflow Validator | II, III | Simulation, synthesis, debugging, and candidate selection |
| Multi-Granularity Design Space Explorer | III | Coarse LLM search plus fine analytical refinement |
| Configurator | IV | OpenROAD configuration generation and revision |

The **AI-Hardware Hierarchical Parser** accepts a natural-language description of the target AI algorithm and design goals, optionally with hardware preferences. It extracts layer structure from **Torchvision** or **HuggingFace** via `print(model)`, decomposes the model into **computing layers** and **interconnection layers**, and uses an LLM plus a **Compute & Interconnect Library** to map each algorithmic layer to a hardware module. If no mapping is available, the framework falls back to **human-computer interaction (HCI)** for missing specifications [2508.14053].

The paper formalizes this mapping as
\[
\mathcal{M} = \left\{ \left(l_i,\, h_i \right) \,\middle|\, \begin{cases} h_i = LLM(l_i,\, \mathcal{H}_{\text{lib}}), & \text{if matches} \\ h_i = h_i^{\text{user}}, & \text{otherwise} \end{cases} \right\}_{l_i \in \mathcal{L}},
\]
where \(\mathcal{L}\) is the set of extracted layers, \(l_i\) an individual layer, \(\mathcal{H}_{\text{lib}}\) the hardware library, and \(h_i\) the mapped hardware module [2508.14053].

This phased decomposition is central to the framework’s identity. A plausible implication is that MAHL treats hierarchy not as a prompting convenience but as the organizing abstraction that makes validation, reuse, and PPA-oriented optimization tractable at chiplet scale.

## 3. Hierarchical generation, retrieval, and adaptive debugging

The **Hierarchical Module Description Generator** transforms mapped modules into structured descriptions with fields including **Module**, **Description**, **Submodules**, **Port**, **Connections**, and **Params**. Mapped modules are retrieved from a **Module Description Library**; unmapped or user-defined modules are produced by a **duo-agent scheme** in which a **Generator LLM** fills the template and an **Evaluator LLM** checks format correctness and semantic completeness. In Phase III the same agent is reused to regenerate descriptions under explicit PPA targets, and the evaluator may suggest techniques such as **clock gating** for lower power or **pipelining** for higher performance [2508.14053].

The **Retrieval-Augmented Code Generator** then emits HDL in a **bottom-up dependency order**. Rule-based structural decomposition splits the design into modules; LLM-assisted dependency analysis determines the generation order; and leaf submodules are generated before parents. Retrieval uses a **Code Library** whose entries contain **Key**, **Weight** \(w\), **PPA**, and **Code**. For a tokenized module query \(T\), the best library match is
\[
S_{\max}(T) = \max_{T_{db}\in \mathrm{DB}} \cos(T, T_{db}),
\]
and reuse is accepted only if
\[
S_{\max} \ge t_{\text{sim}}
\qquad\text{and}\qquad
w(T_{db}) \ge t_w.
\]
Otherwise MAHL generates fresh code. New code enters the library with initial weight
\[
w_0=\alpha.
\]
Weights are then updated according to validator outcomes:
\[
w_n \leftarrow \begin{cases} \beta\, w_n, & \text{if code block } n \text{ passes simulation} \\
\frac{1}{\beta} w_n, & \text{otherwise}
\end{cases}
\qquad\text{and remove code if}\qquad
w_n<t_h.
\]
This mechanism turns validated modules into reusable assets whose future selection is conditioned on both similarity and prior success [2508.14053].

Validation is delegated to the **Diverseflow Validator**. Each RTL module is simulated with **ICARUS Verilog**, using testbenches generated manually with LLM assistance and/or retrieved from a **Testbench Library**. Passing modules are synthesized with **Design Compiler**, and the extracted module-level PPA is stored back into the code library. If simulation fails, MAHL launches **\(K\) parallel debugging threads**, adds controlled **symbolic noise** to some prompts, and uses a **Thinker/Coder** duo-agent repair loop. Noise is injected into a subset of symbolic tokens equal to **\(P\%\)** of code length. If any candidate passes simulation, the framework chooses the one with best target metric; otherwise it chooses the one with the fewest failed test cases. The target criterion is expressed as
\[
\text{target\_result}(\text{code}) \in \{\text{power},\ \text{area},\ 1/\text{clk\_freq}, \ldots\}.
\]
Adaptive debugging also includes multi-round iteration, seed selection from the least-bad failed candidate, stopping after a curb count \(C\), and fallback to a **human-written debugging manual** appended to later prompts [2508.14053].

This debugging regime is narrower than formal program repair. The paper explicitly frames it as a structured, multi-agent, tool-in-the-loop repair process rather than reinforcement learning or theorem-based correction [2508.14053].

## 4. Design space exploration and physical implementation

MAHL’s PPA optimization layer is the **Multi-Granularity Design Space Explorer (DSE)**. The motivating observation is combinatorial: with \(i\) parameters and 10 choices each, the design space size is \(10^i\). The framework therefore combines **coarse-grained LLM-driven breadth exploration** with **fine-grained analytical refinement** [2508.14053].

The DSE consumes two principal inputs: submodule PPA values derived from validated RTL and synthesis, and an AI model graph whose node and edge weights encode compute and interconnect cost. The loop is: update the graph with submodule PPA, ask the LLM to propose **\(M\)** coarse baseline configurations, run analytical DSE in local neighborhoods around those baselines, compare refined candidates against objectives and constraints, perform bottleneck analysis when constraints are not met, and feed the bottleneck information back to the LLM [2508.14053].

The paper gives the selection rule
\[
x^* = \arg\max_{x \in S} O(x), \quad S = X' \text{ if } X' \neq \emptyset \text{ else } X
\]
with
\[
X' = \{ x \in X \mid P_1(x) \geq T_1, P_2(x) \geq T_2 \}.
\]
Here \(X\) is the candidate set, \(X'\) the subset satisfying soft constraints, \(O(x)\) the optimization objective, and \(P_1,P_2\) the auxiliary soft constraints. In the reported experiments,
\[
T_1 = 250\ \mathrm{mm}^2
\qquad\text{and}\qquad
T_2 = 2500\ \mathrm{mW/mm}^2.
\]
The paper notes that the notation uses \(\arg\max\) even though practical optimization may minimize latency or energy depending on mode. A plausible implication is that the operational meaning is objective-driven selection with soft preference for area and power-density-feasible candidates rather than a single closed-form scalarization [2508.14053].

For **Phase IV**, the **Configurator** uses an LLM to generate and iteratively revise **OpenROAD** configuration files, parsing tutorial information and error messages and adjusting parameters such as **wire length**, **spacing**, **chip size**, and **congestion tolerance**. The paper reports one layout case: a BERT compact-area chiplet with **32 instances of 32×32 systolic array**, **16 activation units (GELU/TANH)**, and **320 Gbps AIB channels** [2508.14053].

The paper is explicit about a methodological limitation: it does **not** provide closed-form equations for chiplet-level latency, energy, area, or partitioning cost models. Global PPA optimization relies instead on tool outputs and analytical simulator support [2508.14053].

## 5. Experimental evaluation and reported performance

The empirical study uses two benchmark families. **Dataset I** targets simple RTL generation, including **Multiplexer**, **Adder**, **Decoder**, **Barrel Shifter**, **Systolic Array**, **AES Block Cipher**, and **UART**, with a representative evaluation table covering **Mux 64-to-1**, **64-bit Adder**, **5-to-32 Decoder**, **32-bit Barrel Shifter**, **4x4 Systolic Array**, and **8-bit UART**. **Dataset II** targets chiplet designs for **BERT**, **LLaMA**, and **GPT** [2508.14053].

The evaluation includes ablations of non-hierarchical prompting (**N**), hierarchical description only (**H**), hierarchical plus retrieval (**HR**), non-hierarchical plus Diverseflow (**ND**), hierarchical plus Diverseflow (**HD**), and full MAHL (**HRD**). It uses **GPT-4o**, **LLaMA 3.3 70B**, and **Gemma 3 27B**; temperatures are **0.8** for GPT-4o and **0.6** for local models. The toolchain includes **ICARUS Verilog**, **Design Compiler**, the same **cycle-accurate chiplet simulator** used by CLARIE, **TSMC 28nm** for synthesis-based PPA comparison, and **OpenROAD** with **SkyWater 130nm** for the layout case. Reported settings include **\(K=2\)** debugging threads, **\(C=5\)** debugging curb, **\(P=30\%\)** symbolic noise, **10 trials** for simple RTL, **20 trials** for chiplet designs, and **\(M=80\)** coarse-grained LLM configurations, all run on a Linux server with **4× A6000 GPUs** and an **AMD EPYC 7763 64-core CPU** [2508.14053].

The generation-accuracy metric is **Pass@k**, estimated as
\[
\text{pass@k} = \mathbb{E}_{\text{Problems}} \left[ 1 - \frac{\binom{n - c_p}{k}}{\binom{n}{k}} \right],
\]
where \(n\) is the total number of generations, \(c_p\) the number of successful generations, and \(k\) the number of attempts considered. Reported PPA metrics are **Energy** \((\mu J)\), **Latency** \((\mathrm{ns})\), **Area** \((\mathrm{mm}^2)\), and **Power density** \((\mathrm{mW/mm}^2)\) [2508.14053].

The main reported findings are as follows. On simple RTL generation, **hierarchical generation** improves Pass@1 by up to **0.5**, typically by **20%–40%**; **Diverseflow Validator** improves Pass@1 by up to **0.6**; **retrieval augmentation** improves pass rate by about **10%–40%**; and full **MAHL (HRD)** achieves an average **Pass@1 gain of 44.67%** over the non-hierarchical baseline. On complex chiplet generation, conventional general-purpose LLMs fail completely in the reported trials—**GPT-4o alone: Pass@5 = 0** and **Llama-3.3 alone: Pass@5 = 0**—whereas MAHL reaches nonzero success, including **Pass@5 = 0.72** for **BERT, GPT-4o backend, high-performance mode**, and **Pass@5 = 0.44** for **GPT, Llama-3.3 backend, high-performance mode** [2508.14053].

Against the expert baseline **CLARIE**, the reported PPA picture is mixed. In **High Performance Mode**, MAHL improves selected primary objectives in several cases: for **BERT**, MAHL reports lower **energy** and **latency** and lower **power density**, but higher **area**; for **LLaMA**, it improves **latency** and **area** but is worse in **energy** and **power density**; for **GPT**, it improves **latency** and **area** but loses on **energy** and **power density**. In **Compact Area Mode**, MAHL often attains very small area, sometimes with marked trade-offs in latency or power density. The introduction summarizes these outcomes as average **16.08% latency reduction** in high-performance mode and **83.96% area reduction** in compact-area mode relative to human-designed chiplets [2508.14053].

The ablation analysis supports a specific interpretation. Hierarchy addresses the flattening problem; Diverseflow reduces repetitive failure modes in HDL repair; retrieval becomes more effective as the validated library grows; and the largest relative advantage appears on complex chiplet generation rather than on simpler standalone RTL [2508.14053].

## 6. Assumptions, limitations, and conceptual position

MAHL assumes the existence of reusable libraries for compute/interconnect modules, module descriptions, code, and testbenches; it also assumes that layer-to-module mapping is feasible from model structure and that validated module-level PPA is a useful proxy for system-level exploration [2508.14053].

Its limitations are stated with unusual clarity. The framework still struggles with **multi-objective tradeoffs**, especially softer metrics such as **power density**. Some AI-chiplet designs—notably **LLaMA compact-area mode**—remain below expert trade-off quality. The repair loop may still require **human-written debugging manuals**. Formal global PPA models are absent, and end-to-end physical demonstration is limited to a single layout case. The baseline name **CLARIE** is also reported as inconsistently spelled **CLAIRE/CLARIE** in the paper’s own text, which reflects a documentation inconsistency rather than a methodological claim [2508.14053].

Within LLM-for-hardware research, MAHL’s distinctiveness lies in how it combines **AI-model-to-hardware mapping**, **hierarchical description generation**, **retrieval-backed bottom-up RTL generation**, **simulation/synthesis-guided validation**, **parallel noisy debugging**, and **hybrid LLM plus analytical DSE** in a single chiplet-oriented flow. This suggests that the framework’s principal contribution is architectural rather than solely algorithmic: it reorganizes chiplet generation around hierarchy, reuse, and feedback rather than treating RTL synthesis as an isolated prompting task [2508.14053].

Source: https://www.emergentmind.com/topics/mahl