💻 computer science

AI-Generated RTL Code: A Functional Evaluation of Natural-Language and HLS Prompting

Deze studie evalueert het vermogen van commerciële LLM's om functionele Verilog RTL te genereren vanuit hoogwaardige specificaties, waarbij wordt vastgesteld dat het gebruik van HLS-C prompts de correctheid aanzienlijk verbetert ten opzichte van natuurlijke taal, terwijl hardnekkige uitdagingen met simulatiefouten en een beperkte generalisatie over variabele bitbreedtes aan het licht komen.

Oorspronkelijke auteurs: Giordano Santorum Lorenzetto, Vanderlei Bonato, Oliver Sinnen

Gepubliceerd 2026-08-05

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Giordano Santorum Lorenzetto, Vanderlei Bonato, Oliver Sinnen

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een piekleine, supersnelle fabriek probeert te bouwen binnenin een microchip. Dit is geen fabriek die speelgoed of auto's maakt; het is een digitale fabriek die informatie verwerkt met de snelheid van het licht. Om deze fabriek te bouwen, schrijven ingenieurs een speciaal soort instructiehandleiding genaamd RTL-code (Register-Transfer Level). Je kunt deze code zien als de blauwdruk voor de lopende banden, assemblagewerkarmen en verkeerslichten van de fabriek. Als de blauwdruk zelfs maar één kleine fout bevat, kan de hele fabriek vastlopen, in brand vliegen of gewoon stoppen met werken.

Lange tijd was het schrijven van deze blauwdrukken alsof je een geheime, rigide taal sprak die alleen door een handvol experts wordt begrepen. Maar nu hebben we Artificiële Intelligentie (AI) die ongelooflijk goed is in het schrijven van softwarecode — zoals de apps op je telefoon of de websites die je bezoekt. Mensen begonnen zich af te vragen: "Als AI zo goed softwarecode kan schrijven, kan het dan ook deze lastige hardware-blauwdrukken schrijven?" Dit is de grote vraag die de onderzoekers aanpakten. Ze wilden zien of een slimme AI een eenvoudige beschrijving van een hardwaretaak kon bekijken en dit kon omzetten in een werkende fabrieksblauwdruk, of dat de AI simpelweg in de war zou raken door de strikte regels van hardware.

Het Experiment: Praten versus Programmeren

De onderzoekers zetten een enorme test op om te zien hoe goed verschillende AI-modellen deze taak konden uitvoeren. Ze gaven de AI twee zeer verschillende manieren om om een blauwdruk te vragen:

De "Chatty" Aanpak (Natuurlijke Taal): Ze vertelden de AI in gewoon Engels wat de hardware moest doen. Bijvoorbeeld: "Maak een machine die twee getallen vermenigvuldigt." Het is alsof je tegen een vriend zegt: "Hey, bouw me een broodje," zonder een recept te geven.
De "Programmeerder" Aanpak (HLS-C Prompting): In plaats van gewone Engelse taal, gaven ze de AI een stukje C-code (een veelvoorkomende programmeertaal) dat de logica beschreef. Dit is alsof je de AI een gedetailleerd recept geeft dat geschreven is in een taal die de AI heel goed kent, en de AI vraagt om dat recept te vertalen naar de specifieke "fabriekstaal" (Verilog).

Ze testten dit op zeven verschillende AI-modellen (inclusen grote namen zoals GPT-4 en Gemini) en vroegen hen om acht verschillende soorten digitale circuits te bouwen, variërend van eenvoudige verkeerslichtregelaars tot complexe rekenmachines. Ze voerden elke test 30 keer uit om te zien of de AI het goed kreeg door toeval, of dat de AI de taak echt begreep.

De Resultaten: Het Recept Wint

De bevindingen waren vrij duidelijk, en ze kunnen je verrassen. Wanneer de AI alleen via "chat" in gewone taal werd aangesproken, had het moeite. Gemiddeld genereerde de AI slechts ongeveer 26,9% werkende blauwdrukken. Meestal maakte de AI fouten die leken op het proberen te bouwen van een huis met de verkeerde stenen — de code compileerde niet eens (startte niet op), of de code draaide wel, maar gaf de verkeerde resultaten.

