要旨

  • UCIe は、チップ間の物理層、アダプタ、プロトコル、リンク管理の共通ルールを定める。機能、パッケージング、ベンダーの責任はその対象外である
  • バージョン1.0から3.0まで、この標準は低コストのパッケージングオプション、自動車向けモニタリング、3D、管理、64 GT/s のデータレートへと拡張されてきた
  • その商業的価値は、再現可能な適合プロファイル、実際にサポートされるマルチベンダーパッケージ、障害時の明確な責任分担によって測られるだろう

64 GT/s 版は、速度競争をシステムの問題へと変えた

2025年8月5日、公に存在してからわずか3年余りの標準化コンソーシアムが、3つ目の主要仕様を公開した。Universal Chiplet Interconnect Express（一般に UCIe と略される）は、標準パッケージングとアドバンストパッケージングを対象としたチャネルクラスに、48 GT/s と64 GT/s を追加した。この版はまた、低速補助チャネルの到達範囲を拡大し、連続ローデータ転送を広げ、管理コマンドを強化した。目玉は速度だった。しかし最も示唆に富む論点は、独立に設計された複数のチップで構成されるパッケージを、管理可能なシステムとして機能させる試みだった。

この区別は重要だ。なぜなら、より高速なリンクはチップレット製品の一要素にすぎないからだ。購入者は依然として、各チップの機能、消費電力、冷却方法、それを発見するソフトウェア、ファームウェアの更新方法、コンポーネントが故障したときに何が起きるか、どのベンダーが保証を担うのかを知る必要がある。UCIe は、チップ間で情報を移動させるための共通ルールと、その移動を取り巻く管理の一部を提供する。UCIe だけでは、無関係なシリコンの集合体を完成したプロセッサに変えることはできない。

コンソーシアムは公に「オープンなチップレットエコシステム」を掲げている。この表現は志としては有用だが、すでに形成された市場の説明と誤解される恐れがある。このプロフィールのために検討した公開資料には、実際に納入された UCIe マルチベンダーパッケージの完全な独立調査も、認証済み製品の網羅的なリストも、設計者が交換可能なチップを選ぶためのカタログもなかった。そこにあったのは、仕様、メンバー間の活動、実装トレーニング、デモンストレーションだった。これらのステップは必要である。しかし、それらは反復可能な購入や確立された量産と同義ではない。

したがって、指針となる問いは、チップレットの将来的重要性についての問いよりも狭い。チップレットは、複雑なシステムを分割する手段としてすでに重要である。問うべきは、共有リンクが、その周囲のパッケージが高度に統合された対象であり続けるとき、実際にどのようなモジュール性を生み出せるかである。UCIe はチップ間の境界で話される共通言語になるかもしれないが、システムの物理的・商業的次元の多くはプロプライエタリのままだ。したがって、このインターフェースは、単一の交換可能性の約束としてではなく、一連のバトンタッチとして評価されるべきである。

「交換可能性」という言葉は、複数の試練を一つに圧縮している。第一は電気的試練だ。送信機、受信機、パッケージのチャネルは、同じ物理プロファイルでリンクを確立できるか。第二はプロトコルの試練だ。両端は同じ PCIe、CXL、またはローマッピングを理解しているか。第三は運用上の試練だ。パッケージは、互換性のある管理機能を通じてチップを発見・テスト・監視・更新できるか。第四は機能とソフトウェアの試練だ。チップレットは、ファームウェア、ドライバ、アプリケーションが利用方法を知っている動作を公開しているか。第五は商業上の試練だ。購入者は、テスト証拠、量産実績、サポート、保証を十分に備えたコンポーネントを調達し、製品に統合できるか。

UCIe は、最初の二つの約束に直接取り組み、第三の約束にもますます対応している。UCIe は、電気的ネゴシエーション、プロトコル転送、管理のバトンタッチを、二者間の非公開契約への依存から解放することができる。第四の層は、PCIe、CXL、製品固有のソフトウェアに部分的に属する。第五の層は、ベンダー、ファウンドリ、アセンブラ、購入者のものだ。

これらの層を混同すると、正反対の二つの誤りが生じる。第一の誤りは、UCIe だけでは完成した市場を生み出さないとして標準を退けることだ。これは、繰り返し発生する物理的・プロトコル上の障壁を取り除く価値を無視している。第二の誤りは、二つのチップが適合リンクを確立しただけで市場は完成したと宣言することだ。これは、そのリンクをサポートされるシステムに変えるために必要なすべての決定を軽視している。

専門的な評価は、どの約束が証明されたかを明確にすべきだ。物理インターフェースのデモは、プロトコルのペアリングよりも証明力が弱い。プロトコルのペアリングは、ライフサイクル全体で管理可能なパッケージよりも証明力が弱い。管理可能なパッケージは、ソフトウェアの書き換えや契約の再交渉なしに交換可能なコンポーネントよりも証明力が弱い。この階層は UCIe への批判ではない。それは、コンソーシアムが何を掌握し、何を市場に委ねているかを示す最も明確な方法だ。

この五層の読み方は、進歩が「プラグアンドプレイ」の購入に見えなくても本物であり得る理由も説明する。仕様のバージョンは最初の三つの約束を強化できる一方で、第四と第五の約束はゆっくりと成熟する。チップレット市場は一つの発表で出現するわけではない。それは、信頼を生むほど反復可能になった、より狭いバトンタッチの連続によって構築されるだろう。

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

