まとめ

  • UCIe は PHY、アダプター、プロトコル、および Die-to-Die 接続の管理に関する共通ルールを定めている。チップレットの機能、パッケージング、サプライヤーの責任はその対象外である。
  • バージョン 1.0 から 3.0 までに、低コストのパッケージオプション、自動車向けモニタリング、3D サポート、管理容易性、64 GT/s 動作が加わった。
  • 市場価値は、再現可能な適合プロファイル、サポートされたマルチベンダーの量産製品、およびサプライヤーをまたぐ障害時の明確な責任に表れる。

64 GT/s により、速度競争はシステムの課題となった

2025年8月5日、公開されてからまだ3年余りの標準化コンソーシアムが、3番目のメイン仕様を発表した。ユニバーサル・チップレット・インターコネクト・エクスプレス（通称 UCIe）は、標準パッケージングおよびアドバンスト・パッケージングのチャネル向けに、毎秒48ギガトランスファーと64ギガトランスファーを追加した。この版はまた、低速サイドバンド経路の到達範囲を拡大し、連続的なロー転送を拡張し、管理制御を追加した。見出しは「速度」だった。それ以上に重要だったのは、独立に開発された複数のダイからなるパッケージを、単一の制御可能なシステムとして扱おうとしたことだ。

この区別は重要だ。高速な接続はチップレット製品の一部にすぎないからだ。購入者は、各ダイがどのような機能を果たすのか、どれだけの電力を必要とするのか、どのように冷却されるのか、どのソフトウェアがそれを認識するのか、ファームウェアがどう更新されるのか、障害時に何が起きるのか、どのサプライヤーが保証を負うのかを、引き続き知る必要がある。UCIe は、ダイ間の情報転送と、その周辺の管理の一部について共通ルールを定める。この標準だけでは、無関係なシリコンブロックの集まりを完成したプロセッサに変えることはできない。

コンソーシアムの公式の言葉は「オープンなチップレット・エコシステム」を目指している。意欲としては有益だが、その表現はすでに存在する市場を描写しているかのように聞こえるかもしれない。このプロフィールのために検証した公開文書には、出荷されたマルチベンダー UCIe パッケージの完全な独立した棚卸しも、認定製品の普遍的なリストも、交換可能なダイのカタログも存在しなかった。見えたのは、仕様、メンバーの活動、実装トレーニング、デモンストレーションだった。これらは必要なステップだが、繰り返し可能な調達や量産とは異なる証拠である。

したがって、中心的な問いは「チップレットが重要になるか」という問いよりも狭い。複雑なシステムを分割する手段としては、すでに重要になっている。重要なのは、パッケージ全体が緊密に調整されたエンジニアリング製品であり続ける中で、共通の接続がどれだけのモジュール性を生み出せるかだ。UCIe はダイの境界における共通言語となり得る一方で、物理システムとビジネス関係の大部分をプロプライエタリに残すこともできる。したがって、インターフェースは「交換可能性の総花的な約束」としてではなく、「引き継ぎの連鎖」として評価されるべきだ。

「交換可能性」という概念は、いくつかの検証をまとめたものだ。第一に電気的検証：送信機、受信機、パッケージ・チャネルは、同じ物理プロファイルの下で接続を確立できるか。第二にプロトコル検証：両側が同じ PCIe、CXL、またはロー・マッピングを理解しているか。第三に運用検証：パッケージは、互換性のある管理機能を持つダイを認識、テスト、監視、更新できるか。第四に機能・ソフトウェア検証：チップレットは、ファームウェア、ドライバ、アプリケーションが利用できる動作を提供するか。第五に商業検証：その部品は、十分なテスト証拠、数量、サポート、保証を備えて入手可能か。

UCIe は最初の2つのレベルに直接対応し、第3のレベルにも徐々に対応している。電気的ネゴシエーション、プロトコル転送、管理の引き継ぎは、これによってプライベートな二者間設計への依存を減らすことができる。第4のレベルは、PCIe、CXL、および製品固有のソフトウェアに部分的に委ねられている。第5のレベルは、サプライヤー、ファウンドリ、パッケージング企業、購入者のものである。

レベルを取り違えると、二つの正反対の誤りに陥る。一つは、標準が完成した市場を作り出さないという理由で標準を退け、取り除かれた物理的・プロトコル上の障壁の価値を見落とすこと。もう一つは、2つのダイが適合した接続を確立した時点で市場は完成したと宣言し、リンクをサポート可能なシステムにするすべての決定を無視することだ。

専門的な評価は、どの約束が証明されているかを明確にすべきだ。PHY のデモンストレーションが証明するのは、プロトコル結合よりも少ない。プロトコル結合が証明するのは、ライフサイクル全体で管理可能なパッケージよりも少ない。そして管理可能なパッケージが証明するのは、新しいソフトウェアや契約なしで交換できる部品よりも少ない。この階層は UCIe への批判ではなく、コンソーシアムが何を管理し、何を市場に委ねているかを最も明確に示している。

この5つのレベルは、実際の進歩がまだプラグアンドプレイのような調達に見えない理由も説明している。仕様の版は最初の3つの約束を強化できるが、残りの2つは成熟が遅い。チップレット市場はアナウンスメントによって生まれるのではなく、反復可能で信頼できるようになる緊密な引き継ぎによって生まれる。

チップレットは複雑さをシリコンからパッケージへ移す

