Il bug da 10 milioni di dollari scritto dall'AI — e perché ho fondato un'azienda per eliminarlo

Ricordo il momento esatto in cui decisi di fondare Veriprajna.

Non fu un lampo di ispirazione. Fu una telefonata. Di quelle in cui nessuno parla per i primi cinque secondi perché la persona dall'altra parte sta cercando di capire come dire ciò che deve dire. Un team di progettazione — persone che rispettavo, persone davvero brave nel loro lavoro — aveva appena ricevuto il primo silicio di ritorno dalla fonderia per un acceleratore RISC-V personalizzato. Il chip era morto. Non morto nel senso di "serve una soluzione alternativa". Non morto nel senso di "possiamo correggerlo via firmware". Mattonato. In un allineamento specifico e raro tra throttling termico e traffico di memoria ad alta larghezza di banda, il modulo di arbitraggio entrava in uno stato indefinito e l'intero sistema andava in deadlock.

La causa principale era una race condition. Una singola, sottile discrepanza tra assegnazioni blocking e non-blocking nell'RTL — quel genere di cosa che simula alla perfezione, passa il lint senza un sussurro, supera ogni test di regressione che gli lanci, e poi ti tradisce nel silicio dove non ci sono seconde possibilità.

Il set di maschere per quel chip a 5nm costava circa 10 milioni di dollari. Persi. Ma il vero danno non erano le maschere. Erano i sei mesi necessari per diagnosticare, correggere, ri-verificare e ri-fabbricare. Nel mercato degli acceleratori AI, dove le generazioni di prodotto durano circa 18 mesi, uno slittamento di sei mesi può erodere il 50% del profitto lordo totale sull'intero ciclo di vita di un prodotto. Per un'azienda che punta a 100 milioni di dollari di fatturato, quella race condition non è costata 10 milioni di dollari. È costata 50 milioni di dollari.

Ed ecco la parte che mi teneva sveglio la notte: il codice che l'aveva causata era stato generato da un LLM.

La corsa all'oro che nessuno mette in discussione

In questo momento l'industria dei semiconduttori è nel bel mezzo di una corsa all'oro. Tutti — e intendo proprio tutti — fanno a gara per innestare i Large Language Model nel flusso di lavoro dell'Electronic Design Automation (EDA). La promessa è irresistibile: prendere cicli di progettazione che duravano anni e comprimerli in mesi. Democratizzare la progettazione dei chip. Lasciare che l'AI gestisca la noiosa codifica a livello register-transfer così che gli ingegneri possano concentrarsi sull'architettura.

Ne capisco il fascino. L'ho provato io stesso. La prima volta che ho visto un LLM generare un modulo Verilog sintatticamente corretto da un prompt in linguaggio naturale, ho pensato: questo cambia tutto.

Ma poi ho iniziato a guardare più attentamente cosa significa davvero "sintatticamente corretto" quando scrivi hardware invece di software. E ho capito che l'industria stava costruendo su fondamenta di sabbia.

Gli strumenti che stanno inondando il mercato in questo momento sono ciò che io chiamo "Wrapper". Prendono un LLM generalista — GPT-4, Claude, Llama — lo avvolgono in un'interfaccia di chat con qualche prompt di sistema in salsa Verilog, e lo vendono come "Copilot per la progettazione di chip". Alcuni sono demo davvero impressionanti. Il codice sembra pulito. Compila. Simula perfino.

Ma ecco cosa sono fondamentalmente questi strumenti: predittori stocastici di token con una veste hardware. Non comprendono la topologia dei circuiti. Non comprendono il timing closure. Non comprendono la metastabilità. Predicono il prossimo token probabile in base a pattern statistici presenti nei loro dati di addestramento.

Quando un LLM ha un'allucinazione nel software, ottieni un errore a runtime che puoi correggere over-the-air. Quando un LLM ha un'allucinazione nell'hardware, ottieni un fermacarte da 10 milioni di dollari.

Quell'asimmetria è l'intera ragione per cui Veriprajna esiste.

Perché l'AI scrive codice hardware difettoso?

Questa è la domanda che mi viene posta più spesso, di solito da ingegneri del software che hanno visto gli LLM scrivere Python perfettamente funzionante e non riescono a capire perché il Verilog sia diverso. La risposta va più a fondo di "l'hardware è più difficile". È una discrepanza fondamentale tra il modo in cui gli LLM pensano e il modo in cui funziona l'hardware.

