De bug van $10 miljoen die AI schreef — en waarom ik een bedrijf oprichtte om die uit te roeien

Ik herinner me het exacte moment waarop ik besloot Veriprajna te starten.

Het was geen flits van inspiratie. Het was een telefoontje. Van het soort waarbij de eerste vijf seconden niemand iets zegt, omdat de persoon aan de andere kant probeert te bedenken hoe hij moet zeggen wat hij moet zeggen. Een ontwerpteam — mensen die ik respecteerde, mensen die oprecht goed waren in hun werk — had zojuist het eerste silicium terug van de foundry voor een op maat gemaakte RISC-V-accelerator. De chip was dood. Niet dood in de zin van "heeft een tijdelijke oplossing nodig". Niet dood in de zin van "we kunnen het in firmware patchen". Onbruikbaar. Onder een specifieke, zeldzame samenloop van thermische throttling en high-bandwidth geheugenverkeer kwam de arbitragemodule in een ongedefinieerde toestand terecht en liep het geheel vast in een deadlock.

De hoofdoorzaak was een race condition. Een enkele, subtiele discrepantie tussen blocking en non-blocking assignments in de RTL — het soort ding dat perfect simuleert, zonder enige waarschuwing door de linter komt, elke regressietest doorstaat die je erop loslaat, en je dan verraadt in het silicium, waar geen tweede kansen zijn.

De maskerset voor die 5nm-chip kostte ongeveer $10 miljoen. Weg. Maar de echte schade zat niet in de maskers. Het waren de zes maanden die nodig waren om te diagnosticeren, te repareren, opnieuw te verifiëren en opnieuw te fabriceren. In de markt voor AI-accelerators, waar productgeneraties ongeveer 18 maanden meegaan, kan een vertraging van zes maanden 50% van de totale brutowinst over de levensduur van een product wegvagen. Voor een bedrijf dat mikt op $100 miljoen omzet kostte die race condition geen $10 miljoen. Het kostte $50 miljoen.

En dit is het deel dat me 's nachts wakker hield: de code die het veroorzaakte, was gegenereerd door een LLM.

De Goudkoorts Die Niemand In Twijfel Trekt

Op dit moment zit de halfgeleiderindustrie midden in een goudkoorts. Iedereen — en ik bedoel echt iedereen — racet om Large Language Models in de Electronic Design Automation (EDA)-workflow te integreren. De belofte is onweerstaanbaar: neem ontwerpcycli die vroeger jaren duurden en comprimeer ze tot maanden. Democratiseer chipontwerp. Laat AI de vervelende register-transfer level codering afhandelen zodat engineers zich kunnen richten op architectuur.

Ik snap de aantrekkingskracht. Ik heb het zelf gevoeld. De eerste keer dat ik een LLM een syntactisch correcte Verilog-module zag genereren uit een natuurlijke-taalprompt, dacht ik: dit verandert alles.

Maar toen begon ik zorgvuldiger te kijken naar wat "syntactisch correct" eigenlijk betekent wanneer je hardware schrijft in plaats van software. En ik besefte dat de industrie bouwde op een fundament van zand.

De tools die op dit moment de markt overspoelen, zijn wat ik "Wrappers" noem. Ze nemen een general-purpose LLM — GPT-4, Claude, Llama — verpakken die in een chatinterface met wat Verilog-achtige system prompts, en verkopen het als een "Chip Design Copilot". Sommige zijn oprecht indrukwekkende demo's. De code ziet er schoon uit. Hij compileert. Hij simuleert zelfs.

Maar dit is fundamenteel wat deze tools zijn: stochastische token-voorspellers met een hardwarelaagje. Ze begrijpen de circuittopologie niet. Ze begrijpen timing closure niet. Ze begrijpen metastabiliteit niet. Ze voorspellen het volgende waarschijnlijke token op basis van statistische patronen in hun trainingsdata.

