Un’AI progetta un chip in 48 ore – ma è davvero possibile?

Quarantotto ore, un acceleratore da 4 mm², 1,46 milioni di celle standard, 0,277 MB di SRAM, una matrice INT4 MAC e oltre 8.700 token al secondo in simulazione: sono i dati dichiarati da Moonshot. L’esperimento di Kimi K3 misura soprattutto la portata di un ciclo automatico: generare una variante, passarla agli strumenti EDA, leggerne gli errori e riprovare. Scrivere Verilog è soltanto un tratto del percorso. Il progetto usa strumenti open source e la libreria Nangate 45 nm, basata su FreePDK45; quest’ultimo è un PDK generico destinato alla ricerca e alla sperimentazione EDA e non corrisponde a un processo fabbricabile. Queste condizioni definiscono un proof of concept utile, ma distante da un SoC commerciale pronto per la fabbrica.

Dal requisito al wafer ci sono sei lavori diversi

“Progettare un chip” comprime troppe attività in una sola frase. Il flusso parte da specifica e architettura, passa per RTL, sintesi, floorplanning, placement, clock tree e routing, quindi affronta verifica funzionale, sign-off fisico, fabbricazione e bring-up. Ogni passaggio possiede un criterio di uscita diverso. Un simulatore può confermare l’output di un blocco; l’analisi temporale statica verifica setup e hold; DRC e LVS confrontano layout, regole geometriche e netlist; le analisi di alimentazione cercano cadute IR ed elettromigrazione. Un GDS generato con successo risponde solo a una parte di queste domande.

La specifica stabilisce il bersaglio. Per un acceleratore AI occorre fissare modelli supportati, precisione numerica, formato dei pesi, comportamento degli overflow, gerarchia di memoria, banda, latenza, protocolli, reset, gestione degli errori e interazione con il software. “Esegui velocemente un nano model” lascia aperte decisioni capaci di cambiare l’intera architettura. Un requisito ambiguo produce molte implementazioni formalmente valide e una sola, forse, utile nel prodotto. L’intento progettuale deve diventare una raccolta di proprietà misurabili, con valori limite, eccezioni e priorità esplicite.

L’RTL traduce quelle proprietà in registri, logica combinatoria e trasferimenti scanditi dal clock. Qui un agente può creare moduli, correggere errori sintattici, aggiustare le larghezze dei bus e reagire ai test. Sintesi e implementazione fisica offrono un feedback strutturato: area, slack, congestione, fanout, potenza stimata e violazioni di progetto. OpenROAD organizza già un flusso autonomo da RTL a GDSII con floorplan, placement, clock-tree synthesis, routing e controlli finali. Il modello acquista valore quando usa questi segnali per iterare, perché il punteggio arriva da uno strumento deterministico anziché da una valutazione linguistica.

Il sign-off commerciale aggiunge il processo reale. Servono modelli qualificati della fonderia, corner di processo, tensione e temperatura, estrazione parassita, integrità del segnale, rete di alimentazione, testabilità, packaging e vincoli delle memorie compilate. Seguono wafer, resa, caratterizzazione, firmware, driver e validazione sulla scheda. Un race condition al reset, una transizione fra domini di clock o un picco termico può apparire quando molti blocchi e il software lavorano insieme. La simulazione dell’acceleratore resta una prova circoscritta al perimetro osservato.

Il vantaggio concreto è aumentare le iterazioni verificabili

Gli agenti rendono economico il ciclo ipotesi-esecuzione-misura. Un team può provare profondità diverse della pipeline, numero e larghezza dei MAC, banking della SRAM, dimensione dei buffer, strategie di clock gating e fattori di tiling. Ogni variante entra nello stesso flusso e restituisce frequenza, area, congestione e consumo stimato. Le soluzioni dominate vengono scartate; quelle sul fronte di Pareto meritano analisi più costose. Il guadagno nasce dal numero di alternative confrontabili, soprattutto nelle fasi iniziali, quando cambiare architettura costa ancora poco.

