Codegenerierung für Hardware-Design und Chip-Verifikation (RTL, Testbenches)

Chip- und FPGA-Projekte wenden für die Verifikation ungefähr so viel Aufwand auf wie für das Design, und Ingenieure sind knapp. LLM-Agenten entwerfen inzwischen RTL aus Spezifikationen, erzeugen UVM-Testbenches und Assertions, starten den Simulator, lesen Logs und Coverage-Berichte und iterieren. Weil die EDA-Toolchain objektive Rückmeldung liefert (Kompilieren, Simulieren, Linten, Synthetisieren), ist dies eines der besser abgesicherten Felder für agentisches Programmieren, braucht aber weiterhin erfahrene Ingenieure, die jedes Ergebnis prüfen.

Problem & Nutzen

• Heute: Designer schreiben RTL von Hand nach Spezifikationen; Verifikationsingenieure schreiben Testbenches, Constrained-Random-Sequenzen, Assertions und Coverage-Modelle und verbringen dann lange Zyklen damit, fehlgeschlagene Regressionsläufe anhand von Wellenformen und Logs zu analysieren. In beiden Disziplinen fehlt Personal, und jede Neuauflage eines Chips (Respin) ist sehr teuer.
• KI-Nutzen: schnellere erste Entwürfe von Standard-RTL (Schnittstellen, Zustandsautomaten, Registerblöcke, Verbindungs- logik), Testbench-Gerüste, Assertion-Erzeugung aus Spezifikationstext, Regressions-Triage und Vorschläge zum Schließen der Coverage. Der Hauptgewinn liegt in der Verifikationsproduktivität, nicht im Ersatz des Entwurfsurteils.
• Evidenz: EDA-Hersteller haben agentische Produkte für diese Aufgaben vorgestellt (Synopsys AgentEngineer, in stufenweiser Einführung; Cadence ChipStack AI Super Agent, seit Februar 2026 im Early Access; KI-Agenten von Siemens EDA), und Start-ups wie ChipAgents haben Finanzierung eingeworben. Öffentliche Benchmarks (VerilogEval, RTLLM, NVIDIA CVDP) zeigen deutliche Fortschritte bei kleinen Modulen, aber klar schwächere Ergebnisse bei umfassenden Verifikationsaufgaben [1][2][3]. Produktivitäts- versprechen der Hersteller sind nicht unabhängig geprüft; messen Sie an Ihren eigenen Designs.

Varianten

• ASIC-Designteams: RTL- und UVM-Erzeugung in kommerziellen Simulatoren und Abläufen.
• FPGA-Teams (KMU, Industrie, Fahrzeugelektronik): VHDL-/Verilog-Erzeugung, Skripting der Herstellerwerkzeuge (Vivado, Quartus, Libero), Unterstützung bei Constraints und Timing-Closure.
• Reine Verifikationsagenten: Erzeugung von Assertions, Testbenches und Coverage, Regressions-Triage.
• Assistenten für formale Verifikation: Erzeugung von Eigenschaften (SVA) und Beweisskripten für formale Werkzeuge.

So funktioniert es

1. spec / IP docs (RAG over specs, protocol standards, internal coding rules)
2. LLM drafts RTL / testbench / assertions
3. lint (Verilator, Spyglass-class) + compile + simulate (VCS, Xcelium, Questa, Verilator, Icarus)
4. parse logs, waveforms, coverage
5. LLM diagnoses failures and patches code
6. loop until tests pass and coverage targets are met
7. optional: synthesis / PPA (power, performance, area) feedback
8. refine
9. human design review, formal checks, sign-off

