Il problema non è più far scrivere una netlist a un modello linguistico. È far diventare quella netlist un layout producibile. PICasso, il framework presentato dai ricercatori, sposta il confine proprio su questo passaggio: una pipeline che parte da specifiche in linguaggio naturale, le traduce in YAML e arriva alla generazione GDS, con verifica DRC/LVS, simulazione fotonica basata su SAX e iniezione di vincoli consapevoli del PDK.

La novità non è l’ennesimo LLM capace di generare codice, ma l’architettura che lo circonda. Per valutare il sistema senza illusioni, il team ha introdotto PIC-Set, un benchmark di 36 task parametrizzati che coprono primitive fotoniche di base e circuiti multi-componente. Su questo benchmark, diversi LLM allo stato dell’arte sono stati provati con metriche uniformi, tra cui Spec@k strutturale e funzionale, efficienza di ottimizzazione e robustezza sotto perturbazioni. I numeri raccontano un divario importante: PICasso raggiunge fino al 92,7% di Spec@3 strutturale e fino al 52% di Spec@3 funzionale sui circuiti ad alta complessità. In altre parole, la struttura può esserci, ma la funzione resta molto più difficile da centrare.

È qui che il lavoro offre una tesi chiara: il valore non sta nel modello generale, ma nel ciclo di vincoli fisici e feedback. Gli LLM da soli producono netlist fragili; dentro PICasso diventano un componente di un processo che verifica, simula e corregge. La riduzione della perdita di inserzione media da 4,98 dB a 3,25 dB, con un miglioramento di 1,74 dB guidato dalla simulazione, non è solo un dettaglio prestazionale: mostra che l’ottimizzazione fisica può essere automatizzata in modo misurabile, non solo sintattico.

Questo cambia gli incentivi per chi sviluppa strumenti di automazione per la fotonica. La competizione non si gioca più sulla dimensione del modello, ma sulla capacità di collegare il modello a un backend EDA affidabile, ai file PDK e ai controlli di producibilità. Un framework che riduce il tempo di progettazione rispetto ai flussi manuali basati su GUI rende il progettista più un supervisore di vincoli che un manipolatore diretto di geometrie. La conseguenza di secondo ordine è una pressione sui fornitori di strumenti: la barriera non è più il singolo modello, ma l’integrazione con i flussi di verifica e simulazione già adottati dalle fonderie.

Per chi valuta deployment on-premise, questo tipo di pipeline ha implicazioni precise. I PDK e i progetti di circuiti fotonici sono spesso proprietà intellettuale sensibile, coperta da accordi di riservatezza. Un flusso che genera layout e li valida fisicamente porta con sé la necessità di tenere sotto controllo i dati di progetto e i vincoli di processo. L’architettura modulare di PICasso, con generazione, verifica e simulazione, si presta a un’esecuzione self-hosted, dove il controllo sui dati e la prevedibilità dei costi di calcolo diventano variabili di progetto tanto quanto la qualità del layout. AI-RADAR offre framework analitici su /llm-onpremise per valutare questi trade-off, senza ridurre la scelta a una semplice preferenza tecnicica.

Il punto, per ora, è che la distanza tra generazione e produzione si accorcia solo quando il modello è costretto a confrontarsi con le leggi fisiche.