モノリシック・チップは、システムの機能を大きなシリコン片の上に載せる。これにより通信は簡素化できるが、すべての機能を同じ製造プロセスに強制することになる。先進ノードにおける設計、マスク、歩留まりのコストとリスクが増大するにつれて、すべてのブロックを1つの大きなダイに収めることは高価で困難になる。チップレットは別の経路を提供する：演算ロジック、メモリ、I/O、アナログ機能、セキュリティ、アクセラレータを分離し、それぞれに適したプロセスで製造し、システム・イン・パッケージで接続できる。

分割は複雑さを取り除くのではなく、その一部をダイからパッケージへ移す。それぞれの境界には、シグナリング、クロッキング、エラー処理、電力供給、熱設計、テストカバレッジ、ソフトウェアから見える動作が必要だ。大きなモノリシック・ダイは面積が増えるにつれて歩留まりを失う可能性がある。マルチダイ・パッケージは、個々の組み込まれたダイが不良、限界品質、または誤った実装であるために価値を失う可能性がある。システム開発者は、プロセスノードを混在させ、ブロックを再利用する機会を得る一方で、パッケージレベルでの新たな依存関係を負う。

だからこそ「モジュール式」には正確さが求められる。プリント基板がモジュール式であるのは、部品が標準化された形状、電気的な慣習、識別可能な機能、成熟した商習慣を持つからでもある。サプライヤーはデータシートを公開し、販売代理店は在庫を保持し、インテグレータはソケット、コネクタ、故障限界を知っている。アドバンスト・パッケージ内のチップレットは、はるかに狭い物理的環境にあり、許容誤差もはるかに小さい。それは、電力、熱、管理、高速チャネルを隣接部品と共有するかもしれないが、組み立て後は基板上の部品のように検査したり交換したりすることはできない。

UCIe は、最も困難な繰り返し発生する境界の一つ、すなわち短く高密度な Die-to-Die リンクに取り組んでいる。その標準化は、繰り返されるインターフェース開発を減らし、ツールベンダー、IP サプライヤー、システム企業に共通の目標を与えることができる。残りの統合問題は消えない。価値は、特定の種類の二者間開発を削減することにあり、パッケージを緩く独立した部品に変えることではない。

共通のインターフェースがなければ、企業はシステムを複数のダイに分割しても、垂直統合を維持できた。リンクは、あるベンダーの電気的想定、プロトコル、パッケージングプロセス、テストフローに合わせて最適化できた。これはレイテンシ、性能、面積に関して自由度を与えるが、他のサプライヤーはその非公開の契約を知り、実装しない限り、ダイを提供することが難しくなる。

その罠は技術的であると同時に経済的でもある。システム企業は、有用なモジュールを他の企業に提供せずに、自社の設計をチップレットベースと称することができる。再利用は自社の製品世代間で行われる。外部市場が見るのは閉じたパッケージだ。企業の境界の内側ではアーキテクチャはモジュール式であり、外側では分割不可能である。

UCIe の創設者たちは、システム全体を規定することなく、共通の境界を作りたかった。コンソーシアムは PHY の動作、アダプター、プロトコルマッピングを定義する。ベンダーは機能、パッケージング、目に見える特徴を引き続き決定する。共通層は、多様な製品に対応できるほど薄く、同じ仕様に適合する独立した実装が可能なほど詳細であるべきだ。

そのバランスは難しい。規定が少なすぎると、すべての組み合わせが特別な統合になってしまう。多すぎると、設計上の決定を凍結し、初期の実装者を有利にし、差別化を削ぐ可能性がある。UCIe がリンクとプロトコルから、管理容易性、DFx、3D パッケージングへと急速に拡大したのは、完全に運用可能なパッケージには当初の境界では不十分だったことを示している。コンソーシアムは、市場が認識していた以上に、非公開の想定が再利用を妨げている箇所で、より多くの引き継ぎを標準化する必要があった。

競合各社は、意図的に狭い境界のための非営利組織を設立した

UCIe は 2022年3月2日、バージョン 1.0 で始まった。Universal Chiplet Interconnect Express, Inc. は同年8月2日にデラウェア州で非営利法人として登記され、正式な会員制度を開始した。プロモーターは、プロセッサ開発、クラウド、ファウンドリ製造、アセンブリ・テスト、メモリ、アクセラレータから集まった。現在の資料では、AMD、ASE、Alibaba Cloud、Arm、Google Cloud、Intel、Meta、Microsoft、NVIDIA、Qualcomm、Samsung、TSMC が挙げられている。

その広がりは、最も強力な制度的資本である。Die-to-Die 接続は、プロセッサ開発者だけでは有用にならない。ファウンドリは、製造できるチャネルとルールを必要とする。アセンブリ・テスト企業は、認定可能なプロセスを必要とする。EDA およびインターフェース IP ベンダーは、コントローラ、PHY、検証のための仕様を必要とする。クラウドおよびシステム企業は、結果として得られるパッケージを実際のワークロードに展開できなければならない。

同じリストには、相反するインセンティブが含まれている。ハイパースケーラーは、再利用可能なブロックを望みながら、システムアーキテクチャを非公開に保つかもしれない。ファウンドリは、共通リンクを支援しつつ、設計キット、容量、プロセス知識を保護するかもしれない。既存のプロセッサベンダーは、より多くのサプライヤーから恩恵を受ける一方で、特定の製品にはより優れた内部リンクを持つかもしれない。コンソーシアムは、これらの利害が境界に合意する場を作るが、利害を同一化するわけではない。

