🤖 AI

EstRTL: Functional Estimation Guided RTL Code Generation

Dieses Paper stellt EstRTL vor, ein dreistufiges, LLM-gestütztes kollaboratives Agenten-Framework, das die funktionale Korrektheit des generierten RTL-Codes durch statische funktionale Score-Schätzung verbessert und dabei eine Steigerung von 3,2 %–9,0 % gegenüber generischen Modellen erzielt.

Ursprüngliche Autoren: Qi Xiong, Renzhi Chen, Bowei Wang, Yuqing Xiong, Libo Huang, Lei Wang

Veröffentlicht 2026-06-10

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Qi Xiong, Renzhi Chen, Bowei Wang, Yuqing Xiong, Libo Huang, Lei Wang

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie versuchen, eine komplexe Maschine zu bauen, wie zum Beispiel einen Hochleistungsautomotor, aber anstatt Werkzeuge und Blaupausen zu verwenden, bitten Sie einen sehr klugen, belesenen Roboter, die Anweisungen für Sie zu schreiben. In der Welt der Computerchips werden diese Anweisungen als RTL-Code (Register Transfer Level) bezeichnet.

Das Problem ist, dass diese Roboter (die als Large Language Models oder LLMs bezeichnet werden) zwar gut darin sind, Sätze zu schreiben, aber oft dumme Fehler machen, wenn sie diese technischen Anweisungen verfassen. Sie könnten ein Stoppschild mit einem Vorfahrtgewähr-Schild verwechseln oder ein Zahnrad an die falsche Stelle setzen. Normalerweise erfordert die Überprüfung, ob der Motor tatsächlich funktioniert, den Bau einer massiven, teuren Teststrecke (eines sogenannten „Testbenches“), um das Auto zu testen, was viel Zeit und Geld kostet.

Hier kommt EstRTL: Das Qualitätskontroll-Team

Das Paper stellt EstRTL vor, ein neues System, das wie ein dreiköpfiges Qualitätskontroll-Team fungiert, das zusammenarbeitet, um die Fehler des Roboters zu beheben, bevor der Motor überhaupt gebaut wird. Anstatt nur den Roboter zu fragen: „Mach es nochmal“, nutzt dieses System eine clevere Schleife aus Generierung, Schätzung und Korrektur.

So arbeitet das Team (unter Verwendung einer einfachen Analogie):

1. Der Generator (Der Architekt)

Zuerst ist der Code Generation Agent der Architekt. Er hört auf Ihre Anfrage (z. B. „Baue einen Zähler, der bis 255 zählt“) und entwirft die ersten Blaupausen (den RTL-Code).

Die Prüfung: Bevor sich jemand das Design ansieht, stellt ein Grammatik-Prüfer sicher, dass die Blaupausen keinen Unsinn enthalten (wie fehlende Klammern oder Tippfehler). Wenn die Blaupausen grammatikalisch falsch sind, zeichnet der Architekt sie sofort neu.

2. Der Schätzer (Der intuitive Inspektor)

Dies ist die wichtigste Neuerung des Papers. Normalerweise muss man den gesamten Motor bauen und testen, um zu wissen, ob eine Blaupause funktioniert. Das ist langsam.

Der Trick: Der Functional Estimation Agent ist wie ein super-intuitiver Inspektor, der auf die Blaupause schaut und sagt: „Ich habe dies noch nicht gebaut, aber basierend auf dem Design ist es zu 85 % wahrscheinlich, dass es funktionieren wird.“
Wie es funktioniert: Er baut den Motor nicht. Stattdessen liest er die Blaupause und versucht, eine Beschreibung dessen zu verfassen, was die Maschine tun sollte. Dann vergleicht er diese Beschreibung mit Ihrer ursprünglichen Anfrage.
- Analogie: Wenn Sie nach einem „roten Sportwagen“ gefragt haben und die Blaupause einen „blauen Lastwagen“ beschreibt, weiß der Inspektor sofort, dass etwas falsch ist, selbst ohne den Wagen gesehen zu haben.
Die Entscheidung:
- Wenn die Punktzahl niedrig ist (das Design sieht schrecklich aus), schickt er es an den Architekten zurück, damit dieser komplett von vorne beginnt.
- Wenn die Punktzahl mittelmäßig ist (das Design ist okay, hat aber einige Mängel), schickt er es an den Fixer.