Wanneer een LLM in software hallucineert, krijg je een runtime-fout die je over the air kunt patchen. Wanneer een LLM in hardware hallucineert, krijg je een presse-papier van $10 miljoen.

Die asymmetrie is de hele reden dat Veriprajna bestaat.

Waarom Schrijft AI Slechte Hardwarecode?

Dit is de vraag die me het vaakst wordt gesteld, meestal door software-engineers die LLM's perfect functionele Python hebben zien schrijven en niet kunnen begrijpen waarom Verilog anders is. Het antwoord gaat dieper dan "hardware is moeilijker". Het is een fundamentele mismatch tussen hoe LLM's denken en hoe hardware werkt.

LLM's worden overwegend getraind op software — Python, Java, C++, JavaScript. Dit zijn imperatieve, sequentiële talen. Regel A wordt uitgevoerd, dan regel B. De toestand van het systeem wordt bepaald door de volgorde van de operaties. LLM's hebben dit paradigma zo diep geïnternaliseerd dat het in feite hun moedertaal is.

Verilog en VHDL zijn declaratief en gelijktijdig. In een hardwaremodule wordt elk always-blok, elke assign-instructie, elke module-instantiatie gelijktijdig en continu uitgevoerd. De volgorde van de regels in de broncode heeft vaak geen enkele invloed op de volgorde van uitvoering in het silicium.

Ik zag dit in real time gebeuren tijdens een van onze vroege experimenten. We vroegen drie verschillende frontier-LLM's om een eenvoudig driestaps pipeline-register te implementeren. Alle drie gebruikten blocking assignments (=) in plaats van non-blocking assignments (<=). De code zag er volkomen redelijk uit als je er scheel naar keek zoals naar C-code. Maar in hardware betekenen blocking assignments in een geklokt blok dat stage2 wordt bijgewerkt met de waarde van stage1 onmiddellijk, en dat stage3 vervolgens de nieuwe waarde van stage2 krijgt — waardoor een pipeline van twee cycli in feite tot één cyclus wordt samengeperst.

Een van mijn engineers, Priya, staarde een minuut naar de output en zei: "Het schrijft C met de puntkomma's op de verkeerde plekken." Ze had helemaal gelijk. De LLM had een sequentiële bias — hij behandelde Verilog als een programmeertaal terwijl het in werkelijkheid een beschrijvingstaal is. Het onderscheid is syntactisch subtiel en fysiek catastrofaal.

En het wordt nog erger. Hardwareontwerp berust op strikte interfaceprotocollen — AXI, AHB, PCIe, TileLink — met complexe temporele regels. "Ready mag niet wachten op Valid." "Grant moet binnen 5 cycli worden geasserteerd." LLM's kunnen code genereren die deze regels 90% van de tijd respecteert, wat geweldig klinkt totdat je beseft dat de 10% die het fout doet precies de corner cases zijn die chips fataal worden. Een AXI-master die WVALID asserteert vóór AWREADY in een specifieke sub-clausule-schending gooit geen syntaxfout. Hij compileert, simuleert, en loopt dan vast wanneer hij in silicium wordt aangesloten op een conforme geheugencontroller.

Het trainingsdataprobleem verergert alles. Het volume aan hoogwaardige, productieklare Verilog dat beschikbaar is voor training is ordes van grootte kleiner dan Python of JavaScript. Veel van de open-source Verilog op GitHub bestaat uit studentenprojecten, verlaten prototypes, speelgoedimplementaties die een tape-out-review nooit zouden overleven. Wanneer je traint op middelmatige data, krijg je middelmatige output — output die er professioneel uitziet maar het DNA van amateurfouten bevat.

De Regel Die Elke Chipontwerper Achtervolgt

Er is een vuistregel in halfgeleiderontwerp die de "Rule of Ten" heet, en zodra je die begrijpt, begrijp je waarom ik zo geobsedeerd ben door het vroeg opsporen van bugs.