モノリシックチップは、システムの機能を一枚の大きなシリコンに配置する。この構成は内部通信を簡素化できるが、製造プロセスを一つに固定する。最先端ノードの設計、マスク、歩留まりの制約が強まると、すべてのブロックを大きなチップにまとめることは高価で困難になる。チップレットは別の道を提供する。計算、メモリ、入出力、アナログ機能、セキュリティ、アクセラレータを分離し、それぞれの役割に適したプロセスで製造し、パッケージ化されたシステムに統合することができる。

分割は複雑さを取り除くわけではない。その一部をチップからパッケージへ移すのだ。境界ごとに、シグナリング、クロック、エラー処理、電源、熱設計、テスト網羅性、ソフトウェアから見える動作が必要になる。大きなモノリシックチップは面積とともに歩留まりを失うことがある。マルチチップパッケージは、統合されたチップの一つが欠陥品、限界品、または組み立て不良だったために価値を失うことがある。設計者は製造ノードを混在させ、ブロックを再利用する可能性を得る一方で、パッケージレベルの新たな依存関係を受け入れる。

だからこそ「モジュール式」という言葉には注意が必要だ。プリント基板がモジュール式であるのは、コンポーネントに成熟した物理フォーマット、電気的慣習、識別可能な機能、商業的条件があるからだ。ベンダーはデータシートを公開する。流通業者は部品を在庫する。インテグレータはコネクタと障害境界を知っている。アドバンストパッケージ内のチップレットは、はるかに狭い物理環境に置かれ、エラーに対する許容度がはるかに低い。その隣のチップと電源、熱、管理、高速チャネルを共有することもあり、組み立て後は基板実装部品のように検査や交換ができない。

UCIe は、最も困難で繰り返し発生する境界の一つ、つまりチップ間の短く高密度なリンクに取り組む。その標準化は、インターフェースの再発明を減らし、ツール、IP ベンダー、インテグレータに共通のターゲットを与えることができる。しかし、他の統合問題を消し去るわけではない。この標準の価値は、特定のカテゴリの二者間エンジニアリングを減らすことから来ており、パッケージを独立部品の緩い集合体に変えることから来るのではない。

共通インターフェースが登場する前は、企業はシステムを複数のチップに分割しながら垂直統合を維持できた。チップ間のリンクは、独自の電気的仮定、プロトコル、パッケージプロセス、テストフローを持つことができた。この自由は、特定の製品のレイテンシ、電力、面積を最適化することを可能にする。一方で、他社のチップを追加するには、非公開の契約を学び、実装する必要があった。

プロプライエタリリンクの罠は技術的であると同時に経済的でもある。企業は自社製品をチップレットベースと説明しながら、有用なモジュールを他者に提供しないことがある。再利用は自社の製品世代を越えて進む一方、外部市場には閉じたパッケージしか見えない。アーキテクチャは企業境界の内側ではモジュール式になり、外側では分割不能になる。

UCIe の創設者たちは、システム全体を規定せずに共通の境界を確立しようとした。コンソーシアムは物理層の動作、アダプタ、プロトコルマッピングを定義する。ベンダーはチップレットの機能、パッケージの製造、公開する機能を自由に選べる。提案された共通層は、異なる製品に役立つほど薄くなければならず、同時に、独立したリンク実装が同じ仕様を満たすほど正確でなければならない。

このバランスは微妙だ。曖昧すぎる標準は、あらゆるペアを特注プロジェクトのままにしておく。詳細すぎる標準は、選択肢を固定し、初期の実装者を優遇し、差別化を減らす可能性がある。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 が挙げられている。

この幅広さがコンソーシアムの最大の制度的強みだ。チップ間リンクは、単一のプロセッサ設計者の行動だけでは有用にならない。ファウンドリは、製造できるチャネルとパッケージルールを必要とする。組立・テスト企業は、認定可能なフローを必要とする。EDA ツールベンダーとインターフェース IP プロバイダーは、仕様をコントローラ、物理層、検証製品に変える必要がある。クラウド・システム企業は、実際のワークロードでパッケージを採用する必要がある。

同じリストには競合するインセンティブが集まっている。ハイパースケーラーは、私的なシステムアーキテクチャを維持しながら再利用可能なブロックを望むかもしれない。ファウンドリは、設計キット、生産能力、パッケージングのノウハウをプロプライエタリに保ちながら、共通の電気リンクを支援するかもしれない。既存のプロセッサメーカーは、サプライヤーの選択肢を広げることから利益を得る一方で、特定の用途ではより高性能な社内リンクを持つかもしれない。コンソーシアムは、これらの利益が一つの境界で合意する場を作る。しかし、それらを同一にするわけではない。

だからこそ、会員資格は導入の証明ではない。プロモーターのロゴは、運営と技術作業への参加を示す。コントリビューターはツールや IP を提供するかもしれない。アダプターは標準を評価するかもしれない。これらのいずれの地位も、それだけで、名前のある量産パッケージに独立系ベンダーから購入した UCIe チップレットが含まれていることや、それらの部品が商業的に交換可能であることを証明するものではない。この制度的境界は、技術スタックが複数のパッケージ選択肢で使用可能であり続ける場合にのみ価値を持つ。

UCIe の現在の理事会では、Intel の Debendra Das Sharma が理事会会長、Samsung の Cheolmin Park がコンソーシアム会長、Arm の Dong Wei が書記、ASE Group の Lihong Cao が会計を務めている。他の理事は Google Cloud、Qualcomm、Alibaba Cloud、Meta、TSMC、AMD、NVIDIA を代表している。これらの運営上の役職は会員組織を通じて担われている。それらは、仕様の個人的所有権や、その技術的内容への排他的な功績を与えるものではない。

