Il verificatore formale diceva "dimostrata". Il chip era comunque difettoso.

La prima volta che uno dei nostri strumenti mi ha mentito, lo ha fatto con garbo. Il motore formale ha restituito un segno di spunta verde. Ogni proprietà che gli avevamo chiesto di dimostrare risultava dimostrata. La libreria di asserzioni sembrava completa. Sulla carta, il progetto era verificato.

Ci sono voluti due giorni per capire che il certificato era privo di valore — e che tutto ciò che avevo dato per scontato sulla verifica AI dei semiconduttori ci stava proteggendo dal guasto sbagliato.

Le proprietà erano state generate da un large language model che avevamo avvolto attorno al motore formale — esattamente il tipo di demo agentica e brillante per la progettazione di chip che tutti stavano costruendo. E il motore le aveva dimostrate in millisecondi, il che avrebbe dovuto essere il segnale rivelatore. Erano dimostrate perché le condizioni che le avrebbero messe alla prova non si verificavano mai. Una proprietà che dice "ogni richiesta prima o poi ottiene una concessione" è banalmente vera se la richiesta non può mai avvenire. Il solver non aveva torto. Rispondeva alla domanda che avevamo posto per sbaglio, e la domanda era vuota. Quello è il momento in cui ho capito da cosa devono davvero difendersi queste pipeline di verifica AI — e perché quasi nessuno di quelli che ne vendevano una si difendeva dalla cosa giusta.

Voglio raccontarti cosa abbiamo scoperto, perché le classi di bug che uccidono i chip moderni non sono quelle che l'industria pubblicizza di saper individuare. Costruiamo pipeline di verifica personalizzate per i team di chip fabless — modelli open-weight messi a punto e avvolti attorno al motore formale che un team già possiede, eseguiti interamente sul loro hardware — e l'intero approccio è nato dall'aver sbagliato questo per primo. Puoi vederne la forma su veriprajna.com/solutions/semiconductor-ai-verification. Ma l'approccio ha senso solo dopo aver visto fallire un progetto "promosso".

Un numero che dovrebbe spaventare ogni CFO fabless

Una statistica inquadra l'intero problema. Lo studio 2024 sulla Functional Verification del Wilson Research Group / Siemens EDA — il benchmark più longevo del settore — ha fissato il successo al primo silicio al 14%. Il valore più basso in vent'anni di rilevazioni. Nel 2020 quel numero era intorno al 32%. È più che dimezzato in quattro anni.

Non è una storia di ingegneri che diventano pigri. È una storia di complessità che supera gli strumenti, e di una specifica che muta più velocemente del testbench che le corre dietro. Lo stesso studio ha rilevato che circa il 70% dei respin è causato da errori legati a modifiche della specifica — non da puri bug logici.

Il successo al primo silicio non è calato perché i team di chip sono peggiorati. È calato perché la specifica ora si muove più velocemente di quanto la verifica riesca a chiuderla.

Sono rimasto a lungo su quel numero del 70%, perché mette silenziosamente sotto accusa molte proposte di "AI per la progettazione di chip". Se la maggior parte dei respin nasce dalla deriva della specifica, allora uno strumento che individua solo i bug logici affronta una fetta del problema e la chiama torta intera.

E il costo di sbagliare è brutale in un modo che chi lavora nel software sottovaluta. Un set di maschere a 5nm costa 10-20 milioni di dollari. A 3nm ti avvicini ai 40 milioni di dollari, con oltre settanta strati di maschera, di cui più di venti strati EUV. Un tape-out completo a 2nm ora costa nell'ordine dei 725 milioni di dollari tutto compreso. Quando qualcosa sfugge, un respin è uno slittamento di programma di 3-6 mesi sopra il conto delle maschere. Su una finestra di prodotto di diciotto mesi, uno slittamento di sei mesi può cancellare metà dei ricavi che il chip genera in tutta la sua vita. Il CFO non vede la verifica come un centro di costo. La vede come un'assicurazione contro un singolo errore da otto cifre.

