Automated Chiplet IP Generation Framework

• Automated Chiplet IP generation framework is a design methodology that converts high-level specifications into chiplet implementation artifacts with minimal manual effort.
• It integrates contract-driven flows, reusable templates, and multi-agent pipelines to perform functional verification, behavioral modeling, and design-space exploration.
• The framework addresses hardware bottlenecks by automating transitions from software object models to RTL, package-level interconnects, and physical layout generation.

An automated chiplet IP generation framework is a design methodology that converts high-level specifications into chiplet-relevant implementation artifacts with minimal manual intervention. Recent formulations place the automation boundary at different layers of the stack: one line of work extends a vertically integrated, object-aligned chip design flow into chiplets through one-to-one software-object to hardware-module mapping, sequence-typed protocol verification, and templated physical layouts (Kim et al., 10 Dec 2025); another translates raw datasheets directly into functionally verified SystemC chiplet models through a four-stage multi-agent pipeline (Wu et al., 22 Mar 2026); a third generates chiplet-link IP for 2.5D architecture exploration together with Verilog, Liberty, LEF, and related collateral (Zhu et al., 26 May 2026); and a fourth uses six cooperating agents for hierarchical chiplet design generation, validation, design-space exploration, and 2.5D physical realization (Tang et al., 8 Aug 2025).

1. Scope and problem setting

Automated chiplet IP generation addresses several distinct bottlenecks that appear at different points in the hardware design process. Software-oriented developers often struggle to incorporate custom hardware into applications even when specialized silicon can provide substantial benefits to machine learning and AI workloads (Kim et al., 10 Dec 2025). At the behavioral-modeling level, manual construction of SystemC chiplet models is described as time-consuming and error-prone, especially when the source material is a lengthy and highly unstructured datasheet (Wu et al., 22 Mar 2026). At the package and interconnect level, system architects are described as lacking a suitable early-stage design-space-exploration framework that captures the consequences of 2.5D packaging and communication choices (Zhu et al., 26 May 2026). In LLM-driven chiplet design, the reported challenges include flatten design, high validation cost, and imprecise parameter optimization (Tang et al., 8 Aug 2025).

The resulting literature does not present a single canonical pipeline. Instead, it spans multiple entry points and abstraction levels. Inputs may be a standard object-oriented program in Python, Java, or C++; a raw multimodal PDF datasheet plus a pre-filled JSON template; a one-page JSON package/link specification; or a high-level AI workload description such as a Torchvision or Huggingface model (Kim et al., 10 Dec 2025). Outputs likewise range from behavioral models and testbenches to RTL, Liberty timing libraries, LEF abstracts, GDSII layouts, and package-level interconnect definitions (Zhu et al., 26 May 2026).

A plausible implication is that “automated chiplet IP generation” is best understood as a family of contract-driven flows rather than a single tool category. The common thread is the replacement of ad hoc manual transitions between abstraction levels with explicit representations, reusable templates, and verification loops.

2. Front ends and intermediate representations

A central design choice in these frameworks is the definition of an intermediate representation that is precise enough for automation but still traceable to the original specification.

In the vertically integrated object-oriented flow, the front end parses an object graph $O$ from a standard object-oriented program and extracts, for each link $(o_i \to o_j)$, a session type $S_{ij}$ describing the allowed send/receive sequence and payload widths. The session-type grammar is:

$$T ::= end \mid !m\langle \tau,w\rangle . T \mid ?m\langle \tau,w\rangle . T \mid T_1 \oplus T_2 \mid T_1$$

For each object $o$, the framework builds a typing judgment of the form $\Gamma \vdash o : \{S_{oi}, S_{jo}, \dots\}$, stating that the object’s RTL implementation must implement all incoming and outgoing sessions (Kim et al., 10 Dec 2025). This representation is explicitly intended to preserve mental continuity between the software source program and the chip layout by mapping each software object to a corresponding region on the die.

