Resumo

  • O UCIe estabelece regras comuns para a camada física, o adaptador, os protocolos e o gerenciamento dos links entre dies, mas não abrange as funções dos chiplets, o projeto do encapsulamento nem as responsabilidades dos fornecedores.
  • Da versão 1.0 à 3.0, foram acrescentados encapsulamentos de baixo custo, monitoramento automotivo, suporte a 3D, recursos de gerenciamento e operação a 64 GT/s.
  • Seu valor de mercado será demonstrado por perfis de conformidade reproduzíveis, produtos multivendor fabricados em volume com suporte contínuo e uma divisão clara de responsabilidades em caso de falha.

A versão de 64 GT/s transformou a corrida por velocidade em um problema de projeto de sistemas

Em 5 de agosto de 2025, um consórcio de padronização criado publicamente havia pouco mais de três anos anunciou sua terceira grande especificação. O Universal Chiplet Interconnect Express, conhecido como UCIe, acrescentou 48 e 64 GT/s às classes de canais para encapsulamentos padrão e avançados. Também ampliou o alcance do caminho lateral de baixa velocidade, estendeu a transmissão raw contínua e reforçou os controles de gerenciamento. A velocidade ganhou as manchetes, mas o aspecto mais importante foi a tentativa de tratar um encapsulamento composto por vários dies projetados de forma independente como um único sistema gerenciável.

Essa distinção importa. Um link de alta velocidade é apenas um componente de um produto baseado em chiplets. O comprador precisa conhecer a função, o consumo de energia e o método de resfriamento de cada die, o software que o detecta, o processo de atualização de firmware, o comportamento diante da falha de um componente e qual fornecedor assume a garantia. O UCIe fornece regras comuns para mover informações entre dies e gerenciar parte do entorno dessa comunicação. Ele não transforma um conjunto de silícios sem relação entre si em um processador completo.

O consórcio promove um “ecossistema aberto de chiplets”. É uma meta útil, mas pode ser confundida com a descrição de um mercado já existente. Os materiais públicos consultados para este artigo não incluíam um levantamento independente abrangente de encapsulamentos UCIe multivendor em comercialização, uma lista universal de produtos certificados nem um catálogo no qual projetistas pudessem escolher dies intercambiáveis. O que foi possível confirmar foram especificações, atividades de membros, formação sobre implementação e demonstrações. Tudo isso é necessário, mas não equivale a evidências de compras repetíveis e fabricação em volume.

A questão central, portanto, não é se os chiplets serão importantes. Eles já são importantes como forma de dividir sistemas complexos. A questão é até que ponto um link compartilhado pode criar modularidade enquanto o encapsulamento ao redor continua sendo um projeto específico e estreitamente integrado. O UCIe pode se tornar uma linguagem comum usada na fronteira entre dies e, ainda assim, deixar proprietária grande parte do sistema físico e das relações comerciais. Por isso, a interface deve ser avaliada não como uma única promessa de “intercambiabilidade”, mas como uma sequência de transferências de responsabilidade.

O termo intercambiabilidade reúne vários testes diferentes. O primeiro é a compatibilidade elétrica: transceptores e canais do encapsulamento conseguem estabelecer um link usando o mesmo perfil físico? O segundo é o protocolo: as duas extremidades entendem o mesmo mapeamento de PCIe, CXL ou raw? O terceiro é operacional: o die pode ser descoberto, testado, monitorado e atualizado por recursos de gerenciamento compatíveis? O quarto envolve função e software: o chiplet oferece um comportamento utilizável pelo firmware, pelos drivers e pelos aplicativos?

O quinto é comercial: o componente pode ser adquirido com evidências de teste, volume, suporte e garantia suficientes para ser incorporado a um produto?

O UCIe trata diretamente dos dois primeiros aspectos e amplia gradualmente seu alcance sobre o terceiro. Ele pode reduzir a dependência de projetos privados entre apenas duas empresas para negociação elétrica, transporte de protocolos e transferências de gerenciamento. A quarta camada pertence em parte ao PCIe, ao CXL e ao software específico do produto; a quinta pertence aos fornecedores, foundries, empresas de encapsulamento e compradores.

Confundir essas camadas gera dois erros opostos. Um é rejeitar o padrão porque ele não cria sozinho um mercado completo. Isso ignora o valor de remover barreiras físicas e de protocolo recorrentes. O outro é concluir que o mercado está pronto porque dois dies conseguiram estabelecer um link em conformidade. Isso ignora as decisões restantes necessárias para transformar o link em um sistema que possa ser mantido.

Uma avaliação especializada deve indicar qual promessa foi demonstrada. Uma demonstração de interface física oferece menos evidências do que uma conexão de protocolo; esta, por sua vez, oferece menos do que um encapsulamento gerenciável durante todo o ciclo de vida. Mesmo um encapsulamento gerenciável comprova menos do que um componente substituível sem novo software ou novos contratos. Essa hierarquia não é uma crítica ao UCIe, mas a forma mais clara de mostrar o que o consórcio administra e o que deixa para o mercado.

A visão em cinco camadas também explica por que um progresso real pode não se parecer com uma aquisição plug-and-play. Mesmo que atualizações da especificação fortaleçam as três primeiras camadas, a quarta e a quinta podem amadurecer lentamente. O mercado de chiplets não chegará com um único anúncio. Ele será construído à medida que transferências de responsabilidade mais restritas se tornarem repetíveis e atingirem um nível confiável.

Os chiplets transferem a complexidade do interior do silício para o encapsulamento

Um chip monolítico reúne as funções do sistema em uma única grande peça de silício. Isso pode simplificar a comunicação entre funções, mas obriga todas elas a seguir um único plano de fabricação. À medida que aumentam as pressões de projeto, máscaras e rendimento nos nós avançados, colocar todos os blocos em um grande die fica mais caro e difícil. Os chiplets permitem separar computação, memória, I/O, funções analógicas, segurança e aceleradores, fabricar cada parte no processo mais adequado e combiná-las em um sistema em encapsulamento.

