CktEvo: Repository-Level RTL Code Benchmark for Design Evolution

Dit paper introduceert CktEvo, een benchmark en referentiekader dat grote taalmodellen in staat stelt om op repository-niveau functioneel correcte RTL-code te evolueren met als doel de Power, Performance en Area (PPA) te verbeteren door middel van een gesloten lus met toolchain-feedback.

De kern

Stel je voor dat je een enorme, ingewikkelde machine bouwt, zoals een supermoderne auto of een robot. In de wereld van chipontwerp noemen we dit een RTL-ontwerp (Register-Transfer Level). Dit is de blauwdruk die vertelt hoe de elektronische onderdelen met elkaar moeten praten.

Maar hier is het probleem: deze blauwdruk bestaat vaak uit duizenden losse documenten (bestanden) die allemaal met elkaar verbonden zijn. Als je één schroefje in de ene hoek losdraait om de auto sneller te maken, kan het zijn dat je per ongeluk de remmen in de andere hoek verzwakt.

Tot nu toe waren computers (en zelfs slimme AI) niet goed in het bekijken van het hele plaatje om deze machines te verbeteren. Ze konden wel een klein stukje code schrijven, maar niet de hele machine optimaliseren zonder het kapot te maken.

Hier komt CktEvo om de hoek kijken.

Wat is CktEvo eigenlijk?

CktEvo is een nieuwe testbaan en een slimme assistent voor het verbeteren van deze chipontwerpen. Het is geen tool die zomaar een nieuwe auto uit het niets bedenkt, maar een systeem dat kijkt naar een bestaande, werkende auto en zegt: "Hé, als we hier en daar de motor iets anders afstellen, wordt hij sneller en zuiniger, zonder dat hij uit elkaar valt."

Hoe werkt het? (De Creatieve Analogie)

Stel je voor dat je een grote, oude bibliotheek hebt met duizenden boeken (de code-bestanden). Je wilt dat de bibliotheek efficiënter werkt: minder ruimte nodig (Area) en sneller om boeken te vinden (Delay/Performance).

1. De Slimme Boekhouder (De Graph-based Analyzer):
   In plaats dat een mens alle boeken één voor één leest, heeft CktEvo een slimme robot die een 3D-kaart maakt van de bibliotheek. Hij ziet precies welke boeken het vaakst worden geraadpleegd en welke paden er te vol zijn. Hij zegt: "Kijk, in dit specifieke boek (module) zit een lange wachtrij die de hele bibliotheek vertraagt."

2. De Slimme Schrijver (De LLM):
   Vervolgens vraagt het systeem aan een Super-Schrijver (een geavanceerde AI, zoals GPT of DeepSeek): "Kijk naar dit ene boek. Schrijf de tekst zo om dat de wachtrij wegvalt, maar zorg dat de inhoud (de functie) exact hetzelfde blijft."

3. De Kwaliteitscontroleur (De Verificatie):
   Dit is het allerbelangrijkste deel. De Super-Schrijver is slim, maar kan soms hallucineren (dromen). Daarom heeft CktEvo een strenge Kwaliteitscontroleur.

   • De Schrijver levert een nieuw hoofdstuk aan.
   • De Kwaliteitscontroleur vergelijkt het nieuwe hoofdstuk letterlijk met het oude. "Zie je dit nieuwe woord? Dat verandert de betekenis van de zin. Gooi het weg!"
   • Alleen als de betekenis 100% hetzelfde is, maar de opmaak efficiënter, wordt het geaccepteerd.

4. De Cyclus (Het Iteratieve Proces):
   Dit proces herhaalt zich duizenden keren. De robot kijkt, de schrijver past aan, de controleur checkt. Langzaam wordt de hele bibliotheek (de chip) kleiner, sneller en zuiniger, zonder dat er ook maar één boek verdwijnt of verandert in betekenis.

Wat hebben ze ontdekt?

De auteurs hebben dit systeem getest op 11 verschillende "chips" (zoals processoren en geheugens). Het resultaat was verrassend:

• Zonder menselijke hulp: Het systeem kon de chips verbeteren zonder dat een mens hoefde in te grijpen.
• Snelheidswinst: De chips werden aanzienlijk sneller (minder vertraging).
• Ruimtebesparing: Ze werden ook iets kleiner en zuiniger.
• De "Gouden" regel: Het systeem werkt het beste bij complexe, logische puzzels (zoals processors), maar heeft het moeilijk bij al te standaard, starre ontwerpen (zoals simpele USB-controllers), omdat die al zo perfect zijn dat er weinig meer te verbeteren valt.