DS2SC-Agent uses a different IR discipline. Its Specification Parsing Agent consumes a raw PDF together with a “mixed-fill” JSON template and produces a fully populated Spec IR that serves as the single source of truth for interface definitions, performance specs, behavioral pseudocode, and test scenarios. To handle raw datasheets up to 100+ pages, the framework uses hierarchical segmentation rather than a one-shot prompt, sliding windows over a token sequence of length $N$ with context window size $C$ and overlap ratio $\alpha$ (Wu et al., 22 Mar 2026). The mixed-fill template is divided into four structural modules: pre-filled global config and boundary constraints, an extraction zone for domain-specific interfaces, behavioral logic pseudocode, and simulation test cases.

MAHL introduces a hierarchy-oriented representation. An AI-Hardware Hierarchical Parser “prints” a model to extract its layer graph $\mathcal{L}$, then maps each layer $(o_i \to o_j)$0 to a hardware module $(o_i \to o_j)$1 via a built-in compute/interconnect library, producing a preliminary hardware module set $(o_i \to o_j)$2. A Hierarchical Description Generator then retrieves or constructs module descriptions containing Module, Submodules, Ports, Params, and Connections, with parameter placeholders retained for subsequent exploration (Tang et al., 8 Aug 2025).

CLIPGen uses a narrower but highly structured front end: a single JSON configuration file with eight user parameters, namely pkg_type, reach_mm, bump_pitch_um, data_rate_Gbps, lane_count, passive_eq_en, ac_coupled, and pad_cap_mode. These parameters directly drive package selection, channel modeling, pad capacitance estimation, Nyquist-frequency loss computation, total lane-area scaling, and equalization/termination behavior (Zhu et al., 26 May 2026).

3. Contracts, verification, and adaptive debugging

Verification is not an auxiliary stage in these frameworks; it is part of the generative formulation itself.

In the object-to-hardware flow, verification is expressed through labeled transition systems and session-type subtyping. The framework extracts an LTS $(o_i \to o_j)$3 from the software session type and an LTS $(o_i \to o_j)$4 from the FSM of module $(o_i \to o_j)$5, then checks mutual subtyping, $(o_i \to o_j)$6 and $(o_i \to o_j)$7, using send/receive contravariance and covariance rules. The selected rules include send-width contravariance,

$(o_i \to o_j)$8

receive-width covariance,

$(o_i \to o_j)$9

and equivalence,

$S_{ij}$0

Only modules whose sessions match are wired together (Kim et al., 10 Dec 2025).

DS2SC-Agent operationalizes verification through generated testbenches and a closed debugging loop. Its Testbench Generation Agent creates main.cpp that instantiates DUT and TB modules, binds ports via sc_signals or TLM sockets, synthesizes stimulus generators, logs .csv, compares against Spec IR expectations, and writes a PASS/FAIL report. Coverage is formalized as

$S_{ij}$1

The Automated Debugging Agent then runs a Syntax Debugging Loop at compile time and a Functional Debugging Loop at runtime; the latter ingests .csv logs, a verification report, and the original Spec IR, computes error maps such as $S_{ij}$2, diagnoses behavioral mismatches, and patches the generated files until PASS (Wu et al., 22 Mar 2026).

MAHL uses a “Diverseflow Validator” rather than a single debugging chain. Newly generated or retrieved RTL is first functionally simulated and then synthesized for PPA extraction. If simulation fails, the framework spawns $S_{ij}$3 parallel debug threads with controlled prompt noise, each handled by a Thinker/Coder duo-agent, and then selects the best variant through a code-selection strategy that prefers functional correctness and a target metric such as $S_{ij}$4, or otherwise the fewest failing cases. A debug curb $S_{ij}$5 limits the number of iterations, after which human-written hints are required (Tang et al., 8 Aug 2025).

A common misconception is that automated chiplet IP generation is principally a code-emission problem. These systems indicate otherwise. The recurrent pattern is specification formalization, constrained generation, and contract- or test-based refinement rather than unconstrained synthesis.

4. IP construction, templating, and reusable collateral

The frameworks differ sharply in what they consider the primary reusable IP unit.

