iScript: A Domain-Adapted Large Language Model and Benchmark for Physical Design Tcl Script Generation

Die Arbeit stellt iScript vor, ein spezialisiertes Large Language Model und einen umfassenden Benchmark für die Generierung von Tcl-Skripten im physischen Chipdesign, die durch eine mehrstufige Daten-Synthesepipeline und eine zweistufige Validierung entwickelt wurden, um die Datenknappheit und hohen Zuverlässigkeitsanforderungen in EDA-Flows zu bewältigen.

Das Wesentliche

Stellen Sie sich vor, Sie müssten einen riesigen, hochkomplexen Schaltschrank für einen modernen Computer entwerfen. Das ist die Aufgabe eines Chip-Entwurfsingenieurs. Um diesen Schaltschrank zu bauen, nutzen sie eine spezielle Programmiersprache namens Tcl. Diese Sprache ist wie eine sehr strenge, altmodische Bedienungsanleitung: Ein einziger falscher Befehl kann den ganzen Schaltschrank zerstören oder ihn so ineffizient machen, dass er nicht funktioniert.

Bisher mussten Menschen diese tausenden von Zeilen Code mühsam von Hand schreiben. Das ist anstrengend, fehleranfällig und dauert ewig.

Hier kommt das neue Projekt iScript ins Spiel. Es ist wie ein super-intelligenter, speziell ausgebildeter Assistent, der gelernt hat, diese schwierige Sprache perfekt zu beherrschen.

Hier ist die Geschichte des Projekts, einfach erklärt:

1. Das Problem: Der leere Kochbuch-Schrank

Stellen Sie sich vor, Sie wollen einen Kochkurs für eine sehr spezielle, exotische Küche geben (die "Chip-Design-Küche"). Das Problem? Es gibt kein Kochbuch. Niemand hat die Rezepte (die Skripte) öffentlich geteilt, weil sie Firmengeheimnisse sind.

• Das Dilemma: Normale KI-Modelle (wie ein allgemeiner Koch) wissen zwar, wie man Eier kocht, aber sie haben noch nie von diesen speziellen "Chip-Zutaten" gehört. Wenn man sie fragt, raten sie nur, und das Ergebnis ist meistens ungenießbar (fehlerhafter Code).

2. Die Lösung: iScript – Der Spezial-Koch

Die Forscher haben einen neuen Koch namens iScript erschaffen. Aber wie trainiert man einen Koch, wenn es keine Rezepte gibt? Sie haben einen kreativen Trick angewendet:

• Schritt 1: Das Erfinden von Rezepten (Daten-Synthese)
  Statt auf echte Rezepte zu warten, haben sie einen "Koch-Roboter" (eine andere, starke KI) gebeten, tausende von theoretischen Rezepten zu erfinden, indem er die Zutatenlisten (Befehle) aus den Handbüchern durcheinandergewürfelt hat.
• Schritt 2: Der strenge Prüfer (Syntax-Check)
  Ein anderer Roboter hat diese Rezepte auf Fehler geprüft. Alles, was grammatikalisch falsch war (z. B. "Salz in den Ofen" statt "Salz in den Topf"), wurde weggeworfen. Nur die technisch korrekten Rezepte blieben übrig.
• Schritt 3: Die Rückwärts-Logik (CoT)
  Das war der geniale Teil: Die KI hat die korrekten Rezepte genommen und sich gefragt: "Welche Frage müsste ein Mensch gestellt haben, um genau dieses Rezept zu erhalten?"
  So haben sie eine riesige Bibliothek aus Frage-Antwort-Paaren erstellt, bei denen die KI nicht nur das Rezept (den Code), sondern auch den Gedankengang (warum sie dieses Rezept gewählt hat) gelernt hat.

Mit diesem "selbstgemachten Kochbuch" haben sie dann ihren Assistenten iScript trainiert. Er ist jetzt ein Experte für genau diese Art von Chip-Design.

3. Der Prüfstand: iScript-Bench

Wie weiß man, ob der Koch wirklich gut ist? Man kann ihn nicht einfach in eine echte Fabrik schicken, um zu sehen, ob der Schaltschrank funktioniert – das wäre zu teuer und zu riskant.
Stattdessen haben die Forscher einen simulierten Prüfstand gebaut:

1. Der Grammatik-Check: Schaut der Assistent, ob die Sätze korrekt sind? (Wie ein Lehrer, der nach Rechtschreibfehlern sucht).
2. Der Logik-Check: Eine zweite KI liest den Code und fragt: "Macht das Sinn? Würde das den Schaltschrank so bauen, wie gewünscht?"

Sie haben einen Test namens iScript-Bench entwickelt, der Aufgaben von "einfach" (ein Befehl) bis "sehr schwer" (komplexe Logik) abdeckt.

4. Das Ergebnis: Der Spezialist gewinnt

Als sie iScript gegen die großen, allgemeinen KI-Modelle (wie GPT, Gemini, Claude) antreten ließen, war das Ergebnis eindeutig:

