SchGen: Teaching LLMs to Design Circuit Boards Through Semantic Code

Paper: 2605.30345 Authors: Qinpei Luo, Ruichun Ma, Xinyu Zhang, Lili Qiu Categories: cs.AI, cs.CL, cs.LG

The Gap

Generative AI has automated IC design (chips), but PCB schematic design (the boards that connect chips) remains manual. Prior work focused on layout optimization or component placement given an existing schematic. No one tackled generating the schematic itself from natural language because existing formats (KiCad, Altium) are verbose XML/JSON with absolute coordinates and tool-specific syntax — LLMs drown in geometric noise and can’t reliably generate valid schematics.

Problem: PCB design manual + expertise-intensive
   |
   v
Gap: Existing formats = geometry-heavy + tool-specific
   |                    (X=142.5, Y=87.3, rotation=90...)
   v
Assumption: LLMs need semantic primitives, not coordinates
   |
   v
Method: New representation = editing operations + relative placement
   |                          (place R1 right-of U1, wire R1.pin2 to U1.GND)
   v
Evidence: SchGen outperforms baselines on wire accuracy + functional correctness
   |
   v
Conclusion: Representation design > model scale for hardware generation

The Increment

One sentence: Before — PCB schematics locked in geometry-heavy formats, inaccessible to LLMs; After — semantic code representation enables LLM-driven schematic generation from natural language.

Core Mechanism

SchGen’s representation has three layers. First, component instantiation declares parts with semantic names (not coordinates): U1 = MCU("STM32F4"). Second, relative placement positions components using spatial relations: place(R1, right_of=U1, offset=2). Third, pin-name wiring connects components by function, not geometry: wire(R1.pin2, U1.GND). This transforms schematic generation from “predict X/Y coordinates” into “predict which components connect and how.”

Input: "Add LED indicator to microcontroller"
   |
   v
[Component Layer]  U1=MCU, LED1=LED, R1=Resistor
   |
   v
[Placement Layer]  place(LED1, above=U1)
   |               place(R1, between=[U1, LED1])
   v
[Wiring Layer]     wire(U1.GPIO_PIN, R1.pin1)
   |               wire(R1.pin2, LED1.anode)
   v               wire(LED1.cathode, U1.GND)
Output: Executable schematic code

Think of it like cooking instructions vs. a photograph of a dish. Traditional formats are the photograph — they show where every ingredient ended up (X=5cm, Y=3cm), but you can’t recreate the dish from pixel coordinates. SchGen’s representation is the recipe — it tells you the steps (add resistor, place it near the chip, connect pin 2 to ground). The recipe is executable: a renderer can turn it into any visual format. More importantly, an LLM can learn to write recipes because they follow semantic logic (resistors limit current, so they go between power sources and LEDs), not arbitrary geometry.

Key Concepts

• Semantic grounding: Instead of treating schematics as drawings (lines at coordinates), treat them as functional relationships (this resistor limits current to that LED). Pin names like GPIO_PIN and GND carry meaning; coordinates like (142.5, 87.3) don’t. When you wire R1.pin2 to U1.GND, you’re expressing intent (connect resistor to ground), not geometry. This lets the LLM reason about electrical function rather than memorize spatial patterns. Example: “Add pull-up resistor” becomes R1=Resistor(10k); wire(R1.pin1, U1.VCC); wire(R1.pin2, U1.INPUT) — the model understands pull-ups connect between power and signal, not because it saw this X/Y pattern before.

• Relative placement: Absolute coordinates are brittle (move one component, everything breaks). Relative placement uses spatial relations: right_of, above, between. This mirrors how humans think (“put the capacitor near the power pin”) and makes schematics robust to layout changes. The renderer resolves relations into coordinates, but the LLM never sees them. Example: place(C1, near=U1.VCC, offset=1) works regardless of where U1 ends up on the canvas.

Framework Shift

Before (geometry-driven):              After (semantics-driven):

User: "Add LED"                        User: "Add LED"
   |                                      |
   v                                      v
LLM generates:                         LLM generates:
<component id="LED1"                   LED1 = LED("red")
 x="142.5" y="87.3"                    place(LED1, above=U1)
 rotation="90">                        R1 = Resistor("330")
<wire x1="142.5" y1="87.3"            place(R1, between=[U1,LED1])
      x2="98.2" y2="65.1"/>            wire(U1.GPIO, R1.pin1)
                                       wire(R1.pin2, LED1.anode)
Problem: Coordinates are              wire(LED1.cathode, U1.GND)
arbitrary, no semantic check
                                       Benefit: Semantically valid,
                                       renderer handles geometry

[One sentence: From predicting pixel-level geometry to predicting functional relationships, the core shift is treating schematics as executable code rather than static drawings.]

Expert Assessment

Problem choice: Real gap. PCB design is a $70B+ industry stuck in manual workflows. Prior generative work (IC synthesis, layout optimization) assumed the schematic already exists. This is the first to tackle schematic generation itself, which is the bottleneck for hardware prototyping.

Method maturity: The representation is clever and well-motivated. Relative placement and pin-name wiring are how human engineers think. The human-agent collaborative dataset pipeline (converting open-source designs into semantic code) is pragmatic but labor-intensive — they don’t report annotation cost or inter-annotator agreement. The model itself is a fine-tuned LLM (likely Llama-based, though they don’t specify), nothing architecturally novel. The win comes from representation, not model innovation.

Experimental integrity: Baselines are fair (raw KiCad format, coordinate-based representations, GPT-4). Metrics focus on wire connectivity accuracy and functional correctness (does the circuit do what the user asked?). They test on held-out designs and user prompts. One concern: dataset size isn’t disclosed, so we can’t assess overfitting risk. Ablations show relative placement and pin-name wiring both matter, which is good. No user study — would be valuable to see if real engineers find the output usable.

Writing quality: Abstract and intro are crisp. Method section is dense but clear. Related work undersells prior efforts in hardware generation (there’s a body of work on HDL synthesis they gloss over). Experiments section could use error analysis — when does SchGen fail? What kinds of prompts break it? The paper reads like it was written under deadline pressure; another revision pass would help.

Verdict: weak accept — Solid contribution on representation design for a real problem, but experimental evaluation could be deeper and the method itself is straightforward fine-tuning once you have the representation.

Takeaways

Representation matters more than model scale: SchGen with a smaller LLM beats GPT-4 on this task because the representation is tailored to the domain. If you’re applying LLMs to structured generation (CAD, music notation, molecular design), invest in designing a semantically grounded intermediate format before throwing compute at the problem.

Relative positioning > absolute coordinates: Any domain with spatial relationships (UI layout, floor plans, network diagrams) benefits from relative placement primitives. Let the model reason about “near” and “between,” not pixel offsets.

Human-agent collaboration for dataset construction: They used LLMs to bootstrap dataset creation (converting existing designs into their format), then had humans verify. This pipeline is reusable for other domains where you have legacy data in the wrong format but can’t afford full manual annotation.