Echter, wanneer de onderzoekers overschakelden naar het C-code recept (HLS-C prompting), schoot de prestatie van de AI omhoog. Het succespercentage steeg naar 39,5%. Dat is een grote verbetering! Het suggereert dat de AI, hoewel slim, meer denkt als een programmeur dan als een hardware-ingenieur. Wanneer je het een gestructureerd code-recept geeft, weet het precies hoe het die stappen moet vertalen naar de hardwaretaal. Het is alsof de AI zegt: "Oh, je gaf me een recept in het Frans? Dan kan ik dat perfect naar het Spaans vertalen. Maar als je alleen in het Engels 'maak een broodje' zegt, kan ik de verkeerde ingrediënten raden."

De "Vreemde Getallen" Test: Kopieert het of Begrijpt het?

Om te zien of de AI gewoon antwoorden kopieerde die het eerder had gezien (memoriseren) of dat het daadwerkelijk begreep hoe deze machines gebouwd moesten worden, speelden de onderzoekers een trucje. Ze vroegen de AI om een vermenigvuldiger (een rekenmachine) te bouwen met vreemde, ongebruikelijke aantallen bits, zoals 7 bits of 31 bits. Dit zijn getallen die je bijna nooit in het echte leven ziet, waardoor de AI het antwoord niet zomaar uit zijn trainingsdata had kunnen kopiëren.

De resultaten hiervan waren fascinerend. Sommige van de slimmere AI-modellen (zoals o4-mini en Gemini 2.5 Pro) gingen bijna perfect om met deze vreemde getallen en kregen het in meer dan 90% van de gevallen goed. Dit suggereert dat deze modellen niet alleen aan het kopiëren en plakken zijn; ze begrijpen daadwerkelijk de logica van hoe je de machine bouwt, ongeacht de grootte. Ze kunnen generaliseren, wat betekent dat ze de regels kunnen toepassen op nieuwe situaties die ze nog nooit eerder hebben gezien.

De Addertjes onder het Gras: Het is Nog Niet Perfect

Ondanks de verbeteringen maakt het artikel heel duidelijk dat we er nog niet zijn. Zelfs met de "recept"-aanpak faalt de AI nog steeds vaker dan hij slaagt. Het grootste probleem is niet dat de AI de syntaxis fout doet (zoals spelfouten); het is dat de AI de timing fout doet.

Stel je voor dat de AI een fabriek bouwt waarbij de lopende band één seconde te snel beweegt. De blauwdruk ziet er perfect uit en de machine gaat aan, maar de producten vallen van de lijn voordat ze verpakt kunnen worden. In de studie waren deze "simulatiefouten" de meest voorkomende fouten. De AI maakt vaak code die er goed uitziet, maar die net even anders reageert wanneer de klok begint te tikken. Het oplossen van deze fouten is moeilijk omdat het een diep begrip vereist van hoe de hardware zich in de loop van de tijd gedraagt, iets waar de AI nog steeds moeite mee heeft.

De onderzoekers ontdekten ook dat wanneer de AI het wél goed deed, de resulterende hardware vaak net zo snel, of zelfs sneller was, dan blauwdrukken geschreven door menselijke experts. Dit is een enorme overwinning, wat suggereert dat als we de AI de timingfouten kunnen laten vermijden, het een superkrachtige assistent voor ingenieurs kan zijn.

De Conclusie

Dus, wat is de belangrijkste les? AI wordt echt goed in het helpen bij het ontwerpen van computerchips, maar het is nog niet klaar om de baan volledig over te nemen. Het is als een briljante stagiair die een geweldig ontwerp kan maken als je een duidelijk, gestructureerd plan geeft (zoals een C-code recept), maar die nog steeds een menselijke supervisor nodig heeft om de laatste details te controleren en te zorgen dat de fabriek niet crasht.