したがって、会員であることは展開の証明にはならない。プロモーターのロゴは、ガバナンスと技術への関与を示す。コントリビューターはツールや IP を提供するかもしれない。アダプターはまだ評価段階かもしれない。どのカテゴリーも、量産パッケージが独立して調達された UCIe チップレットを含んでいることや、部品が商業的に交換可能であることを単独で証明するものではない。この制度的な境界は、技術スタックがさまざまなパッケージングの決定とともに利用可能であり続けて初めて価値を持つ。

現在の理事会では、Intel の Debendra Das Sharma が議長、Samsung の Cheolmin Park が会長、Arm の Dong Wei が書記、ASE Group の Lihong Cao が会計を務めている。他の理事は Google Cloud、Qualcomm、Alibaba Cloud、Meta、TSMC、AMD、NVIDIA を代表している。これらの役職は会員組織を通じて行使される。それらは、仕様の個人的な所有や単独の著作権を意味するものではない。

非営利の仕組みは、会員、IP ルール、技術作業に法的な拠り所を与える。プロモーター、コントリビューター、アダプターは異なる参加形態を持つ。公開された評価用コピーはアーキテクチャを可視化するが、その条件は「閲覧」と「さらなる実装・会員権利」を区別している。ライセンスは内部評価に限定されており、仕様を特許フリーの共有財産として提供するものではない。

これは中小サプライヤーにとって重要だ。公開文書は要件を理解するコストを下げるが、法的な不確実性を自動的に排除するものではなく、検証ツールを提供するものでもなく、高速開発の資金を提供するものでもない。スタートアップはプロモーターと同じ仕様を読むことができても、その特許ポートフォリオ、パッケージング関係、検証予算を持っているわけではない。

UCIe は会費によって支えられているが、用いた文書には、監査済みの収入、準備金、職員数、仕様世代別の支出は含まれていない。これは、組織の財務規模に関する発言を制限するが、標準をめぐる経済的利害に関する発言を制限するものではない。

高コストな作業は会員とサプライヤーの側で行われる。半導体企業はコントローラとダイを開発し、PHY ベンダーは再利用可能な IP を、EDA 企業はモデリングと検証を、ファウンドリとアセンブリ企業はパッケージングプロセスを担う。システム企業は統合、認定、ソフトウェアに費用を払う。共通リンクは重複作業を減らすことができるが、その利益は製品の経済性に現れ、コンソーシアムの収益として現れるわけではない。

会員制度は権利とリスクも分配する。プロモーターとコントリビューターはコンソーシアム契約の下で技術に取り組む。公開評価は洞察を与えるが、実装権と IP 保護はそれぞれの契約に依存する。こうして、実装をめぐる構造化された会員経済を伴うオープンな技術参照が生まれる。

これは持続可能性にとって中心的だ。影響力には半導体メーカーのような売上高は必要ないが、仕様を維持し、解釈を明確にし、適合性を発展させ、次世代を調整するための十分な継続的支援が必要だ。リスクは古典的な製品故障ではなく、実装コストを考慮した企業がプロプライエタリな経路のほうが収益性が高いと判断することや、認定コストが幅広い相互運用性の価値よりも速く上昇することだ。

仕様は既存のプロトコルを活用し、パッケージングの決定はメーカーに委ねる

最初の版は、上位のトランザクションをすべて再発明しようとはしなかった。それは、物理的な Die-to-Die リンクと、PCI Express や Compute Express Link などの既存プロトコルおよびロー・トラフィックのためのアダプターを定義した。これにより、新しいパッケージ境界が、システム開発者がすでに知っているソフトウェアモデルとデバイスモデルに接続された。

PCIe は、なじみのあるホスト・デバイスおよび I/O セマンティクスを提供する。CXL は、サポートされるシステムにおいてコヒーレント・メモリとキャッシュ・セマンティクスを追加する。UCIe はいずれの組織や仕様も置き換えるものではなく、それらのパケットと意味を同じパッケージ内のダイ間で移動させる。ある機能はメイン・ダイの外部に現れても、既存の列挙とソフトウェアを利用できる。

その利点は継続性であり、自動的な互換性ではない。パッケージは引き続き、選択したプロトコルのためのファームウェア、列挙、メモリポリシー、エラー処理、ソフトウェアを必要とする。電気的に UCIe 互換の2つのリンクは、PCIe、CXL、またはロー・メッセージを運ぶことができる。あるデバイスクラスを知っているオペレーティングシステムが、別のチップレットを自動的に理解するわけではない。

成熟したセマンティクスの再利用は、UCIe を依存関係にも結びつける。PCIe や CXL の変更は将来のマッピングに影響を与える可能性がある。パッケージ開発者は、リンクと上位プロトコルを認定する必要がある。転送の適合性は、コヒーレンスのエラーや不足しているドライバを修復するものではない。この標準は、既存のソフトウェア契約を新しい物理的境界の間で移植可能にするが、それを単純化するわけではない。

UCIe アーキテクチャは階層化されている。物理層は短い電気チャネルを扱う。Die-to-Die アダプターはリンクを管理し、上位のプロトコルトラフィックとの仲介を行う。その上に、転送されるビットにソフトウェア的な意味を与えるマッピングが存在する。この分離は移植性の核心である：同じリンクアーキテクチャが、プロトコルを特定のパッケージング技術に縛り付けることなく、異なるタイプのトラフィックを運ぶことができる。

アダプターは受動的な殻ではない。仕様書には、リンク管理、エラー、再送、プロトコル適応が記述されている。ダイの境界は、信頼性が低くソフトウェアから見えない配線のように振る舞うべきではない。パッケージは、上位層が経路を信頼する前に、リンク確立、機能通知、エラー封じ込めのための定義された経路を必要とする。