Come fa davvero un LLM ad allucinare nell'hardware?

Il tuo team sta già usando gli LLM su Verilog. Non fingerò il contrario, e non dovrebbe farlo nessuno che venda a te. Il campo di ricerca ora è reale — i paper sugli LLM che scrivono Verilog sono passati da uno nel 2020 a sessantaquattro nel 2025. Sui problemi più difficili del benchmark VerilogEval, i modelli di classe GPT-4 raggiungono circa il 43% di correttezza funzionale. Utile. Non affidabile.

La domanda interessante non è se i modelli aiutano. È come falliscono, perché le modalità di guasto non assomigliano ai guasti che gli ingegneri del software sono addestrati a temere. Dopo abbastanza notti insonni passate a fissare il perché di un RTL "apparentemente corretto" che andava storto, ho iniziato a classificare i guasti in cinque classi.

La prima è quella innocua. Sintattica allucinazione — codice che semplicemente non compila. Verilator o il front-end di sintesi la individua in pochi secondi. Tutti sanno già come gestirla, ed è la classe che le persone indicano quando vogliono sostenere che il problema è risolto.

La seconda è dove inizia a fare male. Semantica allucinazione, e il caso da manuale è l'assegnazione bloccante contro quella non bloccante. Un modello addestrato su Python e C legge Verilog come se le istruzioni si eseguissero dall'alto verso il basso. Così scrive un'assegnazione bloccante — un semplice = — dentro un blocco always_ff sincronizzato al clock dove il linguaggio richiede l'assegnazione non bloccante <=. Il progettista voleva una pipeline a due cicli. Con le assegnazioni bloccanti, il secondo stadio legge il valore nuovo del primo, non quello vecchio, e il silicio spedisce un bypass a un ciclo invece di una pipeline. Alcuni simulatori pianificano gli eventi in un ordine che nasconde del tutto la race. Simula bene. Sintetizza nella macchina sbagliata.

La terza classe è quella che mi ha insegnato a tenere la specifica AMBA aperta su un secondo monitor. Protocollo allucinazione. Il codice compila, supera il novanta percento dei test diretti, e poi asserisce un segnale di write-data-valid prima che lo slave sia pronto ad accettare l'indirizzo — una violazione dell'handshake AXI. Oppure tiene alto un segnale valid mentre cambia i dati sotto di esso. Oppure fa scattare una sotto-clausola sepolta a pagina 84 della specifica del bus che nessun essere umano ha memorizzato. Il chip funziona perfettamente sul tuo banco di test interno e si blocca nell'istante in cui viene collegato a un controller di memoria di terze parti. Non puoi risolverlo a forza bruta con più cicli di simulazione. Lo individui con librerie di asserzioni pre-verificate scritte per ciascun protocollo.

La quarta classe è quella che ci ha ingannato, ed è quella pericolosa.

Perché "dimostrata" è la parola più pericolosa in un report di verifica?

Vacuità allucinazione. Il modello genera un'asserzione SystemVerilog. Il motore formale la dimostra. Tu spedisci. E la proprietà era banalmente vera perché il suo antecedente — la parte "se" — non è mai diventato vero in primo luogo.

Immagina una proprietà di un arbitro: se viene sollevata una richiesta, una concessione deve seguire entro un certo numero di cicli. Ora supponi che lo stesso modello, cercando di essere d'aiuto, abbia anche scritto un'assunzione che forza a basso il segnale di richiesta. Il motore formale dimostra diligentemente la proprietà della concessione in millisecondi, perché non c'è alcuna richiesta a violarla mai. L'arbitro reale sottostante potrebbe essere completamente rotto. Il certificato dice "dimostrata". È privo di valore.

Una prova formale che gira in millisecondi non è veloce. È sospetta. Il motore potrebbe non aver dimostrato proprio nulla.

