Source-linked AI summary
The Code Behind the Layout: AI Agents for Analog Layout Generators
Minxing Chu, Anhang Li, Martins Atilla, Ruichen Qi, Mehdi Saligane
TL;DR
Analog layout generators preserve design decisions across configurations, but writing them takes expertise, and models may instead draw layouts directly. The paper tests generator editing and family-level checks on gLayout, finding that family-label training improves a local model’s hidden-configuration feasibility by 21 percentage points over point-label training.
Problem
Generator frameworks preserve layout decisions across device sizes, but writing them requires expertise, while LLMs can also draw layouts directly; the paper asks what generators contribute and how models benefit from working inside them.
Source: §I · p. 1Method
Controlled gLayout experiments study generator-source edits evaluated across circuit families and use family verdicts to train a local editing model.
Source: §IV · p. 3, §V · p. 4Results
On hidden configurations, family-label training reaches S2 on 21 percentage points more than point-label training, under both SFT and DPO.
Source: §V · p. 4Takeaways & Limitations
Generator edits can be reused across a layout family, and family-check results can train a smaller local model at a fraction of frontier-model inference cost.
Source: §VI · p. 4
Abstract
from arXiv · showhide
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.
I. INTRODUCTION
Generator frameworks preserve layout decisions in parameterized code, but writing them still requires substantial expertise. The paper asks whether models should draw layouts directly or work inside generators, and examines where they should edit, how edits should be evaluated, and whether family verdicts can train a local model.
I. INTRODUCTION
- Generator frameworks encode layout decisions in parameterized programs, so new device sizes produce members of the same layout family; prior frameworks include BAG, LAYGO2, ALIGN, MAGICAL, and gLayout,.The frameworks differ in how they represent or derive layout, but each aims to carry design decisions across configurations.Source: §I · p. 1
- Writing a generator still demands expertise in layout design rules, device construction, routing, and the framework’s programming interface.Meanwhile, LLMs have begun contributing to generator design and layout tasks,,.Source: §I · p. 1
- LLMs can propose circuit topologies,, size analog circuits, and draw entire layouts from scratch, polygon by polygon, directly from design intent.They also translate design intent into generator code, extend existing generators, tune exposed parameters from post-layout feedback, [15], and repair design-rule violations with a checker in the loop [16],.Source: §I · p. 1
- The study asks where a model should act, how many family configurations an edit should be tested on, and whether those verdicts can train a lower-cost local model.The comparison includes raw geometry, framework-cell calls, and generator source; family checks may supply training labels for reducing frontier-model inference tokens.Source: §I · p. 1
- Controlled experiments on gLayout in SKY130 compare Claude Opus 5.5 and GPT-6.1 across three action levels, then use family verdicts to train a local 32B editing model.The three levels are raw geometry, device and routing cells, and full generators.Source: §I · pp. 1–2
II. TASKS, VERIFICATION AND SETUP
The setup defines what counts as a passing candidate and how quality is compared, then applies consistent tasks and evaluation protocols across the experiments. Each task includes visible and hidden family configurations, while searches record both token use and physical CPU time.
II. TASKS, VERIFICATION AND SETUP
- A patch changes generator source but cannot alter device sizes, ports, or the read-only reference netlist and intended devices.The generator is written as Gθ(z, p), with editable source θ, legal configuration z, and fixed process p.Source: §II · p. 2
- S2 requires full-rule DRC and LVS, a finger-by-finger device check, extracted parasitics, and converged simulations meeting every specification at three process corners.A candidate is feasible on a configuration if it reaches S2 there; extraction and three-corner simulation constitute a full evaluation.Source: §II · p. 2
- Quality is compared only among feasible candidates: component generators use layout area, while OTAs use worst-corner unity-gain bandwidth per unit area.Feasibility is a constraint, not a weighted score, so unstable amplifiers cannot be rewarded for bandwidth.Source: §II · p. 2
- Across 24 tasks covering six component generators and two OTAs, each task starts from a layout with a design issue and specifies an anchor, eight visible configurations, and sixteen hidden configurations.Hidden configurations are evaluated once at the end without feedback to the policy.Source: §II · p. 2
- The searches use fresh sessions in which policies submit git-style diffs and request evaluations; each reply is limited to 1,024 tokens, and output tokens and CPU time are recorded.Fig. 2 organizes analysis around action-level outcomes, area–bandwidth rankings, and four screening signals compared with full evaluations.Source: §II · p. 2, Figure 2 · p. 2
III. WHERE TO ACT: GENERATOR EDITS COST LEAST
The study compares layout edits at the geometry, primitive, and generator-source levels. Generator-level edits are smaller and cheaper to infer, while verified edits can be checked across a family of configurations.
III. WHERE TO ACT: GENERATOR EDITS COST LEAST
- At the generator level, GPT-6.1 verified 44 of 52 reuse episodes, and 45 of 46 verified anchors held on every hidden configuration.At geometry and primitive levels, it verified one episode each out of 119 and 118, respectively.Source: §III · p. 2
- One verified generator edit could yield 17 verified configurations by also testing its 16 hidden configurations.The generator-level edit is typically a change to one argument or call, whereas lower-level first diffs added 32–41 lines.Source: §III · p. 2
- A generator-level verified configuration cost 56 times fewer output tokens than geometry or primitive edits: about 0.3k versus 16.1k.Physical CPU time was similar: about 4 minutes per verified configuration at the generator level and 3 minutes below it.Source: §III · p. 3
IV. EVALUATING AN EDIT: JUDGE IT ON THE FAMILY
A generator-source edit applies across the configurations served by that generator, so it offers family-wide reach but can also cause regressions. The study scores edits on both coverage and regression and asks which configurations to evaluate under a limited budget.
IV. EVALUATING AN EDIT: JUDGE IT ON THE FAMILY
- A generator-level edit reaches the whole configuration family because its members share the revised source, but that shared change can also break a member.A check on only one configuration cannot distinguish an edit that generalizes from one that causes a regression elsewhere.Source: §IV · p. 3
- Coverage measures the fraction of configurations in a test set D that reach S2 with the revised generator.Source: §IV · p. 3
- Regression measures the fraction of configurations that reached S2 before the edit but no longer do afterward; partial evaluation also requires choosing which configurations to check.Source: §IV · p. 3
A. Checks need the physical stages, rarely the full simulation
The fidelity study distinguishes checking whether layouts pass from ranking layouts that pass. Its results support running physical checks on every candidate and reserving three-corner simulation for candidates that survive extraction.
A. Checks need the physical stages, rarely the full simulation
- Every layout that passed DRC, LVS, and the device check also met every specification at all three corners in the evaluated oracle pools.The authors therefore run physical stages on every candidate and three-corner simulation only on candidates that survive extraction.Source: A. Checks need the physical stages,… · p. 3
- Bounding-box area ranked passing layouts almost perfectly on the five-transistor OTA (Spearman ρ = −0.97), but missed only 0.04% of bandwidth on the compact Miller OTA.Source: A. Checks need the physical stages,… · p. 3
- Area screening did not reliably predict physical-check success on the compact Miller OTA: only 4 of 16 area-selected layouts passed, while every RCΣ- or F3-selected layout passed.Three quarters of Miller layouts failed physical checks despite being legal; on the five-transistor pool, RCΣ and F3 lost the fewest evaluations to the time limit.Source: A. Checks need the physical stages,… · p. 3
B. Test the configurations where an edit is most likely to fail
The editing study compares rules for selecting configurations to test a patch when evaluations cannot cover the whole family. Risk-based rule C best preserved hidden configurations with the least breakage, while source edits also produced substantial layout improvements across tasks.
B. Test the configurations where an edit is most likely to fail
- Three quarters of revisions that improved the anchor under rules R, B, and C passed all seven other visible configurations evaluated in the search.The eight evaluations covered the anchor and seven of the eight other visible configurations.Source: B. Test the configurations where an… · p. 3
- On the sixteen hidden configurations, rule C kept the most configurations working with the least breakage for both policies, while rule A kept the fewest.Rule C selects untested configurations using distance from those already tested and a score that rises as specification margin falls.Source: B. Test the configurations where an… · pp. 3–4
- For the compact Miller OTA, 43 GPT and 12 Claude revisions passed every anchor check while another configuration failed DRC; component-generator revisions that passed the anchor held everywhere.Source: B. Test the configurations where an… · p. 4
V. FROM VERDICTS TO A LOCAL MODEL: FAMILY LABELS TRAIN THE BETTER POLICY
Family-wide verdicts produce a stronger local editing policy than point labels, while local inference costs less than frontier inference at the same hidden coverage. The section also describes how the training data and labels were built.
V. FROM VERDICTS TO A LOCAL MODEL: FAMILY LABELS TRAIN THE BETTER POLICY
- Training uses circuits from seven textbook designs, verified patches, and point or family labels, with hidden configurations evaluated only after the data are frozen.Family labels rank patches by coverage, regression, and quality across a family, whereas point labels use the anchor alone; the final data contain 648 SFT examples and 1,024 preference pairs. Free-form teacher plans yielded no applicable patch in forty attempts, whereas requests for exact replacement text did.Source: §V · p. 4
- On hidden configurations, family-trained models reach S2 21 percentage points more often than the same models trained on point labels under both SFT and DPO (95% bootstrap interval 11 to 30).Both family-trained models also outperform the untuned base model.Source: §V · p. 4
- Family-trained models regress least and improve the most tasks; the two labels disagree on which patch is better in 18% of preference pairs.Those disagreements are where the two models part ways.Source: §V · p. 4
- At the same hidden coverage, a local search costs 0.3 USD of GPU time versus 1.1 USD of frontier inference; training's 46 GPU-hours pay back after 144 searches.Physical verification costs about 148 CPU hours for GPT-6.1 searches and 106 for Claude searches, regardless of which model proposes edits.Source: §V · p. 4
VI. DISCUSSION AND CONCLUSION
The discussion argues that generator-source edits are more reusable than drawing layouts from scratch: one edit can serve a family of configurations. Verified cells, family testing, and the resulting training labels support this workflow.
VI. DISCUSSION AND CONCLUSION
- A generator edit is paid for once and, if it holds across a family, serves every layout the generator produces.By contrast, a drawn layout must be produced again for each new set of device sizes.Source: §VI · p. 4
- Verified cells keep edits small enough to check and make them easier to trust.Source: §VI · p. 4
- Because generators are parameterized, edits can be tested on other configurations, and family-check results can train a smaller local model at a fraction of the inference cost.Source: §VI · p. 4