La promesa de los chiplets y el problema de la integración

Dividir un procesador en varios troqueles permite asignar funciones distintas a bloques de silicio y, potencialmente, combinar procesos de fabricación. Esa modularidad puede evitar que todo un diseño dependa de un solo troquel grande, pero no elimina el trabajo de integración: los chiplets tienen que comunicarse dentro del encapsulado con límites estrictos de energía, espacio y señal. El estándar UCIe —Universal Chiplet Interconnect Express— busca proporcionar una base común para esa comunicación die-to-die y para parte de los protocolos y funciones asociadas. No es, por sí solo, un diseño de procesador, un formato universal de encapsulado ni una garantía de que dos componentes de distintos proveedores funcionarán juntos sin adaptación.

La distinción importa para quienes evalúan un diseño modular: «usar chiplets» describe una arquitectura; «usar UCIe» describe una interfaz bajo una especificación concreta. Aun con una interfaz común, las empresas deben decidir la implementación física, la distribución de señales, el suministro eléctrico, la gestión térmica y la estrategia de prueba. Mezclar procesos o proveedores podría aportar flexibilidad, pero también añade trabajo de diseño y validación. Por eso conviene tratar la reducción de costes o la mejora de rendimiento como posibilidades dependientes del caso, no como resultados automáticos de adoptar el estándar. UCIe proporciona una pieza común del sistema, no reemplaza el análisis de viabilidad del paquete completo.

Qué define UCIe: interfaz, protocolos y administración

El consorcio describe UCIe como una especificación de interconexión a nivel de encapsulado que cubre la capa física de entrada/salida die-to-die, protocolos die-to-die y una pila de software que aprovecha PCI Express y Compute Express Link. En términos prácticos, la especificación pretende que los equipos acuerden aspectos de la conexión y del transporte, en lugar de inventar desde cero cada enlace entre troqueles. La versión 1.1 añadió, entre otros elementos, mecanismos de fiabilidad y atributos de arquitectura para apoyar planes de prueba y conformidad. La versión 2.0 incorporó una arquitectura estandarizada de gestión y funciones para prueba, depuración y telemetría a lo largo del ciclo de vida del sistema en paquete.

Estas funciones tampoco equivalen a una solución completa de gestión o seguridad para cualquier producto: el diseño debe integrarlas y decidir qué datos recoge, cómo se controla el acceso y cómo se comporta ante fallos. La frontera útil es separar lo que define la interfaz común de lo que sigue siendo responsabilidad del producto: políticas, firmware, coherencia de memoria del sistema, seguridad de extremo a extremo y comportamiento de las aplicaciones no quedan resueltos automáticamente por un enlace UCIe. La documentación pública de la organización es una guía sobre el alcance de la especificación; para implementar un producto, los equipos necesitan consultar la revisión aplicable y comprobar los derechos de propiedad intelectual y las condiciones correspondientes.

Versiones y tasas: qué aporta UCIe 3.0

UCIe 3.0 se anunció el 5 de agosto de 2025. Según el consorcio, admite tasas de 48 y 64 GT/s, frente al máximo de 32 GT/s citado para UCIe 2.0, e incorpora cambios de arquitectura. La página de especificaciones destaca un canal lateral que puede alcanzar 100 mm, transmisión continua mediante mapeos para Raw Mode, descarga temprana de firmware mediante Management Transport Protocol, señalización lateral prioritaria y mecanismos de ahorro de energía, incluida la recalibración durante el funcionamiento. Esos datos describen capacidades de la revisión, no el rendimiento de un producto terminado: el ancho de banda efectivo y el consumo dependen también de la implementación y del sistema físico.

Las etiquetas UCIe-S y UCIe-A diferencian clases orientadas a configuraciones de encapsulado distintas; UCIe 3.0 anuncia las tasas de 48/64 GT/s para ambas. UCIe 2.0, además, contempla UCIe-3D para empaquetado tridimensional y unión híbrida. No conviene convertir estas etiquetas en una comparación simplista de «lento y barato» frente a «rápido y caro»: la selección depende de las reglas de diseño, materiales, geometría, disponibilidad de fabricación y objetivos del producto. La información pública del consorcio es suficiente para identificar las capacidades de la especificación, pero no para concluir qué tasa alcanzará una combinación específica de troqueles y paquete. Ese dato requiere validación sobre la implementación real, no extrapolación del nombre de la versión.

Interoperabilidad: una especificación no es una certificación integral