非営利という形態は、会員資格、知的財産契約、技術作業に法的な拠点を提供する。プロモーター、コントリビューター、アダプターの各レベルは、異なる参加方法を提供する。公開された評価用コピーは、第三者にアーキテクチャを閲覧可能にする。ただし、評価条件は、調査のためのアクセスと、実装および会員資格に伴うより広い権利を区別している。この契約は限定的な社内評価ライセンスを付与するものであり、仕様を特許フリーのパブリックドメイン設計として提示するものではない。

この境界は中小サプライヤーにとって重要だ。公開文書はインターフェースを学ぶコストを下げる。しかし、法的な不確実性、検証ツールの必要性、超高データレートパッケージに必要なエンジニアリングを排除するわけではない。新興企業は、プロモーターと同じ仕様を読むことはできても、同じ特許ポートフォリオ、アセンブラとの関係、検証予算を持っているとは限らない。

UCIe は会費で運営されているが、ここで使用した公開資料には、監査済みの収益、準備金、職員数、仕様世代ごとの支出は含まれていない。この欠如は、財務規模に関する主張を制限する。しかし、この標準をめぐる経済的利害を減らすものではない。

コストのかかる作業は、会員企業とサプライヤーの側で行われる。メーカーはコントローラとチップを設計する。物理層ベンダーは再利用可能な IP を生み出す。ツールベンダーはモデリングと検証を追加する。ファウンドリとアセンブラはプロセスを開発する。システム企業は統合、認定、ソフトウェアに資金を投じる。共通リンクは重複作業を減らすことができるが、その節約はコンソーシアムの収入ではなく、製品の経済性に現れる。

会員資格は権利とリスクも配分する。プロモーターとコントリビューターは、コンソーシアムの契約の下で開発に参加する。公開された評価アクセスは第三者に仕様のビューを提供する一方、実装権と知的財産保護は適用される契約に依存する。その結果は、実装のために構成された会員経済に囲まれたオープンな技術リファレンスだ。

これは持続可能性にとって重要だ。コンソーシアムは影響力を行使するために半導体メーカーの収益プロファイルを必要としない。必要なのは、仕様を維持し、解釈を解決し、適合性を開発し、次世代を調整するための継続的な支援だ。リスクは典型的な製品の失敗ではない。実装コストを負担する企業が、プロプライエタリな道の方が収益性が高いと判断すること、あるいは、認定コストが相互運用性の拡大による価値よりも速く上昇することだ。

仕様は実績あるプロトコルを再利用し、パッケージの選択はメーカーに委ねる

最初の仕様は、パッケージ内で運ばれるすべての高レベルトランザクションを発明しようとはしなかった。それは、PCI Express や Compute Express Link などの確立されたファミリー、およびローデータを運ぶことができるチップ間物理層とアダプタを定義した。この選択は、新しいパッケージ境界を、開発者がすでに理解しているソフトウェアおよびデバイスモデルに結び付けた。

PCIe は、ホスト、デバイス、入出力に関するおなじみのセマンティクスを提供する。CXL は、サポートされるシステムに、コヒーレントメモリとキャッシュのセマンティクスを追加する。UCIe はこれらの構成や仕様を置き換えるものではない。UCIe は、そのパケットと意味が単一パッケージ内の複数のチップを横断できるようにする。これにより、チップレットは、その機能がメインチップから離れたという理由だけで、まったく新しいホストモデルを要求することなく、既存の列挙・ソフトウェア環境に現れることができる。

利益は継続性であり、自動的な互換性ではない。パッケージには依然としてファームウェア、列挙、メモリポリシー、エラー処理、選択されたプロトコルを理解するソフトウェアが必要だ。二つの UCIe リンクは電気的に互換性があっても、一方は PCIe、もう一方は CXL、三つ目はローメッセージを運ぶかもしれない。あるデバイスクラスをサポートするオペレーティングシステムは、別のチップレットの機能をまったく無視するかもしれない。

成熟したセマンティクスの再利用は、UCIe を依存関係の連鎖に置く。PCIe と CXL の進化は将来のマッピングに影響を与えるかもしれない。設計者はリンクと上位プロトコルの両方を認定する必要がある。トランスポートの適合性は、コヒーレントメモリの設計ミスやドライバの欠如を修正しない。この標準は、既存のソフトウェア契約を新しい物理的境界に移植可能にする。しかし、その契約を自明にするわけではない。

UCIe のアーキテクチャは層状になっている。物理層はチップ間の短い電気チャネルを処理する。Die-to-Die アダプタはリンクを管理し、上位プロトコルトラフィックとの仲介を行う。その上には、転送されたビットにソフトウェアから見える意味を与えるマッピングがある。この分離は移植性に不可欠だ。同じ一般的なアーキテクチャが、プロトコルを単一のパッケージ技術に固定することなく、複数のタイプのトラフィックを運ぶことができる。

アダプタは受動的なラッパーではない。資料は、リンク管理、エラー、再送、プロトコル適応の責任を担うものとして説明している。これらの機能が重要なのは、チップ間の境界が、ソフトウェアに見えない信頼性の低い電線のように振る舞うことはできないからだ。上位層が経路を信頼する前に、パッケージはリンクを確立し、機能を通知し、障害を封じ込めなければならない。

層構造はまた、複数の分岐点も生み出す。物理インターフェースは特定のデータレートまたはパッケージクラスをサポートするかもしれない。アダプタは異なる信頼性・管理のオプション機能セットを実装するかもしれない。プロトコルエンジンは PCIe を受け入れても CXL を受け入れないかもしれない。メーカーは自社製品に役立つサブセットだけを公開するかもしれない。したがって、UCIe という言葉は一様な機能セットではなく、仕様のファミリーを指す。

