CktEvo: Repository-Level RTL Code Benchmark for Design Evolution

Das Paper stellt CktEvo vor, ein Benchmark und Referenzrahmen für die evolutionäre Optimierung von RTL-Code auf Repository-Ebene, der mittels eines geschlossenen Regelkreises aus LLM-Änderungen und Toolchain-Feedback funktionserhaltende Verbesserungen von Leistung, Leistungsaufnahme und Flächennutzung (PPA) in realen Hardware-Designs ohne menschliches Eingreifen ermöglicht.

Das Wesentliche

Stellen Sie sich vor, Sie haben einen riesigen, komplexen Kochrezept-Buch (das ist der RTL-Code, der beschreibt, wie ein Computer-Chip funktioniert). Dieses Buch besteht aus hunderten von Seiten, die alle miteinander verknüpft sind. Wenn Sie eine Zutat auf Seite 1 ändern, kann das auf Seite 50 den Geschmack des ganzen Gerichts verändern.

Das Ziel ist es, das Gericht schneller (weniger Verzögerung), kleiner (weniger Platz auf dem Chip) und effizienter (weniger Stromverbrauch) zu machen, ohne dass es plötzlich schmeckt wie etwas anderes (die Funktion muss gleich bleiben).

Bisher haben KI-Modelle (wie Chatbots) versucht, ganze neue Rezepte aus dem Nichts zu erfinden oder nur kleine Fehler auf einer einzelnen Seite zu korrigieren. Das Problem: Wenn man ein ganzes Buch umschreibt, passieren oft Fehler, und die KI "halluziniert" Dinge, die in der realen Welt nicht funktionieren.

Hier kommt CktEvo ins Spiel. Es ist wie ein super-intelligenter, geduldiger Küchenchef-Assistent, der speziell dafür trainiert wurde, bestehende, komplexe Kochbücher Schritt für Schritt zu verbessern.

Wie funktioniert CktEvo? (Die Metapher)

Stellen Sie sich den Prozess als einen Kreislauf aus vier Schritten vor, den der KI-Assistent immer wieder durchläuft:

1. Der Check (Die EDA-Werkzeuge):
   Zuerst nimmt der Assistent das aktuelle Rezept und probiert es in einer simulierten Küche aus (das sind die EDA-Tools). Er misst genau: "Wie lange dauert das Kochen?" und "Wie viel Platz braucht der Herd?".
   Ergebnis: Ein detaillierter Bericht, der sagt: "Auf Seite 42 ist der Ofen zu langsam" oder "Auf Seite 15 nehmen wir zu viel Platz ein".

2. Die Analyse (Der Graph-basierte Scanner):
   Der Assistent liest nicht einfach nur den Text. Er erstellt eine Landkarte des Rezepts. Er sieht genau, welche Zeile auf welcher Seite mit welcher anderen Zeile verbunden ist. So findet er die "Engpässe" – die Stellen, die das ganze System verlangsamen.

3. Der Vorschlag (Der KI-Chatbot):
   Jetzt fragt der Assistent die KI: "Hey, hier auf Seite 42 ist ein Engpass. Wie können wir diesen Satz umschreiben, damit es schneller geht, aber der Geschmack (die Funktion) gleich bleibt?"
   Die KI schlägt eine kleine Änderung vor (z. B. "Statt 'wenn A dann B' schreiben wir 'A und B parallel'").

4. Der Test und die Korrektur (Die Sicherheitskontrolle):
   Bevor die Änderung ins Buch geschrieben wird, prüft der Assistent sofort:

   • Ist die Grammatik korrekt? (Syntax-Check)
   • Schmeckt das Gericht immer noch genau so wie vorher? (Formale Verifikation)
   • Ist es wirklich schneller? (Neuer Testlauf)

   Wenn ja: Eintrag ins Buch! Wenn nein: Die Änderung wird verworfen oder die KI bekommt eine Rückmeldung, um es noch einmal zu versuchen.

Was haben sie herausgefunden?

Die Forscher haben dieses System mit echten, komplexen Designs getestet (von einfachen Prozessoren bis hin zu Sicherheitsmodulen).

• Es funktioniert wirklich: Ohne dass ein Mensch eingreifen musste, konnte das System die Designs im Durchschnitt um 10,5 % effizienter machen. Das ist wie ein Koch, der ein Gericht 10 % schneller zubereitet, ohne die Zutaten zu ändern.
• Geschwindigkeit ist der Gewinner: Die größte Verbesserung war oft bei der Geschwindigkeit (Verzögerung). Die KI fand Wege, logische Schritte parallel zu machen, statt sie nacheinander abzuarbeiten.
• Der Unterschied zwischen Hobby- und Profi-Küche: Wenn man das System mit einfachen, kostenlosen Werkzeugen testete, waren die Ergebnisse riesig. Mit den allerbesten, teuren Profi-Werkzeugen (die in der Industrie genutzt werden) war der Gewinn kleiner, aber immer noch signifikant. Das liegt daran, dass die Profi-Werkzeuge schon sehr gut optimieren, aber die KI konnte noch die letzten paar Prozent herausholen, die für High-End-Chips entscheidend sind.