Waarom is dit belangrijk?

Vroeger moesten ingenieurs urenlang zitten te zoeken naar kleine foutjes of verbeterpunten in die duizenden bestanden. Met CktEvo kunnen we nu een automatische "coach" hebben die de hele ontwerpfabriek in de gaten houdt en continu kleine, veilige verbeteringen doorvoert.

Het is alsof je een auto hebt die zichzelf elke dag een beetje beter instelt, zolang hij maar niet crasht. Dit is een enorme stap richting chips die zichzelf ontwerpen en optimaliseren, wat tijd en geld bespaart voor de toekomst van onze technologie.

Kortom: CktEvo is de eerste echte testomgeving waar AI leert om niet alleen code te schrijven, maar om bestaande, complexe machines te verbeteren zonder ze kapot te maken.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "CktEvo: Repository-Level RTL Code Benchmark for Design Evolution" in het Nederlands.

Probleemstelling

De huidige toepassing van Large Language Models (LLM's) in de hardwareontwerppraxis (EDA) kampt met twee belangrijke beperkingen:

1. Focus op generatie en debugging: Bestaande benchmarks richten zich voornamelijk op het genereren van Verilog-code vanuit natuurlijke taal of het oplossen van fouten in losse modules. Dit leidt vaak tot hallucinaties en code die functioneel onjuist is of niet voldoet aan strenge eisen voor vermogen, prestaties en oppervlakte (PPA).
2. Gebrek aan repository-schaal: PPA-resultaten zijn emergente eigenschappen van het volledige ontwerp en de interacties tussen bestanden, niet van geïsoleerde modules. Bestaande methoden die uitgaan van formele inputs (zoals HLS) zijn vaak losgekoppeld van cross-file afhankelijkheden en kunnen geen complexe, multi-module codebases optimaliseren.

Er is een duidelijke kloof tussen de huidige LLM-capaciteiten en de industriële behoefte aan iteratieve, repository-level RTL-evolutie: het verbeteren van een bestaand, functioneel correct "gouden" ontwerp om PPA-doelstellingen te bereiken, zonder de functionaliteit te wijzigen.

Methodologie

Het paper introduceert CktEvo, een benchmark en een referentiekader voor deze taak.

1. Taakdefinitie

De taak wordt geformaliseerd als een iteratief, multi-objectief optimalisatieprobleem:

• Input: Een initiële RTL-repository ($D_0$) met meerdere bestanden en ontwerpbeperkingen (SDC).
• Doel: Een reeks van ontwerpen genereren ($D_0, D_1, ..., D_T$) waarbij elke stap functioneel equivalent blijft aan het origineel, maar de PPA-metrics (voornamelijk oppervlakte en vertraging) verbetert.
• Beperkingen: Geen nieuwe functionaliteit toevoegen; strikte functionele equivalentie vereist via formele verificatie.

2. De CktEvo Benchmark

De dataset bestaat uit 11 hoogwaardige, menselijk gecontroleerde Verilog-repository's uit open-source projecten (bijv. GitHub, OpenCore).

• Diversiteit: De ontwerpen variëren van kleine interfaces (SPI) tot complexe processoren (RISC) en neurale netwerken.
• Schaal: Ze omvatten duizenden regels code en tientallen modules, wat cross-file redenering vereist.
• Validatie: Alle ontwerpen zijn synthetiseerbaar met zowel open-source (Yosys) als commerciële toolchains.

3. Gesloten-lus Evolutie Kader (Reference Framework)

Het auteurs stellen een geautomatiseerd kader voor dat LLM's koppelt aan EDA-toolchains feedback. Het proces verloopt als volgt:

1. EDA Toolchain: Voert logische synthese (LS) en statische tijdsanalyse (STA) uit om PPA-rapporten te genereren.
2. Graph-based Code Analyzer: Parseert de RTL-code naar een gestructureerd Control Data Flow Graph (CDFG) en koppelt dit aan de kritieke timing- en oppervlakte-rapporten van de EDA-tools. Dit identificeert exact welke code-segmenten bottlenecks veroorzaken.
3. Prompt Generator: Creëert contextrijke prompts voor de LLM, inclusief de geannoteerde CDFG, de specifieke code-snippets en de tool-feedback.
4. LLM Agent: Stelt een patch voor (in diff-formaat) om de geïdentificeerde bottlenecks op te lossen.
5. Rectificatie en Verificatie:
   • De voorgestelde wijzigingen worden eerst op syntax en basisfouten gecontroleerd.
   • Vervolgens wordt formele verificatie uitgevoerd om functionele equivalentie met het origineel te garanderen.
   • Alleen succesvolle, gevalideerde wijzigingen worden opgeslagen in een evolutionaire database.

4. Evolutie-algoritme

Het systeem gebruikt een island-based populatiemodel (geïnspireerd op AlphaEvolve):

• Meerdere "eilanden" (populaties) van ontwerpen worden parallel onderhouden.
• De LLM fungeert als mutatie-operator, geleid door een prompt die het ouderontwerp, inspiratie-voorbeelden uit de database en de optimalisatiegeschiedenis bevat.
• Een MAP-Elites strategie wordt gebruikt om de database bij te werken, waarbij ontwerpen worden geselecteerd op basis van hun structuur (bijv. aantal modules) en kosten (Area-Delay Product).

Kernresultaten

De experimenten zijn uitgevoerd met verschillende LLM's (DeepSeek-v3, GPT-4o, Qwen3-coder) en toolchains (open-source Yosys en commerciële Synopsys Design Compiler).

• Open-source Toolchain Resultaten:

  • Het kader slaagde erin om de PPA-metrics voor alle ontwerpen te verbeteren zonder menselijke tussenkomst.
  • Met DeepSeek-v3 werd een gemiddelde reductie van 10,50% in het Area-Delay Product (ADP) bereikt.
  • De verbetering in vertraging (delay) was significant sterker (gemiddeld 7,92%) dan in oppervlakte (2,80%), wat wijst op de effectiviteit van het analyseren van timing-paden.
  • Control-rijke ontwerpen (zoals controllers en processoren) lieten de grootste verbeteringen zien, terwijl gestandaardiseerde interfaces (zoals USB) minder vatbaar waren voor verbetering door bestaande rigiditeit.

• Commerciële Toolchain Resultaten:

  • Met de geavanceerde Synopsys Design Compiler waren de verbeteringen kleiner (gemiddeld 1,77% ADP-reductie), omdat commerciële tools de originele code al sterk optimaliseren.
  • Desondanks werden nog steeds significante verbeteringen behaald in specifieke gevallen (bijv. 10,61% vertragingreductie bij het 'audio' ontwerp), wat aantoont dat er nog ruimte is voor verbetering bovenop de beste commerciële synthese.

• Analyse van Code-wijzigingen:
  De LLM's pasten systematisch drie strategieën toe:

  1. Coding Style: Aanpassen van syntaxis naar synthese-vriendelijke patronen (bijv. blokkerende naar niet-blokkerende toewijzingen).
  2. Logica Flattening: Het omzetten van diepe, seriële logica naar parallelle expressies en het verwijderen van overbodige registers.
  3. State Machine Optimalisatie: Het samenvoegen van staten en vereenvoudigen van transitielogica.

Bijdragen en Significantie

1. Eerste Repository-Level Benchmark: CktEvo is het eerste benchmark dat zich richt op het optimaliseren van volledige, multi-file hardware-repository's in plaats van geïsoleerde modules.
2. Formalisatie van Evolutie: Het definieert een strikt kader voor "functioneel behoudende" hardware-optimalisatie, gekoppeld aan end-to-end verificatie.
3. Validatie van Gesloten-lus Automatisering: Het bewijst dat LLM's, wanneer ze worden gekoppeld aan EDA-feedback en formele verificatie, autonoom PPA-winst kunnen behalen in complexe ontwerpen.
4. Richting voor Toekomstig Onderzoek: Het paper identificeert de noodzaak voor agents die verder gaan dan lokale refactorings en in staat zijn tot architecturale hervormingen (high-level changes) om de grenzen van commerciële synthetische tools te overstijgen.

Conclusie:
CktEvo legt een fundamentele basis voor de overgang van LLM's van "code-generators" naar "ontwerp-experts" in de praktijk. Het toont aan dat geautomatiseerde, iteratieve evolutie van RTL-code een haalbare route is om de steeds strakkere PPA-eisen in chipontwerp te halen, zelfs na de toepassing van geavanceerde logische optimalisatie.