VeriInteresting: An Empirical Study of Model Prompt Interactions in Verilog Code Generation

Die Studie „VeriInteresting" liefert eine empirische Analyse der Wechselwirkungen zwischen verschiedenen Sprachmodellklassen und Prompt-Strategien bei der Verilog-Code-Generierung und identifiziert generalisierbare Muster sowie modellspezifische Trends.

Das Wesentliche

Hier ist eine einfache Erklärung der Studie „VeriInteresting", die sich mit der Frage beschäftigt, wie künstliche Intelligenz (KI) beim Schreiben von Hardware-Code (Verilog) hilft – und wo sie noch stolpert.

Das große Bild: KI als neuer Architekt

Stellen Sie sich vor, Sie wollen ein Haus bauen.

• Software-Code (wie Python) ist wie das Schreiben eines Kochrezepts. Wenn Sie einen Fehler machen, sagt Ihnen der Computer: „Das schmeckt nicht." Sie können es einfach löschen und neu versuchen.
• Hardware-Code (Verilog) ist wie das Entwerfen einer echten Fabrik oder eines Brückenbau-Plans. Wenn Sie hier einen Fehler machen, bauen Sie keine Brücke, die wackelt – Sie bauen eine, die einstürzt, bevor sie überhaupt fertig ist. Die Regeln sind viel strenger, und die Zeitverzögerungen (Signale müssen genau zur richtigen Zeit ankommen) sind kritisch.

Diese Studie untersucht, wie gut verschiedene KI-Modelle diesen „Brückenbau" meistern, wenn man ihnen unterschiedliche Anweisungen (Prompts) gibt.

---

Die Hauptakteure: Die Baumeister

Die Forscher haben 18 verschiedene KI-Modelle getestet. Man kann sie in drei Gruppen einteilen:

1. Die Generalisten (Die Allrounder): Das sind die großen, bekannten KIs (wie GPT-4 oder Claude). Sie können alles ein bisschen, sind aber keine Spezialisten für Hardware.
2. Die Spezialisten (Die Auszubildenden): Das sind KIs, die extra auf Hardware-Code trainiert wurden. Sie kennen die Fachbegriffe und die Regeln besser.
3. Die Kleinen vs. Die Großen: Es gab Modelle mit wenig „Gehirn" (wenige Parameter) und solche mit riesigem Gehirn.

Die Experimente: Wie man den Baumeister anweist

Die Forscher haben nicht nur gefragt, sondern verschiedene Methoden ausprobiert, um die KI besser zu steuern:

• Der einfache Befehl: „Bau mir eine Brücke." (Baseline)
• Der strukturierte Plan: „Hier ist ein Formular: Fülle erst die Fundamente aus, dann die Säulen, dann das Dach." (Strukturierte Prompts)
• Das Nachdenken vor dem Handeln: „Erkläre mir zuerst, wie die Brücke funktionieren soll, bevor du den Code schreibst." (Chain-of-Thought)
• Die Vorlage: „Hier sind drei Beispiele von perfekten Brücken. Mach es genauso." (In-Context Learning)
• Der Optimierer: Eine KI, die automatisch versucht, den Befehl so lange zu verbessern, bis er perfekt ist.

Was haben sie herausgefunden? (Die überraschenden Ergebnisse)

1. Größe ist nicht alles, aber Training hilft

Ein riesiges Gehirn (ein großes KI-Modell) ist oft besser als ein kleines. Aber: Ein kleiner Spezialist, der extra für Hardware trainiert wurde, kann oft mit einem großen Generalisten mithalten oder ihn sogar schlagen.

• Analogie: Ein riesiger, intelligenter Ingenieur, der noch nie eine Brücke gebaut hat, macht vielleicht mehr Fehler als ein kleiner, erfahrener Handwerker, der sein ganzes Leben Brücken gebaut hat.

2. Der „Struktur-Falle"

Interessanterweise halfen strukturierte Anweisungen (Formulare, klare Schritte) nicht immer.