A divisão não elimina a complexidade. Ela transfere parte dela do die para o encapsulamento. Cada fronteira exige sinalização, relógio, tratamento de erros, alimentação elétrica, projeto térmico, cobertura de testes e um comportamento visível ao software. Um grande die monolítico pode perder rendimento à medida que sua área aumenta, mas um encapsulamento com vários dies também pode perder todo o seu valor se um die integrado estiver defeituoso, próximo do limite ou tiver sido montado incorretamente. Em troca da opção de combinar nós de processo e reutilizar blocos, o projetista do sistema assume novas dependências no nível do encapsulamento.

Por isso, a palavra “módulo” exige cautela. Uma placa de circuito impresso é modular também porque os componentes têm formatos padronizados, práticas elétricas comuns, funções detectáveis e condições comerciais maduras. Fornecedores publicam folhas de dados, distribuidores mantêm estoque e integradores entendem soquetes, conectores e limites de falha. Chiplets dentro de encapsulamentos avançados operam em um ambiente físico muito mais exigente e com menor margem para erro.

Eles compartilham energia, calor, gerenciamento e canais de alta velocidade com dies adjacentes e, depois da montagem, talvez não possam ser inspecionados ou substituídos como componentes de uma placa.

O UCIe trata de uma das fronteiras recorrentes mais difíceis: o link entre dies de curta distância e alta densidade. Padronizar esse link pode reduzir projetos de interface duplicados e oferecer um objetivo comum a ferramentas, fornecedores de IP e empresas de sistemas. Os demais problemas de integração não desaparecem. O valor do padrão está em reduzir a engenharia específica entre duas partes, não em transformar o encapsulamento em uma coleção pouco integrada de componentes independentes.

Sem uma interface comum, as empresas podem dividir um sistema em vários dies e manter a integração vertical. Projetar o link entre dies segundo premissas elétricas, protocolos, processos de encapsulamento e fluxos de teste próprios de uma empresa facilita a otimização de latência, energia e área para um produto específico. Em contrapartida, outro fornecedor só consegue fornecer um die depois de aprender e implementar o acordo privado.

A armadilha dos links proprietários é econômica, além de técnica. Mesmo que uma empresa de sistemas chame seu projeto de arquitetura de chiplets, isso não significa que módulos úteis estejam disponíveis externamente. Pode haver reutilização entre gerações de produtos da própria empresa, embora o sistema pareça um encapsulamento fechado para o mercado externo. Ele é modular dentro da fronteira corporativa e indivisível fora dela.

Os fundadores do UCIe tentaram criar uma fronteira compartilhada sem especificar todo o sistema. O consórcio define o comportamento da camada física, o adaptador e os mapeamentos de protocolo. Os fornecedores podem escolher as funções dos chiplets, a forma de construir o encapsulamento e os recursos que expõem. A camada comum precisa ser suficientemente fina para atender a produtos diferentes e suficientemente específica para que implementações independentes obedeçam à mesma especificação.

Esse equilíbrio é difícil. Com poucas prescrições, cada combinação continua exigindo integração individual. Com prescrições demais, o padrão pode congelar escolhas de projeto, favorecer os primeiros implementadores e reduzir o espaço para diferenciação. A rápida expansão do UCIe, dos fundamentos de link e protocolo para gerenciamento, DFx e encapsulamento 3D, mostra que a fronteira original não bastava para criar um encapsulamento operacional. Sempre que o mercado identificou premissas privadas que impediam a reutilização, o consórcio padronizou uma parcela adicional da transferência de responsabilidade.

Empresas concorrentes criaram uma organização sem fins lucrativos para uma fronteira deliberadamente restrita

O UCIe foi lançado publicamente em 2 de março de 2022 junto com a versão 1.0. A Universal Chiplet Interconnect Express, Inc. foi constituída como corporação sem fins lucrativos em Delaware em 2 de agosto daquele ano e abriu seu sistema formal de adesão. Os membros promotores reuniam empresas de projeto de processadores, nuvem, foundries, montagem e testes, memória e aceleradores. Os materiais atuais citam AMD, ASE, Alibaba Cloud, Arm, Google Cloud, Intel, Meta, Microsoft, NVIDIA, Qualcomm, Samsung e TSMC.

Essa amplitude é seu maior ativo institucional. Um link entre dies não se torna útil apenas com projetistas de processadores. Foundries precisam de canais fabricáveis e regras de encapsulamento; empresas de montagem e testes precisam de fluxos que possam qualificar. Fornecedores de EDA e IP de interface precisam de especificações que possam transformar em controladores, PHYs e produtos de verificação. Empresas de nuvem e sistemas precisam usar os encapsulamentos completos com cargas reais.

A mesma lista reúne motivações concorrentes. Operadores de hiperescala querem blocos reutilizáveis, mas também desejam manter privada sua arquitetura de sistemas. Foundries podem apoiar um link elétrico comum enquanto mantêm proprietários seus kits de projeto de encapsulamento, capacidades e conhecimentos de processo. Grandes empresas de processadores se beneficiam de mais fornecedores, mas podem ter links internos superiores ao padrão geral em aplicações selecionadas. O consórcio cria um local onde esses interesses podem concordar sobre uma fronteira; ele não torna os interesses idênticos.

Por isso, a condição de membro não é evidência de implantação. O logotipo de um promotor indica participação na governança e no trabalho técnico. Um colaborador pode fornecer ferramentas ou IP, enquanto um adotante talvez ainda esteja em avaliação. Nenhuma dessas condições demonstra, isoladamente, que um encapsulamento específico fabricado em volume contém chiplets UCIe fornecidos de forma independente ou que eles sejam comercialmente intercambiáveis. Essa fronteira institucional só terá significado quando a pilha técnica atender a várias opções de encapsulamento.