Non è un rischio marginale. Siemens pubblica avvertimenti sulle prove vacue dal 2017, e il settore continua a spedire flussi senza controllo automatico della vacuità. Quando dico alla gente che un flusso di verifica formale senza rilevamento della vacuità è peggiore di nessuna verifica formale, pensano che stia esagerando. Non è così. Nessuna verifica ti lascia opportunamente spaventato. Un "dimostrata" vacuo ti lascia fiducioso e in errore, con un blocco approvato che va verso il tape-out. È il guasto che ha quasi raggiunto la produzione nel nostro primo prototipo, e ha cambiato per sempre ciò che costruiamo.

La quinta classe è quella che la simulazione strutturalmente non può vedere. Attraversamento dei domini di clock punti ciechi. Un LLM legge i nomi dei segnali; non percepisce i domini di clock. Così collega un segnale da un dominio CPU a 2 GHz direttamente in un flop di un dominio periferico a 400 MHz, saltando il sincronizzatore a doppio flop che previene la metastabilità. La simulazione RTL non modella la metastabilità — quindi la regressione passa, ogni volta, e il silicio va in stallo sul campo. Ecco perché i bug CDC divorano i set di maschere. È anche il motivo per cui Accellera ha aperto uno standard di interoperabilità CDC/RDC nel 2024: la frammentazione tra gli strumenti CDC commerciali era diventata abbastanza grave da rompere il sign-off.

Le classi dalla seconda alla quinta condividono una proprietà terrificante: passano la simulazione. Emergono solo nel silicio. È il sottoinsieme di bug che ancora fa saltare i tape-out, ed è precisamente il sottoinsieme che una proposta del tipo "individua i bug logici" lascia sul tavolo.

Il muro di fornitori davanti a cui un team di chip si trova davvero

Quando ho cercato un aiuto genuinamente indipendente per un tape-out, mi sono ritrovato con meno opzioni di quante ne avessi qualche anno prima — e non è nostalgia, è la struttura del mercato. I tre fornitori EDA tra cui un responsabile della verifica di progetto può davvero scegliere — Synopsys, Cadence, Siemens — sono passati da meno del 75% del mercato di un decennio fa a oltre l'85% oggi. Aggiungi l'acquisizione di Ansys da 35 miliardi di dollari di Synopsys e i primi quattro controllano circa il 90%. Il campo in cui fa acquisti una startup fabless si è ristretto, non allargato, esattamente mentre il problema diventava più difficile.

E gli operatori affermati non stanno fermi sull'AI. Synopsys ha rilasciato AgentEngineer a marzo 2026, un flusso di verifica agentico che rivendica una produttività da due a cinque volte superiore, e si appoggia su VC Formal — lo stack agentico di fornitore più credibile che abbia valutato. Cadence ha annunciato il suo ChipStack AI Super Agent a febbraio 2026 e fa girare Cerebrus AI Studio per l'implementazione guidata dal reinforcement learning, con JasperGold che rimane il motore formale gold-standard con cui tutti gli altri vengono misurati. Lo dico senza esitazioni: JasperGold e VC Formal sono genuinamente eccellenti. Chiunque apra una proposta screditandoli ti ha appena detto che non ha mai portato a termine un vero tape-out.

Il problema è il prezzo e l'atteggiamento. La linea base storica di JasperGold si aggirava intorno ai 225.000 dollari più 45.000 dollari per postazione — accettabile per una grande azienda fabless, fuori portata per le startup RISC-V e di acceleratori AI in fase iniziale che fanno il lavoro più interessante. E le più recenti funzionalità AI degli operatori affermati sono cloud-first, il che si scontra frontalmente con l'unico requisito su cui questi clienti non cederanno. Tra poco ci torniamo.

Poi c'è l'ondata di startup, ed è rumorosa. All'ultimo DAC e DVCon, un responsabile della verifica con cui lavoro si era visto proporre otto diverse aziende di "AI agentica per la progettazione di chip" in un solo trimestre. ChipAgents ha raccolto 74 milioni di dollari a inizio 2026 e rivendica una produttività di progettazione e verifica dieci volte superiore. Normal Computing ha raccolto 50 milioni di dollari guidati dal Catalyst Fund di Samsung, costruendo l'auto-formalizzazione — LLM che traducono l'intento dell'ingegnere direttamente in proprietà formali e le dimostrano — e afferma che metà delle prime dieci aziende di progettazione di semiconduttori al mondo la sta usando. Ce ne sono altre: MooresLabAI che genera interi testbench, Bronco sull'analisi di regressione, Silimate sulla predizione di potenza-prestazioni-area.

