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

Dit empirische onderzoek analyseert de interacties tussen modelkenmerken en promptontwerp bij het genereren van Verilog-code, waarbij het via een gecontroleerde factoriële opzet patronen identificeert die generaliseren over verschillende modellen en benchmarks.

De kern

Stel je voor dat je een meester-architect bent die een heel complexe, digitale stad moet bouwen. In de wereld van computers heet dit "Verilog" schrijven. Het is de taal waarmee ingenieurs vertellen hoe een chip (het brein van een computer) moet werken.

Deze paper, getiteld "VeriInteresting", is als een groot onderzoeksbureau dat kijkt naar hoe goed moderne AI (kunstmatige intelligentie) deze digitale steden kan bouwen als je haar een opdracht geeft.

Hier is de samenvatting in gewone taal, met een paar leuke vergelijkingen:

1. Het Probleem: AI is slim, maar hardware is streng

AI-modellen (zoals de chatbots die we allemaal kennen) zijn geweldig in het schrijven van Python of JavaScript. Het is alsof ze een verhaal kunnen vertellen of een e-mail kunnen opstellen. Maar hardware (chips) is anders.

• De Analogie: Als je een verhaal schrijft en er staat één woord verkeerd, is het misschien nog steeds leuk te lezen. Maar als je een brug bouwt en één bout verkeerd zet, stort de brug in.
• In de chipwereld mag er geen enkele fout zijn. Een klein foutje in de timing (wanneer iets gebeurt) kan betekenen dat de hele chip faalt, zelfs als hij er op papier perfect uitziet.

2. De Experimenten: 18 AI's en 2000 Opdrachten

De onderzoekers hebben 18 verschillende AI-modellen getest. Sommige zijn heel groot en slim (de "giganten"), andere zijn kleiner en sneller (de "wielrenners"), en sommige zijn speciaal getraind op hardware (de "specialisten").

Ze gaven deze AI's twee soorten tests:

1. De Simulatie-test (Verilog Eval): Alsof je een modelauto bouwt en hem op een testbaan rijdt. Als hij de bochten goed neemt, is hij goed. Maar misschien mis je wel een zeldzame situatie (een "hoekje") waar hij vastloopt.
2. De Formele Test (VeriThoughts): Alsof je een wiskundig bewijs maakt dat de brug nooit kan instorten, ongeacht wat er gebeurt. Dit is veel strenger.

3. De Vragen: Hoe praten we met de AI?

De onderzoekers wilden weten: Hoe moeten we de AI opdracht geven om het beste werk te leveren? Ze probeerden verschillende manieren van "prompt engineering" (het formuleren van de opdracht):

• De "Strakke Opdracht" (Structured Prompt): In plaats van "Bouw een chip", zeggen ze: "Gebruik dit exacte formulier, vul deze vakjes in, en gebruik deze specifieke stijl."
  • Resultaat: Dit hielp vooral de kleinere AI's. Het was alsof je een kind een bouwpakket geeft met duidelijke instructies in plaats van alleen te zeggen "bouw iets".
• De "Denk Eerst Na" Strategie (Chain-of-Thought): De AI moet eerst uitleggen hoe ze gaat bouwen voordat ze de code schrijft.
  • Resultaat: Dit werkte wisselend. Soms hielp het, maar soms begon de AI te "dromen" en verzon ze dingen die niet klopten. Bij hardware is "te veel nadenken" soms gevaarlijk als je de basisregels uit het oog verliest.
• De "Herformulering" (Prompt Refinement): Je vraagt de AI eerst om de opdracht zelf te verbeteren, en daarna pas de code te schrijven.
  • Resultaat: Dit was vaak een foute zet. De AI verbeterde de opdracht zo, dat ze eigenlijk een heel ander ding bouwde dan bedoeld was. Het was alsof je een kok vraagt om het recept te verbeteren, en hij besluit ineens een taart te bakken in plaats van een soep.

4. De Grote Ontdekkingen

• Specialisten vs. Giganten:
  De AI's die speciaal getraind waren op hardware (de "specialisten") deden het vaak goed op de tests waar ze voor getraind waren. Maar als je ze een andere, iets andere opdracht gaf, faalden ze soms dramatisch. Ze waren als een zwemmer die alleen op de 100m vrije slag kan zwemmen. Als je ze vraagt om te duiken, zakken ze door de bodem.
  De grote, algemene AI's waren minder perfect, maar veel flexibeler. Ze konden met verschillende soorten opdrachten omgaan.

• De "Gouden Middelweg":
  De beste resultaten kwamen vaak van een combinatie: een redelijk grote AI + een strakke, duidelijke opdracht. Je hoeft niet per se de duurste, slimste AI te hebben als je haar maar heel duidelijk vertelt wat je wilt.

• De Valstrik van de Test:
  Een AI die perfect scoort op de ene test (de simulatie), kon op de andere test (de formele check) volledig falen. Dit betekent dat je niet op één test moet vertrouwen om te zeggen welke AI het beste is. Het is alsof een auto die perfect rijdt op een racecircuit, op een modderweg volledig vastloopt.