No atual conselho do UCIe, Debendra Das Sharma, da Intel, é presidente do conselho; Cheolmin Park, da Samsung, é presidente; Dong Wei, da Arm, é secretário; e Lihong Cao, da ASE Group, é tesoureiro. Há também representantes de Google Cloud, Qualcomm, Alibaba Cloud, Meta, TSMC, AMD e NVIDIA. Todos são cargos de governança exercidos por meio das organizações associadas; não significam propriedade individual da especificação nem contribuição exclusiva ao conteúdo técnico.

A estrutura sem fins lucrativos oferece um veículo jurídico para administrar membros, propriedade intelectual e trabalho técnico. Promotores, colaboradores e adotantes têm formas diferentes de participação. A versão pública de avaliação permite que pessoas externas examinem a arquitetura, mas seus termos distinguem o acesso para estudo dos direitos mais amplos associados à implementação e à condição de membro. O contrato concede apenas uma licença limitada para avaliação interna; não transforma a especificação em um projeto de domínio público sem patentes.

Essa fronteira é importante para pequenos fornecedores. Documentos públicos reduzem o custo de aprender os requisitos, mas não eliminam automaticamente a incerteza jurídica, não fornecem ferramentas de verificação nem pagam o desenvolvimento necessário para atender às restrições de encapsulamento de alta velocidade. Uma startup pode ler a mesma especificação que um promotor sem ter acesso ao mesmo conjunto de patentes, às mesmas relações de encapsulamento ou ao mesmo orçamento de verificação.

O UCIe é financiado por anuidades, mas os materiais públicos deste artigo não incluem receita auditada, reservas, número de funcionários ou gastos por geração da especificação. Essa ausência limita afirmações sobre a escala financeira da organização, mas não reduz o peso econômico do padrão.

O trabalho caro ocorre dentro das empresas associadas e fornecedoras. Empresas de semicondutores projetam controladores e dies; fornecedores de PHY criam IP reutilizável; empresas de EDA acrescentam modelagem e verificação; foundries e montadoras desenvolvem processos de encapsulamento. Empresas de sistemas pagam por integração, qualificação e software. Um link compartilhado pode reduzir trabalho duplicado, mas a economia aparece na economia dos produtos, não na receita do consórcio.

O sistema de membros também distribui direitos e riscos. Promotores e colaboradores participam do desenvolvimento técnico com base em contratos. A versão pública de avaliação permite que terceiros leiam a especificação, mas os direitos de implementação e as proteções de propriedade intelectual dependem dos contratos aplicáveis. O resultado combina material técnico público com uma economia estruturada de participação ao redor da implementação.

Esse é o ponto central para a sustentabilidade. O UCIe não precisa ter a receita de uma fabricante de chips para exercer influência, mas precisa de apoio contínuo suficiente para manter a especificação, coordenar interpretações, desenvolver a conformidade e organizar a geração seguinte. O risco não é uma falha comum de mercado de produto. É que as empresas que pagam pela implementação concluam que métodos proprietários são mais vantajosos ou que o custo de qualificação cresça mais rapidamente do que o valor da interoperabilidade ampla.

A especificação aproveita protocolos maduros e deixa as escolhas de encapsulamento para os fabricantes

A primeira especificação não tentou reinventar todas as transações de nível superior transportadas dentro do encapsulamento. Ela definiu o link físico entre dies e o adaptador, permitindo transportar PCI Express, Compute Express Link e tráfego raw. Assim, conectou uma nova fronteira de encapsulamento a modelos de software e dispositivos que os desenvolvedores de sistemas já conheciam.

O PCIe oferece uma semântica conhecida de host, dispositivo e I/O; o CXL acrescenta uma semântica de memória coerente e cache nos sistemas compatíveis. O UCIe não substitui nenhuma dessas organizações ou especificações. Ele transporta seus pacotes e significados entre dies no mesmo encapsulamento. Mesmo que uma função seja movida para fora do die principal, ela pode aparecer no ambiente de enumeração e software existente sem exigir um modelo de host inteiramente novo.

A vantagem é a continuidade, não a compatibilidade automática. O encapsulamento ainda precisa de firmware, enumeração, políticas de memória, tratamento de erros e software que entendam o protocolo escolhido. Dois links UCIe eletricamente compatíveis podem transportar, respectivamente, PCIe, CXL ou mensagens raw. Um sistema operacional compatível com uma classe de dispositivos não necessariamente conhece a função de outro chiplet.

Ao reutilizar significados maduros, o UCIe também entra em uma cadeia de dependências. Mudanças em PCIe ou CXL podem afetar mapeamentos futuros. Projetistas de encapsulamento precisam qualificar tanto o link quanto o protocolo superior. A conformidade da camada de transporte não corrige erros no projeto de memória coerente nem a ausência de drivers. O padrão leva contratos de software existentes através de uma nova fronteira física, mas não simplifica esses contratos.

O UCIe é organizado em camadas. A camada física trata do curto canal elétrico entre dies. O Die-to-Die Adapter gerencia o link e faz a mediação entre a camada física e o tráfego de protocolos superiores. Acima dele ficam os mapeamentos que dão aos bits transportados um significado visível ao software. Essa separação é essencial para a portabilidade: a mesma estrutura geral de link pode transportar vários tipos de tráfego, e um protocolo não fica preso a uma única tecnologia de encapsulamento.

O adaptador não é apenas um invólucro. Os materiais pesquisados o descrevem como responsável por gerenciamento do link, erros, novas tentativas e adaptação de protocolos. A fronteira entre dies não pode ser tratada como um fio não confiável invisível ao software. Antes que as camadas superiores confiem no caminho, o encapsulamento precisa de métodos para estabelecer o link, informar capacidades e conter falhas.