La compatibilidad práctica tiene varias capas. Dos implementaciones deben ajustarse a la revisión y a las opciones comunes que hayan elegido; además, el paquete, los PHY, los canales y las herramientas de prueba deben ser compatibles con la configuración concreta. También deben acordarse las funciones que cada chiplet ofrece por encima del enlace. Por eso, que dos proveedores anuncien IP UCIe no basta para asegurar que cualquier par de sus productos pueda conectarse directamente: pueden diferir en versión, protocolos habilitados, encapsulado, configuración de lanes o requisitos de señal. El estándar reduce la cantidad de acuerdos que hay que inventar, pero no elimina las matrices de compatibilidad ni las pruebas conjuntas.

Hay evidencia pública de integración entre organizaciones: Intel informó en 2023 sobre el test chip Pike Creek, que combinó un chiplet con IP UCIe fabricado en Intel 3 y otro con IP de Synopsys fabricado en TSMC N3E, conectados mediante EMIB. Es una demostración útil de una combinación concreta, no una prueba de que todas las parejas de proveedores, procesos y paquetes sean interoperables. El consorcio publica materiales de conformidad y describe atributos de prueba en sus especificaciones; la evidencia consultada no permite afirmar que exista un registro público universal que certifique productos completos como interoperables en todos los escenarios. En una evaluación de compra, conviene pedir resultados de prueba y condiciones exactas: revisión, PHY, protocolos, proceso, paquete, temperatura y límites de señal medidos.

Ecosistema y productos: estándar abierto, implementaciones diferentes

La adopción puede tomar formas distintas. Foundries, proveedores de IP, empresas de diseño y fabricantes de encapsulados pueden trabajar con UCIe en partes concretas de su oferta; eso no significa que todos ofrezcan un chiplet listo para combinar con cualquier otro. La lista pública de miembros y los anuncios del consorcio muestran participación industrial, pero la disponibilidad comercial debe confirmarse por nodo, proceso, paquete y calendario. Asimismo, tecnologías de integración como EMIB o SoIC describen enfoques de empaquetado, no son sinónimos de UCIe: una solución puede combinar una tecnología física de encapsulado con una interfaz de chiplet, y esa combinación debe comprobarse en cada anuncio.

Un ejemplo anunciado de producto con UCIe es la serie Versal RF de AMD: la empresa comunicó que determinados dispositivos incluirán interfaces UCIe 1.1 y que espera chiplets de producción para el cuarto trimestre de 2027. Es un anuncio con fecha futura respecto a esta pieza; no debe describirse como producto ya disponible ni como prueba de compatibilidad universal. En contraste, NVIDIA presenta NVLink-C2C como una interconexión chip-to-chip propia para conexiones coherentes de alto ancho de banda dentro de sus sistemas. Estas opciones ilustran que la industria puede utilizar interfaces propietarias, abiertas o combinaciones de tecnologías según el producto. No permiten establecer una clasificación de rendimiento justa sin comparar especificaciones equivalentes y condiciones de medición.

Cómo evaluar un diseño «UCIe-ready»

Para evaluar una propuesta, la primera pregunta no es solo «¿es compatible con UCIe?», sino «¿con qué revisión, clase de PHY, protocolo y configuración exacta?». Solicita que el proveedor identifique la revisión implementada y las funciones opcionales, y que explique las limitaciones de compatibilidad con versiones anteriores. Después, verifica que la implementación esté disponible en el proceso y el encapsulado del proyecto, y que los modelos de canal y los flujos de diseño cubran esa combinación. Un anuncio de propiedad intelectual o de soporte de herramientas es una señal de ecosistema, no una aprobación automática del diseño final ni una promesa de rendimiento en el producto.

La segunda parte es convertir la interoperabilidad en evidencia verificable. Define una matriz de interfaces y versiones para cada chiplet; pide pruebas de enlace con las configuraciones y condiciones de uso previstas; acuerda quién diagnostica fallos y qué registros estarán disponibles; e incluye pruebas de integridad de señal, energía, temperatura y recuperación frente a errores. Por último, trata por separado la integración funcional: UCIe puede facilitar el enlace, pero no asegura que los bloques compartan semántica, coherencia o software sin trabajo adicional. En la práctica, la especificación reduce una parte del riesgo de integración; no hace desaparecer la necesidad de ingeniería conjunta. La mejor señal de preparación no es una etiqueta promocional, sino documentación que vincula una implementación concreta con pruebas reproducibles y criterios de aceptación.