La promessa dei chiplet e il problema dell’integrazione

Suddividere un processore in più die consente di assegnare funzioni diverse a blocchi di silicio e, potenzialmente, di combinare processi produttivi. Questa modularità può evitare che un intero progetto dipenda da un unico die di grandi dimensioni, ma non elimina il lavoro d’integrazione: i chiplet devono comunicare all’interno del package rispettando limiti rigorosi di potenza, spazio e segnale. Lo standard UCIe — Universal Chiplet Interconnect Express — mira a offrire una base comune per la comunicazione die-to-die e per alcuni protocolli e funzioni associati. Da solo, non è un progetto di processore, un formato universale di package né la garanzia che due componenti di fornitori diversi funzionino insieme senza adattamenti.

La distinzione è importante quando si valuta un progetto modulare: «usare chiplet» descrive un’architettura; «usare UCIe» descrive un’interfaccia soggetta a una specifica concreta. Anche con un’interfaccia comune, le aziende devono decidere implementazione fisica, distribuzione dei segnali, alimentazione, gestione termica e strategia di test. Combinare processi o fornitori può offrire flessibilità, ma aggiunge anche lavoro di progettazione e convalida. La riduzione dei costi o il miglioramento delle prestazioni vanno quindi considerati possibilità dipendenti dal caso, non risultati automatici dell’adozione dello standard. UCIe fornisce un elemento comune del sistema, ma non sostituisce l’analisi di fattibilità dell’intero package.

Cosa definisce UCIe: interfaccia, protocolli e gestione

Il consorzio descrive UCIe come una specifica d’interconnessione a livello di package che comprende uno strato fisico I/O die-to-die, protocolli die-to-die e uno stack software che sfrutta PCI Express e Compute Express Link. In termini pratici, la specifica intende aiutare i team a concordare gli aspetti della connessione e del trasporto, anziché inventare da zero ogni collegamento tra die. La versione 1.1 ha aggiunto, tra le altre cose, meccanismi di affidabilità e attributi architetturali a supporto dei piani di test e conformità. La versione 2.0 ha introdotto un’architettura standardizzata di gestione e funzioni per test, debug e telemetria lungo il ciclo di vita del sistema in package.

Queste funzioni non equivalgono però a una soluzione completa di gestione o sicurezza per qualsiasi prodotto: il progetto deve integrarle e stabilire quali dati raccogliere, come controllare l’accesso e come comportarsi in caso di guasto. Il confine utile è distinguere ciò che definisce l’interfaccia comune da ciò che resta responsabilità del prodotto: policy, firmware, coerenza della memoria di sistema, sicurezza end-to-end e comportamento delle applicazioni non vengono risolti automaticamente da un collegamento UCIe. La documentazione pubblica dell’organizzazione chiarisce l’ambito della specifica; per realizzare un prodotto, i team devono consultare la revisione applicabile e verificare i diritti di proprietà intellettuale e le relative condizioni.

Versioni e velocità: cosa offre UCIe 3.0

UCIe 3.0 è stato annunciato il 5 agosto 2025. Secondo il consorzio, supporta velocità di 48 e 64 GT/s, rispetto al massimo di 32 GT/s indicato per UCIe 2.0, e introduce modifiche architetturali. La pagina delle specifiche evidenzia un canale laterale che può raggiungere 100 mm, trasmissione continua tramite mappature per Raw Mode, download anticipato del firmware attraverso il Management Transport Protocol, segnalazione laterale prioritaria e meccanismi di risparmio energetico, inclusa la ricalibrazione durante il funzionamento. Questi dati descrivono le capacità della revisione, non le prestazioni di un prodotto finito: larghezza di banda effettiva e consumo dipendono anche dall’implementazione e dal sistema fisico.

Le etichette UCIe-S e UCIe-A distinguono classi destinate a diverse configurazioni di package; UCIe 3.0 annuncia velocità di 48/64 GT/s per entrambe. UCIe 2.0 contempla inoltre UCIe-3D per il packaging tridimensionale e l’incollaggio ibrido. Non è utile ridurre queste etichette a un confronto semplicistico tra «lento ed economico» e «veloce e costoso»: la scelta dipende da regole di progettazione, materiali, geometria, disponibilità produttiva e obiettivi del prodotto. Le informazioni pubbliche del consorzio bastano a identificare le capacità della specifica, ma non a concludere quale velocità raggiungerà una combinazione specifica di die e package. Per saperlo occorre convalidare l’implementazione reale, non estrapolare dal nome della versione.

Interoperabilità: una specifica non è una certificazione completa