Alcune di queste sono reali. Nessuna di esse risolve il vero problema del cliente, ovvero che ora ha comprato tre di questi strumenti puntuali e non ha idea di come farli funzionare insieme all'interno del flusso di sign-off di cui già si fida.

La storia del posizionamento basato sul reinforcement learning che nessuno vuole dire ad alta voce

C'è una tentazione parallela nella progettazione di chip oltre la verifica: usare il reinforcement learning per fare il floorplanning fisico — decidere dove si collocano i grandi blocchi sul die. È seducente, e il risultato più citato è contestato in un modo che la maggior parte delle proposte convenientemente salta.

Il paper di Google su Nature del 2020 sosteneva che l'RL batte il simulated annealing per il posizionamento delle macro, ed è stato usato in silicio reale — generazioni di TPU sono state spedite con esso. Ma nel 2023 Nature ha aggiunto una nota editoriale dopo che erano state sollevate preoccupazioni metodologiche. Igor Markov, ora in Synopsys, ha pubblicato una critica riga per riga il cui confronto di punta è difficile da ignorare: l'approccio RL ha impiegato 32,31 ore, una base di simulated annealing ottimizzata ha impiegato 12,5 ore, e uno strumento commerciale Cadence ha completato lo stesso lavoro in 0,05 ore. DeepMind ha risposto con un paper intitolato "That Chip Has Sailed". Anni dopo, nessuna replica esterna indipendente ha confermato le rivendicazioni originali, e sia la critica sia la replica sono ancora aperte.

Sollevo la questione per via di cosa succede quando un consulente propone il posizionamento RL a un vero team formale e finge che la controversia non esista. La fiutano entro dieci minuti, e hai perso la sala. La posizione onesta è che esistono nicchie genuine — floorplanning termico-consapevole per chiplet e 3D-IC, layout analogico, ottimizzazione di IP RISC-V su strumenti aperti — dove un approccio ibrido si guadagna il pane. Un assalto frontale ai motori di posizionamento degli operatori affermati no. Conoscere la differenza, e dirla ad alta voce, è tutto il lavoro.

Cosa è cambiato dopo che il nostro strumento ci ha ingannato

Ecco dunque dove ci ha portato il disastro della prova vacua. Abbiamo smesso di provare a costruire un'AI migliore che scrive Verilog, perché è una corsa affollata con otto concorrenti finanziati, e abbiamo iniziato a costruire la cosa che nessuno di loro vende: lo strato di integrazione neutrale rispetto al fornitore che rende affidabili gli strumenti esistenti di un team.

Concretamente, questo significa alcune decisioni, ognuna imposta da un guasto che avevamo visto. Mettiamo a punto un modello open-weight — Qwen Coder, Llama, quale che sia adatto — sul proprio corpus RTL del cliente, le sue specifiche, la sua storia passata di bug, perché un modello che non ha visto il tuo stile interno ci allucina contro. Lo avvolgiamo attorno a qualsiasi motore formale il team già possieda: JasperGold, VC Formal, Questa Formal, o l'open-source SymbiYosys. Non chiediamo mai loro di strappar via lo strumento gold-standard di cui già si fidano. E ogni proprietà che il modello propone passa attraverso controlli di vacuità e copertura prima che a chiunque sia permesso di leggere la parola "dimostrata" — perché abbiamo imparato nel modo costoso che una prova non sorvegliata è teatro.