購入者とインテグレータにとって、正しい質問は、デバイスが「UCIe をサポートしている」かどうかではない。世代、パッケージクラス、データレート、幅、プロトコルマッピング、管理機能、テスト条件を知る必要がある。これらの詳細が宣言・テスト・比較できるとき、標準はインフラストラクチャになる。それまでは、一般的なサポート主張は、見た目ほど多くのことを語らない。

バージョンの整合は独自の統合負荷を生む。システム企業は、ある世代の UCIe とパッケージクラスでコントローラを認定し、その後、より新しいオプションを持つ新しいチップレットを受け取るかもしれない。機能のディスカバリとネゴシエーションは共通の基盤を特定できるが、どちらかの端に存在しない機能を作り出すことはできない。したがって、製品チームはサポートされる共通集合を必要とする。つまり、データレート、プロトコル、管理機能、フォールバック動作を宣言し、ファームウェアとシリコンのリビジョンにわたって維持するのだ。チップがパッケージにコミットされた後に発見された非互換性は、基板コネクタで発見された欠陥よりもはるかに高くつく。

ソフトウェアの移植性も同じ論理に従う。PCIe と CXL のマッピングはおなじみのデバイスモデルを維持できるが、ローモードやベンダー固有の管理データは再び特注作業を導入する。パッケージは正しく列挙されても、新しいドライバ、ファームウェア、トポロジ記述、障害ルールを要求するかもしれない。有用なテストは、同じソフトウェア契約がベンダーの交代と次の製品リビジョンに耐えられるかどうかだ。UCIe はトランスポートと機能の枠組みを提供する。機能の命名とライフサイクルポリシーは、他の標準または明示的な契約から来なければならない。

コンソーシアムは二つの主要なチャネルクラスを定義している。UCIe-S は標準パッケージング、特に低コストで低密度のアプローチを対象とする。UCIe-A は、より狭いマイクロバンプピッチとより高い帯域幅密度を持つアドバンストパッケージングを対象とする。この区別により、同じ仕様ファミリーが、同じインターポーザ、ブリッジ、接合プロセスを正当化できない製品にも役立つ。

これは重要な商業的選択だ。最も高価なパッケージのみに限定された標準は、性能の可能性は高いが市場は狭い。通常の有機基板のみのために設計された標準は、アドバンストコンピューティングに必要な密度を欠くかもしれない。二つのクラスは、相互運用性が異なる物理的・経済的制約の下で機能しなければならないことを認めている。

しかし、それらは制約を除去しない。標準パッケージとアドバンストパッケージでは、チャネル予算、マイクロバンプの配置、製造公差が異なる。UCIe-A 用に認定された設計は、証拠なしには UCIe-S へ移せない。メーカーは依然として、インターポーザ、ブリッジ、有機基板、ハイブリッド接合、または別の構造を選ぶ。ファウンドリと組立・テスト企業のルールが依然として決定的だ。

結果は有用だが限定的な選択肢だ。UCIe は二つの環境に共通の語彙を与えながら、プロセス固有の実装を許容できる。一方で、一方のために設計されたチップレットが、他方で経済的、機械的に互換性があり、電気的に認定されることを約束するものではない。パッケージクラスは製品のアイデンティティの一部だ。

UCIe 3.0は、UCIe-S と UCIe-A の両方で、ライン当たりの最大規定データレートを32 GT/s から48および64 GT/s に引き上げた。より高速な転送は、チップエッジの接続数を比例的に増やさずに、総帯域幅を増やすことができる。これは、計算、メモリ、専用アクセラレータが限られた周辺で大量のデータをやり取りする AI や計算集中型ワークロードにとって魅力的だ。

仕様上のデータレートは製品の測定値ではない。有用な帯域幅は、ライン数、コーディング、プロトコルオーバーヘッド、チャネル品質、コントローラ、トラフィックに依存する。ビット当たりのエネルギーは実装と条件に依存する。歩留まりは、チャネル全体を繰り返し製造・テストする能力に依存する。文書中の64 GT/s という記述はモードが定義されていることを証明する。すべてのパッケージがそれを経済的に利用できることを証明するわけではない。

より高速なモードは検証を強化するかもしれない。シグナルインテグリティ、タイミングマージン、パッケージ内の配線、熱設計は密度とともに複雑になる。ある実装はデモに成功しても、その後、経年変化、電圧、温度の異なる条件に直面するかもしれない。メンバーのトレーニングとデモンストレーションはエンジニアリングの進歩を示すものであり、サービス中の普遍的な信頼性の実績ではない。

ここで価値と限界が交わる。64 GT/s という共通ターゲットは、ツールとベンダーの投資を集中させる。検証問題を比較可能にする。しかし、このターゲットは、それぞれのパッケージの物理的現実を乗り越えなければならない。

管理は帯域幅と同じくらい重要になった

高速チャネルはペイロードを運ぶが、マルチチップパッケージには低速のコマンド・管理経路も必要だ。UCIe はメインチャネルとは別の補助機構を規定している。バージョン3.0は、関連する条件下で、その規定範囲を100ミリメートルまで拡大し、パッケージ内の管理対象コンポーネントの配置に柔軟性を持たせた。

この経路が重要なのは、コンポーネントが高速リンクの準備ができる前に、発見、問い合わせ、安全な状態への移行が必要になることがあるからだ。管理は、診断しようとしている経路に完全に依存すべきではない。低レイテンシのシグナリングと緊急コマンドは、複数のチップレットがリソースを共有し、その一つが誤動作したときに特に重要になる。

範囲の拡大は、メインチャネルの64 GT/s が同じジオメトリに従えることを約束するものではない。補助チャネルとデータチャネルは目的と電気的制約が異なる。パッケージは、高速リンクを短く高密度に保ちながら、前者をより長い内部距離で使用できる。

