ChipAgents Transcript: Hoe agentic AI EDA en chipontwerpprocessen revolutioneert
11 juni 2025 - Semiconductor Engineering interview met ChipAgents
De transitie van LLM's naar agentic AI begrijpen
Ann Mutschler: Ik ben Ann Mutschler, Senior Executive Editor bij Semiconductor Engineering. Ik ben hier bij ChipAgents met Mahir Arora om te spreken over agentic AI. Mahir, bedankt dat je er vandaag bent. Kun je uitleggen wat agentic AI is en wat het betekent voor de chipontwerper?
Mahir Arora: Large language models, of LLM's, zijn een extreem recente technologie, en AI-agents zijn een nog recentere technologie. Geen van beide is echt volledig doorgedrongen in het EDA-landschap. Om echt over het verschil tussen AI-agents en LLM's te praten, moet je teruggaan naar wat LLM's precies zijn, wat hun tekortkomingen in de hardware-sector zijn, en dan kunnen we praten over AI-agents en hoe dat uiteindelijk de processen voor hardware-ontwerpers en verificatieteams verbetert. Ik denk dat de meeste mensen bekend zijn met LLM's vanuit een gebruikersperspectief. Iedereen heeft wel eens iets als ChatGPT gebruikt om bijvoorbeeld e-mails op te stellen.
[Visuele beschrijving: Mahir staat voor een whiteboard waarop hij diagrammen heeft geschetst die de werking van large language models en de iteratieve feedbackloop van agentic AI uitleggen.]
Mahir Arora: Ik heb wat dingen op dit whiteboard geschreven om de kernconcepten van LLM's en AI-agents uit te leggen. Je moet mijn handschrift even voor lief nemen, maar het kernidee bij LLM's is dat ze iets doen dat autoregressieve tokenvoorspelling of autoregressieve sequentiemodellering heet. De details daarvan zijn vrij eenvoudig. Als je een krachtig LLM hebt, zoals GPT-4o, kun je die een vraag stellen. De manier waarop je die vraag stelt is bijvoorbeeld: "Wat is 2 plus 2?". Dit wordt vervolgens ge-tokenized. De exacte methode van tokenization is niet zo belangrijk, maar de input wordt opgedeeld in delen die het LLM daadwerkelijk kan begrijpen. Zodra je deze input geeft, kun je ook een inleiding toevoegen, zoals: "Het antwoord op 2 plus 2 is". Waar LLM's fundamenteel op getraind zijn, is het invullen van dit lege token aan het einde. Er is een soort onbekende, een masker, dat aan het einde wordt geplaatst, en ze zijn getraind om dit token te proberen te voorspellen.
Mahir Arora: Concreet, wiskundig gezien, voorspellen LLM's een kansverdeling. Gegeven alle voorgaande input-tokens, willen we proberen de waarde van het onbekende te voorspellen. Omdat je een kansverdeling krijgt aan de andere kant, en aangezien we een krachtig LLM hebben dat goed is in deze tokenvoorspellingstaak, zal het voor 2 plus 2 sterk suggereren dat de output 4 is. In mijn voorbeeld op het whiteboard laat ik zien dat er ongeveer 99% kans is op 4, 1% kans op 5, en dan een kans van 1 op een miljard op iets als "Madagascar", omdat dat gewoon een willekeurig woord uit de Engelse taal is, of elke andere taal in het geval van meertalige LLM's. Dit is geweldig voor het beantwoorden van één specifieke vraag in deze kunstmatige vorm waarbij we een prompt hebben en gewoon het lege vakje willen invullen. Maar wat als we meer willen dan alleen de vakjes invullen?
Mahir Arora: Om dat te doen, komen we bij autoregressieve sequentiemodellering. "Auto" betekent zelf, en "regressief" is in feite terugkeren naar zichzelf, vandaar de term autoregressief. Het idee is dat als ik wil dat mijn LLM een volledige functie voor me invult, een pagina tekst, een heel essay of potentieel een hele codebase genereert, ik wil dat het hetzelfde proces doorloopt van het modelleren van de potentiële outputdistributie van één token, maar dat vele, vele malen doet. Hier op het whiteboard heb ik mijn model geprompt met een paar input-tokens voor een functie genaamd "add", met een open haakje. Nu heb ik hetzelfde probleem als voorheen. Ik moet dit ontbrekende token voorspellen, dat ik "mask" heb genoemd. Er zijn een paar mogelijkheden voor de output. We zouden bijvoorbeeld het token "num1" kunnen krijgen, of een token zoals "a". Er is een waarschijnlijkheid toegewezen aan elk van deze outputs. De magie zit in de sampling. Op basis van deze kansverdeling kunnen we een potentieel output-token samplen. Bijvoorbeeld, we kunnen "num1" samplen, of "a". Laten we in dit geval zeggen dat we "a" samplen. Nu nemen we dit token "a", stoppen het terug in de input en herhalen het proces. In stap twee hebben we "function add, open haakje, a" en nu herhaalt het probleem zich. We kunnen dit direct terugvoeren om de volgende sequentie autoregressief te modelleren.
De kracht van zelfreflectie en feedbackloops
Ann Mutschler: Ik wilde je ook vragen naar zelfreflectie. Hoe speelt dat hierbij een rol?
Mahir Arora: Dat is een uitstekende vraag. Om over zelfreflectie te praten, moeten we kijken naar wat er gebeurt zodra je n herhalingen van dit proces hebt doorlopen. Zodra we n herhalingen hebben gehad, komen we bij de volledige output, die eruit zou kunnen zien als: "function add, a comma b, return a plus b", waarna het een stop-token voorspelt om het autoregressieve proces te beëindigen. Wat je zult merken in dit proces is dat wanneer ik een beslissing neem – het sampling-proces waarbij ik kies om "a" als mijn output op te nemen – ik met die beslissing moet leven. Wanneer ik later in de sequentie iets teruggeef, kan ik niet plotseling van gedachten veranderen. Ik moet zeggen "return a plus b". Ik kan niet zeggen "return num1 plus num2". Kortom, beslissingen uit het verleden kunnen mijn toekomstige beslissingen informeren, maar andersom is dat niet waar. Wat als ik een fout heb gemaakt in mijn sampling-proces? Wat als ik in plaats van "a" een sluitend haakje had uitgevoerd? Nou, dan zit ik vast. Ik ga fundamenteel iets onjuists uitvoeren. Informatie kan niet in de andere richting stromen. Hoe ga je van toekomstige beslissingen naar het beïnvloeden van beslissingen uit het verleden? De directe consequentie hiervan is dat als ik onjuiste beslissingen uit het verleden heb, ik gegarandeerd onjuiste toekomstige beslissingen krijg, wat een algeheel onjuiste output garandeert. Dit brengt ons direct bij zelfreflectie, verfijning en zelfcorrectie. Dat is waar we vervolgens in duiken, en dit is waar we kunnen gaan praten over agentic AI.
Mahir Arora: Het eerste wat je moet begrijpen over agents is dat ze boven op LLM's liggen. Het is een technologie die is afgeleid van LLM's, maar agentic AI gaat over een heel proces, niet slechts over een enkel gebruik van een LLM. Om over agents, zelfcorrectie en hoe ze dit probleem fundamenteel oplossen te praten, moeten we de basis leggen.
Ann Mutschler: Kun je meer in detail treden over wat agents zijn?
Mahir Arora: Absoluut. Om precies te begrijpen wat agents zijn, moet je begrijpen dat agentic AI een proces is. Het is niet één enkel gebruik van een LLM. Wat je bij agents echt zult zien, is dat het LLM's zijn die gekoppeld zijn aan een zoekproces en, het allerbelangrijkste, feedback. Ze gebruiken feedback om zichzelf te corrigeren, zichzelf te stabiliseren en daadwerkelijk uit te voeren en te slagen waar LLM's normaal gesproken zouden falen. Laten we een uitgewerkt voorbeeld doornemen. Bij een agentic proces kun je als input voor je agent een hele taak hebben. Bijvoorbeeld: ik wil een Verilog-module schrijven, iets als een asynchrone FIFO. De details van de module zijn niet zo belangrijk, maar we gaan een aantal stappen doorlopen.
[Visuele beschrijving: Mahir wijst naar het whiteboard dat een agentic proces met meerdere stappen illustreert, inclusief feedback van compilers, linters, testbenches en golfvormen.]
Mahir Arora: In de eerste stap roept de agent een LLM aan om een potentiële output te produceren. Het genereert een bestand voor mij, fifo.sv, in SystemVerilog, met deze module. Maar we hebben nog steeds alle problemen met autoregressieve modellering van voorheen, die zich in deze eerste stap manifesteren. De agent kan een set input-pinnen instellen en daarover beslissen, maar later gebruikt hij misschien een nieuwe input. Misschien heeft hij ergens een 'wire' niet gedefinieerd, maar wil hij die nu wel gebruiken. Wat moet hij doen? Als het slechts een LLM is, voert hij deze code uit, geeft die aan jou, jij probeert het te compileren en uit te voeren, het werkt niet, en dat is het einde van het verhaal. Dat is niet wat we willen. We willen reflectie en feedback. Het volgende dat gebeurt na stap één is feedback. Feedback kan in veel verschillende vormen komen. Het kan komen van je compilers, je linters of je testbenches. Asserties kunnen falen, tests kunnen falen, of er kunnen lastige outputs in je logs staan die suggereren dat er iets mis is, inclusief golfvorm-outputs. Al deze dingen zijn outputs die het agentic proces zal onderzoeken. Je voert deze feedback terug in de agent. De agent onderzoekt dit in de context van zijn eerdere output en concludeert dat er iets mis is. Hij gaat het debuggen, bedenkt hoe hij dat proces kan repareren, en dan herhaalt het zich. We gaan door stap twee waar hij deze problemen oplost, en dan krijgen we potentieel meer feedback. Bijvoorbeeld: er zijn meer tests die falen, of er zijn golfvormen die inconsistent zijn met wat we verwachten van ons 'golden reference model'. De agent gaat door en blijft dat proces repareren. Het uiteindelijke doel is dat je niet slechts één poging krijgt om een module te produceren, maar dat je een systeem hebt dat zichzelf corrigeert en stabiliseert door het feedbackproces, wat uiteindelijk resulteert in een werkende, correcte implementatie.
AI-agents in EDA en de Verilog-Eval benchmark
Ann Mutschler: Hoe gaan agents verschijnen in EDA-tools?
Mahir Arora: Dat is een uitstekende vraag. Bij ChipAgents produceren we een product dat specifiek is ontworpen voor EDA, waarbij agents worden gebruikt als onderdeel van je dagelijkse EDA-flow. De details van hoe ze verschijnen omvatten allerlei verschillende use-cases. Eén ding dat erg belangrijk is om op te merken over agents, is dat de prestaties van LLM's in hardware vergeleken met de prestaties van agents in hardware dramatisch verschillen. Er is een zeer bekende benchmark genaamd Verilog-Eval, die is gebouwd door Nvidia. Wat je zult merken is dat wanneer je een standaard LLM gebruikt voor deze benchmarks, waarbij de taak is om van een natuurlijke taalbeschrijving naar een functionele Verilog-module-output te gaan, de prestaties echt abominabel zijn. Je kunt een krachtig taalmodel zoals GPT-4o gebruiken, dat extreem goed presteert op Python-softwaretaken, maar het presteert abominabel slecht op Verilog-taken, met een nauwkeurigheid van ongeveer 50%. Een nauwkeurigheid van 50% is verschrikkelijk. Dat is een onvoldoende, en we willen dergelijke technologie niet gebruiken. Maar het blijkt dat zodra je je LLM's in een agentic proces verpakt, de prestaties enorm omhoog schieten. Je begint dichter bij de 80% en 90% range te komen. Het systeem dat ik hier heb beschreven, vertegenwoordigt deze processen in hun eenvoudigste termen, maar je kunt veel doen om ze te verbeteren. Uiteindelijk kunnen we de prestaties opdrijven tot het niveau van 99% of 99,7%. Door het gebruik van agents zijn we deze benchmarks gaan verzadigen. Terwijl LLM's daar op zichzelf niet toe in staat zijn, zijn agents dat wel.
Mahir Arora: Dit verklaart waarom LLM's niet zijn verschenen in de dagelijkse workflows van hardware-engineers, omdat standaard LLM's niet betrouwbaar genoeg zijn om te worden gebruikt bij de taken waar engineers in geïnteresseerd zijn. AI-agents zijn echter wel betrouwbaar genoeg om in deze situaties te worden gebruikt. De meest voorkomende manier waarop we onze klanten tegenwoordig AI-agents zien gebruiken, is voor zeer snelle prototyping. Als je een design engineer bent, wil je een aantal verschillende microarchitecturale beslissingen verkennen en het stroomverbruik, de prestaties en het oppervlak (PPA) van allemaal evalueren. Je wilt de Pareto-grens vinden en kiezen welke het beste werkt voor jouw use-case. Maar er gaat veel werk zitten in het opzetten van die experimenten. Je moet build-scripts, build-harnesses en simulatie-harnesses afhandelen, en je moet je module integreren met de bestaande apparatuur die nodig is om die tests uit te voeren. Agents doen hier fantastisch werk. Je kunt je microarchitectuurbeschrijving aan een agent geven, en deze zal autonoom informatie verzamelen uit je repositories, documentatie, specificaties en andere modaliteiten. Hij zal die informatie extraheren en een langetermijnplan maken over hoe dit uit te voeren. Hij zal de implementatie van de module afhandelen met behulp van de zelfcorrectie en zelfstabilisatie waar we het over hadden, om ervoor te zorgen dat de module van hoge kwaliteit is, en dan doet hij ook het zware werk van integratie. Hij zal het zo instellen dat het daadwerkelijk aansluit bij al je bestaande infrastructuur, die tests uitvoeren, informatie uit die logs extraheren en vervolgens verslag aan je uitbrengen.
Verificatie en systeemanalyse stroomlijnen
Ann Mutschler: Mahir, je noemde verificatie eerder, en dat is een grote uitdaging voor elk verificatie- en ontwerpteam. Hoe zullen AI-agents daar een rol spelen?
Mahir Arora: Dat is een uitstekende vraag. Op het gebied van verificatie is de reden waarom verificatie zo moeilijk is, de exponentiële toename in de complexiteit van de chips die we willen verifiëren. We hebben op dit punt te maken met biljoenen transistoren, miljarden op een individuele System on Chip (SoC), en biljoenen in het hele overkoepelende systeem. Hoe moet je die complexiteit beheersen en onderhouden? Het grote probleem dat verificatie-engineers hebben, is dat ze een mentaal beeld moeten opbouwen van alles wat te maken heeft met het subsysteem dat ze verifiëren. Je verifieert niet alleen één module; je verifieert een heel subsysteem tegelijk, en potentieel een groot deel van je SoC tegelijk. Hoe extraheer je al die informatie in de eerste plaats? Hoewel het voor een mens erg moeilijk is om tienduizenden of honderdduizenden regels code door te lezen, is dat iets waar AI-agents zeer toe in staat zijn. Je kunt een AI-agent op een open taak zetten, zoals precies uitzoeken hoe data door een complex systeem stroomt. Die agent zal een hiërarchisch plan op lange termijn maken over hoe hij die informatie gaat vinden. Hij zal op al deze verschillende locaties zoeken, en zelfs als hij ergens informatie niet vindt, zal hij zijn eigen plan corrigeren. Hij zal de verzamelde informatie gebruiken om te vinden waar hij nog meer moet kijken, al die informatie samenbrengen en aan jou uitleggen hoe data door het systeem stroomt. Vanaf dat punt, nu je weet hoe data door het systeem stroomt, heb je een veel beter idee van hoe je het daadwerkelijk moet verifiëren, met welke edge cases je rekening moet houden, en welke stimulus je ook aan het systeem moet bieden.
De dagelijkse impact op ontwerp- en verificatieteams
Ann Mutschler: Hoe gaat dat er vandaag uitzien voor de ontwerp- en verificatie-engineer? Wat zullen zij in hun dagelijkse werk zien?
Mahir Arora: Breder genomen is dit echt impactvol voor teams. AI-agents werken geweldig in de handen van één persoon die te veel taken op zijn bordje heeft. Als je aan de ontwerpkant zit, is je hoofdtaak misschien het samenstellen van een soort microarchitectuur. Als je aan de verificatiekant zit, is het het opstellen van een verificatieplan en proberen uit te zoeken hoe je intelligent door je systeem kunt navigeren naar al deze interessante condities, constraints en edge cases. Maar je hebt ook zoveel extra taken. Je moet je testbench opzetten, het harness opzetten, en je testplan nemen en schrijven in termen van bijvoorbeeld UVM, wat veel schrijfwerk van UVM-sequenties vereist. Met AI-agents kun je al deze taken asynchroon op de achtergrond afhandelen. Je kunt AI-agents al deze taken tegelijkertijd laten uitvoeren.
Mahir Arora: Voor een verificatie-engineer is de flow die we tegenwoordig vaak zien, dat ze het verificatieplan dat ze hebben en een bestaande testbench nemen, misschien van een processor van een vorige generatie. Ze verstrekken die informatie aan de agent en vragen hem de testbench uit te breiden met de nieuwe sequenties of functies die moeten worden geverifieerd zoals gespecificeerd in het verificatieplan. Dit zal kleinere teams het gevoel geven dat ze veel grotere teams zijn, en dat is echt spannend. Wij zijn zelf een startup en we werken met veel startups en zeer grote bedrijven. Kleinere teams zullen een enorme krachtvermenigvuldiger voelen door het gebruik van AI-agents. Plotseling zullen een paar senior engineers het gevoel hebben dat ze een team van senior engineers zijn, ondersteund door een stel junior engineers om hen te helpen, wat erg spannend gaat worden.
Onboarding voor junior engineers versnellen
Ann Mutschler: Ik wilde ook vragen naar junior engineers. Hoe kan dit hen helpen om sneller ingewerkt te raken?
Mahir Arora: Dat is een uitstekende vraag. Het grote probleem met het inwerken van iemand die bijzonder groen is, is dat er een enorme hoeveelheid code is om doorheen te werken. Ze moeten een mentaal model opbouwen van alles in de codebase om erachter te komen hoe ze deze zelfs maar kunnen uitbreiden of verifiëren. Begrijpen waar alles staat is een uitzonderlijk moeilijke taak voor een mens. Wij hebben menselijke ogen en lezen op menselijke snelheid. LLM's en AI-agents kunnen op veel hogere snelheden lezen, dankzij de onderliggende technologie van LLM's waardoor ze dingen parallel kunnen verwerken. Daarom kun je een agent vragen hoe het systeem precies werkt en hem iets laten doen zoals het bouwen van een blokdiagram van hoe een bepaald datapad werkt. AI-agents kunnen op pad gaan, alle benodigde informatie vinden en die documentatie voor je produceren. Dat is een veelvoorkomende taak die we onze klanten zien doen. Het helpt echt bij het inwerken van nieuwe engineers, zodat ze een solide mentaal model hebben van hoe deze processors en grote systemen werken.
IP-beveiliging en rekenkracht-constraints aanpakken
Ann Mutschler: Beveiliging is een probleem bij AI. Hoe ziet dat eruit voor AI-agents en ChipAgents?
Mahir Arora: Beveiliging is altijd een belangrijk punt. Ieders IP is uiterst kritiek. Hoe behoud je die IP-beveiliging terwijl je toch de enorme productiviteitsverbeteringen van AI-agents benut? Dit hangt zeker af van onderneming tot onderneming en van klant tot klant, want als je echt AI-agents wilt gebruiken, moet je veel rekenkracht gebruiken. De beste AI-agents werken met de beste, grootste basismodellen die vervolgens worden gefinetuned op een grote hoeveelheid agent-trainingsdata, en die vereisen echt krachtige servers. Er zullen organisaties zijn die die extra rekenkracht hebben liggen die ze kunnen gebruiken voor agentic AI, maar er zullen ook ondernemingen zijn die naar de cloud moeten gaan om servertijd te huren op zeer grote GPU-servers.
Mahir Arora: Voor ChipAgents in het bijzonder bedienen we allerlei verschillende klanten. Sommige klanten voelen zich comfortabeler bij het gebruik van onze implementaties in de cloud waar wij GPU-tijd inkopen. Wij doen de inferentie voor hen, en de garanties die we bieden zijn dat alle data versleuteld is tijdens transport en versleuteld in rust, of alleen efemerisch in het geheugen wordt verwerkt en vervolgens wordt teruggegeven aan hen. Dat is een compromis dat geweldig werkt voor veel verschillende klanten, inclusief beursgenoteerde bedrijven. Er zijn een aantal zeer grote bedrijven die zeer specifieke beperkingen hebben, en zij vragen ons vaak om in hun eigen cloud te implementeren. Het is heel gebruikelijk voor ons om naar een klant te gaan die bijvoorbeeld een AWS-account heeft, en zij geven ons voor een korte periode toegang om dit allemaal voor hen in te stellen, zodat ze het intern kunnen gebruiken.
Ann Mutschler: Mahir, bedankt voor al deze uitleg.
Mahir Arora: Heel erg bedankt voor je tijd.