A estrutura em camadas também amplia os pontos em que implementações podem divergir. Um PHY talvez aceite apenas uma velocidade ou classe de encapsulamento. Adaptadores podem oferecer diferentes recursos opcionais de confiabilidade e gerenciamento, enquanto um mecanismo de protocolo pode implementar apenas PCIe, sem CXL. Fornecedores de sistemas também podem expor somente as partes necessárias ao produto. “UCIe” designa uma família de especificações, não um conjunto uniforme de recursos.

Compradores e integradores não deveriam perguntar apenas se um produto é compatível com UCIe, mas qual geração, classe de encapsulamento, velocidade, largura, mapeamento de protocolo, recurso de gerenciamento e condição de teste ele implementa. O padrão só se torna infraestrutura operacional quando esses elementos podem ser declarados, testados e comparados. Até lá, uma indicação genérica de compatibilidade comunica menos do que aparenta.

O alinhamento entre versões também se torna um encargo de integração. Depois de qualificar um controlador para determinada geração do UCIe e tipo de encapsulamento, uma empresa de sistemas pode receber um novo chiplet com recursos opcionais posteriores. A descoberta e a negociação de capacidades encontram o conjunto comum, mas não criam um recurso ausente em uma das partes. A equipe do produto precisa manter uma “interseção compatível” documentada de velocidades, protocolos, funções de gerenciamento e comportamento de fallback entre revisões de firmware e silício.

Descobrir uma incompatibilidade depois de fixar o die no encapsulamento custa muito mais do que encontrá-la em um conector de placa.

A portabilidade do software segue o mesmo padrão. Mapeamentos PCIe e CXL podem preservar modelos de dispositivos existentes, enquanto o modo raw e dados de gerenciamento específicos do fornecedor reintroduzem trabalho individual. Mesmo um encapsulamento que enumere corretamente pode exigir novos drivers, firmware, descrições de topologia e políticas de falha. O teste prático não é saber se o software reconheceu o die uma vez, mas se o mesmo contrato de software resiste à substituição do fornecedor e à revisão seguinte do produto.

O UCIe fornece uma estrutura para transporte e capacidades, mas nomes de funções e políticas de ciclo de vida precisam ser complementados por outros padrões ou acordos explícitos.

O consórcio define duas grandes classes de canais. O UCIe-S destina-se a encapsulamentos padrão, de menor densidade física e menor custo; o UCIe-A atende a encapsulamentos avançados, com passo fino de bumps e maior densidade de largura de banda. Uma única família de especificações precisa atender a produtos que não justificam o mesmo interposer, bridge ou tecnologia de união.

É uma escolha comercial importante. Um padrão voltado apenas aos encapsulamentos mais caros poderia oferecer alto desempenho, mas teria um mercado restrito. Um padrão ajustado somente a substratos orgânicos comuns perderia a densidade exigida pela computação avançada. As duas classes reconhecem que a interoperabilidade precisa funcionar sob diferentes custos e condições físicas.

As restrições não desaparecem. Encapsulamentos padrão e avançados têm orçamentos de canal, distribuição de bumps e tolerâncias de fabricação diferentes. Um projeto qualificado para UCIe-A não pode necessariamente ser transferido sem alterações para UCIe-S. A escolha entre interposer, bridge, substrato orgânico e união híbrida continua com a empresa de encapsulamento, e as regras de foundries e OSATs são decisivas.

O resultado é uma escolha com limites. O UCIe oferece vocabulário comum a dois ambientes enquanto permite implementações específicas de processo. Ele não garante que um chiplet feito para um ambiente seja economicamente, mecanicamente ou eletricamente adequado ao outro. A classe de encapsulamento faz parte da identidade do produto, não é apenas informação secundária de implantação.

O UCIe 3.0 elevou de 32 GT/s para 48 e 64 GT/s a maior velocidade especificada por lane em UCIe-S e UCIe-A. Isso permite aumentar a largura de banda total sem elevar na mesma proporção o número de conexões na borda do die. É atraente para produtos de IA e HPC, nos quais computação, memória e aceleradores especializados trocam grandes volumes de dados ao redor de um perímetro limitado do encapsulamento.

A velocidade da especificação não é uma medição do produto. A largura de banda disponível depende do número de lanes, da codificação e sobrecarga do protocolo, da qualidade do canal do encapsulamento, do projeto do controlador e do tráfego. A energia por bit varia com a implementação física e as condições, enquanto o rendimento depende da capacidade de fabricar e testar repetidamente canais completos. A indicação de 64 GT/s no documento define um modo; não comprova que todos os encapsulamentos possam operá-lo de forma economicamente viável.

Velocidades maiores também dificultam a verificação. Com o aumento da densidade, tornam-se mais rigorosos os requisitos de integridade de sinal, margem de temporização, roteamento do encapsulamento e comportamento térmico. Uma demonstração pode funcionar, mas a fabricação em volume enfrenta condições diferentes de envelhecimento, tensão e temperatura. Formação e demonstrações dos membros indicam progresso de engenharia, mas não fornecem um histórico universal de confiabilidade em campo.

Nesse ponto, valor e limite do padrão se encontram. Uma meta compartilhada de 64 GT/s concentra investimentos de ferramentas e fornecedores e torna os desafios de verificação comparáveis entre empresas. Ainda assim, cada encapsulamento precisa superar sua própria realidade física.

Os recursos de gerenciamento tornaram-se tão importantes quanto a largura de banda

Os canais de dados de alta velocidade transportam a carga, mas um encapsulamento com vários dies também precisa de um caminho de controle e gerenciamento de baixa velocidade. O UCIe possui um mecanismo lateral independente do caminho principal de dados. Na versão 3.0, o alcance definido foi ampliado para até 100 milímetros sob as condições de canal aplicáveis, oferecendo maior flexibilidade para posicionar componentes de gerenciamento em um sistema em encapsulamento.