システムの観点では、このチャネルは、統合がデータ転送で終わらないことを示している。パッケージには運用計画が必要だ。標準はその計画に共通の経路を提供できるが、各ベンダーは依然としてメッセージの背後にある状態、ポリシー、是正手段の多くを定義する。共通の神経があっても、すべての器官が同じ診断を下すとは限らない。

2023年8月8日に公開された UCIe 1.1は、自動車関連のヘルスモニタリングと、低コストパッケージを目指すオプションを追加した。この進化はファミリー内で後方互換性を保ち、最も高性能で高価なパッケージを超えてターゲットを広げた。

自動車システムは、モニタリング、信頼性、サービス寿命に異なる重みを置く。ヘルス情報の導入は、チップ間リンクが、潜在的な障害と運用中の診断がピークデータレートと同じくらい重要であるシステムに置かれ得ることを認めていた。低コストオプションはもう一つの圧力に応えた。相互運用性は、常にハイエンドパッケージングを要求するなら範囲が狭い。

仕様に関数が存在することは、業界による採用を証明しない。自動車プラットフォーム、認定サイクル、ベンダーの責任は UCIe の管理外にある。バージョン1.1の重要性はその方向性にある。コンソーシアムは、共通の高速リンクが、狭いセグメント以上に役立つために、パッケージの柔軟性とライフサイクルシグナルを提供しなければならないことをすでに理解していた。

同じ動きは2.0と3.0でも続いた。各世代は、以前は非公開の合意に委ねられていた統合負荷の別の部分を標準化した。標準が成長したのは、その最も困難な問題が、当初のリンクの周囲にもリンク自体の中にもあったからだ。2番目の主要リビジョン以降、主題はリンクの確立から、パッケージの長期にわたる運用へと移っていた。

2024年8月6日に公開された UCIe 2.0は、管理アーキテクチャと3D サポートを追加した。管理作業は、複数のチップにわたるディスカバリ、テスト、テレメトリ、ファームウェア操作、デバッグ、ライフサイクル制御を対象としていた。そこには Management Transport Protocol と、DFx という略称でまとめられたテスト・デバッグ・テレメトリのための設計アーキテクチャが含まれていた。

この変更は相互運用性を再定義した。パッケージはデータを正しく転送しても、運用不能なままかもしれない。製造チームは組み立て前後のチップをテストする必要がある。ファームウェアチームはバージョンを識別し、更新を調整する必要がある。オペレータはテレメトリと障害の切り分けを必要とする。設計者は、故障したコンポーネントがパッケージ全体を停止させずに封じ込められるかどうかを知る必要がある。

共通アーキテクチャはこれらの活動に共有トランスポートとモデルを提供する。しかし、すべての管理オブジェクト、更新ポリシー、保守手順を定義するわけではない。あるベンダーは豊富なテレメトリを公開し、別のベンダーは最小限の状態しか公開しないかもしれない。あるメーカーは調整された更新を許可し、別のメーカーは承認されたイメージのセットにパッケージをロックするかもしれない。この標準はベンダー間の管理メッセージを可能にするが、ベンダーのポリシー境界を除去しない。

実際の試練は責任だ。テレメトリが限界リンクを示したとき、診断はチップベンダー、アセンブラ、システムメーカーのどれに属するのか。更新が動作を変えたとき、パッケージ全体を再認定するのは誰か。UCIe 2.0はこれらの質問をする共通の場を作った。契約で解決したわけではない。

テスト、デバッグ、テレメトリ、その他のライフサイクル機能のための設計は、工場の仕事に追いやられがちだ。マルチチップシステムでは、それは製品アーキテクチャの一部になる。パッケージには、異なるプロセスで製造され、異なる企業から供給され、異なる社内メソッドでテストされたチップが含まれることがある。組み立て後、システムは、障害がチップ、リンク、パッケージチャネル、共有電源、全体を調整するソフトウェアのどこにあるのかを判断しなければならない。

UCIe の DFx アーキテクチャは、これらの機能に共通の枠組みを提供しようとしている。管理経路は状態と診断を運ぶことができる。テストとデバッグは、ペアごとのプロプライエタリ接続ではなく、共通のパッケージモデルに依存できる。これは特注のバトンタッチを減らし、製造と運用の間に証拠を保存することを容易にするかもしれない。

標準は、チップレットが実装していない観測可能性を作り出すことはできない。また、報告されたシグナルが根本原因であることを保証するわけでもない。チップが、他の場所の電源ノイズによって引き起こされたエラーを報告することがある。リンクは限界条件の周りで再トレーニングし、どれほど故障に近いかを示さないかもしれない。アセンブラは、メーカーのラボでは再現されない歩留まり問題を観察するかもしれない。共有トランスポートは証拠の流れを助けるが、その証拠を完全にするわけではない。

DFx は商業的な境界も動かす。テスト網羅性、テレメトリへのアクセス、ファームウェア制御の権利は、購入者が指定しなければならない項目になる。UCIe に適合していてもアクセス可能な診断を欠くチップは、より良いライフサイクルサポートを備えたプロプライエタリチップよりも有用でないかもしれない。共通アーキテクチャは管理経路を開く。その管理の質は依然として製品の決定だ。

3D は設計空間と障害面の両方を広げる

同じ UCIe 2.0世代は、垂直に積層されたチップと非常に短く高密度な接続を含む3D パッケージングのサポートを追加した。積層は計算とメモリを近づけ、帯域幅密度を高め、パッケージのフットプリントを減らすことができる。また、2D や2.5D のレイアウトよりも、熱、機械的応力、製造歩留まりを強く結合させる可能性がある。