In the vertically integrated flow, each object $S_{ij}$6 is assigned an RTL IP module $S_{ij}$7 whose FSM implements exactly the session-type protocols $S_{ij}$8. That module is packaged with an API-level wrapper in the host language for simulation, its user-visible configuration parameters, and pre-verified GDSII layout templates; the resulting triple is called a vertical-IP cell. A Python-based DSL can parameterize such cells, and a Python metaclass can inspect a @Module annotation, instantiate multiple copies of a Chisel/FIRRTL template or hand-written Verilog, emit multiple RTLIL variants, and record per-variant performance and area numbers $S_{ij}$9 in a JSON manifest. All variants are pre-synthesized and DRC-/LVS-cleaned so that upper levels never regenerate RTL or re-run P&R (Kim et al., 10 Dec 2025).

DS2SC-Agent’s reusable artifact is a verified behavioral model library entry. Its Code Generation Agent synthesizes a single, header-only C++ file inheriting from sc_module, instantiating ports, signals, and event-driven processes based strictly on the Spec IR. The output chiplet_core.h contains class declaration, constructor, SC_THREADs or SC_METHODs, wait(sc_time(...)) for timing, and inline comments. The companion main.cpp is a black-box testbench that generates digital transactions or continuous-time waveforms and monitors correctness (Wu et al., 22 Mar 2026).

CLIPGen’s reusable unit is a drop-in chiplet-link IP package. From a single JSON input, it produces a datasheet, Verilog, Liberty, LEF, and SPICE/SDC collateral. Internally, a Physical-Channel & Link Modeling Engine builds a distributed $$T ::= end \mid !m\langle \tau,w\rangle . T \mid ?m\langle \tau,w\rangle . T \mid T_1 \oplus T_2 \mid T_1$$0-ladder RC model of the die-to-die channel; a Transceiver Sizing & PPA Estimator generates and sizes a tapered CMOS inverter TX chain and a two-stage RX; and a Collateral Generator emits a physical abstract, parameterized behavioral RTL stub, timing constraints, and machine-readable PPA summaries. Cadence Liberate is used to produce Liberty timing arcs and internal switching-power numbers that include channel loading (Zhu et al., 26 May 2026).

MAHL emphasizes cumulative reuse through a Code Library. Each entry stores a module identifier, an embedding token $$T ::= end \mid !m\langle \tau,w\rangle . T \mid ?m\langle \tau,w\rangle . T \mid T_1 \oplus T_2 \mid T_1$$1, a quality weight $$T ::= end \mid !m\langle \tau,w\rangle . T \mid ?m\langle \tau,w\rangle . T \mid T_1 \oplus T_2 \mid T_1$$2, measured PPA, and HDL code. Similarity is computed as

$$T ::= end \mid !m\langle \tau,w\rangle . T \mid ?m\langle \tau,w\rangle . T \mid T_1 \oplus T_2 \mid T_1$$3

and reuse occurs when $$T ::= end \mid !m\langle \tau,w\rangle . T \mid ?m\langle \tau,w\rangle . T \mid T_1 \oplus T_2 \mid T_1$$4 and $$T ::= end \mid !m\langle \tau,w\rangle . T \mid ?m\langle \tau,w\rangle . T \mid T_1 \oplus T_2 \mid T_1$$5; otherwise the system prompts an LLM to generate new RTL, assigns initial weight $$T ::= end \mid !m\langle \tau,w\rangle . T \mid ?m\langle \tau,w\rangle . T \mid T_1 \oplus T_2 \mid T_1$$6, validates it, and inserts it into the library. Weights are updated multiplicatively on pass or fail, and entries below threshold $$T ::= end \mid !m\langle \tau,w\rangle . T \mid ?m\langle \tau,w\rangle . T \mid T_1 \oplus T_2 \mid T_1$$7 are removed (Tang et al., 8 Aug 2025).

These designs suggest two complementary reuse strategies: pre-characterized physical templates on one side, and validated code-and-metric repositories on the other. The former primarily reduces backend regeneration; the latter reduces front-end synthesis uncertainty.