5. Conclusie: Wat betekent dit voor de toekomst?

De boodschap van dit onderzoek is: Wees voorzichtig.

Het bouwen van hardware met AI is niet zomaar "AI laten doen en klaar".

• Je kunt niet zomaar een AI uit de software-wereld nemen en hopen dat hij hardware bouwt.
• De manier waarop je de AI een opdracht geeft (de prompt) is net zo belangrijk als de AI zelf.
• Soms is een kleinere, goedkopere AI met een heel duidelijke opdracht beter dan een dure, super-slimme AI met een vaag berichtje.

Kortom: AI is een geweldige assistent voor het bouwen van digitale chips, maar je moet hem niet alleen laten werken. Je moet als een strenge, ervaren architect naast hem staan, precies vertellen wat hij moet doen, en constant controleren of hij niet "te creatief" wordt. Hardware vergt precisie, en creativiteit is daar soms een gevaar.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "VeriInteresting: An Empirical Study of Model–Prompt Interactions in Verilog Code Generation", geschreven in het Nederlands.

1. Probleemstelling

De snelle vooruitgang in Taalmodellen (LM's) heeft de geautomatiseerde codegeneratie voor software (zoals Python) revolutionair veranderd. Echter, de toepassing op hardwareontwerp (specifiek Verilog) blijft achter. Dit komt door fundamentele verschillen:

• Strikte Semantiek: Verilog is een taal voor hardwarebeschrijving (HDL) die concurrentie, timing en micro-architectuur encodeert. Een ogenschijnlijk correcte module kan in simulatie werken, maar toch timingproblemen of race-conditions bevatten die pas bij fabricage of late verificatie aan het licht komen.
• Data-schaarste: Hardwareontwerpen zijn vaak gesloten intellectueel eigendom (IP), wat het beschikbaar maken van grote, open datasets voor training beperkt.
• Beperkingen voor Fine-tuning: Organisaties kunnen vaak geen privédata gebruiken voor het hertrainen van modellen, waardoor inference-tijd strategieën (prompt engineering) cruciaal zijn zonder de modelgewichten aan te passen.

De kernvraag is: In welke mate transfereren prompt- en redeneertechnieken die succesvol zijn in softwareontwerp naar het genereren van Verilog-code, en hoe interageren modelgrootte, specialisatie en prompt-ontwerp?

2. Methodologie

De auteurs hebben een grote, gecontroleerde empirische studie uitgevoerd met een factorieel ontwerp om de interactie tussen modelkenmerken en prompt-strategieën te analyseren.

Benchmarks:
Er werden twee complementaire benchmarks gebruikt om verschillende aspecten van correctheid te testen:

1. Verilog Eval v2: Gebaseerd op dynamische simulatie (testbenches). Dit is vergelijkbaar met unit testing in software, maar biedt slechts gedeeltelijke dekking.
2. VeriThoughts: Gebaseerd op formele equivalentie-checking (LEC) met Yosys. Dit bewijst functionele equivalentie met een "golden reference" voor alle mogelijke invoerstaten, maar is computatiever en vereist een referentie-ontwerp.

Modellen:
Er werden 18 Taalmodellen geëvalueerd, variërend van:

• Commerciële state-of-the-art modellen (bijv. GPT-4.1, GPT-5, Gemini 3, Claude Sonnet 4).
• Open-source algemene en code-specialistische modellen (Qwen2.5 familie, DeepSeek Coder).
• Verilog-specialistische modellen: Modellen die specifiek zijn gefinetuned voor Verilog (VeriReason en VeriThoughts), inclusief varianten met Reinforcement Learning (GRPO).

Prompt-strategieën (Inference-time Adaptation):
De studie testte diverse strategieën zonder de modelgewichten aan te passen:

• Basis (Base): Standaard prompt.
• Gestructureerde Prompting (Struct): Dwingt een consistente taaksignatuur en modulaire componenten af (via DSPy).
• Refinement: Een twee-staps proces waarbij de specificatie eerst wordt herschreven/verduidelijkt voordat de code wordt gegenereerd.
• Chain-of-Thought (CoT): Toevoegen van een redeneerstap voorafgaand aan de codegeneratie.
• In-Context Learning (ICL): Toevoegen van voorbeelden (few-shot) aan de prompt.
• GEPA (Genetic-Pareto): Een geautomatiseerde, evolutionaire methode om prompts te optimaliseren op basis van feedback, zonder fine-tuning.

Evaluatiemetrics:
De prestaties werden gemeten aan de hand van Pass@k (k=1, 5, 10), waarbij 20 kandidaat-oplossingen per taak werden gegenereerd om de kans op succes te schatten.

3. Belangrijkste Bijdragen

• Empirische Landkaart: De eerste systematische evaluatie van de interactie tussen modelgrootte, specialisatie en prompt-engineering specifiek voor Verilog.
• Benchmark-Validatie: Het aantonen dat resultaten sterk afhankelijk zijn van het gebruikte benchmark (simulatie vs. formele verificatie).
• Trade-off Analyse: Het in kaart brengen van de afweging tussen modelgrootte en domeinspecialisatie, en tussen training-time (fine-tuning) en inference-time (prompting) optimalisatie.

4. Resultaten en Bevindingen

RQ1: Schaal vs. Specialisatie

• Zowel schaalvergroting als specialisatie verbeteren de prestaties, maar ze gedragen zich anders.
• VeriThoughts (VT) modellen (gefinetuned op formele verificatie) presteren goed op hun eigen benchmark maar degraderen bij grotere schaal (van 7B naar 14B) of bij complexe prompts. Dit suggereert overfitting op de trainingsdistributie.
• VeriReason (VR) modellen (gefinetuned met simulatie-feedback) profiteren meer van schaalvergroting en concurreren goed met algemene modellen.
• Algemene modellen (zoals Qwen-14B) kunnen zonder fine-tuning zeer competitief zijn, vooral op Verilog Eval v2.

RQ2: Gevoeligheid voor Prompt-strategieën

• Gestructureerde Prompting: Werkt vaak goed voor kleinere, code-specialistische modellen (zoals Qwen-Coder), maar kan de prestaties van gespecialiseerde Verilog-modellen (VT) juist verslechteren.
• Refinement (Herschrijven van specificaties): Dit is de ** minst stabiele** strategie. Veel modellen (inclusief sterke redenerende modellen zoals GPT-5m en VT-familie) presteren slechter wanneer ze eerst de specificatie moeten herschrijven. Dit introduceert vaak semantische drift of fouten in de testbench-generatie.
• Chain-of-Thought (CoT): Heeft een gemengd effect. Het helpt bij gestructureerde prompts voor kleinere modellen, maar kan bij formele verificatie (VeriThoughts) leiden tot extra, ongevalideerde aannames die de output verstoren.
• ICL (Few-shot): Werkt niet universeel. Voor sommige modellen en prompts helpt het, voor anderen (vooral gespecialiseerde modellen) kan het de prestaties verlagen door context-overbelasting of mismatch met de benchmark-distributie.
• GEPA: De geautomatiseerde prompt-optimalisatie leverde geen significante verbetering op ten opzichte van een sterke handmatige prompt (Struct CoT), wat suggereert dat prompt-evolutie geen "wondermiddel" is voor deze taak.

RQ3: Fine-tuning vs. Sterke Prompting

• Sterke prompting kan de kloof met fine-tuned modellen voor sommige basismodellen verkleinen, maar elimineert deze niet volledig.
• Fine-tuning is superieur wanneer de trainingsdoelstelling (bijv. simulatie-based) exact overeenkomt met de evaluatie. Echter, modellen die specifiek zijn getraind op één benchmark (zoals VT op VeriThoughts) presteren vaak slechter op de andere benchmark, wat wijst op gebrek aan generalisatie.
• Conclusie: Prompting is een kostenefficiënte eerste stap, maar vervangt fine-tuning niet wanneer de doelverdeling specifiek is.

RQ4: Stabiliteit over Benchmarks

• Er is een sterke correlatie (r = 0.868) tussen de twee benchmarks, maar er zijn significante afwijkingen.
• Verilog Eval v2 is systematisch moeilijker dan VeriThoughts voor veel modellen (lagere Pass@1), waarschijnlijk omdat simulatie specifieke timing- en randgeval-fouten pakt die formele checking mist.
• Het vertrouwen op één enkele benchmark kan leiden tot verkeerde conclusies over de robuustheid van een model.

5. Significantie en Conclusie

Het paper concludeert dat Verilog-generatie een kwalitatief andere taak is dan software-generatie.

• Fragiele Verbeteringen: Technieken die in software werken (zoals automatische refinement of generieke CoT) zijn niet direct overdraagbaar naar hardware. Hardware vereist globale consistentie in timing en structuur; kleine semantische afwijkingen in de prompt kunnen leiden tot volledig onbruikbare ontwerpen.
• Specialisatie-Robuustheid Trade-off: Modellen die extreem goed zijn op een specifieke benchmark (door fine-tuning) verliezen vaak hun robuustheid tegenover prompt-variaties of andere benchmarks.
• Aanbeveling: Voor het inzetten van LM's in hardwareontwerp is een multi-benchmark evaluatie essentieel. Er is geen "beste" model of methode; de keuze hangt af van de specifieke toolchain, de beschikbare data en de vereiste mate van correctheid (simulatie vs. formele verificatie).

De studie biedt een fundament voor toekomstig onderzoek dat zich richt op robuustere trainingsignalen en diepere integratie van LM's met hardware-toolchains, in plaats van alleen te vertrouwen op prompt-engineering.