階層化は分岐点も生む。PHY は特定のレートかクラスのみをサポートするかもしれない。アダプターは異なるオプションの信頼性・管理機能を持つかもしれない。エンジンは PCIe は扱えても CXL は扱えないかもしれない。システムベンダーは必要な部分だけを公開するかもしれない。したがって「UCIe」は単一の機能セットではなく、一つの仕様ファミリーを指す。

プロフェッショナルな購入者にとって重要なのは、デバイスが UCIe をサポートしているかではなく、どの世代、パッケージングクラス、レート、幅、プロトコルマッピング、管理機能、テスト条件が実装されているかだ。これらの詳細を宣言、テスト、比較できるようになって初めて、標準は運用インフラとなる。それまでは、一般的な記述は見た目ほど多くのことを語らない。

バージョンの調整はそれ自体が統合負荷を生む。システムベンダーは、ある UCIe 世代とパッケージクラス向けにコントローラを認定するかもしれないが、その一方で、後期のオプション機能を持つ新しいチップレットが届くかもしれない。機能発見とネゴシエーションは共通部分を見つけるが、一方にない機能を作り出すことはできない。したがって、製品チームはサポートされる共通部分、すなわち、ファームウェアとシリコンのリビジョンを通じて安定した、宣言されたレート、プロトコル、管理機能、フォールバック動作を必要とする。ダイをパッケージに固定した後にずれを発見するのは、基板上のコネクタで発見するよりはるかに高くつく。

ソフトウェアの移植性も同じパターンに従う。PCIe と CXL のマッピングは、なじみのあるデバイスモデルを維持できる一方で、ロー・モードやベンダー固有の管理データは再び特別な作業を導入する。パッケージは正しく列挙できても、新しいドライバ、ファームウェア、トポロジ記述、エラールールを必要とするかもしれない。実際のテストは、ソフトウェア契約がサプライヤー変更と次の製品リビジョンを乗り切れるかどうかであり、ソフトウェアがダイを一度見られたかどうかではない。UCIe は転送と機能の枠組みを提供する。機能の命名とライフサイクルポリシーは、他の標準または明示的な合意からもたらされなければならない。

コンソーシアムは2つのクラスを定義している。UCIe-S は、より低い密度とコストの標準パッケージングを対象とする。UCIe-A は、より狭いバンプピッチと高い帯域幅密度を持つアドバンスト・パッケージングを対象とする。こうして仕様ファミリーは、同じインターオポーザ、ブリッジ、ボンディングコストを正当化しない製品にも対応できる。

これは重要なビジネス上の決定だ。最も高価なパッケージングのみを対象とした標準は、高い潜在力を持つが市場は小さい。通常の有機基板のみを対象とした標準は、先進的なコンピューティングシステムに必要な密度に届かないかもしれない。2つのクラスは、相互運用性が異なるコストと物理的制約の下で機能しなければならないことを認識している。

境界は消えない。標準パッケージとアドバンスト・パッケージは、異なるチャネル予算、バンプマップ、許容差を持つ。UCIe-A の設計をそのまま UCIe-S に流用することはできない。インターオポーザ、ブリッジ、有機基板、ハイブリッドボンディング、その他の構造は、パッケージベンダーの決定事項であり続ける。ファウンドリと OSAT のルールも重要であり続ける。

その結果、選択の自由は限られる。UCIe は2つの環境に共通の語彙を作り、プロセス固有の実装を可能にする。しかし、ある環境のチップレットが別の環境で経済的に、機械的に互換性があり、電気的に認定されることを保証するものではない。パッケージング・クラスは製品のアイデンティティに属する。

UCIe 3.0 は、UCIe-S および UCIe-A について、レーンあたりの最大レートを 32 から 48、64 GT/s へ引き上げた。より高いレートは、ダイの端部接続数を比例的に増やさずに全体の帯域幅を増やすことができる。これは、限られたパッケージ面積で計算ロジック、メモリ、アクセラレータが大量のデータをやり取りする AI および HPC パッケージにとって魅力的だ。

仕様上のレートは、測定された製品の結果ではない。利用可能な帯域幅は、レーン数、符号化、オーバーヘッド、チャネル品質、コントローラ、トラフィックパターンに依存する。ビットあたりのエネルギーは実装と条件に依存し、歩留まりは完全なチャネルを繰り返し製造・テストできるかどうかに依存する。ドキュメント上の 64 GT/s は、モードの定義を証明するものであり、あらゆるパッケージでの経済的な動作を証明するものではない。

より高速なモードは検証を厳しくする。高密度では、信号インテグリティ、タイミングマージン、配線、熱設計が難しくなる。デモは成功しても、量産製品は異なる経年変化、電圧、温度条件にさらされる。トレーニングとデモは進歩を示すが、普遍的な実地信頼性の証明にはならない。

ここで価値と限界が交差する。共通の 64 GT/s 目標は、ツールとサプライヤーの投資を集中させ、検証問題を比較可能にする。それでもなお、各パッケージの物理的現実を乗り越えなければならない。

管理容易性は帯域幅と同様に重要になった

高速チャネルはペイロードを運ぶが、マルチダイ・パッケージには、より低速の制御・管理経路も必要だ。UCIe はメインのデータ経路から分離されたサイドバンド機構を含む。バージョン 3.0 は、関連する条件下での定義された到達範囲を最大100ミリメートルに拡大し、管理対象コンポーネントのより柔軟な配置を可能にした。