De kosten om een defect te herstellen nemen met 10x toe bij elke volgende fase van de ontwerplevenscyclus. Een bug die tijdens het RTL-ontwerp wordt opgemerkt kost ongeveer $100 om te herstellen — iemand bewerkt een bestand en voert een controle opnieuw uit. Dezelfde bug die tijdens block verification wordt opgemerkt kost $1.000. Bij system verification $10.000. Als hij ontsnapt naar post-silicon validation — wanneer je echte chips in een lab aan het debuggen bent — kijk je tegen $10 miljoen of meer aan voor een respin. En als hij de klanten in het veld bereikt? Dat is $100 miljoen-terrein. Terugroepacties, rechtszaken, merkvernietiging. Vraag het Intel maar over de Pentium FDIV-bug.

De Wrapper-AI-tools opereren vrijwel uitsluitend in de RTL-ontwerpfase. Ze helpen engineers sneller code te schrijven. Maar omdat ze geen enkele verificatiecapaciteit hebben buiten "compileert het", injecteren ze bugs die ongehinderd door block en system verification zeilen, om vervolgens in het silicium tot ontploffing te komen.

Hier komt de wrede ironie: door de snelheid van codegeneratie te verhogen zonder de striktheid van verificatie te verhogen, versnellen deze tools de injectie van kostbare defecten in de pipeline. Je gaat niet alleen snel en breekt dingen. Je gaat snel en bakt bugs in maskersets van $10 miljoen.

Gegevens uit de industrie bevestigen dit. Slechts 32% van de ontwerpen behaalt first-silicon success. De overige 68% vereist ten minste één respin, en de belangrijkste oorzaak zijn logische en functionele fouten — precies het soort fouten dat LLM's genereren wanneer ze protocollen hallucineren of concurrency verkeerd begrijpen.

Ik legde dit ooit uit aan een investeerder, vroeg in onze fondsenwerving. Hij luisterde geduldig en zei toen: "Kun je niet gewoon GPT-4 met betere prompts gebruiken?"

Ik haalde het voorbeeld van het pipeline-register erbij. Ik liet hem de blocking-assignment-bug zien. Ik liet hem zien dat het door de linting kwam, de simulatie doorstond, elke geautomatiseerde controle doorstond die de Wrapper-tools boden. Toen liet ik hem zien wat het in silicium zou doen.

Hij vroeg niet meer naar betere prompts.

Wat Als Je Code Correct Kon Bewijzen In Plaats Van Hem Alleen Te Testen?

Dit is waar het verhaal een wending neemt. Want het antwoord op het LLM-hallucinatieprobleem zijn geen betere prompts, grotere modellen of meer trainingsdata. Het is een fundamenteel andere benadering van verificatie.

Traditionele verificatie berust op simulatie — je schrijft testbenches, draait miljoenen cycli en controleert of het ontwerp doet wat je verwacht. Dit is als het testen van de remmen van een auto door duizend keer om het blok te rijden. Als de remmen het niet begeven, ga je ervan uit dat ze veilig zijn. Maar wat als ze het alleen begeven wanneer het regent, je exact 100 km/u rijdt en de radio is afgestemd op een specifieke frequentie? Simulatie kan alleen de scenario's verifiëren die het expliciet test. Al het overige is een gebed.

Formele Verificatie draait het ontwerp helemaal niet. Het zet het volledige ontwerp om in een wiskundige formule en gebruikt Satisfiability Modulo Theories (SMT)-solvers — tools zoals Microsofts Z3 — om uitputtend te bewijzen dat een eigenschap standhoudt onder elke mogelijke combinatie van invoer en interne toestand. Elke afzonderlijke. Geen steekproef. Geen statistische benadering. Een wiskundig bewijs.

Simulatie vraagt: "Werkt dit in de gevallen die ik heb getest?" Formele verificatie vraagt: "Is er enig mogelijk geval waarin dit faalt?" Het verschil is het verschil tussen hoop en bewijs.