Gli LLM sono addestrati in modo schiacciante sul software — Python, Java, C++, JavaScript. Questi sono linguaggi imperativi, sequenziali. La riga A viene eseguita, poi la riga B. Lo stato del sistema è definito dall'ordine delle operazioni. Gli LLM hanno interiorizzato questo paradigma così profondamente che è praticamente la loro lingua madre.

Verilog e VHDL sono dichiarativi e concorrenti. In un modulo hardware, ogni blocco always, ogni istruzione assign, ogni istanziazione di modulo viene eseguita simultaneamente e continuamente. L'ordine delle righe nel codice sorgente spesso non ha alcuna rilevanza sull'ordine di esecuzione nel silicio.

L'ho visto accadere in tempo reale durante uno dei nostri primi esperimenti. Abbiamo chiesto a tre diversi LLM di frontiera di implementare un semplice registro di pipeline a tre stadi. Tutti e tre hanno usato assegnazioni blocking (=) invece di assegnazioni non-blocking (<=). Il codice sembrava perfettamente ragionevole se lo guardavi socchiudendo gli occhi come fosse codice C. Ma nell'hardware, le assegnazioni blocking in un blocco temporizzato significano che stage2 viene aggiornato con il valore di stage1 immediatamente, e poi stage3 ottiene il valore nuovo di stage2 — collassando di fatto una pipeline a due cicli in un solo ciclo.

Una delle mie ingegnere, Priya, fissò l'output per un minuto e disse: "Sta scrivendo C con i punti e virgola nei posti sbagliati." Aveva perfettamente ragione. L'LLM aveva un bias sequenziale — trattava il Verilog come un linguaggio di programmazione quando in realtà è un linguaggio di descrizione. La distinzione è sottile sul piano sintattico e catastrofica sul piano fisico.

E c'è di peggio. La progettazione hardware si basa su protocolli di interfaccia rigorosi — AXI, AHB, PCIe, TileLink — con complesse regole temporali. "Ready non deve attendere Valid." "Grant deve essere asserito entro 5 cicli." Gli LLM possono generare codice che rispetta queste regole il 90% delle volte, il che suona benissimo finché non ti rendi conto che il 10% che sbagliano sono precisamente i casi limite che uccidono i chip. Un master AXI che asserisce WVALID prima di AWREADY in una violazione di una sotto-clausola specifica non genererà un errore di sintassi. Compilerà, simulerà, e poi si bloccherà quando connesso a un controller di memoria conforme nel silicio.

Il problema dei dati di addestramento aggrava tutto. Il volume di Verilog di alta qualità e di livello produttivo disponibile per l'addestramento è di diversi ordini di grandezza inferiore rispetto a Python o JavaScript. Gran parte del Verilog open-source su GitHub è costituita da progetti studenteschi, prototipi abbandonati, implementazioni giocattolo che non supererebbero mai una revisione di tape-out. Quando ti addestri su dati mediocri, ottieni output mediocri — output che sembrano professionali ma contengono il DNA di errori da dilettanti.

La regola che perseguita ogni progettista di chip

Nella progettazione dei semiconduttori esiste un'euristica chiamata "Regola del Dieci", e una volta che la comprendi, capisci perché sono così ossessionato dallo scovare i bug in anticipo.

Il costo per correggere un difetto aumenta di 10 volte a ogni fase successiva del ciclo di vita della progettazione. Un bug intercettato durante la progettazione RTL costa circa 100 dollari da correggere — qualcuno modifica un file e riesegue un controllo. Lo stesso bug intercettato durante la verifica di blocco costa 1.000 dollari. Alla verifica di sistema, 10.000 dollari. Se sfugge fino alla validazione post-silicio — quando stai facendo debug su chip reali in laboratorio — ti trovi davanti a 10 milioni di dollari o più per un respin. E se raggiunge i clienti sul campo? Quello è territorio da 100 milioni di dollari. Richiami, cause legali, distruzione del brand. Chiedi a Intel del bug FDIV del Pentium.

Gli strumenti AI Wrapper operano quasi esclusivamente nella fase di progettazione RTL. Aiutano gli ingegneri a scrivere codice più velocemente. Ma poiché mancano di qualsiasi capacità di verifica al di là di "compila?", iniettano bug che attraversano indenni la verifica di blocco e di sistema, solo per detonare nel silicio.

Ecco la crudele ironia: aumentando la velocità di generazione del codice senza aumentare il rigore della verifica, questi strumenti accelerano l'iniezione di difetti ad alto costo nella pipeline. Non stai solo andando veloce e rompendo le cose. Stai andando veloce e incastonando bug in set di maschere da 10 milioni di dollari.