5. Interconnect, packaging, and physical realization

Chiplet IP generation becomes distinct from monolithic IP generation when communication, partitioning, and package-level implementation enter the optimization loop.

The object-aligned chiplet extension begins from an object graph $$T ::= end \mid !m\langle \tau,w\rangle . T \mid ?m\langle \tau,w\rangle . T \mid T_1 \oplus T_2 \mid T_1$$8 and session set $$T ::= end \mid !m\langle \tau,w\rangle . T \mid ?m\langle \tau,w\rangle . T \mid T_1 \oplus T_2 \mid T_1$$9, then clusters objects into $o$0 chiplets by graph partitioning, for example METIS, to minimize inter-chip traffic:

$o$1

Cross-cluster edges are implemented with package-level interface IP consisting of SerDes engines, a standardized physical link such as UCIe, and accompanying session-type wrappers. The session-type vocabulary is extended with chiplet-link actions such as $o$2 and $o$3. Die-level floorplanning proceeds by locally floorplanning each chiplet’s objects with the same template-based flow, placing chiplets on an interposer substrate, and routing inter-chip lanes on defined wiring channels. The global objective adds package area and inter-die latency,

$o$4

with additional physical-design constraints including pin-limited I/O budgeting, timing closure across the die boundary, and partition-aware power delivery (Kim et al., 10 Dec 2025).

Within a monolithic die, the same framework presents alternative on-die interconnect choices. A Snoopy Bus has area $o$5, latency $o$6, and power $o$7, whereas a Full Crossbar has $o$8, $o$9, and $\Gamma \vdash o : \{S_{oi}, S_{jo}, \dots\}$0. The composite cost is expressed through area and latency terms,

$\Gamma \vdash o : \{S_{oi}, S_{jo}, \dots\}$1

and

$\Gamma \vdash o : \{S_{oi}, S_{jo}, \dots\}$2

Placement is then performed with a templated floorplanner that assigns each module to a rectangular “object region” (Kim et al., 10 Dec 2025).

CLIPGen develops the package and link side of this problem in greater detail. Its mathematical models include pad capacitance,

$\Gamma \vdash o : \{S_{oi}, S_{jo}, \dots\}$3

bump resistance with skin effect,

$\Gamma \vdash o : \{S_{oi}, S_{jo}, \dots\}$4

channel loss at Nyquist,

$\Gamma \vdash o : \{S_{oi}, S_{jo}, \dots\}$5

passive-equalization sizing,

$\Gamma \vdash o : \{S_{oi}, S_{jo}, \dots\}$6

and total energy per bit,

$\Gamma \vdash o : \{S_{oi}, S_{jo}, \dots\}$7

The framework also computes area from transistor counts, passive-EQ components, ESD/termination diodes and bias resistors, plus bump/pad macro footprint. In a UCIe case study, a single-lane 48 Gb/s Standard link was swept from 2 to 25 mm on both a 112.64 µm-pitch organic substrate and a 25 µm-pitch silicon interposer across three PDKs. The reported findings were that silicon interposer has lower energy up to approximately 10 mm, but beyond approximately 10 mm organic outperforms; at 25 mm on TSMC 16 nm, the values are 0.41 versus 0.83 pJ/bit. Silicon holds a latency edge only up to approximately 4.5 mm, after which organic stays under the UCIe 16 UI budget longer (Zhu et al., 26 May 2026).

MAHL approaches physical realization through an Adaptive Debugger that automatically generates and refines OpenROAD configuration files, including interposer dimensions and wire spacing, until the 2.5D floorplan completes successfully, yielding final physical GDSII layout on a 2.5D substrate (Tang et al., 8 Aug 2025). This suggests a different strategy from template-based closure or analytical package models: physical design automation as an error-log-driven configuration synthesis problem.

6. Empirical results, limitations, and open directions

The empirical record is heterogeneous because the evaluated targets differ: behavioral SystemC models, chiplet-link IP, and full RTL-to-layout chiplet flows are not benchmarked on a common workload class.