• Bei den Generalisten halfen klare Strukturen oft, weil sie sich daran halten mussten.
• Bei den Spezialisten (den extra trainierten KIs) führte eine zu strenge Struktur oft zu Chaos. Sie waren so darauf trainiert, „natürlich" zu denken, dass sie durch starre Formulare verwirrt wurden.
• Metapher: Ein erfahrener Koch (Spezialist) mag es, wenn man ihm sagt: „Mach einfach ein tolles Essen." Wenn man ihm aber ein strengen 10-Schritte-Formular gibt, verliert er den Fluss und das Essen wird schlecht. Ein Anfänger (Generalist) braucht das Formular, um nicht zu scheitern.

3. Das „Nachdenken" (Chain-of-Thought) ist ein zweischneidiges Schwert

Wenn man die KI auffordert, erst zu überlegen, bevor sie schreibt, hilft das manchmal. Aber oft führt das dazu, dass die KI sich selbst widerspricht oder falsche Annahmen trifft.

• Analogie: Wenn Sie einen Architekten bitten, erst eine 5-seitige Abhandlung über Statik zu schreiben, bevor er den Plan zeichnet, könnte er in der Theorie so viel Zeit verlieren, dass er im Plan einen Fehler macht, den er ohne Nachdenken gar nicht gemacht hätte.

4. Der „Optimierer" (GEPA) war enttäuschend