I dati del settore lo confermano. Solo il 32% dei progetti raggiunge il successo al primo silicio. Il restante 68% richiede almeno un respin, e la causa principale sono difetti logici e funzionali — esattamente il tipo di errori che gli LLM generano quando allucinano protocolli o fraintendono la concorrenza.

Una volta l'ho spiegato a un investitore, all'inizio della nostra raccolta fondi. Ascoltò pazientemente, poi disse: "Non puoi semplicemente usare GPT-4 con prompt migliori?"

Tirai fuori l'esempio del registro di pipeline. Gli mostrai il bug dell'assegnazione blocking. Gli mostrai che superava il linting, superava la simulazione, superava ogni controllo automatico offerto dagli strumenti Wrapper. Poi gli mostrai cosa avrebbe fatto nel silicio.

Non chiese più di prompt migliori.

E se potessi dimostrare che il codice è corretto invece di limitarti a testarlo?

È qui che la storia cambia. Perché la risposta al problema delle allucinazioni degli LLM non sono prompt migliori, modelli più grandi o più dati di addestramento. È un approccio fondamentalmente diverso alla verifica.

La verifica tradizionale si basa sulla simulazione — scrivi testbench, esegui milioni di cicli e controlli se il progetto fa ciò che ti aspetti. È come testare i freni di un'auto guidando intorno all'isolato mille volte. Se i freni non cedono, presumi che siano sicuri. Ma cosa succede se cedono solo quando piove, stai andando esattamente a 100 km/h e la radio è sintonizzata su una frequenza specifica? La simulazione può verificare solo gli scenari che testa esplicitamente. Tutto il resto è una preghiera.

La verifica formale non esegue affatto il progetto. Converte l'intero progetto in una formula matematica e usa i solver Satisfiability Modulo Theories (SMT) — strumenti come Z3 di Microsoft — per dimostrare in modo esaustivo che una proprietà vale sotto ogni possibile combinazione di input e stato interno. Ognuna singola. Non un campione. Non un'approssimazione statistica. Una dimostrazione matematica.

La simulazione chiede: "Funziona nei casi che ho testato?" La verifica formale chiede: "Esiste un qualche caso possibile in cui fallisce?" La differenza è la differenza tra la speranza e la dimostrazione.

Quando il solver restituisce "UNSAT" — non soddisfacibile — significa che non esiste alcun controesempio. La proprietà è garantita matematicamente. Quando restituisce "SAT", ti consegna una sequenza specifica di input che rompe il tuo progetto, fino all'esatto ciclo di clock.

La verifica formale esiste da decenni. Il motivo per cui non ha conquistato l'industria è che scrivere le proprietà formali — le SystemVerilog Assertions, o SVA — è notoriamente difficile. Richiede un insieme di competenze specializzate che la maggior parte dei team di progettazione non possiede. Le asserzioni sono il "contratto" per l'hardware: "Se request va alto, grant deve seguire entro N cicli." "Il dato letto dall'indirizzo X deve corrispondere all'ultimo dato scritto all'indirizzo X." "La pipeline non deve mai andare in deadlock." Scriverle correttamente è una forma d'arte, e non ci sono abbastanza professionisti in circolazione.

Ed è esattamente qui che l'AI diventa utile — non per scrivere il codice hardware, ma per scrivere la dimostrazione.

Il "Formal Sandwich" — come lo abbiamo davvero costruito

Ho passato mesi a discutere con il mio team sull'architettura giusta. Il dibattito fu acceso e, col senno di poi, chiarificatore. Una fazione voleva fare fine-tuning di un LLM finché non generasse Verilog corretto per impostazione predefinita. L'altra fazione — quella con cui alla fine mi sono schierato — sosteneva che la correttezza-tramite-addestramento fosse una fantasia. Non puoi eliminare l'allucinazione con l'addestramento. Puoi solo intercettarla.

Siamo approdati a ciò che chiamiamo il "Formal Sandwich" — un'architettura neuro-simbolica in cui l'LLM è il motore creativo e un solver di verifica formale è il critico inflessibile. Nessuno dei due funziona da solo. Insieme fanno qualcosa che nessuno dei due può fare in modo indipendente.

Ecco come funziona nella pratica. Un progettista fornisce una specifica — "Progetta un bridge APB-to-AXI" o persino uno screenshot di un diagramma di temporizzazione. Il nostro agente Spec Analyzer lo scompone in requisiti funzionali. Poi arriva l'innovazione chiave: invece di generare solo codice, l'LLM genera due artefatti simultaneamente.