• Die allgemeinen Modelle waren wie Allround-Köche: Sie können Pizza backen, aber wenn man sie bittet, ein komplexes Chip-Design zu programmieren, scheitern sie oft an den Details.
• iScript war wie ein Meister-Koch für diese eine spezielle Küche. Er hat bei fast allen Aufgaben deutlich besser abgeschnitten, besonders bei den schwierigen Fragen. Er macht weniger Fehler und versteht die Logik hinter den Befehlen viel besser.

Zusammenfassung in einer Metapher

Stellen Sie sich vor, Sie müssten ein riesiges, tausendstöckiges Gebäude bauen.

• Die alten KI-Modelle sind wie Bauarbeiter, die nur wissen, wie man Ziegelsteine stapelt. Wenn man sie bittet, den gesamten Bauplan zu erstellen, bauen sie ein Haus, das umfällt.
• iScript ist wie ein Architekt, der jahrelang nur für dieses eine spezielle Gebäude-Design trainiert wurde. Er kennt jede Norm, jede Schraube und jede Regel. Er kann den Bauplan (das Skript) so präzise erstellen, dass das Gebäude stabil steht.

Fazit: Die Forscher haben gezeigt, dass man KI nicht einfach "so lassen" kann. Wenn man sie für spezielle, hochkomplexe Aufgaben wie das Chip-Design trainiert – indem man ihr eine eigene, synthetische Wissensbasis gibt – dann wird sie zum unersetzlichen Experten. Das spart Zeit, Geld und verhindert teure Fehler in der Halbleiterindustrie.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „iScript: A Domain-Adapted Large Language Model and Benchmark for Physical Design Tcl Script Generation" auf Deutsch:

1. Problemstellung

Der Bereich des modernen ASIC-Entwurfs (Physical Design, PD) ist durch extrem komplexe Prozesse gekennzeichnet, die stark auf Tcl-Skripte (Tool Command Language) angewiesen sind, um Tools wie Cadence Innovus zu steuern. Trotz des Fortschritts bei Large Language Models (LLMs) gibt es erhebliche Hürden bei der Automatisierung dieser Skripterstellung:

• Datenknappheit: Es gibt kaum öffentlich zugängliche, hochwertige Tcl-Skripte für den physischen Entwurf, da diese oft proprietär sind.
• Domain-spezifische Semantik: Die Befehle und Optionen von EDA-Tools bilden ein spezialisiertes, spärliches Vokabular, das allgemeine LLMs kaum kennen. Zudem bestehen starke semantische Kopplungen zwischen Befehlen (z. B. müssen Platzierungsbereiche mit dem Floorplan übereinstimmen).
• Hohe Zuverlässigkeitsanforderungen: Fehlerhafte Skripte können zu teuren Design-Iterationen führen.
• Fehlende Benchmarks und Evaluierung: Es existiert kein standardisiertes Benchmark für PD-Tcl-Generierung. Eine vollständige funktionale Validierung erfordert den Einsatz teurer kommerzieller EDA-Tools, was die Reproduzierbarkeit und Skalierbarkeit von Forschungen einschränkt.

2. Methodik

Die Autoren schlagen einen umfassenden Ansatz vor, der aus einem neuen Trainingsdatensatz, einem spezialisierten Modell und einem neuen Evaluierungsframework besteht.

A. Daten-Synthese-Pipeline (Multi-Stage)

Um das Problem der Datenknappheit zu lösen, entwickelten die Autoren eine Pipeline zur Generierung eines 10.000-Tupel-Datensatzes (Anforderung, Chain-of-Thought, Skript):

1. Quellensammlung: Nutzung von Tool-Dokumentationen, Benutzerhandbüchern und Community-Foren.
2. Skript-Generierung (Stage 1): Erstellung einer großen Menge an Tcl-Skript-Fragmenten durch Permutationen und Kombinationen von Befehlen und Parametern (inspiriert von Multi-Agent-Systemen).
3. Statische Syntax-Validierung (Stage 2): Filterung der generierten Skripte mittels eines Tcl-Linters, um nur syntaktisch korrekte Skripte weiterzuverarbeiten.
4. Rückinferenz und CoT-Generierung (Stage 3): Ein leistungsstarkes „Teacher-Modell" (GPT-4.1) wird verwendet, um aus den validen Skripten die ursprüngliche natürliche Sprach-Anforderung („Requirement") zurückzufolgern. Anschließend wird eine Chain-of-Thought (CoT) Erklärung generiert, die den logischen Weg von der Anforderung zum Skript detailliert beschreibt.

B. Modell-Training (iScript)

Das Modell basiert auf Qwen3-8B und wird in zwei Stufen trainiert:

1. Domain-Adaptive Continued Pre-Training (CPT): Das Modell wird auf dem Rohkorpus der syntaktisch korrekten Tcl-Skripte vortrainiert, um die spezifische Syntax und das Vokabular von Innovus-Tcl zu erlernen („Fluency").
2. Supervised Fine-Tuning (SFT) mit CoT: Das Modell wird auf dem (Anforderung, CoT, Skript)-Datensatz feinabgestimmt. Der Fokus liegt hier auf dem semantischen Mapping von Benutzerabsichten zu korrekten Aktionen unter Einbeziehung des logischen Denkprozesses (CoT), um komplexe mehrstufige Anforderungen zu bewältigen.

C. Evaluierungs-Framework (iScript-Bench & Two-Step Verification)

Da eine vollständige Ausführung in kommerziellen Tools oft nicht möglich ist, wurde ein zweistufiges Verifikationsframework entwickelt:

1. Statische Syntax-Verifikation: Skripte werden in einer leichten, physikalisch konsistenten „Sandbox" (basierend auf minimalen Layouts) ausgeführt. Fehler werden durch das Parsing von Tool-Logs (Suche nach ** ERROR:) erkannt.
2. LLM-basierte funktionale Evaluierung: Skripte, die die Syntaxprüfung bestehen, werden von einem wissensgestärkten LLM (mit Zugriff auf Befehlsdefinitionen aus Handbüchern) auf ihre funktionale Korrektheit bezüglich der Anforderung geprüft. Dies ersetzt teure manuelle Überprüfungen.

Der iScript-Bench umfasst 116 Testfälle in 5 Kategorien (z. B. Floorplan-Anpassung, Timing-Analyse) und 3 Schwierigkeitsstufen (L1–L3).

3. Wichtige Beiträge

• iScript: Ein domain-adaptiertes LLM, das speziell für die Generierung von Innovus-Tcl-Skripten trainiert wurde und syntaktisch valide sowie semantisch sinnvolle Skripte erzeugt.
• iScript-Bench: Der erste umfassende Benchmark für die Generierung von Physical-Design-Tcl-Skripten, der verschiedene Aufgabenkategorien und Schwierigkeitsgrade abdeckt.
• Skalierbares Evaluierungs-Framework: Ein zweistufiger Ansatz (Syntax + LLM-Funktionalität), der eine zuverlässige und reproduzierbare Bewertung ohne direkten Zugriff auf teure kommerzielle EDA-Tools ermöglicht.
• Daten-Synthese-Strategie: Ein innovativer Workflow zur Erstellung hochwertiger Trainingsdaten durch Rückinferenz und CoT-Generierung aus synthetischen Skripten.

4. Ergebnisse

Die Experimente verglichen iScript mit führenden allgemeinen LLMs (GPT-4.1, Gemini-2.5-pro, Claude-sonnet-4.5, DeepSeek-V3.1).

• Überlegenheit in allen Kategorien: iScript erzielte in fast allen Kategorien (DIQA, NIAA, FA, PAO, TAO) die höchsten Werte.
  • Pass@1 (Syntax): iScript erreichte 59,48 % (Gesamt), während der zweitbeste (Gemini) nur 31,03 % erreichte.
  • Pass@1 (Funktion): iScript erreichte 18,97 %, deutlich vor Gemini (14,66 %).
  • Pass@5 (Syntax): iScript erreichte 91,38 %, was eine massive Lücke zu den anderen Modellen zeigt.
• Robustheit bei hoher Komplexität: Während die Leistung aller Modelle mit steigender Schwierigkeit (L1 bis L3) abfiel, behielt iScript die beste Robustheit. Bei den schwierigsten Aufgaben (L3) lag iScript bei der Syntax-Pass-Rate (Pass@1) bei 61,54 %, während andere Modelle oft unter 4 % fielen.
• Validierung der Evaluierung: Ein Abgleich zwischen der LLM-basierten funktionalen Bewertung und menschlichen Experten zeigte eine hohe Übereinstimmung. Das LLM-System war konservativ (keine „False Positives"), was die Zuverlässigkeit der gemeldeten Pass-Raten unterstreicht.

5. Bedeutung und Ausblick

Die Arbeit demonstriert, dass Domain-Adaptation und datengetriebene Synthese entscheidend sind, um LLMs für hochspezialisierte EDA-Aufgaben nutzbar zu machen. iScript überwindet die Lücke zwischen allgemeinen Sprachmodellen und den strengen Anforderungen des physischen Chip-Designs.

Einschränkungen und Zukunft:

• Die Trainingsdatenmenge ist noch begrenzt, was das Verständnis komplexer Befehlskombinationen einschränkt.
• Die funktionale Evaluierung basiert derzeit auf einem LLM und nicht auf der tatsächlichen Ausführung in einem kommerziellen Tool.
• Zukünftige Arbeiten zielen darauf ab, mehr hochwertige Daten zu sammeln und ein vollautomatisiertes Evaluierungssystem zu entwickeln, das Skripte tatsächlich in EDA-Tools ausführt.

Zusammenfassend stellt iScript einen bedeutenden Schritt in Richtung der Automatisierung von EDA-Workflows dar und liefert mit dem iScript-Bench eine notwendige Infrastruktur für zukünftige Forschung in diesem Bereich.