DS2SC-Agent evaluates three industrial chiplets: FFT (digital), Limiting Amplifier (analog), and Power Amplifier (RF). For FFT with a 96-page datasheet, the end-to-end generation time is approximately 18 minutes, with zero human edits, final closed-loop tolerance below $\Gamma \vdash o : \{S_{oi}, S_{jo}, \dots\}$8, and 100% functional correctness. For the 6-page Limiting Amplifier, the runtime is approximately 12 minutes and the transient SystemC-AMS waveform matches all three operating regions with below 0.02 V deviation. For the 18-page Power Amplifier, the runtime is approximately 15 minutes and the Rapp-model non-linear fit of the $\Gamma \vdash o : \{S_{oi}, S_{jo}, \dots\}$9 curve has maximum error below 1 dB. Relative to a manual baseline of approximately 3 days of expert effort per chiplet, the reported turnaround-time reduction is approximately $N$0 (Wu et al., 22 Mar 2026).

CLIPGen reports workflow performance rather than full-system chiplet synthesis accuracy. In sweep mode, the framework produces PPA results in approximately 1–2 minutes per configuration, with Elmore filtering plus approximately 10 seconds of TX characterization and approximately 5 seconds of RX characterization in parallel. Typical accuracy versus full EM+SPICE tape-out models is reported as $N$1 energy and $N$2–$N$3 ps delay, with runtime described as minutes rather than hours. Its stated limitations are equally specific: only RC-dominated links up to approximately 32 Gb/s and below 50 mm reach are modeled; inductance and multi-pole effects are neglected; TX is restricted to a single-ended full-rail CMOS inverter chain; equalization is limited to a single-zero passive pre-emphasis; thermal effects, yield/cost modeling, and substrate-level IR drop are out of scope; and coupling capacitance is handled without full crosstalk analysis (Zhu et al., 26 May 2026).

MAHL reports both generation-correctness and PPA outcomes. On simple RTL designs including Mux, Adder, Decoder, Barrel Shifter, Systolic Array, and UART, GPT-4o base has Pass@1 approximately 0.0–0.6 and Pass@5 approximately 0.98–1.00, while Hierarchy + Retrieval + Diverseflow yields Pass@1 gains up to +1.0 and an average +44.67% over a flat LLM, with Pass@5 consistently approximately 1.0. On real-world 2.5D chiplets for AI models such as BERT, LLaMA, and GPT, LLM-only yields Pass@5 = 0.0, whereas MAHL under a high-performance mode reports BERT Pass@5 = 0.72, energy 470 µJ versus 647 µJ, latency 1.81 µs versus 2.81 µs, area 236 mm² versus 182 mm², and density 1099 mW/mm² versus 1262 mW/mm². In compact-area mode, BERT area is reduced from 25 mm² to 21.7 mm² with Pass@5 = 0.60 (Tang et al., 8 Aug 2025).

The vertically integrated chiplet extension is presented as a sketch of such a framework rather than a full quantitative evaluation. Its significance lies in the articulation of a unifying flow: write an ordinary object-oriented program, annotate or infer fixed-width session types, verify protocol conformance via sequence-type subtyping, instantiate vertically stacked IP cells from a pre-characterized template library, partition the object graph into chiplets, floorplan each die, place chiplets on an interposer, and emit manufacturable GDSII per die together with a package-level interconnect definition and a JSON manifest preserving the object-to-module mapping and session-type contracts (Kim et al., 10 Dec 2025).

Across these systems, several misconceptions are corrected by the published results. Automation does not eliminate the need for domain constraints; instead, the strongest results are obtained when the generator is anchored by session types, Spec IRs, code libraries, or package/link models. Nor is “chiplet IP” a uniform artifact class: it may denote a SystemC behavioral model, a reusable RTL block, a link macro with standard EDA collateral, or a partitioned multi-die assembly. A plausible implication is that future progress will depend less on larger generative models alone than on tighter integration among formal contracts, library reuse, physical abstractions, and closed-loop verification.