Talvez seja necessário descobrir, consultar ou colocar um componente em estado seguro antes que o link de alta velocidade esteja pronto. O gerenciamento não deve depender apenas do caminho que está sendo diagnosticado. Quando vários chiplets compartilham recursos e um deles apresenta comportamento anormal, sinais de baixa latência e controles de emergência tornam-se especialmente importantes.

O alcance ampliado não deve ser interpretado como garantia de que o canal principal de 64 GT/s possa ter a mesma geometria. O caminho lateral e o caminho de dados têm finalidades e requisitos elétricos diferentes. É possível alongar o caminho de gerenciamento e manter o link de alta velocidade curto e denso.

Do ponto de vista do sistema, isso demonstra que integrar chiplets não termina na transferência de dados. O encapsulamento precisa de uma dimensão operacional. O padrão pode oferecer um caminho comum, mas cada fornecedor ainda define grande parte dos estados, políticas e reparos por trás das mensagens. Um sistema nervoso comum não significa que todos os órgãos relatem o mesmo diagnóstico.

O UCIe 1.1, lançado em 8 de agosto de 2023, acrescentou monitoramento de integridade automotiva e opções de configuração para encapsulamentos de baixo custo. Ele preservou a compatibilidade com versões anteriores na família de especificações e ampliou o alcance para além dos encapsulamentos mais caros e de alto desempenho.

Em sistemas automotivos, monitoramento, confiabilidade e uso prolongado têm mais peso do que em aceleradores de vida curta. Incluir informações de integridade na especificação reconheceu que o link entre dies também entraria em sistemas nos quais falhas potenciais e diagnóstico em campo importam tanto quanto a largura de banda máxima. O encapsulamento de baixo custo respondeu à pressão econômica oposta: se a interoperabilidade funcionasse apenas em encapsulamentos caros, sua adoção seria limitada.

A presença de um recurso na especificação não comprova sua adoção pelo setor. Plataformas automotivas, ciclos de qualificação e responsabilidades dos fornecedores estão fora do controle do UCIe. O significado da versão 1.1 é direcional. O consórcio começou cedo a reconhecer que um link comum de alta velocidade precisaria de flexibilidade de encapsulamento e sinais de ciclo de vida para ir além de um nicho.

A tendência continuou nas versões 2.0 e 3.0. Cada geração padronizou mais encargos de integração antes deixados a acordos privados. A especificação se expandiu porque os problemas mais difíceis estavam tanto dentro quanto ao redor do link original. A partir da segunda grande revisão, o desafio passou do estabelecimento do link para a operação do encapsulamento durante toda a vida útil.

O UCIe 2.0, anunciado em 6 de agosto de 2024, acrescentou uma arquitetura de sistema para gerenciamento e suporte a encapsulamento 3D. Ele tratou de descoberta, testes, telemetria, operações de firmware, depuração e controle de ciclo de vida entre vários dies, incluindo o Management Transport Protocol e recursos de projeto para teste, depuração e telemetria conhecidos coletivamente como DFx.

Isso alterou de forma significativa a definição de interoperabilidade. Um encapsulamento pode transportar dados corretamente e ainda ser impossível de operar. A equipe de fabricação precisa testar dies antes e depois da montagem; a equipe de firmware precisa identificar versões e coordenar atualizações; operadores em campo precisam de telemetria e isolamento de falhas. Os projetistas precisam saber se uma falha de componente pode ser contida sem interromper todo o sistema.

Uma arquitetura comum fornece transporte e estrutura compartilhados, mas não define todos os objetos de gerenciamento, políticas de atualização e procedimentos de manutenção. Um fornecedor pode expor informações detalhadas de integridade e outro mostrar apenas estados mínimos. Uma empresa de sistemas pode permitir atualizações coordenadas ou limitar o sistema a imagens aprovadas. O padrão permite transportar mensagens de gerenciamento entre fornecedores, mas não elimina as fronteiras de política.

O teste prático é a responsabilidade. Quando a telemetria mostra um link próximo do limite, quem deve diagnosticar: o fornecedor do die, a montadora ou a empresa de sistemas? Se uma atualização alterar o comportamento, quem requalifica o encapsulamento inteiro? O UCIe 2.0 criou um espaço técnico comum, mas não forneceu respostas contratuais.

Testabilidade, depuração, telemetria e outros recursos de ciclo de vida costumam ser tratados como questões de fábrica. Em um sistema com vários dies, tornam-se parte da arquitetura do produto. Dies fabricados por processos diferentes, fornecidos por empresas distintas e testados por métodos internos separados entram no mesmo encapsulamento. Depois da montagem, é necessário determinar se uma falha está em um die, no link, no canal do encapsulamento, na alimentação compartilhada ou no software coordenado.

O DFx do UCIe tenta oferecer uma base comum para essas tarefas. O caminho de gerenciamento transporta estados e informações de diagnóstico, permitindo projetar testes e depuração ao redor de um modelo compartilhado de encapsulamento, e não de conexões dedicadas para cada combinação. Isso reduz transferências específicas e ajuda a preservar evidências da fabricação à operação.

O padrão não consegue criar observabilidade que o chiplet não implementa nem garantir que um sinal informado indique a causa raiz. Um die pode relatar erros provocados por ruído de alimentação em outro ponto. Um link pode evitar uma condição limite por meio de novo treinamento sem revelar a margem restante até a falha. Um problema de rendimento observado pela montadora talvez não seja reproduzido no laboratório da empresa de sistemas. O transporte compartilhado move evidências, mas não as torna completas.

O DFx também altera as fronteiras comerciais. Compradores passam a precisar especificar cobertura de testes, acesso à telemetria e autoridade sobre firmware. Um die proprietário com bom suporte de ciclo de vida pode ser mais útil do que um die compatível com UCIe cujos diagnósticos não estejam disponíveis. Uma arquitetura comum abre o caminho para o gerenciamento, mas a qualidade desse gerenciamento continua sendo uma escolha de produto.

