The Code Behind the Layout: AI Agents for Analog Layout Generators

Minxing Chu; Anhang Li; Martins Atilla; Ruichen Qi; Mehdi Saligane

cs.AROct 28, 2026

The Code Behind the Layout: AI Agents for Analog Layout Generators

Authors: Minxing Chu, Anhang Li, Martins Atilla, Ruichen Qi, Mehdi Saligane

Organizations: Brown University, Providence, RI, USA · University of Michigan, Ann Arbor, MI, USA

Abstract

Analog layout remains largely manual and hard to automate. Generator frameworks such as gLayout express layouts as programs, producing layouts from parameterized, design-rule-aware generators; however, writing such generators still takes expert effort. Large language models (LLMs) could now write generator code, and frontier models can even draw layout geometry from design intent. This raises a practical question: if a model can draw the layout itself, what does a generator framework still contribute, and is applying these models to a generator framework better than having them draw a layout from scratch? Through controlled experiments on gLayout in SKY130, we find that the main obstacle to drawing a layout directly is its time and token cost, and that the main advantage of a model building on a generator framework is reusability. Its verified primitives keep each model edit small enough to check, and its parameters allow a single edit to be evaluated across an entire family of layouts. Accordingly, a model is most effective when it develops the layout from the generator source of the family that the design intent belongs to, and tests each edit on the family members most likely to fail, so that one verified change improves every layout the generator produces. The results of these family tests can then serve as supervision for a local model, which learns edits that hold across the family at a fraction of the inference cost.

Figures & tables

Fig. 1: Overview of the family-level editing loop.

Interface	Location of design knowledge	Policy action
Raw GDS geometry [ 19 ]	Program-built polygons, layers, labels and nets	Edit geometry construction and net routing
Primitive Python API [ 6 ]	Device and via construction with port interfaces	Place primitive instances and connect terminals
gLayout [ 5 , 6 ]	MappedPDK, hierarchical device and block generators	Edit generator source or compose allowlisted blocks
BAG/BAG2/BAG3++ [ 1 ]	Procedural schematic and layout generators, test scripts	Edit generator procedures and design parameters
LAYGO2 [ 2 ]	Dynamic templates, technology grids, reusable instances	Edit template generation, grid placement and routing
ALIGN [ 3 ]	Netlist hierarchy, PDK abstraction, inferred constraints	Supply circuit- and hierarchy-level constraints

TABLE I: Where layout frameworks keep their knowledge and what a policy can change.

Fig. 2: Action level and evaluation fidelity shape the search. (a) Outcome of every Claude Opus 5.5 episode by action level (G0 geometry, G1 primitives, G2 generator source) and by whether the needed cell could be reused or had to be built from primitives. (b) Oracle pools of the four amplifiers (5T: five-transistor, FVF: flipped voltage follower) with the Spearman correlation between area and bandwidth. (c) Candidates verified within the time limit against full evaluations on a 5T pool whose layouts all pass, under four screens: area, adaptive geometric rule, extracted RC product and calibrated interval F3.

Fig. 3: Editing searches, their evidence, the local models and their cost. (a) Outcome of every Claude Opus 5.5 search by test rule (A anchor only, R random, B boundary, C risk; C-dist and C-margin keep one term of C) and parameter baseline (P policy, P random). (b) Anchor improvement against visible configurations passing the final patch. (c) The stacked switch before and after a one-line change. (d) Hidden configurations kept by the local models under point and family supervision, SFT and DPO, three seeds. (e) Median physical CPU per search episode.

	GPT					Claude
Rule	n	Impr.	Gain	Cov.	Regr.	n	Impr.	Gain	Cov.	Regr.
A anchor only	120	37	39	58	12	72	36	62	61	11
R random	120	25	48	66	7	72	27	48	69	6
B boundary	120	23	48	64	8	72	32	48	67	7
C risk	120	15	48	74	3	72	29	45	79	2
C+F3	10	3	119	–	–	–	–	–	–	–

TABLE II: Editing searches by test rule and policy: searches ( n ), improving patches, their median gain (%), and hidden coverage and regression (%).

Electronic Design Automation

Electronic Design Automation uses algorithms and software to design, verify, optimize, and manufacture electronic circuits and systems.

See all 219 papers

Who Plans, Who Edits? Verified, Cost-Aware Division of Labor for LLM-Driven Analog Layout Repair
Oct 16, 2026Xilai Dai, Saeed MohammadiLLM Agents Electronic Design Automation
Elmore Family School of Electrical and Computer Engineering, Purdue University, West Lafayette, IN 47907, USA
Simulation-Aware In-Context Policy Improvement for LLM-Aided Analog Layout Refinement
Aug 13, 2026Bingyang Liu, Ziming Wei, Xiaohan Gao +1Electronic Design Automation Large Language Model-Guided Optimization
Department of Electrical & Computer Engineering, The University of Texas at Austin, TX, USA
PANDA: An LLM-Enhanced Performance-Driven Analog Design Framework Bridging Design Intent and Layout Generation
Jun 13, 2026Haoyi Zhang, Weijian Fan, Xiaohan Gao +3Large Language Model-Guided Optimization Electronic Design Automation
School of Integrated Circuits, Peking University, Beijing, China · Beijing Advanced Innovation Center for Integrated Circuits, Beijing, China · Institute of Electronic Design Automation, Peking University, Wuxi, China

Oct 16, 2026J/K move · Enter open · S save

Who Plans, Who Edits? Verified, Cost-Aware Division of Labor for LLM-Driven Analog Layout Repair

Xilai Dai, Saeed Mohammadi

Elmore Family School of Electrical and Computer Engineering, Purdue University, West Lafayette, IN 47907, USA

LLM Agents Electronic Design Automation LLM Agent Workflow Optimization LLM Agent Efficiency

Open paper AskPDF arXiv

Language-model agents can repair analog layouts when sign-off tools check every edit, but which model should plan a repair, which should edit it, and at what cost remain open questions. In our tool-grounded repair agent, models only choose bounded layout operators; sign-off tools rerun each task's contract checks after every edit, so failing layouts are never accepted. On layout-versus-schematic (LVS), design-rule checking (DRC), and post-layout repairs of three designs (a production high-voltage digital-to-analog converter (DAC), a 5-V oscillator, and a SKY130 operational transconductance amplifier (OTA)) with six tier-matched models from two vendors, 182 blind runs show that cheap models execute plans but rarely succeed alone (the cheapest model: 1 of 11 runs alone, 16 of 17 under a flagship planner; p < 0.001), cheap planners fail more often, and no fixed assignment is cheapest on every task. We propose a learning controller that selects models for each role and the escalation order from the first tool evaluation and updates Bayesian estimates after every attempt. With rules and initial estimates frozen before testing, the controller fixed 7 of 8 episodes on four sealed held-out tasks, matching the OpenAI flagship alone, at 15-40% of the flagship's spend per fix on three tasks but 8% higher spend overall. The cheapest mid-tier model alone fixed 6 of 8 at the lowest overall spend per fix but missed the hardest task. All 32 extracted DAC repairs match the human-guided LVS repair's integral nonlinearity (INL) within 0.005 least significant bits (LSB) at every code.

Abstract

Electronic Design Automation

Explore similar work

Who Plans, Who Edits? Verified, Cost-Aware Division of Labor for LLM-Driven Analog Layout Repair

Simulation-Aware In-Context Policy Improvement for LLM-Aided Analog Layout Refinement

PANDA: An LLM-Enhanced Performance-Driven Analog Design Framework Bridging Design Intent and Layout Generation