3. Der Korrektor (Der Mechaniker)

Der Code Correction Agent ist der Mechaniker. Er rät nicht einfach; er nutzt einen „Chain of Thought“-Prozess (Gedankenkette).

Der Prozess: Er fragt zuerst: „Wo genau liegt das Problem? Warum passiert das?“ (z. B. „Das Zahnrad sitzt auf der falschen Achse, weil der Roboter ‚links‘ mit ‚rechts‘ verwechselt hat“).
Die Lösung: Sobald er das Warum verstanden hat, schreibt er den spezifischen Teil der Blaupause um, um den Fehler zu beheben. Er sendet die korrigierte Blaupause dann zurück an den Inspektor, um sie erneut prüfen zu lassen.

Warum ist das eine große Sache?

Das Paper behauptet, dass das Hinzufügen dieses „Inspektor“- und „Mechaniker“-Teams zum Prozess die Erfolgsquote der Roboter signifikant verbessert.

Die Ergebnisse: Als sie dies an einem Standarddatensatz von 156 Hardware-Design-Aufgaben testeten, verbesserte das System die Genauigkeit der Roboter um 3,2 % bis 9 %.
Die Effizienz: Der „Inspektor“ war in der Lage, zwischen einem funktionierenden Design und einem defekten Design mit einer Genauigkeit von etwa 78 % zu unterscheiden, ohne die teure Teststrecke bauen zu müssen.
Der Fixer: Der Mechaniker konnte über 12 % der Fehler, die die Roboter alleine gemacht hatten, erfolgreich beheben.

Das Fazit

Betrachten Sie EstRTL als Sicherheitsnetz. Anstatt darauf zu vertrauen, dass ein Roboter es beim ersten Versuch perfekt macht (was er selten tut), schafft dieses System eine Schleife, in der der Roboter schreibt, ein KI-Inspektor bewertet und ein KI-Mechaniker die schlechten Teile repariert. Dies stellt sicher, dass der endgültige Code nicht nur grammatikalisch korrekt ist, sondern tatsächlich das tut, was Sie verlangt haben, wodurch Ingenieure davor bewahrt werden, tausende Zeilen Code manuell debuggen zu müssen.

Die Autoren haben dieses „Team“ Open-Source zur Verfügung gestellt, was bedeutet, dass jeder diesen dreistufigen Prozess nutzen kann, um seinen eigenen Robotern beim Schreiben von besserem Hardware-Code zu helfen.

Technisches Resümee: EstRTL – Funktionale Schätzung zur geleiteten RTL-Codegenerierung

Problemstellung

Das manuelle Design auf Registerübertragungsebene (Register Transfer Level, RTL) ist ein zeitaufwendiger und fehleranfälliger Prozess, insbesondere bei komplexen Systemen wie modernen Prozessoren. Obwohl Large Language Models (LLMs) vielversprechende Ergebnisse bei der Generierung syntaktisch korrekten Codes aus natürlichen Sprachprompts gezeigt haben, stehen bestehende Methoden zur RTL-Generierung vor erheblichen Einschränkungen hinsichtlich der funktionalen Korrektheit. Derzeitige Ansätze konzentrieren sich primär auf das Fine-Tuning von Modellen, Data Augmentation (z. B. RAG) oder Syntaxprüfung. Sie lassen jedoch häufig Mechanismen vermissen, die sicherstellen, dass der generierte Code in realer Hardware wie intendiert funktioniert.

Ein kritischer Engpass ist die Abhängigkeit von Testbenches zur Verifizierung. Das manuelle Erstellen von Testbenches ist arbeitsintensiv, während automatisch generierte Testbenches oft nicht umfassend genug sind. Infolgedessen konzentrieren sich viele bestehende Methoden ausschließlich auf die syntaktische Korrektheit statt auf die Funktionalität. Darüber hinaus werden Codegenerierung und Code-Korrektur oft getrennt voneinander untersucht, und bestehende Korrekturmethoden verlassen sich typischerweise auf binäre Pass/Fail-Evaluierungen, die kein Zwischenfeedback für eine iterative Optimierung bieten.