A integração 3D amplia ao mesmo tempo a liberdade de projeto e a superfície de falhas

A mesma geração UCIe 2.0 passou a oferecer suporte a encapsulamentos 3D, incluindo dies empilhados verticalmente e conexões de distância extremamente curta e alta densidade. O empilhamento aproxima computação e memória, aumenta a densidade de largura de banda e reduz a área. Em contrapartida, acopla calor, tensão mecânica e rendimento de fabricação com mais intensidade do que abordagens 2D ou 2,5D.

Um padrão de interface ajuda a definir o que cruza a fronteira vertical, mas não determina o processo de união, a estrutura térmica, a rede de alimentação nem a sequência usada para confirmar dies em boas condições antes da montagem final. Essas escolhas permanecem com foundries, empresas de montagem e testes, projetistas de chips e empresas de sistemas.

Isso é particularmente importante para reparos. A modularidade no nível da placa sugere que um componente defeituoso pode ser substituído, mas talvez não seja possível trocar em campo um die interno fortemente unido aos demais. Mesmo que o sistema de gerenciamento identifique o die defeituoso, a solução comercial pode ser substituir todo o encapsulamento. Reduzir o tempo de diagnóstico não altera a possibilidade física de reparo.

O padrão oferece suporte à integração 3D, mas não a torna fácil. Sua contribuição é manter identificáveis as fronteiras de comunicação e gerenciamento mesmo quando a geometria do encapsulamento muda. Os desafios de fabricação ao redor não diminuem; eles se tornam mais rigorosos.

PCIe e CXL fornecem caminhos de software estabelecidos, mas nem todo chiplet se comporta como um dispositivo de I/O convencional ou uma memória coerente. Processamento de sinais, redes e aceleradores especializados podem exigir tráfego contínuo ou específico da aplicação. O modo raw permite transportá-lo sem impor a semântica de PCIe ou CXL. A versão 3.0 ampliou mapeamentos de transmissão contínua, como caminhos de dados A/D e D/A.

O modo raw aumenta o número de sistemas capazes de usar o link físico, mas evidencia a diferença entre interoperabilidade elétrica e funcional. Duas empresas podem atender aos mesmos requisitos de canal e ainda definir quadros, controle de fluxo e significados de aplicação diferentes sobre a transmissão raw. O link pode se conectar, mas a função exige outro acordo.

Isso não é necessariamente uma falha. Mesmo com um protocolo de aplicação específico, uma base física comum pode reduzir duplicações. O risco está em usar a expressão “compatível com UCIe” como se ela também representasse uma portabilidade que o modo raw não oferece. O comprador precisa saber se o mapeamento raw usa um perfil compartilhado, um acordo bilateral ou um protocolo específico do fornecedor.

O modo raw pode produzir efeitos opostos. Ele permite colocar mais tipos de chiplets no mesmo link e ampliar a base de fornecedores, mas também pode preservar ilhas de funções privadas sobre esse link. A direção dependerá de os implementadores criarem perfis raw comuns e divulgarem informações suficientes para a integração independente.

O setor de semicondutores usa muitas siglas, o que facilita interpretar especificações de interconexão como concorrentes diretas. UCIe, PCIe e CXL tratam de partes diferentes. O PCI-SIG define a interconexão PCI Express e seus modelos de dispositivos; o CXL Consortium define significados como memória coerente; o UCIe define canais entre dies de curta distância dentro do encapsulamento e os mapeamentos que transportam esses protocolos.

Essa hierarquia é uma das razões pelas quais o UCIe avançou rapidamente. Ele pôde transportar significados que já tinham software, verificação e organizações setoriais, sem convencer fornecedores de sistemas operacionais e dispositivos a adotar uma semântica inteiramente nova para cada transação.

Ao mesmo tempo, uma implementação UCIe herda as mudanças e a complexidade dos protocolos superiores. Um encapsulamento compatível com CXL ainda precisa de um projeto coerente de sistema; um mapeamento PCIe ainda requer enumeração, drivers e tratamento de erros. Se um pacote atravessa a fronteira entre dies, uma falha no protocolo superior não se transforma automaticamente em falha do UCIe.

A visão mais clara é a de responsabilidades empilhadas. O UCIe responde como bits e pacotes de protocolo cruzam a fronteira sob determinadas condições. PCIe e CXL respondem o que muitos desses pacotes significam. Firmware e software operacional decidem como o sistema integrado aparece e é usado. Nenhuma camada pode reivindicar sozinha o resultado das três.

Um canal de alta velocidade entre dies precisa demonstrar que as duas extremidades conseguem se comunicar sob as condições elétricas do encapsulamento real. A especificação inclui negociação de capacidades, treinamento de link, recalibração durante a operação e limitação de desempenho. O UCIe 3.0 acrescentou recalibração operacional no transmissor e melhorias relacionadas à energia para apoiar ajustes diante de variações de processo, tensão, temperatura e operação.

O encapsulamento não é estático. A temperatura muda conforme a carga, as condições de alimentação oscilam e os componentes envelhecem. São necessários mecanismos para recuperar margem ou reduzir a atividade, em vez de presumir que o estado de fabricação persistirá por toda a vida útil.

O sucesso do treinamento é um resultado limitado. Ele demonstra que o link foi estabelecido nas condições de teste, mas não comprova confiabilidade sob todas as cargas, ciclos térmicos e períodos de vida útil. A recalibração pode corrigir uma forma de variação e deixar outra falha; a limitação de desempenho pode preservar a operação em troca de velocidade.

Isso cria requisitos de divulgação para o comprador. É preciso distinguir a velocidade máxima da especificação daquela verificada no encapsulamento real, além de informar condições de recalibração e comportamento quando falta margem. Um link adaptativo pode gerenciar mudanças, mas não transforma confiabilidade não medida em garantia.

As evidências de conformidade precisam ser específicas o bastante para orientar compras