De studie suggereert dat het gebruik van code-gebaseerde prompts een veel betere manier is om met deze AI-modellen te communiceren dan alleen chatten in gewone Engelse taal. Hoewel de AI nog steeds fouten maakt die menselijke debugging vereisen, bewijst het nu al een krachtig hulpmiddel te zijn om het ontwerpproces te versnellen en mensen die nieuw zijn in hardware engineering op weg te helpen. We zijn nog niet op het punt waarop AI een chip vanaf nul kan bouwen zonder hulp, maar we bewegen zeker de goede richting op.

Technische Samenvatting: AI-gegenereerde RTL-code: Een Functionele Evaluatie van Natural-Language en HLS Prompting

Probleemstelling
De toenemende complexiteit van hardwareontwerp heeft de belangstelling voor het gebruik van Large Language Models (LLM's) voor het genereren van Register-Transfer Level (RTL) code aangewakkerd. Hoewel LLM's bekwaamheid hebben getoond in softwarecodegeneratie, blijft hun toepasbaarheid op hardwareontwikkeling onderbelicht. Hardwareontwerp stelt strengere eisen dan software, wat een strikte vereiste is voor functionele correctheid, resource-optimalisatie en een nauwkeurige afhandeling van concurrency en timing. Hoewel High-Level Synthesis (HLS) tools ontwerpers in staat stellen om hardware te beschrijven in C/C++, vereisen ze vaak specifieke directives en bieden ze beperkte controle over de resulterende RTL-structuur. Deze studie onderzoekt of commercieel beschikbare, algemene LLM's direct functioneel correcte Verilog RTL kunnen genereren vanuit high-level specificaties zonder fine-tuning, en evalueert hoe verschillende prompting-strategieën de kwaliteit van de generatie beïnvloeden.

Methodologie
Het onderzoek maakte gebruik van de RTLLM-benchmark, een dataset bestaande uit natuurlijke taalspecificaties, referentie Verilog-implementaties en functionele testbenches voor diverse hardwaremodules (variërend van combinatorische logica tot sequentiële circuits). De auteurs evalueerden zeven verschillende LLM's van OpenAI (GPT-4.1, GPT-4o, o4-mini) en Google (Gemini 1.5 Pro, 2.0 Flash, 2.5 Flash, 2.5 Pro).

Twee prompting-strategieën werden vergeleken met behulp van een zero-shot benadering:

Natural Language (NL) Prompting: Directe tekstuele beschrijvingen van functionaliteit, I/O-poorten en implementatierichtlijnen.
HLS-stijl C Prompting: Gestructureerde C-codefragmenten die de gewenste hardwarefunctionaliteit vertegenwoordigen, ontworpen om synthetiseerbaar te zijn door AMD Vitis HLS.

De evaluatieworkflow was volledig geautomatiseerd:

Generatie: Elk model genereerde $n=30$ onafhankelijke Verilog-outputs per prompt.
Compilatie: De code werd op syntactische fouten gecontroleerd met de Questa simulator.
Simulatie: Succesvol gecompileerde code werd geïntegreerd met testbenches en gesimuleerd.
Verificatie: Outputs werden vergeleken met de verwachte resultaten. Fouten werden gecategoriseerd als Compilatie-, Integratie- of Simulatie-fouten.
Synthese: Correct functionerende ontwerpen werden gesynthetiseerd op een Intel Cyclone V FPGA om de maximale operationele frequentie ( $F_{max}$ ) en de area-utilisatie (ALM's) te meten ten opzichte van door mensen geschreven referentieontwerpen.

Daarnaast werd een exploratieve casestudy over bitbreedte-schaling uitgevoerd met behulp van een sequentiële multiplier-ontwerp. De bitbreedte werd gevarieerd over standaardwaarden (8, 32, 64) en ongebruikelijke, ijle waarden (7, 12, 15, 23, 24, 31, 50, 63) om het vermogen van de modellen te testen om algoritmische logica te generaliseren versus het louter reproduceren van trainingspatronen.

Belangrijkste Resultaten

Impact van de Prompting-strategie: HLS-C prompting presteerde significant beter dan Natural Language prompting. Het gemiddelde percentage functionele correctheid steeg van 26,9% (NL) naar 39,5% (HLS-C).
Foutverdeling: HLS-C prompts verminderden compilatiefouten aanzienlijk (van gemiddeld 33,5% naar 24,2%) en verminderden integratiefouten. Echter, simulatie-fouten bleven de primaire uitdaging en vormden zelfs met HLS-C nog ongeveer 35% van de pogingen, wat aangeeft dat modellen nog steeds moeite hebben met de cyclus-nauwkeurige vertaling van complexe hardwaregedragingen.
Modelprestaties: De o4-mini en Gemini 2.5 Pro modellen behaalden consistent de hoogste correctheidscijfers bij beide strategieën.
Generalisatie: In de experimenten met bitbreedte-schaling toonden o4-mini en Gemini 2.5 Pro een robuuste generalisatie, waarbij ze een hoge correctheid (>90%) behielden over niet-standaard breedtes (bijv. 7-bit, 23-bit), wat suggereert dat ze niet simpelweg trainingsdata memoriseren maar onderliggende algoritmen begrijpen.
Hardwarekwaliteit: Gesynthetiseerde ontwerpen behaalden vaak $F_{max}$ -waarden die de door mensen geschreven referentieontwerpen overtroffen. Echter, HLS-C prompts neigden naar ontwerpen met een lagere prestatievariabiliteit, maar soms een grotere area-voetafdruk vergeleken met NL-prompts, waarschijnlijk omdat de modellen procedurele C-constructen vertalen naar rigide hardwarestructuren.

Belangrijkste Bijdragen

Vergelijkende Analyse van Prompts: De studie toont aan dat het verstrekken van gestructureerde, code-gecentreerde inputs (HLS-stijl C) de functionele correctheid van door LLM gegenereerde RTL aanzienlijk verbetert ten opzichte van natuurlijke taalbeschrijvingen.
Beoordeling van Generalisatie: Het biedt een analyse van hoe LLM's omgaan met ongebruikelijke ontwerpparameters, waarbij wordt onthuld dat frontier-modellen algoritmische logica effectief kunnen abstraheren, terwijl lichtere modellen vaak falen in het generaliseren buiten standaardpatronen.
Evaluatie van Hardwarekwaliteit: Het werk biedt een kwaliteitsanalyse waarbij de door LLM gegenereerde ontwerpen worden vergeleken met menselijke referenties op het gebied van timing ( $F_{max}$ ) en area, waarbij wordt benadrukt dat hoewel LLM's concurrerende architecturen kunnen produceren, ze vaak handmatige selectie uit meerdere pogingen vereisen om optimale resultaten te bereiken.

Betekenis en Claims
De auteurs concluderen dat hoewel LLM's nog niet in staat zijn om autonoom productie-klare RTL-code te produceren vanwege aanhoudende simulatiefouten en de hoge kosten van debugging, ze een krachtige ondersteunende tool vormen voor hardwareontwikkelaars. De verbeterde prestaties met HLS-C prompts suggereren dat het benutten van de vertrouwdheid van de modellen met software-syntax de kloof in hardwaregeneratie kan overbruggen. Het artikel stelt dat LLM's bijzonder waardevol zijn voor het genereren van conceptuele implementaties of "boilerplate"-code voor ervaren ingenieurs om te beoordelen en te optimaliseren, en als educatieve instrumenten om software engineers te helpen bij de transitie naar hardwareontwerp door bekende C-constructen te mappen naar RTL. De studie benadrukt dat de huidige beperkingen menselijk toezicht noodzakelijk maken, met name voor complexe sequentiële logica en timing-kritische ontwerpen.

Het Experiment: Praten versus Programmeren

De Resultaten: Het Recept Wint

De "Vreemde Getallen" Test: Kopieert het of Begrijpt het?

De Addertjes onder het Gras: Het is Nog Niet Perfect

De Conclusie

Meer zoals dit