標準インターフェースは、垂直境界を横切るものを定義するのに役立つ。しかし、接合プロセス、熱スタック、電源ネットワーク、最終組み立て前にチップが良品と宣言される順序を定義するわけではない。これらの選択は依然としてファウンドリ、アセンブラ、設計者、システムメーカーに属する。

修復の問題は特に重要だ。基板のモジュール性は、故障したコンポーネントを交換できることを示唆する。強く接合されたマルチチップパッケージは、現場での内部チップの実用的な交換手段を提供しないかもしれない。管理は故障したコンポーネントを特定できるが、商業的な是正手段はパッケージ全体の交換のままかもしれない。より良い診断は調査時間を短縮するが、物理的な修復可能性を変えない。

したがって、標準は3D 統合を容易にするが、その製造を容易にするわけではない。ジオメトリが変わっても、認識可能な通信・管理境界を維持する。それを取り巻く産業問題は、より困難になりこそすれ、軽減はしない。

PCIe と CXL は UCIe に確立されたソフトウェア経路を提供するが、すべてのチップレットが入出力デバイスやコヒーレントメモリコンポーネントのように振る舞うわけではない。信号処理、ネットワーク、専用アクセラレータは、継続的またはアプリケーション固有のフローを要求することがある。UCIe のローモードは、PCIe や CXL のセマンティクスを課さずにこれらのフローを運ぶ。バージョン3.0は、特にアナログ-デジタル変換およびデジタル-アナログ変換経路について、継続転送のマッピングを拡張した。

ローモードは、物理層を使用できるシステムの数を増やす。また、電気的相互運用性と機能的相互運用性の間のギャップを露呈させる。二つのベンダーが同じチャネルを尊重しても、フレーム、フロー制御、アプリケーションの意味を異なる方法で定義するかもしれない。リンクは接続する。しかし、機能には依然として別個の合意が必要だ。

これは必ずしも失敗ではない。アプリケーションプロトコルが特化されたままであっても、共通の物理基盤はインターフェースの重複を減らすことができる。リスクは、「UCIe をサポート」という表現が、ローモードが提供しない移植性を示唆するときに現れる。購入者は、マッピングが共有プロファイルなのか、二者間契約なのか、ベンダー固有のプロトコルなのかを知る必要がある。

したがって、ローモードは正反対の二つの効果を生み出す可能性がある。より多くのタイプのチップレットを受け入れることで物理エコシステムを広げる。一方で、リンクの上に私的な機能の島を維持するかもしれない。結果は、共通のロープロファイルと、独立した統合のための十分な情報に依存する。

業界には相互接続の頭字語が溢れており、直接の競合相手として提示されがちだ。UCIe、PCIe、CXL は異なる部分を扱う。PCI-SIG は PCI Express 相互接続とそのデバイスモデルを定義する。CXL Consortium はコヒーレントメモリのセマンティクスと関連プロトコルを定義する。UCIe はパッケージ内のチップ間の非常に短いチャネルと、これらのプロトコルを運ぶことができるマッピングを定義する。

この層構造は、UCIe のスピードを部分的に説明する。コンソーシアムは、オペレーティングシステムとデバイスベンダーに、すべてのトランザクションの新しい意味を採用するよう説得する必要はなかった。すでにソフトウェア、検証、業界団体によってサポートされているセマンティクスを運ぶことができた。

また、UCIe 実装が上位プロトコルの変更と複雑さを受け継ぐことも意味する。CXL パッケージには依然としてコヒーレントな設計が必要だ。PCIe にマッピングされたチップレットには依然として列挙、ドライバ、エラー処理が必要だ。上位プロトコルの欠陥は、パケットがチップ境界を越えたという理由だけで UCIe の障害になるわけではない。

この関係は責任のスタックとして理解できる。UCIe は、定義された条件下でビットとパケットが境界を越える方法を説明する。PCIe と CXL はそれらに意味を与える。ファームウェアとオペレーティングソフトウェアは、結合されたシステムがどのように提示・使用されるかを決定する。どの層も三つの合計を単独で主張することはできない。

高速チャネルは、その両端がパッケージの実際の電気的条件下で通信することを確立しなければならない。資料の分析は、機能ネゴシエーション、リンクトレーニング、実行時の再較正、スロットリングコマンドを説明している。UCIe 3.0は、送信側の再較正と電力関連の改善を追加し、リンクがプロセス、電圧、温度、動作の変動に適応できるようにした。

適応が不可欠なのは、パッケージが静的ではないからだ。温度は負荷に追従する。電源条件は変動する。コンポーネントは経年変化する。リンクは、工場で測定された状態が決して変わらないと仮定するのではなく、マージンを回復するか、アクティビティを減らすことができなければならない。

トレーニングの成功は依然として限定された結果だ。それは、両端がテストされた条件下でリンクを確立したことを証明する。すべての負荷、熱サイクル、寿命に対する普遍的な信頼性を証明するわけではない。再較正はあるドリフトを修正し、別のドリフトをそのまま残すかもしれない。スロットリングは性能を犠牲にしてサービスを維持するかもしれない。

購入者にとって、これは正確な言語を要求する。データシートは、仕様の最大データレートと、パッケージ内で検証されたデータレート、再較正条件、マージンが不十分なときの動作を区別しなければならない。適応リンクは変化を管理する。測定されていない信頼性を保証に変えるわけではない。

適合性の証明は、購入を導くほど正確にならなければならない

単一のラベルでは、すべての UCIe 実装を説明できない。完全な宣言は、少なくとも世代、パッケージクラス、データレート、ライン構成、プロトコル、オプション機能、テスト条件を指定しなければならない。二つの製品が両方とも UCIe を実装していても、要求される使用可能な組み合わせを共有しないかもしれない。