L'artefatto A è l'implementazione RTL — il codice Verilog stesso. L'artefatto B è la specifica formale — un insieme di proprietà SVA derivate dagli stessi requisiti. Se la specifica dice "Grant deve seguire Request", l'LLM genera la macchina a stati e l'asserzione che dimostra che la macchina a stati fa ciò che dichiara.

Poi scateniamo il solver. Prende l'artefatto A e cerca di romperlo usando l'artefatto B. Prima, un controllo di vacuità — assicurandosi che le asserzioni non siano banalmente vere (una generazione "pigra" in cui la condizione di trigger non si attiva mai). Poi il bounded model checking, esplorando spazi di stato profondi — 50, 100 cicli di profondità — a caccia di deadlock, race condition, violazioni di protocollo.

Se il solver trova un bug, non si limita a segnalarlo. Produce una traccia di controesempio — una forma d'onda precisa che mostra esattamente come si manifesta il bug. Ed è qui che il loop si chiude: reimmettiamo quella traccia nell'LLM come prompt. "Il tuo progetto è fallito. Ecco la traccia: Ciclo 1, Reset si disattiva. Ciclo 2, Request va alto. Ciclo 10, Grant è ancora basso. Il grant non è mai arrivato. Correggi la macchina a stati."

L'LLM analizza la traccia, individua la transizione di stato mancante, riscrive il codice. Il solver controlla di nuovo. Questo loop si ripete automaticamente finché il progetto non è dimostrato corretto.

Ho scritto di questa architettura in modo molto più approfondito ne la versione interattiva della nostra ricerca, ma l'intuizione centrale è semplice: usiamo l'AI per scrivere la dimostrazione, e la matematica per controllare l'AI. Nessuno dei due si fida dell'altro. Entrambi rendono l'altro migliore.

I bug che mi hanno reso un credente

Sono diventato un vero credente in questo approccio non attraverso la teoria ma attraverso bug specifici che abbiamo intercettato e che nient'altro avrebbe trovato.

La comunità RISC-V open-source ha prodotto core di processore davvero eccellenti — Ibex (usato nel chip di sicurezza OpenTitan di Google), la piattaforma PULP dell'ETH di Zurigo. Sono progetti scrutinati con attenzione, con veri talenti ingegneristici alle spalle. E contengono comunque bug che solo la verifica formale può trovare.

Axiomise, una società di consulenza in verifica formale, ha trovato un bug nel core Ibex in cui una richiesta di debug in arrivo a un ciclo specifico durante un'istruzione di branch poteva causare il deadlock del core o l'esecuzione dell'istruzione sbagliata. Pensaci — un core critico per la sicurezza, rivisto da decine di ingegneri, e uno strumento formale ha trovato un bug che la simulazione aveva completamente mancato.

Nella piattaforma PULP è stato trovato un bug in cui l'interconnessione AXI poteva affamare indefinitamente un bus master sotto uno specifico pattern "busy" di interazioni tra AWVALID e AWREADY. Un classico fallimento di liveness — il sistema non va in crash, semplicemente smette di fare progressi. Non scriveresti mai un test diretto per quello specifico pattern di interazione. Ci sono troppi pattern possibili da enumerare.

Quando puntiamo Veriprajna su una Load-Store Unit RISC-V, genera automaticamente asserzioni per la conformità dell'interfaccia ("se valid è asserito, deve rimanere alto finché ready"), l'integrità dei dati ("il dato letto dall'indirizzo X corrisponde all'ultima scrittura all'indirizzo X") e il forward progress ("l'unità deve alla fine restituire una risposta"). Non sono ripensamenti aggiunti al codice a posteriori. Sono generate insieme al codice, dalla stessa specifica, e imposte prima che una sola riga di RTL lasci il nostro sistema.

Per l'analisi tecnica completa della nostra metodologia e del motore di verifica formale, consulta il nostro documento di ricerca dettagliato.

"Ma la verifica formale non è scalabile"

Le persone oppongono sempre resistenza su questo punto, e capisco perché. La verifica formale ha la reputazione di essere computazionalmente esplosiva — lo spazio degli stati di un SoC moderno è astronomicamente vasto, e gli approcci formali ingenui si strozzano su qualsiasi cosa più grande di un progetto giocattolo.