Methodik: Das EstRTL-Framework

Um diese Herausforderungen zu bewältigen, schlagen die Autoren EstRTL vor, ein LLM-gestütztes kollaboratives Agenten-Framework, das auf der statischen Schätzung funktionaler Scores basiert. EstRTL operiert nach einem Drei-Stufen-Paradigma: Generierung, Schätzung und Korrektur.

1. Generierung (Code Generation Agent)

Der Prozess beginnt mit einem Code Generation Agent, der RTL-Code basierend auf natürlichen Sprachspezifikationen produziert.

Syntaxverifizierung: Der generierte Code wird einer Syntaxprüfung mittels Icarus Verilog unterzogen. Falls Fehler gefunden werden, erhält der Agent Fehlermeldungen und regeneriert den Code. Diese Schleife ist auf drei Iterationen begrenzt, um Endlosschleifen zu verhindern.
Fehler-Erinnerungen (Error Reminders): Das System integriert „Error Reminders“, die häufig behobene Fehler zusammenfassen (z. B. die Bevorzugung von assign gegenüber always-Blöcken für einfache kombinatorische Logik), um den Agenten während der Regeneration zu leiten.

2. Schätzung (Functional Estimation Agent)

Sobald der Code die Syntaxprüfungen besteht, wird er an den Functional Estimation Agent weitergeleitet, der als zentrale Entscheidungseinheit fungiert. Dieser Agent führt eine statische funktionale Score-Schätzung durch, ohne Testbenches auszuführen.

Reverse Requirement Generation: Der Agent nutzt ein LLM, um den generierten RTL-Code wieder in natürliche Sprachanforderungen zurückzuführen (Reverse Engineering).
Bewertungsmechanismus (Scoring Mechanism): Der Agent berechnet einen VFCS (Functional Correctness) Score basierend auf drei Komponenten:
1. Semantische Ähnlichkeit: Berechnet mittels vortrainierter Modelle (z. B. all-MiniLM-L6-v2, roberta-large), um die Ähnlichkeit zwischen den ursprünglichen Spezifikationen und den rückgenerierten Anforderungen sowohl auf Token- als auch auf Satzebene zu messen.
2. Vollständigkeitswert (Completeness Score): Eine strafbasierte Metrik ( $C$ ), die fehlende oder zusätzliche Schlüsselwörter (Substantive/Verben) zwischen den ursprünglichen und den rückgenerierten Anforderungen bewertet.
3. LLM-Verständnis-Score ( $L_{LLM}$ ): Eine LLM-basierte Evaluierung der funktionalen Korrektheit des Codes unter Berücksichtigung der obigen Werte.
Entscheidungslogik:
- Inakzeptabel niedriger Score: Der Code wird an den Generation Agent zurückgegeben, um eine vollständige Neugenerierung zu starten.
- Fehlerhaft, aber verbesserbar: Der Code wird an den Correction Agent weitergeleitet.
- Hoher Score: Der Code wird als funktional korrekt akzeptiert.

3. Korrektur (Code Correction Agent)

Für Code, der als „fehlerhaft, aber verbesserbar“ eingestuft wurde, wird ein Code Correction Agent eingesetzt, der auf Chain of Thought (CoT) Reasoning basiert.

Reasoning-Phase: Das LLM analysiert den Code im Abgleich mit den Spezifikationen, um spezifische Ausgangssignale mit Fehlern, die durch diese Fehler ausgelösten Eingangsbedingungen und die zugrunde liegenden logischen Ursachen zu identifizieren.
Korrekturphase: Basierend auf dem Reasoning modifiziert der Agent den RTL-Code und implementiert Schutzmaßnahmen, um das Wiederauftreten bekannter Probleme zu verhindern und einen konsistenten Codestil zu gewährleisten.
Iterative Schleife: Der korrigierte Code wird erneut vom Functional Estimation Agent evaluiert. Diese Schleife setzt sich fort, bis der Code die funktionale Prüfung besteht.

Zentrale Beiträge

