MAHL: LLM-Guided Chiplet Design

• MAHL is an LLM-based framework that automatically generates, validates, and optimizes chiplet-based 2.5D integrated hardware IPs for AI workloads.
• It employs a six-agent workflow to decompose chiplet design into phases—from AI-to-hardware mapping to physical layout configuration—for modular, PPA-aware systems.
• The framework integrates hierarchical module descriptions, retrieval-augmented RTL generation, adaptive debugging, and design space exploration to overcome limitations of flat LLM prompting.

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 (Tang et al., 8 Aug 2025).

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 (Tang et al., 8 Aug 2025).

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 (Tang et al., 8 Aug 2025).

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 (Tang et al., 8 Aug 2025).

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 (Tang et al., 8 Aug 2025).

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 (Tang et al., 8 Aug 2025).

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 (Tang et al., 8 Aug 2025).

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 (Tang et al., 8 Aug 2025).

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: $\mathcal{L}$0 This mechanism turns validated modules into reusable assets whose future selection is conditioned on both similarity and prior success (Tang et al., 8 Aug 2025).

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 $\mathcal{L}$1 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 $\mathcal{L}$2 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

$\mathcal{L}$3

Adaptive debugging also includes multi-round iteration, seed selection from the least-bad failed candidate, stopping after a curb count $\mathcal{L}$4, and fallback to a human-written debugging manual appended to later prompts (Tang et al., 8 Aug 2025).

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 (Tang et al., 8 Aug 2025).

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 $\mathcal{L}$5 parameters and 10 choices each, the design space size is $\mathcal{L}$6. The framework therefore combines coarse-grained LLM-driven breadth exploration with fine-grained analytical refinement (Tang et al., 8 Aug 2025).

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 $\mathcal{L}$7 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 (Tang et al., 8 Aug 2025).

The paper gives the selection rule

$\mathcal{L}$8

with

$\mathcal{L}$9

Here $l_i$0 is the candidate set, $l_i$1 the subset satisfying soft constraints, $l_i$2 the optimization objective, and $l_i$3 the auxiliary soft constraints. In the reported experiments,

$l_i$4

The paper notes that the notation uses $l_i$5 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 (Tang et al., 8 Aug 2025).

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 (Tang et al., 8 Aug 2025).

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 (Tang et al., 8 Aug 2025).

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 (Tang et al., 8 Aug 2025).

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 $l_i$6 debugging threads, $l_i$7 debugging curb, $l_i$8 symbolic noise, 10 trials for simple RTL, 20 trials for chiplet designs, and $l_i$9 coarse-grained LLM configurations, all run on a Linux server with 4× A6000 GPUs and an AMD EPYC 7763 64-core CPU (Tang et al., 8 Aug 2025).

The generation-accuracy metric is Pass@k, estimated as

$\mathcal{H}_{\text{lib}}$0

where $\mathcal{H}_{\text{lib}}$1 is the total number of generations, $\mathcal{H}_{\text{lib}}$2 the number of successful generations, and $\mathcal{H}_{\text{lib}}$3 the number of attempts considered. Reported PPA metrics are Energy $\mathcal{H}_{\text{lib}}$4, Latency $\mathcal{H}_{\text{lib}}$5, Area $\mathcal{H}_{\text{lib}}$6, and Power density $\mathcal{H}_{\text{lib}}$7 (Tang et al., 8 Aug 2025).

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 (Tang et al., 8 Aug 2025).

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 (Tang et al., 8 Aug 2025).

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 (Tang et al., 8 Aug 2025).

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 (Tang et al., 8 Aug 2025).

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 (Tang et al., 8 Aug 2025).

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 (Tang et al., 8 Aug 2025).