Wanneer de solver "UNSAT" — unsatisfiable — teruggeeft, betekent dit dat er geen tegenvoorbeeld bestaat. De eigenschap is wiskundig gegarandeerd. Wanneer hij "SAT" teruggeeft, overhandigt hij je een specifieke reeks invoerwaarden die je ontwerp breekt, tot op de exacte klokcyclus.

Formele verificatie bestaat al decennia. De reden dat het de industrie niet heeft overgenomen, is dat het schrijven van de formele eigenschappen — SystemVerilog Assertions, oftewel SVA — berucht moeilijk is. Het vereist een gespecialiseerde vaardigheid die de meeste ontwerpteams niet hebben. De assertions zijn het "contract" voor de hardware: "Als request hoog gaat, moet grant binnen N cycli volgen." "Data die uit adres X wordt gelezen, moet overeenkomen met de laatste data die naar adres X is geschreven." "De pipeline mag nooit in een deadlock raken." Deze correct schrijven is een kunstvorm, en er zijn niet genoeg praktijkbeoefenaars om aan de vraag te voldoen.

Dat is nu precies waar AI nuttig wordt — niet voor het schrijven van de hardwarecode, maar voor het schrijven van het bewijs.

De "Formal Sandwich" — Hoe We Dit Echt Hebben Gebouwd

Ik heb maandenlang met mijn team gediscussieerd over de juiste architectuur. Het debat was fel en, achteraf gezien, verhelderend. Het ene kamp wilde een LLM fine-tunen totdat hij standaard correcte Verilog genereerde. Het andere kamp — het kamp waar ik uiteindelijk voor koos — betoogde dat correctheid-door-training een fantasie was. Je kunt hallucinatie niet wegtrainen. Je kunt het alleen opsporen.

We kwamen uit op wat we de "Formal Sandwich" noemen — een neuro-symbolische architectuur waarin de LLM de creatieve motor is en een formele verificatiesolver de onverbiddelijke criticus. Geen van beide werkt alleen. Samen doen ze iets wat geen van beide zelfstandig kan.

Zo werkt het in de praktijk. Een ontwerper levert een specificatie — "Ontwerp een APB-naar-AXI-bridge" of zelfs een screenshot van een timing-diagram. Onze Spec Analyzer-agent ontleedt dit in functionele vereisten. Dan komt de belangrijkste innovatie: in plaats van alleen code te genereren, genereert de LLM gelijktijdig twee artefacten.

Artefact A is de RTL-implementatie — de Verilog-code zelf. Artefact B is de formele specificatie — een set SVA-eigenschappen afgeleid van dezelfde vereisten. Als de specificatie zegt "Grant moet Request volgen", genereert de LLM de state machine én de assertion die bewijst dat de state machine doet wat hij beweert.

Dan laten we de solver los. Die neemt Artefact A en probeert het te breken met behulp van Artefact B. Eerst een vacuity check — om er zeker van te zijn dat de assertions niet triviaal waar zijn (een "luie" generatie waarbij de triggervoorwaarde nooit wordt geactiveerd). Dan bounded model checking, waarbij diepe toestandsruimten worden verkend — 50, 100 cycli diep — op zoek naar deadlocks, race conditions, protocolschendingen.

Als de solver een bug vindt, markeert hij die niet alleen. Hij produceert een tegenvoorbeeld-trace — een precieze waveform die exact laat zien hoe de bug zich manifesteert. En hier sluit de loop: we voeren die trace terug in de LLM als een prompt. "Je ontwerp is mislukt. Hier is de trace: Cyclus 1, Reset wordt gedeasserteerd. Cyclus 2, Request gaat hoog. Cyclus 10, Grant is nog steeds laag. De grant is nooit aangekomen. Repareer de state machine."