Le librerie di asserzioni pre-verificate contano tanto quanto il modello. Per un core RISC-V, l'harness formale viene fornito con i controlli di conformità AXI4, AHB e TileLink, le asserzioni sui pipeline-hazard, lo scoreboarding load-store, le proprietà di correttezza dell'unità di debug — le cose che individuano le allucinazioni di protocollo e semantiche prima che lo faccia il silicio. Non è speculativo. La società di consulenza formale Axiomise ha trovato oltre 65 bug in Ibex, il core RISC-V aperto all'interno di OpenTitan di Google, inclusi bug di istruzioni di branch nell'unità di debug che solo la verifica formale poteva individuare. La verifica formale funziona su RISC-V. La cosa rara non è il metodo; è un team che sa come brandirlo.

La vera opportunità qui non è mai stata un modello Verilog più intelligente. Era un harness onesto avvolto attorno ai costosi strumenti di cui un team già si fida.

Perché non lo esegui semplicemente nel cloud?

La gente me lo chiede di continuo, e la risposta è la stessa ragione per cui ogni startup di EDA-AI cloud-first è morta all'arrivo con i clienti che mi interessano: l'RTL è il gioiello della corona, e non lascia l'edificio.

Il codice register-transfer-level di un'azienda fabless è l'azienda. I clienti della difesa e dell'aerospazio hanno bisogno che sia air-gapped, a volte in una struttura sicura. I team fabless commerciali vogliono l'on-premise, il virtual-private-cloud come minimo assoluto. Quindi eseguiamo tutto sull'hardware del cliente — vLLM o inferenza simile sul loro cluster H100 o H200 esistente, retrieval locale sul loro stesso corpus, senza che l'RTL attraversi mai il confine di rete. Le più recenti funzionalità agentiche degli operatori affermati sono cloud-first; è un vantaggio per loro e un ostacolo insormontabile per un team di chip sensibile all'IP. La più grande opportunità che vedo non è affatto un problema di algoritmi. È un problema di distribuzione e integrazione che le persone con i migliori algoritmi hanno deciso di non risolvere.

L'altra domanda arriva dai team automotive, ed è quella che decide tutto per loro. Spedisci un chip in un'auto ad ASIL C o D — i livelli di integrità della sicurezza in cui la ISO 26262 smette di limitarsi a suggerire la verifica formale e inizia a imporla — e lo strumento stesso deve portare un pacchetto di qualificazione TCL2 o TCL3. I motori centrali degli operatori affermati hanno quella certificazione di terze parti; uno strumento AI nuovissimo no. Ho visto uno strumento genuinamente migliore messo in panchina in un programma automotive per esattamente questa ragione: nessun pacchetto di qualificazione, nessun posto nel flusso di sign-off, fine della conversazione. Quindi non proviamo a essere lo strumento qualificato. Aiutiamo i team a far girare l'assistenza AI accanto ai motori qualificati degli operatori affermati senza rompere la catena di qualificazione — perché nell'automotive, uno strumento tecnicamente superiore che non può sopravvivere a un audit non vale nulla.

Il certificato non è il chip

Continuo a tornare a quei due giorni passati a fidarci di un segno di spunta verde che non significava nulla. La lezione non era "gli LLM sono cattivi con Verilog". Migliorano ogni trimestre. La lezione era che nell'hardware, il divario tra sembra verificato e è verificato si misura in set di maschere da otto cifre e slittamenti di sei mesi — e gli strumenti che si precipitano in questo spazio in gran parte fanno a gara per rendere più veloce la parte "sembra verificato".

Su un set di maschere da 10 milioni di dollari, un "dimostrata" che non puoi ricondurre a una prova non vacua, eseguito su hardware che controlli, contro asserzioni scritte da qualcuno che ha letto pagina 84 della specifica — quella non è verifica. È una speranza con una buona resa scenica. Se vuoi vedere come distinguiamo la differenza, è tutto esposto su veriprajna.com/solutions/semiconductor-ai-verification.

Al chip non importa cosa dice il report. Fa solo ciò che il silicio è stato effettivamente costruito per fare. La verifica è la disciplina di rendere quelle due cose uguali — e nel momento in cui un'AI ti dice che sono uguali in millisecondi, quello è esattamente il momento in cui dovresti allungare la mano verso la specifica.