成熟した相互接続プログラムでは、適合性は標準への一般的な所属ではなく、定義された機能と手順に付随する。UCIe の公開エコシステムは、本調査の締め切り時点でこの証拠基盤をまだ整備途上にあった。コンソーシアムは相互運用性、サミット、ウェビナー、コントローラと物理層のデモを宣伝していたが、資料には認定済み製品の完全な公開リストはなかった。

有用なプログラムは、最も単純なリンク確立以上のものをテストしなければならない。エラー、ネゴシエーション、管理、プロトコルプロファイルを定義する必要がある。パッケージクラスと条件が重要だ。あるペアで得られた結果を、証拠なしに別のデータレートや別のパッケージに拡張してはならない。

網羅的なリストがないことは、実装が架空であることを意味しない。それは、公開された証拠がまだ若いことを示す。デモは、独立したツールやインターフェースが連携して機能することを確立できる。量産認定は、再現性、量、動作条件、そして後にペアリングが失敗したときの責任を要求する。

この区別は購入者とコンソーシアムの両方を守る。過大評価された一般的なラベルは、その結果を決して約束しなかった仕様への失望を生み出す可能性がある。正確なプロファイルは、標準の実際の成果を見えるようにする。残る障壁は証明だ。購入者は正確な構成とその限界を知らなければならない。

最初のバージョン以来、活動はアイデアの説明から実装へと移ってきた。メンバーはコントローラ、物理層 IP、検証プラットフォーム、パッケージ設計作業を発表してきた。イベントは、シグナルインテグリティ、アドバンストパッケージング、相互運用性に関するデモとセッションを紹介してきた。2025年の文書はこれらを採用の高まりの兆候と表現していた。

デモは焦点を絞った質問に答える。このコントローラはこの物理層と通信できるか。このプラットフォームは定義されたエラーを検出できるか。このチャネルはラボで要求されたデータレートに到達できるか。これらの質問は有用だ。不確実性を減らし、解釈の相違を明らかにする。

量産パッケージはより広いセットに答える。複数のベンダーが認定されたチップを期限内に納入できるか。組み立てられたパッケージは歩留まりと電力の目標を満たすか。ファームウェアは各コンポーネントを安全に更新できるか。ソフトウェアはリビジョン間で移植可能か。限界チップが断続的な障害を引き起こしたとき、誰がシステムを交換するのか。デモはこれらの回答に貢献するが、解決しない。

公開資料には、納入されたマルチベンダーパッケージの完全な棚卸しは含まれていなかった。したがって、慎重な結論は、実装能力が構築されつつあるということだ。証拠はまだ、それを普遍的な市場として数えることを許さない。

インテグレータは、リンクが確立されることを確認するだけでチップレットを評価できない。チップは、対象となる機能、プロセスコーナー、ライフサイクルに対して良好であることが知られていなければならない。ウェーハから組み立て、最終システムまで生き残るテスト証拠が必要だ。コンポーネントが統合後に欠陥品だった場合、コストには他のチップとパッケージ作業も含まれる。

したがって、既知良品ダイの証明は、商業上の要件であると同時に産業上の要件だ。ベンダーは、何がテストされたか、マージン、結果の表現、全体が失敗したときに誰が損失を負担するかについて合意しなければならない。UCIe の管理と DFx は、テストとテレメトリの転送を助けることができる。しかし、各チップの内部機能や企業間の責任を認定するわけではない。

これが、垂直統合パッケージが利点を保つ理由の一つだ。企業は、製品に複数の内部チップが含まれていても、設計、テスト限界、組み立て、保証を制御できる。マルチベンダーパッケージは、これらの私的なバトンタッチを明示的な証拠と契約に変換しなければならない。

欠けている市場の層は派手ではないが、モジュール性が中小サプライヤーに届くかどうかを決定するだろう。共通リンクは一つの障壁を下げる。認定されたチップの保証は、購入者があまり知られていないコンポーネントにパッケージの残りを賭けることができるかどうかを決定する。

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

マルチベンダーパッケージは、非常に親密な信頼の境界を生み出す。チップレットは大量のデータを交換し、管理経路を共有し、最終システムが単一のデバイスとして扱うリソースに影響を与える。したがって、侵害された、または悪意のあるチップは、自身の機能以上のものを脅かし、パッケージのコマンド・データフローへの経路になる可能性がある。

最近のバージョンの管理は、制御されたディスカバリ、ファームウェア操作、緊急シグナリングをサポートできる。会員文書はまた、強化されたセキュリティを作業分野として挙げている。これらのメカニズムは重要だが、完全なアーキテクチャを定義するものではない。チップのアイデンティティ、セキュアブート、ファームウェアの出所、アテステーション、分離、鍵管理、ベンダー保証は、システムの責任のまま残る。

この区別は実用的だ。セキュアなトランスポートはメッセージを保護するが、許可されたが侵害されたチップは悪意を持って行動できる。強力なアイデンティティはどのチップが存在するかを示すが、そのファームウェアが安全であることを証明しない。アテステーションされたコンポーネントは、アーキテクチャが与えたアクセスを悪用する可能性がある。セキュリティは、信頼が確立された後にチップレットが何をできるかに依存する。

将来の世代はより多くの機能を定義するかもしれない。資料はそのスケジュールも形態も確立していない。今のところ、UCIe 適合性はパッケージのセキュリティ認定として読まれるべきではない。購入者は、各ベンダーと全体に対して別個の信頼モデルを確立しなければならない。