Um único rótulo não representa todas as implementações UCIe. Uma declaração completa de conformidade precisa incluir, no mínimo, geração da especificação, classe de encapsulamento, velocidade, configuração de lanes, protocolos aceitos, recursos opcionais de gerenciamento e condições de teste. Dois produtos podem implementar UCIe e não ter uma combinação comum no desempenho necessário.

Programas maduros de interconexão vinculam a conformidade a capacidades definidas e procedimentos de teste, não a uma indicação genérica de relação com o padrão. No encerramento desta pesquisa, o ecossistema público do UCIe ainda construía essa base de evidências. Havia eventos de interoperabilidade, encontros, webinars e demonstrações de controladores e PHYs, mas os materiais não permitiram confirmar uma lista pública completa de produtos certificados.

Um programa útil de conformidade não deve testar apenas a forma mais simples de inicializar o link. Ele precisa definir comportamento de erros, negociação de capacidades, gerenciamento e perfis de protocolos compatíveis. A classe do encapsulamento e as condições do canal também importam. Um resultado não deve ser estendido a outra velocidade ou outro encapsulamento sem evidências.

A ausência de uma lista universal não significa que as implementações sejam fictícias. Significa que as evidências públicas ainda são jovens. Demonstrações dos membros podem mostrar coordenação entre ferramentas e interfaces independentes. A qualificação para fabricação em volume exige repetibilidade, quantidade, condições operacionais e responsabilidade por falhas posteriores.

Essa distinção protege compradores e consórcio. Interpretar demais uma indicação vaga de UCIe cria frustrações que a especificação não foi projetada para evitar. Perfis precisos tornam os resultados do padrão mais visíveis. A barreira restante são as evidências: configurações testadas e limites precisam ser apresentados ao comprador de forma concreta.

Desde a primeira versão, a atividade passou da explicação conceitual à implementação. Membros anunciaram controladores, IP de PHY, plataformas de verificação e projetos de encapsulamento. Eventos apresentaram demonstrações e discussões sobre integridade de sinal, encapsulamento avançado e interoperabilidade. Os materiais de 2025 apontaram essas atividades como evidência de adoção crescente.

Uma demonstração responde a perguntas restritas: este controlador consegue se comunicar com este PHY? O sistema de teste detecta determinado erro? A velocidade pretendida é alcançada em condições de laboratório? São perguntas valiosas, pois reduzem incertezas de implementação e revelam diferenças de interpretação da especificação.

Um encapsulamento produzido em volume responde a perguntas mais amplas. Vários fornecedores conseguem entregar dies em boas condições dentro do prazo? O produto atende às metas de rendimento e energia depois da montagem? É possível atualizar com segurança o firmware de cada componente? O software continua portátil entre revisões do produto? Quem substitui o sistema quando um die próximo do limite apresenta falhas intermitentes? A demonstração é parte das evidências, não a solução completa.

O registro público não contém uma lista completa de encapsulamentos multivendor em comercialização. A conclusão segura é que o ecossistema está construindo capacidade de implementação. As evidências atuais não permitem classificá-lo como um mercado universal.

Um integrador não pode avaliar um chiplet apenas porque o link funciona. O die precisa estar em boas condições para a função, os extremos do processo e o ciclo de vida pretendidos, e as evidências de teste precisam acompanhar o produto do wafer à montagem e ao sistema final. Se um componente estiver defeituoso depois da integração, os outros dies e o trabalho de encapsulamento também podem ser perdidos.

A evidência de known-good die é um requisito comercial, não apenas de fabricação. Fornecedores precisam concordar sobre o que foi testado, quais margens se aplicam, como os resultados são representados e quem arca com os custos quando o conjunto falha. O gerenciamento comum e o DFx ajudam a transportar informações de teste e telemetria, mas não certificam as funções internas de cada die nem distribuem responsabilidades entre empresas.

Essa também é uma vantagem dos encapsulamentos verticalmente integrados. Uma só empresa pode controlar projeto dos dies, limites de teste, montagem e garantia. Um encapsulamento com vários fornecedores precisa transformar transferências privadas em evidências e contratos explícitos.

A camada de mercado que falta não é chamativa, mas determina se a modularidade chegará aos pequenos fornecedores. Um link elétrico comum reduz uma barreira. A garantia de dies em boas condições determina se o comprador pode arriscar o restante do encapsulamento com um componente desconhecido.

Segurança, garantia e software determinarão se um mercado será formado

Um encapsulamento com vários fornecedores cria uma fronteira de confiança extremamente próxima. Chiplets trocam grandes volumes de dados, compartilham caminhos de gerenciamento e afetam recursos tratados pelo sistema final como um único dispositivo. Um die comprometido ou malicioso pode se tornar uma entrada para fluxos de controle e dados, não apenas comprometer sua própria função.

Especificações posteriores de gerenciamento podem apoiar descoberta controlada, operações de firmware e sinais de emergência. Materiais dos membros citam o reforço da segurança como um desafio contínuo. No entanto, eles não definem a segurança completa do encapsulamento. Identidade do dispositivo, inicialização segura, procedência do firmware, atestação, isolamento, gerenciamento de chaves e garantias dos fornecedores são responsabilidades de todo o sistema.

Mesmo com transporte seguro, um chiplet aprovado, porém comprometido, pode agir de forma maliciosa. Uma identidade forte mostra qual die está presente, mas não prova que seu firmware é seguro. Um componente atestado ainda pode abusar do acesso concedido. A segurança depende do que é permitido depois que a confiança é estabelecida.

Versões futuras podem definir recursos adicionais, mas as evidências não confirmam quando nem de que forma. Atualmente, “compatível com UCIe” não é uma certificação de segurança no nível do encapsulamento. O comprador precisa de um modelo de confiança separado para cada fornecedor e para o sistema completo.