• Modell: ein Code- oder Reasoning-LLM, idealerweise auf HDL per Feintuning angepasst oder entsprechend gepromptet; das Basismodell muss Nebenläufigkeit, Timing und Bitbreiten-Semantik beherrschen, die sich von Software unterscheiden.
• Werkzeugnutzung: Der Agent ruft Simulator, Linter und Synthesewerkzeug über eine CLI oder eine MCP-artige Werkzeugschnittstelle auf und liest strukturierte Ergebnisse; das EDA-Werkzeug, nicht das LLM, entscheidet über Bestanden oder Durchgefallen.
• Retrieval: Spezifikationen, Protokollstandards, hausinterne Codierregeln und frühere IP-Blöcke über RAG.
• Mensch-in-der-Schleife (Human-in-the-Loop): Ein Design-Ingenieur prüft den gesamten RTL-Code; ein Verifikationsleiter verantwortet den Verifikationsplan und die Freigabe der Coverage; formale Äquivalenzprüfung und Gatter-Ebenen-Prüfungen bleiben im Standardablauf. Lassen Sie erzeugten Code nie ungeprüft bis zum Tape-out gelangen.

Datenaufbereitung

Die Aufbereitung ist ein erheblicher Teil der Arbeit (grob 30 bis 40 Prozent), weil das Modell mit Ihrem Designkontext arbeiten muss. Die Daten liegen in der Versionsverwaltung (Git, Perforce), in IP-XACT oder IP-Katalogen, Spezifikations-PDFs und Word-Dateien, Wikis, Fehlerverfolgungssystemen, Regressionsdatenbanken und Simulator-Logs auf gemeinsamen Servern. Typische Lücken: Spezifikationen nur als gescannte oder diagrammlastige PDFs, nicht dokumentierte hausinterne Codierregeln, uneinheitliche Benennung in Alt-IP, keine sauberen Paare aus Design und verifizierter Testbench, verstreute Historie von Fehlerbehebungen und unklare Lizenzen wiederverwendeter IP.

Schritte zur Aufbereitung: - Wandeln Sie Spezifikationen und Protokolldokumente in durchsuchbaren Text um und erhalten Sie dabei Tabellen und Abbildungen (DOC-014, DOC-018, PREP-006); indizieren Sie sie für das Retrieval (PREP-013). - Halten Sie hausinterne Codierregeln, Namenskonventionen und Abkürzungen in kurzen Dokumenten fest (PREP-015, PREP-016). - Kuratieren Sie einen Referenzsatz verifizierter Paare aus Design und Testbench sowie früherer Fehlerbehebungen als Evaluationsmaterial (PREP-018, PREP-020). - Stufen Sie Blöcke nach Vertraulichkeit ein, damit nur zulässige IP zu einem bestimmten Modell gelangt (PREP-024). - Machen Sie Simulator-Logs und Coverage-Berichte maschinenlesbar (strukturierte Ausgabe, stabile Pfade). - Klären Sie den Lizenzstatus wiederverwendeter IP.

Siehe GUIDE-003 für den Reifegrad-Check und PREP-005 für den Export von Daten aus Altsystemen.

Umsetzungswege

Welcher Weg für wen

• enterprise: Weg C — Spezifikationen, Netzlisten und RTL sind das wertvollste geistige Eigentum; Open-Weight-Modelle auf eigener HW3/HW4 halten sie im Haus, und das Volumen über mehrere Teams rechtfertigt die Hardware.
• developer: Weg B — eigene Abläufe rund um offene Simulatoren (Verilator, Icarus, GHDL) mit einem Cloud-Code-Modell sind schnell gebaut und für Einzel- oder Open-Source-Projekte günstig.
• smb: Weg B — EDA-Agenten der Hersteller (Synopsys, Cadence, Siemens) sind preislich und lizenzrechtlich auf große Designorganisationen zugeschnitten, und HW4 im Selbstbetrieb ist unerreichbar; nutzen Sie daher APIs ohne Datenspeicherung (Zero Retention) in EU-Regionen rund um Ihre vorhandenen FPGA-Werkzeuge und geben Sie nur nicht sensible Blöcke weiter.

Weg A — Kaufen (Standardsoftware)