La compatibilità pratica ha più livelli. Due implementazioni devono rispettare la revisione e le opzioni comuni selezionate; inoltre, package, PHY, canali e strumenti di test devono essere compatibili con la configurazione concreta. Vanno concordate anche le funzioni che ciascun chiplet offre oltre il collegamento. Perciò l’annuncio di IP UCIe da parte di due fornitori non basta a garantire che qualsiasi coppia dei loro prodotti possa collegarsi direttamente: versione, protocolli abilitati, package, configurazione delle lane o requisiti di segnale possono differire. Lo standard riduce gli accordi da inventare, ma non elimina matrici di compatibilità e prove congiunte.

Esistono prove pubbliche d’integrazione tra organizzazioni: nel 2023 Intel ha riferito del test chip Pike Creek, che combinava un chiplet con IP UCIe prodotto in Intel 3 e un altro con IP Synopsys prodotto in TSMC N3E, collegati tramite EMIB. È una dimostrazione utile di una combinazione specifica, non la prova che ogni coppia di fornitori, processi e package sia interoperabile. Il consorzio pubblica materiali di conformità e descrive attributi di test nelle specifiche; le informazioni esaminate non consentono di affermare che esista un registro pubblico universale che certifichi prodotti completi come interoperabili in ogni scenario. In una valutazione d’acquisto, chiedete risultati di test e condizioni precise: revisione, PHY, protocolli, processo, package, temperatura e limiti di segnale misurati.

Ecosistema e prodotti: standard aperto, implementazioni diverse

L’adozione può assumere forme diverse. Fonderie, fornitori di IP, aziende di progettazione e produttori di package possono lavorare con UCIe in parti specifiche della loro offerta; ciò non significa che tutti propongano un chiplet pronto da combinare con qualsiasi altro. L’elenco pubblico dei membri e gli annunci del consorzio mostrano la partecipazione industriale, ma la disponibilità commerciale va confermata per nodo, processo, package e calendario. Analogamente, tecnologie d’integrazione come EMIB o SoIC descrivono approcci di packaging e non sono sinonimi di UCIe: una soluzione può abbinare una tecnologia fisica di package a un’interfaccia per chiplet, e ogni combinazione va verificata nei relativi annunci.

Un esempio annunciato di prodotto con UCIe è la serie Versal RF di AMD: l’azienda ha comunicato che determinati dispositivi includeranno interfacce UCIe 1.1 e che prevede chiplet di produzione nel quarto trimestre del 2027. Si tratta di un annuncio con una data futura rispetto a questo articolo; non va descritto come un prodotto già disponibile né come prova di compatibilità universale. NVIDIA, invece, presenta NVLink-C2C come una propria interconnessione chip-to-chip per connessioni coerenti ad alta larghezza di banda nei suoi sistemi. Queste opzioni mostrano che il settore può utilizzare interfacce proprietarie, aperte o combinazioni di tecnologie in funzione del prodotto. Non permettono di stilare una classifica equa delle prestazioni senza confrontare specifiche equivalenti e condizioni di misurazione.

Come valutare un progetto «UCIe-ready»

Per valutare una proposta, la prima domanda non è soltanto «è compatibile con UCIe?», ma «con quale revisione, classe PHY, protocollo e configurazione esatta?». Chiedete al fornitore di identificare la revisione implementata e le funzioni opzionali, e di spiegare i limiti della compatibilità con le versioni precedenti. Verificate poi che l’implementazione sia disponibile nel processo e nel package del progetto e che i modelli di canale e i flussi di progettazione coprano quella combinazione. Un annuncio di IP o di supporto agli strumenti è un segnale dell’ecosistema, non l’approvazione automatica del progetto finale né una promessa di prestazioni del prodotto.

Il secondo passaggio consiste nel trasformare l’interoperabilità in prove verificabili. Definite una matrice di interfacce e versioni per ogni chiplet; chiedete test del collegamento con le configurazioni e condizioni operative previste; concordate chi diagnostica i guasti e quali log saranno disponibili; includete test d’integrità del segnale, potenza, temperatura e recupero dagli errori. Infine, valutate separatamente l’integrazione funzionale: UCIe può facilitare il collegamento, ma non garantisce che i blocchi condividano semantica, coerenza o software senza ulteriore lavoro. In pratica, la specifica riduce una parte del rischio d’integrazione, ma non elimina la necessità di un’ingegneria congiunta. Il miglior segnale di preparazione non è un’etichetta promozionale, bensì una documentazione che colleghi un’implementazione concreta a test riproducibili e criteri di accettazione.