O UCIe é chamado de padrão setorial aberto, e a especificação pode ser solicitada publicamente sob termos de avaliação. Isso é importante porque projetistas podem estudar a estrutura, ferramentas podem convergir em conceitos comuns e a compatibilidade pode ser discutida sem que uma empresa seja dona da interface.

O restante da cadeia de suprimentos pode continuar concentrado. Fabricação avançada de wafers, união híbrida, interposers, montagem, equipamentos de teste e EDA vêm de um número limitado de empresas e regiões. Controles de exportação e políticas industriais afetam o acesso a nós, ferramentas e IP. Um link comum não cria uma nova foundry nem uma linha de encapsulamento.

Um padrão aberto tampouco exige uma implementação aberta. Controladores UCIe, PHYs, projetos de chiplets, firmware e kits de projeto de encapsulamento podem ser proprietários. O contrato de avaliação também separa a consulta da especificação da licença de implementação. Uma empresa pode apoiar o link comum e controlar fortemente as camadas acima e abaixo dele.

Talvez essa seja uma força realista. É possível reduzir trabalho bilateral mesmo sem tornar todas as implementações de código aberto. O risco é apresentar a abertura de uma camada como evidência de concorrência e portabilidade em outras camadas que permanecem fechadas. O encapsulamento deve ser analisado camada por camada. Quando o alcance da conformidade fica claro, as questões difíceis passam a ser confiança, suporte comercial e distribuição dos riscos de integração.

Os recursos dos promotores tornam o UCIe confiável. Eles podem fornecer tecnologia, construir interfaces, qualificar encapsulamentos e gerar demanda. Ao mesmo tempo, essas empresas também dispõem das alternativas mais fortes que não dependem de um mercado aberto. Grandes empresas de processadores, nuvem e foundries podem projetar chiplets, links internos e fluxos de encapsulamento proprietários quando isso for vantajoso.

Isso não significa que a participação seja desonesta. Uma empresa pode usar UCIe apenas nas fronteiras externas e manter links proprietários dentro dos produtos mais integrados. Pode transportar protocolos comuns e, ainda assim, diferenciar topologia, memória e políticas de gerenciamento. A adoção pode ser seletiva e organizada em camadas, não total.

O desafio de governança é manter a fronteira compartilhada útil também para empresas que não controlam toda a pilha. A presença de nuvem, processadores, foundries e encapsulamento no conselho é positiva, mas os materiais fornecidos não incluem registros públicos completos de contribuições, votações e resolução de disputas nos grupos técnicos. Posições iguais em uma lista de logotipos não significam igual poder de negociação.

O padrão pode ter sucesso mesmo que as grandes empresas preservem vantagens proprietárias. O teste mais rigoroso é saber se um pequeno fornecedor consegue produzir um chiplet, comprovar um perfil limitado, acessar um encapsulamento e vender para vários sistemas sem transferir ao comprador todo o risco jurídico e de integração.

A intercambiabilidade comercial exige mais do que a especificação do link. São necessários metadados de capacidade que mostrem função, protocolos e velocidades aceitos, método de descoberta, firmware necessário e informações de integridade. O projetista do encapsulamento precisa de condições elétricas, energéticas, térmicas e mecânicas; o software precisa de enumeração e gerenciamento estáveis; as compras precisam de preço, volume, ciclo de vida, garantia e condições de responsabilidade.

O UCIe pode fornecer parte disso por descoberta de capacidades, declaração de perfis e gerenciamento, mas não define uma API funcional completa nem um catálogo universal de produtos. Ele não distribui garantias nem assegura capacidade de foundries. Os materiais e eventos descrevem a meta de mercado, mas as evidências públicas terminam antes de uma camada comercial completa.

É por isso que o UCIe é importante e, ao mesmo tempo, insuficiente. O padrão cria condições para um mercado, não o próprio mercado. Fornecedores, foundries, ferramentas e compradores precisam tornar a interface viável para investimento, testes e suporte.

Em um mercado maduro, a responsabilidade pode ser lida. É possível saber se a causa de uma falha está no chiplet, no link, na montagem, no firmware ou na integração, e os contratos definem quem paga. Sem essa transferência clara, a modularidade técnica pode aumentar, e não reduzir, o risco de integração para o comprador.

As transferências de responsabilidade na fabricação em volume determinarão o valor do UCIe

O consórcio avançou rapidamente: fundamentos em 2022; recursos automotivos e de baixo custo em 2023; gerenciamento e 3D em 2024; 64 GT/s e extensões raw e de gerenciamento em 2025. Em 2026, as atividades públicas passaram a enfatizar formação, implementação e verificação mais do que um novo número de versão.

Esse é o processo de um padrão jovem aprendendo onde a integração se rompe. O link físico precisou de mapeamentos de protocolo; o link precisou de classes de encapsulamento; o encapsulamento precisou de monitoramento de integridade, gerenciamento, DFx e suporte a 3D. O aumento de velocidade exigiu recalibração, controle de energia e um caminho lateral flexível. Cada acréscimo transformou premissas privadas em um contrato técnico compartilhado.

A próxima comprovação virá de outro tipo de evidência. Um sistema de conformidade com alcance limitado precisa mostrar quais perfis funcionam; fornecedores independentes precisam entregar dies que passem por montagem e verificação; o software precisa descobri-los e gerenciá-los sem ser reescrito para cada combinação; contratos precisam dividir responsabilidades por falhas e ciclo de vida; e pequenos fornecedores precisam participar sem transferir toda a incerteza ao comprador.

O UCIe já mudou o debate sobre chiplets. Ele colocou um link comum confiável em uma fronteira antes dominada por conexões proprietárias. Saberemos se ele se tornou um mercado quando a primeira falha entre fornecedores puder ser diagnosticada, atribuída e reparada sem retorno a uma única empresa verticalmente integrada. Nesse momento, o padrão deixará de ser uma interface promissora e se tornará infraestrutura.