コンポーネントは、高速リンクが準備できる前に、認識、照会、または安全な状態への移行が必要かもしれない。管理は、診断対象の経路に完全に依存すべきではない。共有リソースとチップレットの予期しない動作がある場合、低レイテンシのシグナルと緊急制御が特に重要だ。

到達範囲の拡大は、64 GT/s のメイン・チャネルが同じジオメトリを利用できるという約束ではない。サイドバンドとデータ経路は異なる目的と電気的要件を持つ。管理はより長い内部距離を橋渡しできる一方、高速リンクは短く高密度のままである。

システム的に見ると、サイドバンド経路は、チップレット統合がデータ転送で終わらないことを示している。パッケージには運用レベルが必要だ。標準は共通の経路を作り出すことができるが、サプライヤーはメッセージの背後にある多くの状態、ポリシー、是正措置を引き続き定義する。共通の神経があっても、すべての臓器が同じ診断を報告するわけではない。

UCIe 1.1 は2023年8月8日に公開され、車載向けヘルスモニタリングと、より低コストなパッケージのオプションを追加した。この版はファミリー内で後方互換性を持ち、最も高価な高性能パッケージを超えて対象を拡大した。

自動車システムは、監視、信頼性、長期使用を、短命なアクセラレータ製品とは異なる重みで重視する。標準に健康データを含めることは、潜在的な障害と現地診断がピーク帯域幅と同じくらい重要であり得ることを認めている。低コストのオプションは、逆の経済的圧力に応えたものだ。相互運用性がプレミアムなパッケージングを前提とするなら、それは限られたものにとどまる。

仕様内の機能は業界での採用を証明するものではない。車両プラットフォーム、認定サイクル、サプライヤーの責任は UCIe の管理外にある。1.1 の重要性は方向性にある。コンソーシアムは、共通の高速リンクが狭いセグメント以上にサービスを提供するには、パッケージングの柔軟性とライフサイクルシグナルを必要とすることを早期に認識した。

このパターンは 2.0 と 3.0 でも続いた。各世代は、以前は非公開で処理されていた統合負荷の一部を標準化した。仕様が成長したのは、最も困難な市場の問題が当初のリンクの内側と外側の両方にあったからだ。2回目の大型改訂で、課題はリンク構築から、パッケージ全体をライフサイクルにわたって運用することへ移った。

UCIe 2.0 は2024年8月6日に公開され、管理容易性のシステムアーキテクチャと 3D パッケージングのサポートを追加した。これは、複数のダイにわたる認識、テスト、テレメトリ、ファームウェア操作、デバッグ、ライフサイクル制御に対処した。これには、管理転送プロトコルと、設計フォーテスト、デバッグ、テレメトリのためのアーキテクチャ（しばしば DFx と総称される）が含まれる。

これにより、相互運用性の意味が変わった。パッケージはデータを正しく転送しても、管理できないことがある。製造チームは組み立て前後のダイをテストする必要がある。ファームウェアチームはバージョンを認識し、更新を調整する必要がある。運用者はテレメトリと障害分離を必要とする。システム開発者は、パッケージ全体を停止させることなく、障害のあるコンポーネントを封じ込められるかどうかを知る必要がある。

共通アーキテクチャは、これらの活動に共有の転送と構造の枠組みを与える。しかし、すべての管理オブジェクト、更新ポリシー、サービス手順を定義するわけではない。あるサプライヤーは詳細な健康データを提供する一方、別のサプライヤーは最小限の状態のみを提供するかもしれない。システムベンダーは、調整された更新を許可するか、パッケージを承認済みイメージに制限するかもしれない。標準はサプライヤー間で管理メッセージを転送するが、それらのポリシー境界を取り除くわけではない。

実際のテストは責任である。テレメトリが限界状態のリンクを示している場合、ダイのサプライヤー、アセンブリパートナー、システム企業の誰が診断するのか。更新が動作を変えた場合、誰がパッケージ全体を再認定するのか。UCIe 2.0 はこれらの問いのための共通の技術的場を作ったが、契約上の回答は提供しなかった。

設計フォーテスト、デバッグ、テレメトリ、および関連するライフサイクル機能は、工場のテーマのように見えるかもしれない。しかし、マルチダイ・システムでは、これらは製品アーキテクチャに属する。パッケージには、異なるプロセス、異なる企業、異なる内部テスト手法のダイが含まれるかもしれない。組み立て後、システムは、障害がダイ、リンク、パッケージ・チャネル、共通の電源、または調整ソフトウェアのいずれに起因するかを判断しなければならない。

UCIe の DFx アーキテクチャは、これらの機能に共通の基盤を提供することを目的としている。管理経路は状態データと診断データを運ぶ。テストとデバッグは、ペアごとにプロプライエタリな接続を必要とする代わりに、共通のパッケージモデルを中心に設計できる。これにより特別な引き継ぎが減り、製造と運用にわたる証拠の取得が容易になる。

標準は、チップレットが実装していない観測可能性を作り出すことはできず、報告された信号が原因を特定することを保証することもできない。あるダイは、他の場所の電源ノイズによって引き起こされたエラーを報告するかもしれない。リンクは、障害への近接性を示さずに限界状態の周りで再トレーニングするかもしれない。アセンブリ企業は、システムベンダーのラボでは再現できない歩留まり問題を見るかもしれない。共通の転送は証拠を移動させるが、それを完成させるわけではない。

DFx は商業的な境界も変える。テストカバレッジ、テレメトリへのアクセス、ファームウェア制御は調達上の論点になる。アクセス可能な診断機能のない UCIe 準拠のダイは、ライフサイクルサポートが充実したプロプライエタリなダイよりも有用性が低いかもしれない。共通アーキテクチャは管理経路を開くが、その質は製品の決定事項であり続ける。

