💻 computer science

MultModLM: A multi-modal benchmark for Large-Language Model based hardware schematic generation

Dieses Paper führt MultModLM ein, einen multimodalen Benchmark und ein umfassendes Evaluierungsframework zur Bewertung der Fähigkeit von Large Language Models, Hardware-Schaltpläne aus RTL-Beschreibungen zu generieren, wobei aufgezeigt wird, dass Modelle zwar visuell interpretierbare Ausgaben erzeugen, jedoch Schwierigkeiten mit der funktionellen Korrektheit haben und dass LLM-basierte Evaluatoren unzuverlässig sind, um die strukturelle Präzision im Hardware-Design zu beurteilen.

Ursprüngliche Autoren: Dhruv Kulkarni, Sai Manoj Pudukotai Dinkarrao

Veröffentlicht 2026-06-29✓ Author reviewed ⓘ

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Dhruv Kulkarni, Sai Manoj Pudukotai Dinkarrao

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. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie hätten einen sehr klugen, belesenen Bibliothekar (das Large Language Model, oder LLM), der weiß, wie man Geschichten über Maschinen schreibt. Nun stellen Sie sich vor, Sie bitten diesen Bibliothekaren, den Bauplan einer Maschine zu zeichnen, der ausschließlich auf einer schriftlichen Beschreibung basiert, wie diese Maschine funktioniert.

Dieses Papier mit dem Titel MultModLM ist im Wesentlichen ein Zeugnis für diese „Bibliothekare“, wenn sie versuchen, diese Maschinenzuzeichnungen (Hardware-Schaltpläne) aus geschriebenem Code (Rat-Code bzw. RTL) zu erstellen.

Hier ist die Aufschlüsselung dessen, was die Autoren getan haben und was sie herausgefunden haben, unter Verwendung einfacher Analogien:

1. Das Problem: Das „fehlende Bindeglied“

Normalerweise entwerfen Ingenieure Computerchips, indem sie Code schreiben (RTL), und nutzen dann eine teure, spezialisierte Software, um diesen Code in eine visuelle Zeichnung (einen Schaltplan) umzuwandeln. Es ist so, als hätte man ein Rezept und bräuchte einen professionellen Koch, der ein Bild des Gerichts zeichnet.

In jüngster Zeit sind KI-Modelle sehr gut darin geworden, Code zu schreiben, aber niemand hatte getestet, ob sie auch die Maschinendiagramme aus diesem Code zeichnen können. Es gab keinen „Test“, um zu sehen, ob eine KI dies leisten kann. Die Autoren entwickelten diesen Test namens MultModLM.

2. Der Test: 99 verschiedene Rätsel

Die Forscher sammelten 99 verschiedene „Rätsel“. Dies waren schriftliche Beschreibungen digitaler Schaltkreise, die von einfachen Zählern bis hin zu komplexen Prüfmaschinen reichten.

Die Herausforderung: Sie gaben diese schriftlichen Beschreibungen zwei Top-KI-Modellen (GPT und Gemini) und baten sie, die Schaltpläne zu zeichnen.
Der Clou: Im Gegensatz zu einem mathematischen Problem, bei dem es nur eine richtige Antwort gibt, gibt es viele Möglichkeiten, dieselbe Maschine zu zeichnen. Genau wie man ein Haus mit einem roten oder einem blauen Dach zeichnen kann und es immer noch dasselbe Haus ist, konnte die KI den Schaltkreis auf verschiedene Arten zeichnen. Dies machte die Bewertung der Antworten sehr schwierig.

3. Das Bewertungssystem: Ein Gremium aus Richtern

Da es keine einzelne „richtige“ Zeichnung gab, konnten die Autoren nicht einfach einen Computer nutzen, um zu prüfen, ob die Zeichnung korrekt war. Stattdessen stellten sie ein mehrstufiges Richtergremium zusammen:

Der Künstler bewertet sich selbst: Die KI zeichnete das Bild und bewertete ihre eigene Arbeit.
Der Rivalen-Richter: Das andere KI-Modell betrachtete die Zeichnung und bewertete sie anhand des ursprünglichen Codes.
Der blinde Richter: Eine KI betrachtete nur die Zeichnung (ohne den Code zu sehen), um zu sehen, ob die Zeichnung für sich allein genommen Sinn ergibt.
Der menschliche Experte: Echte Ingenieure betrachteten die Zeichnungen, um zu sehen, ob sie tatsächlich korrekt waren.

Sie verwendeten eine Checkliste (Rubrik), um Dinge zu bewerten wie: „Sind die Leitungen korrekt verbunden?“ „Wird das Taktsignal angezeigt?“ „Ist die Zeichnung leicht lesbar?“

4. Die große Entdeckung: Die KI-Richter sind ahnungslos

Dies ist der überraschendste Teil des Papers.

Das Ergebnis: Als die Forscher die von den KI-Richtern vergebenen Punktzahlen mit den von den menschlichen Experten vergebenen Punktzahlen verglichen, stellten sie fest, dass es fast gar keine Übereinstimmung gab.
Die Analogie: Stellen Sie sich vor, Sie fragen einen Roboter, ein Gemälde zu bewerten. Der Roboter gibt ihm eine 10/10, weil es farbenfroh aussieht. Der menschliche Experte gibt ihm eine 2/10, weil die Perspektive falsch ist. Das Paper fand heraus, dass die KI-Richter im Grunde „geraten“ oder halluziniert haben, als sie versuchten, diese technischen Zeichnungen zu bewerten. Sie waren völlig nicht synchron mit den menschlichen Experten.

5. Das Fazit: Die KI kann zeichnen, aber nicht verifizieren

Das Paper kommt zu zwei wesentlichen Schlussfolgerungen:

Die KI kann es versuchen: Die Modelle konnten Bilder erzeugen, die wie Schaltpläne aussahen. Sie waren nicht perfekt, aber visuell interpretierbar.
Die KI kann nicht der Schiedsrichter sein: Man kann einer KI nicht vertrauen, wenn es darum geht, zu sagen, ob ein Hardware-Design korrekt ist. Die Methode „KI als Richter“, die beim Schreiben von Essays oder Programmiertexten gut funktioniert, versagt völlig, wenn es um die Überprüfung der strukturellen Präzision von Hardware-Diagrammen geht.

Kurz gesagt: Die Autoren haben einen Test entwickelt, um zu sehen, ob eine KI Code in Bilder von Maschinen verwandeln kann. Sie fanden heraus, dass die KI zwar versuchen kann, die Bilder zu zeichnen, aber schrecklich darin ist, sie zu bewerten. Wenn Sie wissen wollen, ob ein Hardware-Design korrekt ist, benötigen Sie immer noch einen menschlichen Experten und keine weitere KI.

Basierend auf dem bereitgestellten Paper folgt hier eine detaillierte technische Zusammenfassung von MultModLM.

Problemstellung

Während Large Language Models (LLMs) eine zunehmende Verbreitung in der Hardwareentwicklung bei Aufgaben wie der Codegenerierung, dem Debugging und der textbasierten Evaluierung erfahren haben, besteht eine signifikante Lücke bei multimodalen Hardware-Aufgaben. Speziell gibt es bisher kein bestehendes Benchmark, um die Fähigkeit von LLMs zu bewerten, Hardware-Schaltpläne aus RTL-Beschreibungen (Register Transfer Level) zu generieren.

Diese Lücke ist kritisch, weil:

Nicht-Einzigartigkeit von Schaltplänen: Im Gegensatz zu Code, bei dem oft ein spezifischer Output erforderlich ist, können mehrere strukturell unterschiedliche Schaltpläne funktional äquivalent sein. Dies macht die Definition eines einzelnen „Ground Truth“ unmöglich.
Evaluierungsherausforderungen: Visuelle Ausgaben können nicht auf die gleiche Weise direkt simuliert oder formal verifiziert werden wie Code. Traditionelle EDA-Tools (z. B. von Synopsys, Cadence), die für die Schaltplanerstellung benötigt werden, sind teuer und erfordern hohes Fachwissen, was den Zugang für Forscher einschränkt.
Zuverlässigkeit automatisierter Richter: Es mangelt an Verständnis darüber, ob LLMs zuverlässig die strukturelle und funktionale Korrektheit in Hardware-Domänen bewerten können, was eine Voraussetzung für eine skalierbare automatisierte Evaluierung ist.

Methodik

Die Autoren führen MultModLM ein, ein neuartiges Benchmark und ein mehrstufiges Evaluierungs-Framework, das darauf ausgelegt ist, diese Herausforderungen zu adressieren.

1. Datensatz-Konstruktion

Umfang: Der Datensatz besteht aus 99 diversen RTL-Modulen, die aus Open-Source-Repositories (z. B. OpenRISC) und menschlicher Generierung stammen.
Zusammensetzung: Die Module decken arithmetische Einheiten, Finite State Machines (FSMs), Steuerlogik und numerische Eigenschaftsprüfer (z. B. Armstrong-Zahlen-Erkennung, Palindrom-Erkennung) ab.
Komplexität: Die Designs reichen von kleinen kombinatorischen Schaltungen (1–20 Zeilen) bis hin zu mehrstufigen sequentiellen Designs (bis zu 430+ Zeilen).
Ground Truth: Aufgrund der Nicht-Einzigartigkeit von Schaltplan-Darstellungen werden keine Ground-Truth-Schaltpläne bereitgestellt. Die Korrektheit wird über die funktionale Äquivalenz zur RTL-Beschreibung mittels einer strukturierten Rubrik bewertet.

2. Evaluierungs-Pipeline
Um die Einschränkungen der Einzelmethode-Evaluierung zu überwinden, schlagen die Autoren eine fünfstufige Pipeline vor:

Prompting: Die Modelle werden angewiesen, ein klares, interpretierbares PNG-Bild des Schaltplans basierend auf dem RTL-Code zu generieren. Es werden strikte Einschränkungen angewendet, um zu verhindern, dass Modelle externe Bilder abrufen oder lediglich Text-Erklärungen liefern.
Selbst-Evaluierung (Self-Evaluation): Das generierende Modell bewertet seinen eigenen Output anhand einer vordefinierten Rubrik, um eine Baseline für den Self-Assessment-Bias zu etablieren.
Gegestützte Kreuz-Evaluierung (Grounded Cross-Evaluation): Ein sekundäres Modell bewertet den Schaltplan des Zielmodells mit Zugriff auf den ursprünglichen RTL-Code. Dies approximiert eine objektive Bewertung durch die Prüfung der logischen Äquivalenz.
Blinde Kreuz-Evaluierung (Blind Cross-Evaluation): Das sekundäre Modell bewertet den Schaltplan ohne Zugriff auf den RTL-Code, um die visuelle Kohärenz und Selbstkonsistenz zu messen.
Menschliche Evaluierung: Menschliche Bewerter führen eine strukturierte Verifizierung unter Verwendung derselben Rubrik durch, um eine unabhängige Bewertung zu gewährleisten.

3. Evaluierungsmetriken

Rubrik-basierte Bewertung: Eine JSON-definierte Rubrik mit 8 Kriterien (z. B. Strukturelle Treue, Datenpfad-Repräsentation, Taktgenauigkeit, Signalbeschriftung) wird verwendet. Jedes Kriterium wird als Boolean True/False bewertet, um die Subjektivität von abgestuften Skalen zu vermeiden.
Statistische Analyse: Cohen's Kappa ( $\kappa$ ) wird berechnet, um die Übereinstimmung zwischen menschlichen Bewertern und LLM-basierten Evaluatoren zu messen.
Genauigkeit (Accuracy): Wird durch die Anzahl der erfüllten Rubrik-Kriterien gemessen (maximal 8 Punkte pro Prompt).