• EDA-Herstelleragenten: Synopsys (AgentEngineer, Synopsys.ai Copilot), Cadence (ChipStack AI Super Agent, Cerebrus, JedAI-Plattform), Siemens EDA (Questa One mit KI-Funktionen und agentischen Abläufen) [1][2]. Am besten geeignet für Teams, die diese Abläufe bereits lizenzieren, da die Agenten neben dem Simulator mit lizenziertem Zugriff auf die Werkzeuge laufen.
• Start-ups: ChipAgents (Verifikations- und Design-Agenten), Bronco AI und ähnliche Werkzeuge zur Verifikations-Triage; prüfen Sie IP-Schutz und On-Premises-Optionen.
• Allgemeine Coding-Assistenten (GitHub Copilot, Cursor, Claude Code) nutzen viele FPGA-Teams für HDL; siehe CODE-001 und CODE-002.
• Wählen Sie A, wenn: Sie bereits kommerzielle EDA-Abläufe nutzen und unterstützte, werkzeugintegrierte Agenten wünschen.

Weg B — Auf Cloud-KI-Diensten aufbauen (empfohlen für KMU)

• Modelle: Spitzenmodelle für Reasoning und Code über API (Claude, GPT, Gemini; Mistral als EU- Anbieter, z. B. Codestral/Devstral) mit Hosting in EU-Regionen, wo angeboten.
• Orchestrierung: ein Agenten-Framework (LangGraph, OpenAI Agents SDK, Claude Agent SDK), das Simulator und Linter als Werkzeuge einbindet und die Ausführung in einer Sandbox kapselt; Parser für Logs und Coverage speisen die Ergebnisse in die Prompts zurück.
• Risiko: Entwurfsspezifikationen und RTL sind das wertvollste geistige Eigentum; nutzen Sie API-Bedingungen ohne Datenspeicherung und EU- Regionen oder verlagern Sie sensible Blöcke auf Weg C.
• Wählen Sie B, wenn: Sie eigene Abläufe rund um offene Simulatoren (Verilator, Icarus, GHDL) oder FPGA-Werkzeuge wollen, ohne eine Herstellersuite zu kaufen.

Weg C — Selbst betreiben (Open Source)

• Modelle: Open-Weight-Code-/Reasoning-Modelle wie Qwen3-Coder, die DeepSeek-V3/R1-Familie, gpt-oss, Codestral/Devstral sowie HDL-Forschungsmodelle (z. B. RTLCoder, CodeV, OriGen-Varianten und NVIDIAs offene Arbeiten zur RTL-Erzeugung) [3][4].
• Werkzeuge: Verilator, Icarus Verilog, GHDL, Yosys + nextpnr, cocotb, OpenROAD / OpenLane, Wellenform-Betrachter Surfer oder GTKWave; Bereitstellung über vLLM oder Ollama.
• Hardware: HW3 für ein Code-Modell mit 30-120B; HW4 für die größten offenen Modelle oder Feintuning; die Simulation ist CPU-gebunden und von der GPU getrennt.
• Wählen Sie C, wenn: IP das Haus nicht verlassen darf (typisch für Chipunternehmen und rüstungsnahe Elektronik) und Sie eine geringere Qualität ab Werk in Kauf nehmen.

Weg D — Eigenes Training

Feintuning auf dem eigenen RTL, den Testbenches und der Historie von Fehlerbehebungen eines Unternehmens verbessert die Einhaltung des Hausstils und werkzeugspezifische Idiome. Nötig sind ein kuratierter Korpus (Tausende verifizierter Paare aus Design und Testbench), die Lizenzklärung der Trainingsdaten und ein Regressions-Prüfstand für die Evaluation. Reinforcement Learning mit bestandenem/nicht bestandenem Simulatorlauf und Coverage als Belohnung ist eine aktive Forschungsrichtung.

Stand der Technik (2026)