3D 統合は設計空間と故障面を同時に広げる

UCIe 2.0 は、垂直に積層されたダイや、非常に短く高密度な接続を含む 3D パッケージングもサポートした。積層により、計算ロジックとメモリをより近づけ、帯域幅密度を高め、面積を減らすことができる。同時に、熱、機械的ストレス、歩留まりを 2D や 2.5D 構成よりも緊密に結合する。

インターフェース標準は、垂直境界を何が越えるかを決める助けになる。しかし、ボンディングプロセス、熱スタック、電力分配ネットワーク、または最終組み立て前に良品ダイを証明する順序を定義するものではない。これらの決定は、ファウンドリ、アセンブリ・テストベンダー、チップ開発者、システム企業に委ねられたままである。

これは特に修理の場面で顕著になる。ボードレベルのモジュール性は交換を示唆するが、密にボンディングされたマルチダイ・パッケージでは、内部ダイの実用的な現場交換ができない場合がある。管理システムは障害コンポーネントを特定できても、商業的な是正策はパッケージ全体の交換にとどまる。診断の向上は調査時間を減らすが、物理的な修理可能性は変えない。

標準は 3D 統合をサポートするが、容易にするわけではない。ジオメトリが変わっても、通信と管理の境界を認識可能に保つ。周囲の製造課題はより難しくなり、簡単にはならない。

PCIe と CXL は確立されたソフトウェア経路を提供するが、すべてのチップレットが通常の I/O デバイスやコヒーレント・メモリのように振る舞うわけではない。信号処理、ネットワーク、専門のアクセラレータは、連続的またはアプリケーション固有のトラフィックを必要とするかもしれない。ロー・モードは、PCIe や CXL のセマンティクスなしでそれを転送する。バージョン 3.0 は、アナログ・デジタルおよびデジタル・アナログのデータ経路を含む連続マッピングを拡張した。

ローは利用可能なシステムの範囲を広げ、電気的相互運用性と機能的相互運用性の分離を明らかにする。2つのベンダーが同じチャネル要件を満たしても、ロー転送の上で異なるフレーミング、フロー制御、または異なるアプリケーション意味を定義できる。リンクは接続するが、機能には引き続き別個の合意が必要だ。

これは必ずしも失敗ではない。共通の物理的基盤は、専門のアプリケーションプロトコルでも重複作業を減らす。リスクは、「UCIe サポート」がローが提供しない移植性を示唆するときに生じる。購入者は、マッピングが共通プロファイルなのか、二者間契約なのか、プロプライエタリなプロトコルなのかを知る必要がある。

ローは、同じリンク上でより多くの種類のチップレットを可能にする一方、その上に非公開の機能の島を作り出すという、二つの相反する効果を持ち得る。重要なのは、実装者が共通のロー・プロファイルを作成し、独立した統合のための十分な情報を公開するかどうかだ。

半導体業界には、直接の競争相手に見えるインターコネクトの略語が数多くある。PCI-SIG は PCI Express とデバイスモデルを定義する。CXL コンソーシアムはコヒーレント・メモリと関連するプロトコル・セマンティクスを定義する。UCIe はパッケージ内の短い Die-to-Die チャネルと、これらのプロトコルのマッピングを定義する。

この階層構造は、UCIe が急速に前進した理由を説明している。オペレーティングシステムとデバイスメーカーは、すべてのトランザクションに対して完全に新しい意味を受け入れる必要はなかった。標準は、既存のソフトウェア、検証、業界組織とともにセマンティクスを転送した。

これにより UCIe は上位層の変更と複雑さも継承する。CXL 対応パッケージは引き続きコヒーレントなシステム設計を必要とする。PCIe にマッピングされたチップレットは、列挙、ドライバ、エラー処理を必要とする。上位プロトコルのエラーは、パケットがダイの境界を越えたという理由だけで UCIe のエラーになるわけではない。

この関係は、責任のスタックとして理解できる。UCIe は、定義された条件下でビットとプロトコルパケットがパッケージ境界をどのように越えるかに答える。PCIe と CXL は、それらのパケットの多くが何を意味するかに答える。ファームウェアと運用ソフトウェアは、システム全体がどのように見え、利用されるかを決定する。どの単一の層も、3つのすべての結果を主張することはできない。

高速チャネルは、実際の電気的条件下で両側が通信できることを確認する必要がある。仕様の分析は、機能交渉、リンクトレーニング、実行時再校正、スロットリングを説明する。UCIe 3.0 は、プロセス、電圧、温度、動作の変化を補正するために、送信側の再校正と性能関連の改良を追加した。

適応は、パッケージが静的ではないために必要だ。温度は負荷に追従し、電源は変動し、コンポーネントは経年劣化する。リンクは、製造時の状態をライフサイクル全体にわたって仮定する代わりに、マージンを取り戻すか、アクティビティを減らすメカニズムを必要とする。

それでも、トレーニングの成功は限定的な成果だ。それはテスト条件下でのリンクを証明するが、あらゆる負荷、熱サイクル、寿命にわたる信頼性を証明するものではない。再校正はドリフトを修正できても、別の故障メカニズムには影響を与えないかもしれない。スロットリングは性能を犠牲にして動作を維持できる。

購入者には報告義務が生じる。製品仕様は、最大仕様レート、パッケージで検証されたレート、再校正条件、マージン不足時の動作を区別すべきだ。適応型リンクは変化を管理できるが、測定されていない信頼性を保証することはできない。