Die Forscher versuchten, die Anweisungen automatisch durch einen evolutionären Prozess (wie in der Natur: „Überleben des Passendsten") zu verbessern. Das funktionierte nicht so gut wie erwartet.

• Ergebnis: Die automatisch optimierten Anweisungen waren oft kurz und unvollständig oder zu lang und verwirrend. Sie brachten keinen großen Vorteil gegenüber einem guten, menschlich geschriebenen Befehl.

5. Der Test ist entscheidend

Ein Modell, das auf dem einen Test (Simulation) gut abschnitt, schaffte es auf dem anderen Test (Formale Überprüfung) nicht.

• Wichtig: Man kann sich nicht auf einen einzigen Test verlassen. Ein Modell könnte wie ein Schüler sein, der die Prüfungsfragen auswendig gelernt hat, aber im echten Leben (in der Fabrik) versagt.

Das Fazit für die Praxis

Die Studie sagt uns: Es gibt keinen „einen perfekten Weg".

• Wenn Sie eine KI für Hardware-Code nutzen wollen, müssen Sie wissen, welches Modell Sie haben.
• Für große, allgemeine KIs helfen klare, strukturierte Anweisungen und Beispiele.
• Für kleine, spezialisierte KIs sollten Sie oft einfach und direkt bleiben und sie nicht mit zu vielen Regeln erdrücken.
• Einmaliges „Prompten" reicht oft nicht aus. Man muss testen, ob der Code wirklich funktioniert, denn ein „plausibel aussehender" Code kann in der Realität katastrophal sein.

Zusammenfassend: KI ist ein mächtiges Werkzeug für Hardware-Designer, aber sie ist kein Zauberstab. Man muss sie wie einen talentierten, aber manchmal eigenwilligen Assistenten behandeln, den man genau kennen muss, um die besten Ergebnisse zu erzielen.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „VeriInteresting: An Empirical Study of Model–Prompt Interactions in Verilog Code Generation" auf Deutsch.

1. Problemstellung und Motivation

Die rasante Entwicklung von Sprachmodellen (LMs) hat die automatisierte Codegenerierung in der Softwareentwicklung revolutioniert. Im Hardware-Design, insbesondere bei der Generierung von Verilog-Code (Register-Transfer-Level, RTL), sind die Anforderungen jedoch deutlich strenger als bei Software.

• Semantische Komplexität: Im Gegensatz zu Python ist Verilog eine strukturelle und ausführliche Sprache, die eine hohe Kontextkohärenz für präzise Signalverbindungen erfordert.
• Hohe Fehlerkosten: Ein Verilog-Modul kann syntaktisch korrekt und in der Simulation isoliert funktionieren, aber dennoch Timing-Verletzungen oder Race-Conditions enthalten, die erst in späteren Verifikationsstufen oder bei der Fertigung auffallen.
• Datenmangel: Hardware-Designs sind oft proprietär und geschütztes geistiges Eigentum (IP). Dies erschwert das Fine-Tuning von Modellen mit privaten Daten, da viele Organisationen keine Cloud-Dienste oder Drittanbietermodelle für sensible Designs nutzen können.
• Forschungsfrage: Es ist unklar, inwieweit Prompting-Strategien und Reasoning-Techniken, die in der Softwareentwicklung erfolgreich sind, auf die Hardware-Design-Aufgaben übertragbar sind.

2. Methodik

Die Autoren führen eine groß angelegte, kontrollierte empirische Studie durch, um die Interaktion zwischen Modellarchitektur, Prompt-Design und Inferenzzeit-Optimierung zu analysieren.

• Benchmarks: Die Evaluation erfolgt auf zwei komplementären Benchmarks:
  1. Verilog Eval V2: Basierend auf Simulation (dynamische Testbänke). Misst funktionale Korrektheit über einen begrenzten Satz von Testvektoren.
  2. VeriThoughts: Basierend auf formaler Äquivalenzprüfung (Formal Equivalence Checking). Nutzt Yosys, um die funktionale Identität des generierten RTL mit einer Referenzimplementierung für alle möglichen Eingabezustände zu beweisen.
• Modelle: Es wurden 18 verschiedene LMs evaluiert:
  • 7 kommerzielle Large Language Models (LLMs) (z. B. GPT-4.1, GPT-5, Gemini 3, Claude Sonnet).
  • 11 Open-Source Small Language Models (SLMs), darunter allgemeine Modelle (Qwen-Familie), Code-spezialisierte Modelle und 4 Verilog-spezifisch feinabgestimmte Modelle (VeriReason, VeriThoughts).
• Prompting-Strategien (Inferenzzeit-Adaptation):
  • Basis (Base): Standard-Prompt.
  • Strukturiertes Prompting (Struct): Erzwingt konsistente Task-Signaturen und modulare Komponenten.
  • Prompt-Refinement (Refine): Zwei-Stufen-Pipeline, bei der die Spezifikation zuerst umgeschrieben/klart wird, bevor der Code generiert wird.
  • Chain-of-Thought (CoT): Explizite Zwischenschritte des logischen Denkens vor der Codegenerierung.
  • In-Context Learning (ICL): Hinzufügen von Few-Shot-Beispielen.
  • GEPA (Genetic-Pareto): Eine evolutionäre Optimierungsmethode, die Prompts ohne Fine-Tuning optimiert.
• Metriken: Die Leistung wird mittels Pass@k (k ∈ {1, 5, 10}) gemessen, wobei Pass@1 die Ein-Schuss-Korrektheit und Pass@10 die Robustheit bei leichtem Resampling widerspiegelt.

3. Schlüsselbeiträge und Erkenntnisse

Die Studie beantwortet vier Forschungsfragen (RQs) und liefert folgende Hauptergebnisse:

RQ1: Skalierung vs. Spezialisierung

• Skalierung: Größere Modelle (z. B. Qwen-14B) schneiden im Allgemeinen besser ab als kleinere, zeigen aber nicht immer eine monotone Skalierung.
• Spezialisierung: Verilog-spezifisch feinabgestimmte Modelle (VR, VT) schneiden auf ihren Trainings-Benchmarks oft sehr gut ab. Allerdings zeigt sich ein Trade-off: Modelle, die stark auf einen spezifischen Benchmark (z. B. VeriThoughts) trainiert wurden, leiden unter einer signifikanten Leistungsverschlechterung, wenn der Prompt-Struktur oder die Aufgabe leicht variiert wird (geringere Robustheit).

RQ2: Sensitivität gegenüber Prompting-Strategien

Die Reaktion auf Prompts ist stark modell- und benchmark-abhängig:

• Strukturiertes Prompting: Hilft oft kleineren, code-spezialisierten Modellen, kann aber bei feinabgestimmten Modellen (wie VT) die Leistung verschlechtern, da diese auf eine direkte Generierung spezialisiert sind und zusätzliche Constraints als Störung empfinden.
• Chain-of-Thought (CoT): Wirkt als „Stabilisator" für strukturierte Prompts und verbessert oft Pass@k-Werte bei kleineren Modellen. Bei VeriThoughts-Modellen oder auf dem VeriThoughts-Benchmark kann CoT jedoch schädlich sein, da es falsche Annahmen einführt.
• Prompt Refinement: Erweist sich als instabil. Das Umformulieren der Spezifikation führt bei vielen starken Modellen (inkl. GPT-5m und VT-Familie) zu einem Leistungsabfall, da die Umformulierung Fehler einführt oder die Spezifikation verfälscht.
• In-Context Learning (ICL): Ist kein universelles „Sicherheitsnetz". Es hilft kleinen Modellen bei strukturierten Prompts, kann aber bei Baseline-Prompts oder spezialisierten Modellen die Leistung verschlechtern.

RQ3: Fine-Tuning vs. Starkes Prompting

• Starkes Prompting kann die Lücke zu feinabgestimmten Modellen für einige Basis-Modelle (z. B. Qwen-7/14) schließen.
• Kein vollständiger Ersatz: Wenn das Fine-Tuning-Ziel genau mit der Zielverteilung übereinstimmt (z. B. VeriReason auf Verilog Eval V2), erzielen spezialisierte Modelle Verbesserungen, die durch reines Prompting nicht erreicht werden können.
• Empfehlung: Inferenzzeit-Optimierung ist ein kostengünstiger erster Schritt, ersetzt aber nicht das Training, wenn hohe Anforderungen an die Zielverteilung bestehen.

RQ4: Stabilität über Benchmarks hinweg

• Es besteht eine positive Korrelation (r = 0,868) zwischen den beiden Benchmarks, jedoch liegen die meisten Punkte unter der Diagonalen.
• Verilog Eval V2 ist systematisch schwieriger als VeriThoughts für viele Modelle, da Simulationstests andere Fehlermodi (z. B. Timing, Reset-Verhalten) bestrafen als die formale Äquivalenzprüfung.
• Warnung: Die Abhängigkeit von einem einzigen Benchmark kann die Robustheit von Modellen überschätzen. Modelle, die auf einem Benchmark gut abschneiden, können auf dem anderen versagen.

4. Signifikanz und Schlussfolgerung

Das Paper „VeriInteresting" liefert eine wichtige empirische Landkarte für den Einsatz von LMs im Hardware-Design:

1. Unterschiedliche Domänen: Verilog-Generierung ist qualitativ anders als Software-Generierung. Techniken, die in der Softwareentwicklung funktionieren (z. B. automatisches Refinement), sind im Hardware-Kontext oft riskant und führen zu semantischen Abweichungen.
2. Trade-off zwischen Spezialisierung und Robustheit: Spezialisierte Modelle bieten Spitzenleistungen, verlieren aber an Flexibilität gegenüber Prompt-Änderungen.
3. Kein „One-Size-Fits-All": Es gibt keine universell beste Prompt-Strategie. Die Wahl hängt vom Modelltyp (allgemein vs. spezialisiert), der Größe und dem spezifischen Evaluierungs-Benchmark ab.
4. Notwendigkeit multipler Benchmarks: Für eine zuverlässige Evaluierung von Hardware-LLMs sind sowohl simulationsbasierte als auch formal-verifizierte Benchmarks unerlässlich, um die wahre Robustheit der Modelle zu erfassen.

Die Arbeit unterstreicht die Notwendigkeit einer robustheitsbewussten Analyse und multi-benchmark-basierten Evaluierung, bevor LMs in kritischen Hardware-Design-Workflows eingesetzt werden.