De LLM analyseert de trace, identificeert de ontbrekende toestandsovergang, herschrijft de code. De solver controleert opnieuw. Deze loop herhaalt zich automatisch totdat is bewezen dat het ontwerp correct is.

Ik heb over deze architectuur veel uitgebreider geschreven in de interactieve versie van ons onderzoek, maar het kerninzicht is simpel: we gebruiken AI om het bewijs te schrijven, en wiskunde om de AI te controleren. Geen van beide vertrouwt de ander. Beide maken de ander beter.

De Bugs Die Mij Tot Een Believer Maakten

Ik werd een echte believer in deze benadering, niet via theorie maar via specifieke bugs die we opspoorden en die niets anders zou hebben gevonden.

De open-source RISC-V-gemeenschap heeft oprecht uitstekende processorkernen voortgebracht — Ibex (gebruikt in Googles OpenTitan-beveiligingschip), het PULP-platform van ETH Zürich. Dit zijn zwaar onder de loep genomen ontwerpen met echt engineeringtalent erachter. En toch bevatten ze bugs die alleen formele verificatie kan vinden.

Axiomise, een adviesbureau voor formele verificatie, vond een bug in de Ibex-kern waarbij een debug-verzoek dat op een specifieke cyclus tijdens een branch-instructie arriveerde, ervoor kon zorgen dat de kern in een deadlock raakte of de verkeerde instructie uitvoerde. Denk daar eens over na — een security-kritische kern, beoordeeld door tientallen engineers, en een formele tool vond een bug die de simulatie volledig had gemist.

In het PULP-platform werd een bug gevonden waarbij de AXI-interconnect een bus master onbeperkt kon uithongeren onder een specifiek "busy"-patroon van interacties tussen AWVALID en AWREADY. Een klassieke liveness-fout — het systeem crasht niet, het maakt gewoon geen voortgang meer. Je zou nooit een gerichte test voor dat specifieke interactiepatroon schrijven. Er zijn te veel mogelijke patronen om op te sommen.

Wanneer we Veriprajna richten op een RISC-V Load-Store Unit, genereert het automatisch assertions voor interface-compliance ("als valid wordt geasserteerd, moet het hoog blijven tot ready"), data-integriteit ("data die uit adres X wordt gelezen komt overeen met de laatste write naar adres X") en forward progress ("de unit moet uiteindelijk een respons teruggeven"). Dit zijn geen bijzaken die achteraf op de code worden geschroefd. Ze worden naast de code gegenereerd, vanuit dezelfde specificatie, en afgedwongen voordat één regel RTL ons systeem verlaat.

Voor de volledige technische uiteenzetting van onze methodologie en de formele verificatie-engine, zie ons gedetailleerde onderzoeksrapport.

"Maar Formele Verificatie Schaalt Niet"

Mensen brengen hier altijd tegenin, en ik begrijp waarom. Formele verificatie staat bekend als computationeel explosief — de toestandsruimte van een moderne SoC is astronomisch groot, en naïeve formele benaderingen verslikken zich in alles wat groter is dan een speelgoedontwerp.

We hebben hier aanzienlijke inspanning in gestoken. Ons systeem gebruikt geautomatiseerde abstractietechnieken om formeel op schaal hanteerbaar te maken. Black-boxing stelt ons in staat de glue logic te verifiëren terwijl we grote sub-blokken zoals RAM's of complexe ALU's behandelen als abstracte entiteiten met gedefinieerde interfaces. Cut-points breken valid/ready handshake-paden zodat we flow control onafhankelijk van dataverwerking kunnen verifiëren. Symmetriereductie stelt ons in staat een eigenschap voor één kanaal van een multi-port router te bewijzen en die wiskundig te induceren voor alle N kanalen.

Is het volledig opgelost? Nee. Analoge fysica zal altijd uitdagingen opleveren die formele methoden niet kunnen raken. Maar de logische bugs — de race conditions, de deadlocks, de protocolschendingen — worden wiskundig onmogelijk in de gegenereerde code. En dat zijn de bugs die respins veroorzaken.