UCIe はオープンな業界標準として提示され、その仕様は評価条件の下で公開要求できる。この開放性は重要だ。チームはアーキテクチャを研究でき、ツールは収束でき、企業は単一のベンダーがインターフェースを所有することなく互換性について議論できる。

チェーンの残りは集中したままだ。アドバンスト製造、ハイブリッド接合、インターポーザ、組み立て、テスト装置、設計ツールは、限られた数の企業と地域から来る。輸出管理と産業政策は、ノード、ツール、IP へのアクセスを制限する可能性がある。共通リンクはファウンドリや組立ラインを建設しない。

オープンな標準は、オープンな実装を要求しない。UCIe コントローラ、物理層、チップレット設計、ファームウェアスタック、設計キットはプロプライエタリであり得る。評価契約は、読むことと実装ライセンスを区別する。企業は、上位層と下位層を厳格に制御しながら、共通リンクを支援できる。

この組み合わせは、標準の現実的な強みかもしれない。UCIe は、二者間作業を減らすためにすべてをオープンソースにする必要はない。リスクは修辞的だ。ある層の開放性が、閉じた層の競争や移植性を示唆するために使われることがある。パッケージを層ごとにマッピングする必要がある。適合性が限定されると、最も困難な問題は信頼、商業的サポート、統合リスクの引き受けに関するものになる。

プロモーターは、UCIe を信頼できるものにするリソースを持っている。彼らは専門知識、インターフェース、認定、需要を提供する。彼らはまた、最良の代替案も持っている。大手プロセッサメーカー、ハイパースケーラー、ファウンドリは、それが有利なときに、プロプライエタリなチップレット、社内リンク、パッケージプロセスを設計できる。

これは彼らの参加を不誠実にするものではない。企業は、一部の外部境界で UCIe を使用し、最も統合された製品では私的なリンクを維持できる。共通のプロトコルトランスポートを支援しながら、トポロジ、メモリ、管理ポリシーで差別化できる。採用は全面的ではなく層状であり得る。

運営上の課題は、スタック全体を制御しない企業にとって有用な境界を維持することだ。理事会の多様性は、クラウド、プロセッサ、ファウンドリ、アセンブラが参加しているため、役立つ。資料は、貢献の重み、投票、紛争解決の完全な公開記録を提供していない。ロゴのリストで平等な地位にあることは、平等な権力を意味しない。

標準は、最大手に私的な利点を残しながら成功できる。最も厳しい試練は、中小サプライヤーがチップを構築し、限定されたプロファイルを証明し、パッケージングにアクセスし、購入者に管理不能な法務・産業リスクを転嫁せずに複数のシステムに販売できるかどうかだ。

商業的に交換可能であるためには、チップレットはリンク仕様以上のものを要求する。機能メタデータ、つまり役割、プロトコルとデータレート、ディスカバリ、ファームウェア、ヘルス状態が必要だ。パッケージ設計者は、電気的、電力、熱、機械的制約を必要とする。ソフトウェアは安定した列挙と管理を必要とする。調達は、価格、量、寿命、保証、責任分担を必要とする。

UCIe は、機能ディスカバリ、プロファイル、管理を通じて、これらの情報の一部を提供できる。今日、完全なアプリケーションインターフェースや普遍的な製品カタログを定義してはいない。保証を配分せず、ファウンドリの能力を保証しない。文書とイベントは実行可能な市場を示唆するが、公開された証拠は完全なトランザクション層の手前で止まる。

この違いは、UCIe が重要でありながら不十分であり得る理由を説明する。標準はしばしば市場の条件を作り出すが、市場そのものは作らない。ベンダー、ファウンドリ、ツール、購入者は依然として、インターフェースを資金調達可能で、テスト可能で、維持可能なものにしなければならない。

成熟した市場は責任を読み取り可能にする。パッケージが失敗したとき、当事者は原因がチップ、リンク、組み立て、ファームウェア、統合のどこにあるかを知り、契約は誰が支払うかを示すだろう。これらのバトンタッチがなければ、技術的モジュール性は、より多くの統合リスクを購入者に転嫁するかもしれない。

生産におけるバトンタッチが UCIe の価値を決める

コンソーシアムは、2022年の基本仕様から、2023年の自動車向け・低コストオプション、2024年の管理と3D、そして2025年の64 GT/s と追加のローモード・管理機能へと急速に進んだ。2026年には、公開された作業は、新しい番号付きバージョンよりも、トレーニング、実装、検証にますます重点を置いていた。

このシーケンスは、若い標準が統合のどこが壊れるかを発見していることを示す。物理リンクにはプロトコルマッピングが必要だった。リンクにはパッケージクラスが必要だった。パッケージにはヘルスモニタリング、管理、DFx、3D が必要だった。より高いデータレートには再較正、電力管理、より柔軟な補助チャネルが必要だった。各追加は、私的な仮定を共通契約に持ち込んだ。

次の証明は別の種類の記録から来るだろう。限定された適合体制は、どのプロファイルが機能するかを示さなければならない。独立したベンダーは、組み立てと検証を生き残るチップを納入しなければならない。ソフトウェアは、ペアごとの書き直しなしにそれらを発見・管理しなければならない。契約は障害とライフサイクルを配分しなければならない。中小サプライヤーは、購入者がすべての不確実性を吸収することなく参加できなければならない。

UCIe はすでに議論の条件を変えた。非公開リンクが支配していた場所に、信頼できる共通リンクを提供する。市場の誕生は、ベンダー間の最初の障害が、単一の垂直統合プレーヤーに戻ることなく診断・帰属・修正できるときに見えるようになる。その瞬間、標準は有望なインターフェースからインフラストラクチャへと変わる。