Warum ist das wichtig?

Früher mussten Ingenieure stundenlang manuell nachsehen, wo sie Code umschreiben könnten, um den Chip zu verbessern. Das war mühsam und fehleranfällig.

CktEvo zeigt, dass KI nicht nur neue Dinge erfinden kann, sondern auch bestehende, komplexe Systeme verbessern kann, ohne sie kaputtzumachen. Es ist ein wichtiger Schritt hin zu einer Zukunft, in der KI-Systeme wie erfahrene Ingenieure agieren: Sie verstehen den Kontext, arbeiten mit dem gesamten "Buch" (nicht nur einer Seite) und optimieren schrittweise, bis das Ergebnis perfekt ist.

Kurz gesagt: CktEvo ist der erste Schritt zu einem KI-Assistenten, der nicht nur schreibt, sondern echte Ingenieure bei der Optimierung von Computer-Chips unterstützt.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „CktEvo: Repository-Level RTL Code Benchmark for Design Evolution" auf Deutsch:

1. Problemstellung

Die Entwicklung von Register-Transfer-Level (RTL)-Code ist ein iterativer Prozess auf Repository-Ebene, bei dem Power, Performance und Area (PPA) aus den Interaktionen vieler Dateien und der nachgelagerten EDA-Toolchain (Electronic Design Automation) entstehen.

Obwohl Large Language Models (LLMs) zunehmend in der Hardware-Entwicklung eingesetzt werden, bestehen erhebliche Lücken für den industriellen Einsatz:

• Fokus auf Generierung/Debugging: Die meisten bisherigen Arbeiten konzentrieren sich auf die Generierung von Code aus natürlichen Sprachprompts oder das Debugging. Dies führt oft zu Halluzinationen und mehrdeutigen Ergebnissen, die eine manuelle Expertenprüfung erfordern.
• Isolierte Module: Andere Ansätze beginnen mit formalen Eingaben (z. B. HLS-Code), optimieren jedoch nur isolierte Module und ignorieren die kritischen Abhängigkeiten zwischen verschiedenen Dateien (Cross-File Dependencies).
• Fehlende Repository-Ebene: PPA-Ergebnisse sind emergente Eigenschaften des gesamten Repositories, nicht einzelner Dateien. Es fehlte bisher ein Benchmark und ein Framework, das die evolutionäre Optimierung über das gesamte Repository hinweg unter Beibehaltung der funktionalen Korrektheit adressiert.

2. Methodik

Die Autoren stellen CktEvo vor, einen Benchmark und ein Referenzframework für die evolutionäre Optimierung von RTL-Code auf Repository-Ebene.

A. Aufgabenformulierung

Die Aufgabe wird als iteratives, multi-objektives Optimierungsproblem definiert:

• Eingabe: Ein initiales „Golden Design"-Repository ($D_0$) bestehend aus mehreren Verilog-Dateien und Design-Constraints (SDC).
• Ziel: Erzeugung einer Sequenz von Designs ($D_0, ..., D_T$), die funktional äquivalent zum Original bleiben, aber die nicht-funktionalen Metriken (Fläche und Verzögerung/Delay) verbessern.
• Randbedingungen: Keine neuen Funktionalitäten, strikte funktionale Äquivalenz (verifiziert durch formale Tools), Optimierung von Area ($J_{area}$) und Delay ($J_{delay}$).

B. Der CktEvo Benchmark

Der Benchmark besteht aus 11 hochwertigen, menschlich geprüften Verilog-Repositories aus Open-Source-Projekten (z. B. DeepCircuitX, ForgeEDA).

• Vielfalt: Die Designs umfassen Prozessoren (RISC, simple_cpu), Controller (mem_ctrl, sdc_ctrl), Hochgeschwindigkeitsschnittstellen (ethmac, usb, spi) und spezielle Einheiten (NN-Engine, HSM).
• Skalierung: Von kleinen Designs (ca. 600 Zeilen) bis zu komplexen Pipelines (z. B. RISC mit 42 Modulen und über 5.000 Zeilen).
• Eigenschaften: Alle Designs sind synthetisierbar (sowohl mit Open-Source-Tools wie Yosys als auch kommerziellen Tools) und repräsentieren einen lokalen Optimum-Zustand, der durch traditionelle EDA-Tools kaum weiter optimiert werden kann.

C. Closed-Loop Evolution Framework

Das Framework automatisiert den Optimierungsprozess durch einen Agenten, der auf LLMs basiert und folgende Schritte durchläuft (siehe Abbildung 1 im Paper):