Wesentliche Beiträge

MultModLM Benchmark: Das erste multimodale Benchmark zur Evaluierung der RTL-zu-Schaltplan-Generierung mittels LLMs.
Strukturiertes Evaluierungs-Framework: Eine neuartige Pipeline, die Rubrik-basierte Bewertung, Kreuz-Modell-Bewertung und menschliche Validierung kombiniert, um die Nicht-Einzigartigkeit von Schaltplan-Outputs zu handhaben.
Empirische Evidenz für LLM-as-a-Judge: Die Arbeit liefert Daten, die die Limitationen der Nutzung von LLMs als Evaluatoren in strukturell präzisen Domänen aufzeigen.

Experimentelle Ergebnisse

Die Studie evaluierte State-of-the-Art-Modelle (GPT 5.2 Go und Gemini 3 Flash Pro) auf dem 99-Modul-Datensatz.

Zuverlässigkeit des LLM-as-a-Judge: Die bedeutendste Erkenntnis ist, dass LLM-basierte Evaluatoren eine nahezu Null-Übereinstimmung mit menschlichen Bewertern aufweisen.
- GPT vs. Mensch Kappa: 0.013
- Gemini vs. Mensch Kappa: 0.000
- Dies zeigt, dass LLMs derzeit unzuverlässig als automatisierte Richter für die Korrektheit von Hardware-Schaltplänen sind, selbst wenn sie mit dem zugrunde liegenden RTL-Code versorgt werden.
Modellleistung:
- Gemini zeigte eine geringfügig höhere Genauigkeit (0.314) als GPT (0.297), wenn es durch das sekundäre Modell bewertet wurde.
- Gemini schnitt besser bei semantischen und funktionalen Kriterien (C1–C6) ab, was darauf hindeutet, dass es den logischen Kern der RTL besser bewahrt.
- GPT erzielte etwas höhere Werte bei visuell orientierten Kriterien (C7–C8), wobei die Autoren anmerken, dass dies eher die Layout-Sauberkeit als die strikte Einhaltung von Schaltplan-Konventionen widerspiegeln kann.
Win/Loss-Vergleich: In Paarvergleichen gewann Gemini 37 Prompts, GPT gewann 33, und 29 endeten unentschieden.

Bedeutung und Behauptungen

Das Paper behauptet, dass MultModLM einen fundamentalen Flaschenhals im Feld aufzeigt: die Unfähigkeit, multimodale Hardware-Outputs zuverlässig zu evaluieren.

Limitation von LLM-as-a-Judge: Die nahezu Null-Übereismimmung zwischen LLMs und Menschen offenbart, dass aktuelle LLMs nicht darauf vertraut werden können, die strukturelle und funktionale Korrektheit in Hardware-Domänen zu bewerten. Dies stellt die Anwendbarkeit von „LLM-as-a-judge“-Paradigmen in Feldern, die präzises strukturelles Denken erfordern, infrage.
Notwendigkeit neuer Methodologien: Die Ergebnisse motivieren die Entwicklung robusterer, domänenspezifischer Evaluierungsmethoden und Werkzeuge für die strukturelle Evaluierung (z. B. formale Äquivalenzprüfer), die als skalierbare Proxys für den Ground Truth dienen können.
Zukünftige Ausrichtung: Während der aktuelle Datensatz primär zur Evaluierung und nicht zum Training gedacht ist, schlagen die Autoren vor, dass zukünftige Arbeiten darauf fokussieren sollten, den Datensatz für das Fine-Tuning zu erweitern und automatisierte Tools zu entwickeln, um die Lücke zwischen visuellen Outputs und formaler Verifikation zu schließen.

Das Paper schließt mit der Feststellung, dass LLMs zwar visuell interpretierbare Schaltpläne generieren können, ihre funktionale Korrektheit jedoch begrenzt bleibt und die zuverlässige Evaluierung dieser Outputs weiterhin eine offene Herausforderung darstellt.