適合性の証明は購入判断に十分な精度を持つべきだ

ラベルはすべての UCIe 実装を説明することはできない。完全な適合宣言には、少なくとも世代、パッケージングクラス、データレート、レーン構成、プロトコルマッピング、オプションの管理機能、テスト条件が必要だ。2つの製品が両方とも UCIe を実装していても、望ましい性能点で利用可能な共通点を持たないことがある。

成熟したインターコネクトプログラムは、適合性を定義された機能とテスト手順に結び付ける。公開された UCIe エコシステムは、基準日時点でこの証拠基盤をまだ構築中だった。相互運用性の作業、サミット、ウェビナー、コントローラ/PHY デモはあったが、文書には認定製品の完全な公開リストはなかった。

有用なプログラムは、最も単純な立ち上げ以上のテストを行う必要がある。エラー動作、機能交渉、管理、サポートされるプロトコルプロファイルが定義されなければならない。パッケージングクラスとチャネル条件も重要だ。あるペアの結果は、証拠なしに他のレートやパッケージに転用すべきではない。

普遍的なリストがないことは、実装が架空であることを意味するのではなく、公開された証拠が若いことを意味する。メンバーのデモは、独立したツールとインターフェースの連携を示すことができる。量産認定には、再現性、量、動作条件、そして後の障害時の明確な責任が必要だ。

この区別は購入者とコンソーシアムの両方を守る。過度に拡大解釈された UCIe ラベルは、標準が本来防ぐべきでないことについて失望を生む。正確なプロファイルは実際の性能を可視化する。残る障壁は証明である：購入者は、正確にテストされた構成とその限界を知らなければならない。

最初の版以降、活動は宣言から実装へと移った。メンバーは、コントローラ、PHY IP、検証プラットフォーム、パッケージング作業を発表した。イベントでは、UCIe のデモと、信号インテグリティ、アドバンスト・パッケージング、相互運用性に関するセッションが行われた。2025年の資料はこれを採用の拡大と評価した。

デモは焦点を絞った問いに答える：このコントローラはその PHY と通信できるか？テストプラットフォームは定義されたエラーを認識できるか？チャネルは実験室で目標レートに達するか？これらは、実装の不確実性を減らし、仕様解釈の違いを明らかにする貴重な問いだ。

量産パッケージはより多くの問いに答える：複数のベンダーは良品ダイを予定通りに供給できるか？組み立ては歩留まりと性能目標を達成するか？ファームウェアはすべてのコンポーネントを安全に更新できるか？ソフトウェアはリビジョンを超えて移植性を維持するか？限界品質のダイの断続的な障害時に、誰がシステムを交換するのか？デモは証拠の一部を提供するが、完全な回答ではない。

公開文書には、出荷されたマルチベンダー・パッケージの完全な棚卸しは含まれていない。確実に言えるのは、エコシステムが実装能力を構築しているということだ。既存の証拠は普遍的な市場には十分ではない。

インテグレータは、リンクが立ち上がるかどうかだけでチップレットを評価することはできない。ダイは、機能、プロセスウィンドウ、ライフサイクルについて良好とみなされる必要があり、ウェーハからアセンブリ、システムに至るまでの証拠が求められる。統合後に部品が不良となった場合、他のダイとパッケージング作業も一緒に失われる可能性がある。

既知良品ダイ（Known-good Die）の証明は、商業的かつ製造上の要件だ。サプライヤーは、何がテストされたか、どのマージンが適用されるか、結果がどのように提示されるか、全体の障害時に誰が損失を負うかを合意しなければならない。UCIe の管理と DFx はテスト・テレメトリデータを転送できるが、各ダイの内部機能を認定したり、責任を割り当てたりすることはない。

これは垂直統合型パッケージの利点だ。企業はダイ設計、テスト境界、組み立て、保証を管理できる。マルチベンダー・パッケージは、非公開の引き継ぎを明示的な証拠と契約に変換しなければならない。

欠けている市場層は地味だが、モジュール性が中小サプライヤーに届くかどうかを左右する。共通の電気リンクは1つの障壁を下げる。既知良品の保証は、購入者がパッケージの残りを未知の部品に委ねられるかどうかを決定する。

セキュリティ、保証、ソフトウェアが市場の形成を左右する

マルチベンダー・パッケージは、異常に緊密な信頼境界を作り出す。チップレットは大量のデータを交換し、管理経路を共有し、エンドシステムが単一のデバイスとして扱うリソースに影響を与える。侵害された、または悪意のあるダイは、自身の機能以上のものを危険にさらし、制御フローとデータフローへのアクセス経路になり得る。

その後の管理容易性の作業は、制御された認識、ファームウェア操作、緊急シグナルをサポートできる。メンバーの文書は、セキュリティ強化を継続的なテーマとして挙げている。しかし、これらのメカニズムは完全なパッケージ・セキュリティ・アーキテクチャを定義するものではない。デバイス ID、セキュアブート、ファームウェアの来歴、アテステーション、分離、鍵管理、サプライヤーのセキュリティは、システム側の責任である。

安全な転送はメッセージを保護するが、認可されたが侵害されたチップレットは悪意を持って行動できる。強力な ID はどのダイが存在するかを示すが、そのファームウェアが安全であることは示さない。アテストされたコンポーネントは、許可されたアクセスを悪用できる。セキュリティは、信頼が確立された後に何が許可されるかに依存する。