Le 48 ore di Kimi K3 vanno lette come throughput di progettazione. Un singolo layout che, secondo Moonshot, chiude il timing a 100 MHz conta meno della capacità di produrre, misurare e correggere molte versioni senza attendere ogni volta l’intervento manuale. Questo meccanismo può anticipare problemi di timing e congestione, far emergere un buffer sottodimensionato o rivelare che un aumento dei MAC resta inutile per carenza di banda. La metrica aziendale utile diventa quante ipotesi valide si riescono a eliminare prima del tape-out.

I benchmark crollano quando arriva la gerarchia

I test realistici ridimensionano la facilità apparente del Verilog. CVDP raccoglie 783 problemi scritti da ingegneri hardware in 13 categorie, tra generazione RTL, debug, allineamento alla specifica e verifica. I modelli valutati arrivano al 34% pass@1 nella generazione; i compiti agentici con riuso RTL e verifica risultano più difficili. Testbench, checker e assertion registrano tassi ancora inferiori, compresi casi in cui il SystemVerilog prodotto fallisce già sul piano sintattico. Generare il dispositivo sotto test è più facile che costruire un osservatore capace di giudicarlo.

RealBench alza il livello fino a IP open source strutturate. Con un testbench al 100% di line coverage e un formal checker, o1-preview raggiunge il 13,3% pass@1 sui compiti a livello di modulo e lo 0% a livello di sistema. ChipVerilog aggiunge 64 obiettivi tratti da OR1200, FPU double precision, MIPS-16, I2C e CORDIC; alcuni superano le mille righe e richiedono interazioni fra moduli. La difficoltà cresce nei design gerarchici e cross-module. Il salto dal blocco isolato al sistema riduce nettamente il successo misurato sui piccoli esercizi.

La verifica contiene un problema di indipendenza. Se lo stesso agente interpreta una frase ambigua, scrive l’RTL e genera il testbench, può ripetere il medesimo errore in tutti e tre gli artefatti. Il test passa perché implementazione e controllo condividono un’interpretazione sbagliata. Servono golden model, assertion, coverage plan e proprietà formali ricavati da requisiti tracciabili, con revisioni separate per gli aspetti critici. Un semaforo verde vale quanto l’oracolo che lo ha acceso.

Come cambia il lavoro di un team hardware

Il progettista guadagna leva sulle decisioni ad alto costo. Gli agenti possono preparare varianti, script, test di regressione e report PPA; gli ingegneri concentrano il tempo sulla specifica, sulle interfacce, sui corner e sulle anomalie che attraversano più sottosistemi. Prima di occupare licenze EDA proprietarie, code di emulazione o turni di silicio, il gruppo arriva con meno candidati e prove più mature. La produttività cresce attraverso una maggiore profondità di esplorazione per ogni ora umana.

Anche i ruoli si spostano verso gli asset verificabili. Una specifica in prosa perde valore se ogni modifica richiede una nuova interpretazione. Una specifica collegata a test, assertion, modelli di riferimento, coverage e risultati di regressione alimenta sia gli agenti sia la revisione umana. Lo storico delle decisioni consente di capire quale requisito ha generato un modulo, quale test lo protegge e quale variazione PPA ha motivato una scelta. La tracciabilità riduce il rischio di accettare una soluzione ottimizzata per il bersaglio sbagliato.

Le cinque domande da fare alla prossima demo

Una dichiarazione di “chip progettato dall’IA” si valuta con cinque controlli. Il risultato vive soltanto in simulazione oppure esiste silicio misurato? Il PDK è dimostrativo o qualificato per una fonderia? La verifica è indipendente dalla generazione RTL? Quali coverage, assertion e test di sistema sono stati superati? Esistono sign-off, dati di potenza, resa e bring-up? Le risposte collocano subito il risultato fra esercizio RTL, layout sperimentale, tape-out verificato e prodotto industriale.

Kimi K3 indica una direzione concreta per il mercato EDA. Il vantaggio competitivo andrà alle aziende capaci di chiudere rapidamente il ciclo fra requisito, implementazione, misura e correzione. Il modello conta, insieme alla qualità dei dati di progetto e alla disciplina con cui specifiche, test e assertion vengono mantenuti coerenti. Finché l’intento resta implicito, la verifica conserva il ruolo di collo di bottiglia. La lezione operativa è investire nel ciclo di verifica: è lì che più iterazioni diventano decisioni affidabili.