LLM-Agent-Framework: Entwicklung eines kollaborativen Frameworks, das die Erfolgsrate generischer LLMs auf dem VerilogEval-Datensatz um 3,2 % bis 9,0 % steigert.
Testbench-freie funktionale Schätzung: Einführung einer Methode zur Schätzung der RTL-Funktionalität ohne Testbenches durch die Nutzung von Reverse Requirement Generation und semantischer Ähnlichkeit, wobei eine durchschnittliche Präzision von 84,2 % bei der Unterscheidung zwischen korrektem und inkorrektem Code erreicht wurde.
Integrierte Feedbackschleife: Schaffung einer nahtlosen Integration von Generierung, Schätzung und Korrektur, bei der der Estimation Agent quantitative Scores und feingliedrige Anweisungen liefert und erfolgreich über 12 % des fehlerhaften RTL-Codes korrigiert.
Open-Source-Framework: Das EstRTL-Framework ist Open Source und modellagnostisch konzipiert, sodass es für verschiedene LLMs (sowohl generische als auch domänenspezifische) anwendbar ist, um die Code-Korrektheit zu erhöhen.

Experimentelle Ergebnisse

Das Framework wurde auf den Datensätzen VerilogEval-v1-Human und VerilogEval-v2 unter Verwendung von vier hochmodernen LLMs (Qwen-Plus, Qwen3-32B, DeepSeek-Chat, GPT-4o) evaluiert und gegen Baselines wie RTLFixer, VeriAssistant sowie spezialisierte Modelle wie OriGen und CodeV verglichen.

Generierungsgenauigkeit: EstRTL verbesserte die Pass@1-Genauigkeit generischer LLMs um 3,2 % bis 9,0 %. So verbesserte sich beispielsweise DeepSeek-Chat von 73,1 % auf 76,3 % auf VerilogEval-v1-Human.
Schätzleistung: Der Functional Estimation Agent demonstrierte eine hohe Präzision (bis zu 88,9 % für DeepSeek-Chat) und Genauigkeit (bis zu 78,2 % für Qwen3-32B) bei der Klassifizierung der funktionalen Korrektheit.
Korrekturfähigkeit: Der Code Correction Agent erreichte eine Nettokorrekturrate von 12 % bis 17 % und korrigierte erfolgreich einen signifikanten Teil der Fehler, während er nur minimale neue Regressionen verursachte.
Erweiterbarkeit: Das Framework ließ sich erfolgreich mit spezialisierten RTL-Modellen (OriGen, RTLCoder, CodeV-QC) integrieren und lieferte konsistente Leistungssteigerungen (z. B. verbesserte CodeV-QC um 11,5 % auf VerilogEval-v2), ohne dass ein Retraining oder eine Parametertuning erforderlich war.
Robustheit: Das System zeigte sich robust gegenüber dem Entscheidungsschwellenwert für die Klassifizierung und behielt eine stabile Leistung über einen Bereich von Schwellenwerten (0,38 bis 0,54) bei, was darauf hindeutet, dass ein fester Schwellenwert für verschiedene Modelle verwendet werden kann.

Bedeutung und Ansprüche

Das Paper behauptet, dass EstRTL die kritische Lücke zwischen syntaktischer Korrektheit und funktionaler Korrektheit im KI-gestützten Hardwaredesign schließt. Durch den Ersatz der arbeitsintensiven Testbench-Erstellung durch statische funktionale Score-Schätzung überbrückt das Framework die Lücke zwischen Codegenerierung und -korrektur.

Die Autoren betonen, dass ihr Ansatz quantitative Scores und menschenlesbare Anforderungsvergleiche bietet, wodurch die Transparenz der KI-gestützten RTL-Generierung verbessert wird. Sie behaupten, dass das Framework kein bloß konkurrierendes Modell ist, sondern eine Plug-and-Play-Erweiterung, die auf verschiedene bestehende LLMs angewendet werden kann, um deren Zuverlässigkeit im Hardware-Design erheblich zu steigenern. Die Arbeit wird als ein grundlegender Schritt hin zu robusteren und automatisierteren Hardware-Design-Workflows präsentiert, der den Fokus von der reinen Codegenerierung hin zu verifizierten, funktionalen Hardwarebeschreibungen verschiebt.