• Benchmarks: VerilogEval (NVIDIA) und RTLLM messen die Umsetzung von Spezifikation zu RTL bei kleinen Modulen; starke Modelle lösen davon einen großen Teil, doch die Benchmarks sind weithin kontaminiert und nicht repräsentativ für produktive IP. NVIDIAs CVDP deckt breitere Aufgaben ab (RTL-Erzeugung, Testbench, Debugging, Assertion-Erzeugung, Code-Verständnis) und meldet deutlich niedrigere Werte in den schweren Kategorien [3].
• Agentische Schleifen mit echter Werkzeug-Rückmeldung (Kompilieren, Simulieren, Wellenformen lesen) übertreffen die Erzeugung in einem Schritt und sind die Grundlage der kommerziellen Produkte [1][2].
• Verifikation ist der kommerzielle Sweet Spot: Testbench-Gerüste, Assertions aus Spezifikationstext und Regressions-Triage haben einen klaren Prüfpfad und messbare Coverage.
• Grenzen und Fehlerbilder: falsche Behandlung von Clock-Domain-Crossings und Resets, ungewollte Latches, Bitbreiten-Abweichungen, nicht synthetisierbare Konstrukte, halluzinierte IP oder Werkzeugbefehle, Testbenches, die trivial bestehen, weil sie das Falsche prüfen, und schlechtes PPA des erzeugten RTL. Das Bestehen einer erzeugten Testbench ist ein schwacher Beleg, wenn dasselbe Modell Design und Test geschrieben hat.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (llm-code + agent-framework + Ausführung in der Sandbox): CODE-001 IDE-Assistenten, CODE-002 Coding-Agenten, CODE-004 Testerzeugung, CODE-014 Fehlertriage und -behebung, CODE-023 GPU-Kernel-Erzeugung (ähnliche Schleife aus Kompilieren, Ausführen und Profilieren).
• Angrenzende Bereiche: CODE-016 (SPS-Code, kein Hardware-Design), CODE-020 (eingebettete und sicherheitskritische Software, die den Bedarf an ISO-26262-Nachweisen für Fahrzeug-ASICs/-FPGAs teilt), SCI-006 (mechanisches und generatives Design).

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen bis zum Pilot, Quartale bis zur Skalierung; Kosten sind überwiegend Zusatzlizenzen für EDA und Ingenieurzeit für die Evaluation.
• Weg B: 2-4 Monate für einen Agenten zur Verifikations-Triage oder Testbench-Erzeugung in einem Ablauf.
• Weg C/D: 4-9 Monate inkl. Modellbetrieb, Evaluations-Prüfstand und eventuellem Feintuning.
• Kostentreiber: Simulatorlizenzen und Laufzeit pro Agenten-Iteration, Token-Verbrauch bei langen Logs, Ingenieurzeit für die Prüfung.
• Kennzahlen: Bestehensquote bei Kompilierung und Lint, erreichte funktionale Coverage pro Ingenieur-Woche, Zeit für die Triage eines fehlgeschlagenen Regressionslaufs, durch KI-erzeugte Tests gefundene Fehler, Anteil des KI-erzeugten Codes, der nach der Prüfung akzeptiert wird, Rate durchgerutschter Fehler, PPA gegenüber handgeschriebener Ausgangslage.

Menschen & Veränderung

• Einbinden: Geschäftsleitung und CTO (IP-Richtlinie, Werkzeugbudget), die Design- und Verifikationsleiter als Prozesseigner, die Ingenieure als Anwender, die IT für Lizenzserver und GPU-Hosting, die IT-Sicherheit für IP-Schutz und Sandboxing, Recht für EDA-Lizenzbedingungen, Exportkontrolle und Kunden-NDAs sowie die Verantwortlichen der IP-Repositories als Dateneigner.
• Betriebsrat: abhängig. Das Werkzeug liest Designdaten, keine Personen, doch Agenten-Logs und Akzeptanzstatistiken je Ingenieur können die Leistung überwachen; dann gilt § 87 Abs. 1 Nr. 6 BetrVG. Kündigen Sie die Änderung rechtzeitig nach § 90 Abs. 1 Nr. 3 BetrVG an und halten Sie Kennzahlen auf Teamebene.
• Datenschutz: überwiegend keine personenbezogenen Daten; Ausnahme sind Ingenieur-Kennungen in Commits und Logs. Schließen Sie, wo zutreffend, einen AVV (Art. 28 DSGVO) mit API-Anbietern und beziehen Sie den/die Datenschutzbeauftragte(n) kurz ein. Eine DSFA ist normalerweise nicht nötig.
• KI-Kompetenz: Unterstützen Sie Ingenieure mit Schulungen zu HDL-spezifischen Fehlerbildern wie Timing-, Bitbreiten- und Nebenläufigkeitsfehlern (Art. 4 KI-Verordnung in der geänderten Fassung).
• Pilot und Kommunikation: Wählen Sie einen unkritischen Block oder eine Testbench-Aufgabe mit einem erfahrenen Prüfer; stellen Sie KI als Entlastung bei wiederkehrender Verifikationsarbeit dar, nicht als Ersatz.
• Bedenken: Abfluss von IP und Qualität; begegnen Sie dem mit Sandboxing, Bedingungen ohne Datenspeicherung und simulatorgeprüfter Abnahme.
• Menschen behalten die Kontrolle: Der gesamte RTL-Code wird geprüft; die Freigabe bleibt beim Verifikationsleiter.