将来の世代はより多くのセキュリティ機能を定義するかもしれないが、時期と形態は証明されていない。今日、「UCIe 準拠」はパッケージのセキュリティ認証ではない。購入者は、各サプライヤーとシステム全体について独自の信頼モデルを必要とする。

UCIe はオープンな業界標準と呼ばれ、仕様は評価条件の下で公開請求が可能だ。これにより、単一のインターフェース所有者なしに、調査、共通ツールの概念、互換性の議論が可能になる。

サプライチェーンの残りは強く集中したままだ。先進的なウェーハ製造、ハイブリッドボンディング、インターオポーザ、アセンブリ、テスト装置、EDA は、少数の企業と地域に由来する。輸出管理と産業政策は、ノード、ツール、IP へのアクセスに影響を与える。共通リンクは新しいファウンドリやパッケージングラインを生み出さない。

オープンな標準はオープンな実装を要求しない。コントローラ、PHY、チップレット、ファームウェア、または設計キットはプロプライエタリであり得る。評価契約は、読むことと実装ライセンスを分離する。企業は共通リンクをサポートしつつ、その上も下も支配し続けることができる。

これは現実的な強みになり得る。UCIe は二者間の作業を減らすためにオープンソースを必要としない。リスクは修辞的なものだ：ある層の開放性が、閉じた層での競争や移植性として喧伝される。パッケージは層ごとに調査されなければならない。適合性が限定されて説明されれば、残るのは信頼、商業的サポート、統合リスクの配分だ。

プロモーターは UCIe に信頼性を与える。彼らは技術を持ち込み、インターフェースを構築し、パッケージを認定し、需要を生み出す。同時に、彼らはオープン市場に代わる最強の選択肢を持っている。大手プロセッサ、クラウド、ファウンドリ企業は、有利であればプロプライエタリなチップレット、内部リンク、パッケージフローを利用できる。

これによって参加が不誠実になるわけではない。企業は、選択した外部境界で UCIe を利用し、内部では非公開のインターフェースを維持できる。共通のプロトコル転送は、差別化されたトポロジ、メモリアーキテクチャ、管理ポリシーと共存できる。採用は層状かつ選択的であり得る。

ガバナンスの課題は、スタック全体を管理しない企業にとって共通の境界を有用に保つことだ。理事会の多様性は役立つが、作業部会における貢献の重み、投票、紛争解決に関する完全な公開記録は欠けている。同じ大きさのロゴが同じ交渉力を意味するわけではない。

標準は、最大手の非公開の利益にもかかわらず成功し得る。より厳しいテストは、中小サプライヤーがチップレットを構築し、限定されたプロファイルを証明し、パッケージングへのアクセスを獲得し、制御不能な法的・統合リスクを購入者に転嫁せずに複数のシステムに販売できるかどうかだ。

商業的な交換可能性のためには、購入者はリンク仕様以上のものを必要とする。部品には機能メタデータが必要だ：役割、プロトコルとレート、認識、ファームウェア要件、ヘルスレポート。パッケージ開発者には、電気的、熱的、機械的、性能上の限界が必要だ。ソフトウェアには安定した列挙と管理が必要だ。調達には価格、数量、ライフサイクル、保証、責任が必要だ。

UCIe は、機能発見、プロファイル宣言、管理容易性を通じて一部を提供できる。しかし、完全な機能 API や普遍的な製品カタログを定義するものではなく、保証を割り当てるものでもなく、ファウンドリの容量を保証するものでもない。資料とイベントは市場の目標について語るが、証拠は完全な取引層の手前で終わっている。

だからこそ UCIe は重要であり、同時に不十分でもある。標準は市場の条件を作るが、市場自体を作るわけではない。サプライヤー、ファウンドリ、ツールベンダー、購入者が、インターフェースを投資可能で、テスト可能で、サポート可能なものにしなければならない。

成熟した市場では、責任は読み取れる。障害時には、チップレット、リンク、アセンブリ、ファームウェア、統合のいずれが原因かが明確になり、契約がコストを割り当てる。これらの引き継ぎがなければ、技術的なモジュール性は購入者の統合リスクを高め得る。

生産上の引き継ぎが UCIe の価値を決める

コンソーシアムは、2022年の基本から、2023年の自動車向けと低コストオプション、2024年の管理容易性と3D、2025年の 64 GT/s、拡張ロー、管理へと進んだ。2026年には、公開の取り組みは新しい番号よりも、教育、実装、検証に重点が置かれた。

この流れは、若い標準が統合のどこが壊れるかを学ぶ過程を示している。物理リンクにはプロトコルマッピングとパッケージングクラスが必要だった。パッケージにはヘルスモニタリング、管理容易性、DFx、3D が必要だった。より高速なレートには再校正、性能制御、より柔軟なサイドバンドが必要だった。それぞれの追加は、非公開の想定を共通の技術契約に持ち込んだ。

次の証明は別の証拠クラスからもたらされる。限定された適合性は、どのプロファイルが機能するかを示さなければならない。独立したサプライヤーは、組み立てとシステム検証に合格するダイを供給しなければならない。ソフトウェアは特別な再開発なしに認識・管理できなければならない。契約は障害とライフサイクルの責任を割り当てなければならない。中小サプライヤーは、すべての不確実性を購入者に転嫁せずに参加できなければならない。

UCIe はチップレットをめぐる議論をすでに変え、かつてはプロプライエタリだった境界に信頼できる共通リンクを置いた。それが市場になるかどうかは、最初のベンダー横断的な障害が、垂直統合型ベンダーに後戻りすることなく診断・割り当て・解決できるかどうかで決まる。そのとき、有望なインターフェースはインフラになる。