Het andere bezwaar dat ik hoor gaat over snelheid. "Vertraagt het draaien van een formele solver het ontwerpproces niet?" Ja, het voegt computationele kosten toe. Maar ik ruil elke dag rekentijd in voor planningszekerheid. Een formele solver die een extra uur draait is oneindig veel goedkoper dan een respin van zes maanden.

De Ongemakkelijke Waarheid Over "AI-Ontworpen Chips"

Er is een narratief dat aan terrein wint in de industrie — dat AI binnenkort chips van begin tot eind zal ontwerpen, dat we van Computer-Aided Design naar Computer-Automated Design gaan. Ik geloof dat dat narratief qua richting klopt maar gevaarlijk onvolledig is.

We bouwen richting agentic workflows waarin autonome AI-agents samenwerken — een Architect-agent voor high-level partitionering, een RTL Coder voor implementatie, een Verification Engineer voor het schrijven van testbenches en assertions, een Manager voor het orkestreren van de flow tegen power-, performance- en area-beperkingen. We gebruiken Retrieval-Augmented Generation (RAG) niet alleen voor code maar ook voor kennis — het ophalen van specifieke protocolregels, process design kit-beperkingen en interne codeerstandaarden zodat de LLM conforme code genereert zonder te hallucineren.

Maar niets hiervan werkt — helemaal niets ervan — zonder een ruggengraat van formele verificatie. Hoe autonomer de AI wordt, hoe kritischer het is dat elke output wiskundig is geverifieerd voordat hij verder in de keten gaat. Een AI-agent die sneller code genereert is alleen waardevol als die code correct is. Een AI-agent die sneller code genereert én bewijst dat die correct is? Dat is de toekomst.

Het probleem van de halfgeleiderindustrie is niet dat AI te traag is in het schrijven van hardwarecode. Het is dat AI te snel is in het schrijven van hardwarecode die subtiel verkeerd is.

We zijn geen copilot. We zijn geen chatbot. We zijn een formele verificatie-foundry die toevallig generatieve AI als front-end gebruikt. Het onderscheid is belangrijk omdat het bepaalt waarvoor je optimaliseert. Copilots optimaliseren voor snelheid. Wij optimaliseren voor correctheid. In een wereld waarin één ontsnapte bug $10 miljoen aan maskers en $50 miljoen aan gederfde omzet kost, weet ik welke optimalisatie ik zou kiezen.

De Keuze Is Al Gemaakt

De halfgeleiderindustrie kan zich de "genereer en bid"-benadering niet langer veroorloven. De Rule of Ten is geen suggestie — het is fysica en economie die samenspannen om iedereen te straffen die ongeverifieerd silicium levert. Op 5nm en kleiner, met maskersets die de $20 miljoen naderen, is de foutmarge tot nul geslonken.

Elke week praat ik met ontwerpteams die enthousiast zijn over wat LLM's kunnen doen voor hun productiviteit en doodsbang voor wat LLM's zouden kunnen aanrichten met hun tape-out-planning. Ze hebben gelijk om beide dingen tegelijkertijd te voelen. De technologie is oprecht transformerend. Ze is ook oprecht gevaarlijk zonder een vangnet.

Veriprajna is dat vangnet. Wij geven je de snelheid van AI met de zekerheid van wiskunde. Niet "waarschijnlijk correct". Niet "regressie doorstaan". Bewezen correct, over elke mogelijke invoer, elke mogelijke toestand, elke mogelijke corner case die een simulatie nooit zou bedenken om te testen.

De keuze waar elke chipontwerper vandaag voor staat, is niet of AI gebruikt moet worden. Die trein is vertrokken. De keuze is of je AI gebruikt die zijn eigen werk kan bewijzen, of AI die simpelweg hoopt op het beste.

Ik weet op welke van de twee ik $10 miljoen zou inzetten.