Siehe GUIDE-007, GUIDE-009 und GUIDE-013.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko für das Entwicklungswerkzeug selbst; keine Kategorie nach Anhang III. Die Pflicht zur KI- Kompetenz (Art. 4) gilt. Der Chip kann in einem Hochrisiko- oder Sicherheitsprodukt landen, doch diese Einstufung betrifft das Produkt, nicht das Entwurfswerkzeug [5].
• DSGVO: normalerweise keine personenbezogenen Daten; Ausnahme sind Ingenieur-Kennungen in Commit-Logs.
• IP und Vertraulichkeit: das Hauptrisiko. Spezifikationen, Netzlisten und RTL sind Geschäftsgeheimnisse; schließen Sie vertraglich das Training auf Eingaben aus und bevorzugen Sie EU-/On-Premises-Hosting. Prüfen Sie die Lizenzbedingungen von Open-Source-HDL, das Modelle wiedergeben könnten.
• Funktionale Sicherheit: Bei ISO 26262 (Automobil), IEC 61508 oder DO-254 (Luftfahrt) braucht KI-erzeugter Code Argumente zur Werkzeugqualifizierung und dieselben Verifikationsnachweise wie von Menschen geschriebener Code; siehe CODE-020.
• Gegenmaßnahmen: Werkzeugausführung in der Sandbox, unabhängige Verifikation (ein anderes Modell oder ein Mensch schreibt die Prüfung), formale Äquivalenzprüfung, verpflichtende Prüfung, lückenloser Prüfpfad.

Erste Schritte

1. Wählen Sie eine abgegrenzte Aufgabe: Assertions für einen Protokollblock oder die Triage nächtlicher Regressionsfehler.
2. Bauen Sie aus Ihren eigenen früheren Fehlern und Modulen einen Evaluationssatz mit zurückgehaltenen Referenzlösungen.
3. Führen Sie Verilator oder Ihren lizenzierten Simulator als Agentenwerkzeug in einer Sandbox aus; beginnen Sie mit einer Spitzenmodell-API für unkritische Blöcke oder einem offenen Modell On-Premises für sensible.
4. Messen Sie Coverage, Prüfaufwand und Fehler gegen eine menschliche Ausgangslage, bevor Sie den Umfang erweitern.
5. Legen Sie mit der Rechtsabteilung Regeln für IP und Datenumgang fest, bevor Sie ein Produktiv-Repository anbinden.

Quellen

1. Synopsys — AgentEngineer and Synopsys.ai agentic AI for chip design — https://www.synopsys.com/ai/agentic-ai.html
2. Cadence — ChipStack AI Super Agent and AI for chip design — https://www.cadence.com/en_US/home/ai.html
3. NVIDIA research — Comprehensive Verilog Design Problems (CVDP) benchmark — https://github.com/NVlabs/cvdp_benchmark
4. NVIDIA — VerilogEval benchmark — https://github.com/NVlabs/verilog-eval
5. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
6. Verilator open-source simulator — https://www.veripool.org/verilator/
7. Yosys open synthesis suite — https://github.com/YosysHQ/yosys