1. EDA-Toolchain: Laufzeit von Logik-Synthese (LS) und Static Timing Analysis (STA) zur Generierung von PPA-Berichten.
2. Graph-basierter Code-Analysator: Parsen des RTL-Codes in einen Control Data Flow Graph (CDFG) und Annotation der kritischen Pfade und Module basierend auf den EDA-Berichten.
3. Prompt-Generator: Erzeugung eines kontextreichen Prompts für das LLM, der die Bottlenecks, den Code-Ausschnitt und die Zielmetrik (z. B. Minimierung der Verzögerung) spezifiziert.
4. LLM-Modifikation: Das LLM schlägt Änderungen (Diff-Format) vor.
5. Rektifikation & Verifikation:
   • Syntaxkorrektur und schnelle Synthese-Checks.
   • Formale Verifikation (z. B. Synopsys Formality), um die funktionale Äquivalenz zum Golden Design sicherzustellen.
6. Evolution-Algorithmus:
   • Nutzung eines Island-basierten Populationsmodells (inspiriert von AlphaEvolve) zur Erhaltung der Suchvielfalt.
   • MAP-Elites-Ansatz: Das Archiv speichert die besten Designs für verschiedene strukturelle Merkmale (z. B. Modulanzahl, Registeranzahl), um Diversität zu gewährleisten.
   • Dual-Cycle Evaluation: Ein schneller Filter für Syntaxfehler gefolgt von einer vollständigen Evaluation nur für vielversprechende Kandidaten.

3. Wichtige Beiträge

1. Formalisierung der Repository-Level-Optimierung: Definition einer Aufgabe, die funktionale Äquivalenz und PPA-Optimierung über mehrere Dateien hinweg kombiniert.
2. Erster Benchmark für Design-Evolution: CktEvo ist der erste öffentlich verfügbare Benchmark, der vollständige, mehrdateilige RTL-Repositories für iterative Verbesserungen bereitstellt (nicht nur Code-Generierung).
3. Referenzframework für geschlossene Schleifen: Ein automatisiertes System, das Toolchain-Feedback, Cross-File-Änderungen und iterative Reparatur integriert, ohne menschliches Eingreifen.

4. Ergebnisse

Die Experimente wurden mit drei LLMs (DeepSeek-v3, GPT-4o, Qwen3-coder) durchgeführt, sowohl mit Open-Source-Tools (Yosys) als auch mit kommerziellen Tools (Synopsys Design Compiler).

• Open-Source Toolchain (Yosys):
  • Das Framework konnte bei allen 11 Designs die PPA-Metriken verbessern.
  • DeepSeek-v3 erzielte eine durchschnittliche Reduktion des Area-Delay-Products (ADP) um 10,50%.
  • Die Verzögerung (Delay) wurde signifikant stärker reduziert (geometrisches Mittel: -7,92%) als die Fläche (-2,80%).
  • Besonders starke Verbesserungen wurden bei rechenintensiven Designs (z. B. HSM: -34,97% Delay) und Controllern erzielt.
• Kommerzielle Toolchain (Synopsys):
  • Die Verbesserungen waren geringer (durchschnittlich -1,77% ADP), da kommerzielle Synthesewerkzeuge bereits sehr aggressiv optimieren und viele RTL-Änderungen auf Gate-Level-Niveau neutralisieren.
  • Dennoch wurden signifikante Einzelerfolge erzielt, z. B. eine Delay-Reduktion von 10,61% beim audio-Design und eine Flächenreduktion von ~536 µm² beim hsm-Design.
• Analyse der Optimierungsstrategien:
  Die LLMs entwickelten konsistent drei Hauptstrategien:
  1. Coding Style: Anpassung an synthese-freundliche Stile (z. B. Blocking zu Non-Blocking Assignments).
  2. Logic Flattening & Pruning: Umwandlung serieller Logikketten in parallele Ausdrücke und Entfernen redundanter Pipeline-Register.
  3. State Machine Optimization: Zusammenführen von Statusflags und Vereinfachung von Übergangslogik.

5. Bedeutung und Ausblick

• Paradigmenwechsel: CktEvo verschiebt den Fokus von der reinen Code-Generierung hin zur evolutionären Optimierung bestehender, funktionierender Designs. Dies ist für die Praxis relevanter, da die meisten Chips bereits existieren und optimiert werden müssen.
• Autonomie: Das System demonstriert, dass LLMs autonom PPA-Verbesserungen erzielen können, die über das hinausgehen, was traditionelle EDA-Tools allein erreichen, insbesondere durch das Verständnis von Cross-File-Abhängigkeiten.
• Herausforderungen:
  • Architekturelle Refaktorierung: Aktuelle LLMs optimieren oft nur lokale Codestile. Für weitere Fortschritte (besonders mit kommerziellen Tools) müssen Agenten in der Lage sein, globale Architekturänderungen vorzunehmen.
  • Domänenwissen: Die Modelle benötigen besseres Wissen über spezifische PDKs (Process Design Kits) und Toolchain-Eigenschaften, um effektivere Änderungen vorzuschlagen (z. B. durch RAG oder Fine-Tuning).

Zusammenfassend etabliert CktEvo eine rigorose und ausführbare Grundlage für die Forschung an LLM-gestützter Hardware-Engineering-Automatisierung, die den Weg von Code-Generatoren hin zu echten Design-Experten ebnet.