Ci abbiamo dedicato uno sforzo significativo. Il nostro sistema usa tecniche di astrazione automatizzate per rendere il formale trattabile su larga scala. Il black-boxing ci permette di verificare la logica di collegamento trattando grandi sotto-blocchi come RAM o ALU complesse come entità astratte con interfacce definite. I cut-point spezzano i percorsi di handshake valid/ready così da poter verificare il controllo di flusso indipendentemente dall'elaborazione dei dati. La riduzione per simmetria ci permette di dimostrare una proprietà per un canale di un router multi-porta e di indurla matematicamente per tutti gli N canali.

È risolto completamente? No. La fisica analogica presenterà sempre sfide che i metodi formali non possono toccare. Ma i bug logici — le race condition, i deadlock, le violazioni di protocollo — diventano matematicamente impossibili nel codice generato. E quelli sono i bug che causano i respin.

L'altra obiezione che sento riguarda la velocità. "Eseguire un solver formale non rallenta il processo di progettazione?" Sì, aggiunge costo computazionale. Ma io baratterei tempo di calcolo per certezza di pianificazione ogni singolo giorno. Un solver formale che gira per un'ora in più è infinitamente più economico di un respin di sei mesi.

La scomoda verità sui "chip progettati dall'AI"

C'è una narrazione che sta prendendo piede nel settore — che l'AI presto progetterà i chip end-to-end, che ci stiamo spostando dal Computer-Aided Design al Computer-Automated Design. Credo che quella narrazione sia direzionalmente corretta ma pericolosamente incompleta.

Stiamo costruendo verso flussi di lavoro agentici in cui agenti AI autonomi collaborano — un agente Architetto per il partizionamento ad alto livello, un RTL Coder per l'implementazione, un Verification Engineer per scrivere testbench e asserzioni, un Manager per orchestrare il flusso rispetto ai vincoli di potenza, prestazioni e area. Usiamo la retrieval-augmented generation (RAG) non solo per il codice ma per la conoscenza — recuperando regole di protocollo specifiche, vincoli dei process design kit e standard di codifica interni così che l'LLM generi codice conforme senza allucinare.

Ma nulla di tutto questo funziona — nulla di tutto ciò — senza una spina dorsale di verifica formale. Più l'AI diventa autonoma, più diventa critico che ogni output sia verificato matematicamente prima di scorrere a valle. Un agente AI che genera codice più velocemente ha valore solo se quel codice è corretto. Un agente AI che genera codice più velocemente e ne dimostra la correttezza? Quello è il futuro.

Il problema dell'industria dei semiconduttori non è che l'AI è troppo lenta a scrivere codice hardware. È che l'AI è troppo veloce a scrivere codice hardware sottilmente sbagliato.

Non siamo un copilot. Non siamo un chatbot. Siamo una fonderia di verifica formale che si dà il caso usi l'AI generativa come front end. La distinzione conta perché determina per cosa stai ottimizzando. I copilot ottimizzano per la velocità. Noi ottimizziamo per la correttezza. In un mondo in cui un singolo bug sfuggito costa 10 milioni di dollari in maschere e 50 milioni di dollari in fatturato perso, io so quale ottimizzazione sceglierei.

La scelta è già stata fatta

L'industria dei semiconduttori non può più permettersi l'approccio "genera e prega". La Regola del Dieci non è un suggerimento — è fisica ed economia che cospirano per punire chiunque immetta silicio non verificato. A 5nm e nodi inferiori, con set di maschere che si avvicinano ai 20 milioni di dollari, il margine di errore è crollato a zero.

Ogni settimana parlo con team di progettazione entusiasti di ciò che gli LLM possono fare per la loro produttività e terrorizzati da ciò che gli LLM potrebbero fare alla loro pianificazione di tape-out. Hanno ragione a provare entrambe le cose contemporaneamente. La tecnologia è davvero trasformativa. Ed è anche davvero pericolosa senza una rete di sicurezza.

Veriprajna è quella rete di sicurezza. Ti diamo la velocità dell'AI con la certezza della matematica. Non "probabilmente corretto". Non "ha passato la regressione". Dimostrato corretto, per ogni possibile input, ogni possibile stato, ogni possibile caso limite che una simulazione non penserebbe mai di testare.

La scelta che oggi ogni progettista di chip si trova davanti non è se usare l'AI. Quella nave è già salpata. La scelta è se usare un'AI in grado di dimostrare il proprio lavoro, o un'AI che si limita a sperare per il meglio.

Io so su quale scommetterei 10 milioni di dollari.