第9回 UCIeとは何か――UCIe-S/UCIe-A/UCIe-3Dでチップレットを共通接続する
出典・更新履歴・検証情報
この保存版のデータを照合するための情報です。元記事の初公開日とは区別しています。
- データセットの版
- 2026.09.23.4
- 記事内容のSHA-256
47d314efeeeabc8cddf0bc09bc66b5c39ff1cefb99cbe961eaa9c94c0d86229d- 保存版のSHA-256
a692218a72bd44ebbde2fdfc8fa40f42cb25f8c68c44beb6d2c73010ada4b375
外部証明の最終検査結果は詳細を開くと表示します。
連載:巨大チップの限界を超える――UCIeとチップレット、3D半導体のすべて
#レチクル限界、Die-to-Die PHY、Hybrid Bonding、TSVから、3D V-Cache、Foveros Direct、SoIC
#第9回 UCIeとは何か――UCIe-S/UCIe-A/UCIe-3Dでチップレットを共通接続する
#物理的につながっても、異なるチップレット同士が会話できるとは限らない
#前回は、チップレット内部のデジタルデータを電気信号へ変換し、パッケージ配線へ送り出すDie-to-Die PHYを解説した。
#マイクロバンプ、Hybrid Bonding、TSV、シリコンインターポーザー、Die-to-Die PHYがあれば、2つのダイの間に物理的な通信経路を作れる。
#しかし、それだけでは異なる企業が作ったチップレットを自由に組み合わせられない。
#例えば、両方のダイで次の条件をそろえる必要がある。
#- 電圧と信号振幅
- データレート
- レーン数
- クロック方式
- バンプ配置
- リンク初期化手順
- エラー検出方法
- 再送方法
- データ形式
- 電力管理
- テストと故障診断
- 上位プロトコル
これらを共通化するために策定された規格が、UCIeである。
#UCIeはUniversal Chiplet Interconnect Expressの略で、同一パッケージ内に置かれたチップレット間の物理層、Die-to-Dieプロトコル、ソフトウェアモデル、適合性試験までを扱うオープンな業界標準である。単に電気信号の形だけを定めたPHY規格ではない。(UCIe Consortium)
##
UCIeは「チップレット版USB」なのか
#UCIeは「チップレット版USB」と説明されることがある。
#異なる企業の部品を共通インターフェースで接続するという意味では分かりやすい。しかし、実際のUCIeはUSBよりも、半導体パッケージとSoC設計へ深く入り込んだ規格である。
#USBでは、完成した装置同士をケーブルで接続する。
#UCIeでは、
#- 裸のシリコンダイ
- パッケージ内部配線
- 電源とグラウンド
- バンプ配置
- クロック
- PHY
- プロトコル
- 起動と管理
- 検査
までを協調させなければならない。
#USB
完成した機器
↓
コネクター
↓
ケーブル
↓
完成した機器
UCIe
チップレット内部回路
↓
Protocol
↓
Die-to-Die Adapter
↓
PHY
↓
バンプ/Hybrid Bonding
↓
パッケージ配線
↓
相手側チップレット#したがってUCIeの本質は、
#異なるチップレットを、1つのSoCに近い形で統合するための共通技術スタック#
である。
##
UCIeが標準化する範囲
#UCIeの構造は、大きく次の階層に分けて考えられる。
#Protocol Layer
PCIe/CXL/Streamingなど
↓
Die-to-Die Adapter
リンク管理・交渉・CRC・再送
↓
Physical Layer
電気信号・クロック・レーン・トレーニング
↓
Package Channel
バンプ・RDL・インターポーザー・有機基板#1.Protocol Layer
#上位の回路が、どのような意味のデータを送るのかを定める。
#2.Die-to-Die Adapter
#上位プロトコルとPHYの間で、リンク状態、転送形式、信頼性機能などを管理する。
#3.Physical Layer
#電気信号、クロック、レーン、リンクトレーニングなどを扱う。
#4.パッケージチャネル
#実際に信号が通る物理経路である。
#UCIeはこの階層化によって、同じPHYとパッケージ接続の上へ、PCIe、CXL、Streamingなどの異なる通信方式を載せられるようにしている。
##
Physical Layer
#Physical Layerは、前回扱ったDie-to-Die PHYに相当する。
#主な役割は、
#- 送信ドライバー
- 受信回路
- レーン
- クロック転送
- 信号タイミング
- レーン間のデスキュー
- リンクトレーニング
- 電気パラメーターの調整
- サイドバンド通信
- 故障レーンへの対応
である。
#内部データ
↓
送信PHY
↓
電圧の変化
↓
パッケージ配線
↓
受信PHY
↓
内部データ#初期のUCIeでは、データ線とは別にValid、Track、転送クロック、サイドバンドなどを持つ構成が定められた。UCIe 1.0の基本構成単位であるClusterでは、Standard Packageが16本、Advanced Packageが64本の単方向データレーンを基本としており、複数のClusterを束ねてリンク帯域を拡張できる。
#ここで重要なのは、UCIeのデータレーンが単方向であることだ。
#全二重通信では、送信用と受信用のレーン群を別々に用意する。
#Chiplet A Chiplet B
TXレーン ─────────────→ RX
RXレーン ←───────────── TX##
Die-to-Die Adapter
#Die-to-Die Adapterは、PHYと上位プロトコルの間に置かれる。
#PCIe/CXL/Streaming
↓
Die-to-Die Adapter
↓
PHY#Adapterは、主に次の機能を担当する。
#- リンク状態の管理
- 接続相手との能力交渉
- データ形式の調整
- 複数プロトコル間の仲裁
- CRCによるエラー検出
- リンクレベルの再送
- 電力状態の管理
- PHYとの連携
UCIeの初期仕様では、Adapterが信頼性を担当する場合、256バイトのFLITを基本転送単位とし、CRCとリンクレベル再送を利用できるようにした。
#なぜPHYとAdapterを分けるのか
#PHYは、基本的に0と1を正しく送ることへ集中する。
#Adapterは、
#- どのプロトコルのデータか
- エラーが起きたか
- 再送が必要か
- リンクをどの状態へ移すか
を管理する。
#PHY
=電気信号を正しく送る
Adapter
=リンクとして正しく運ぶ
Protocol
=運んでいる情報の意味を決める#この分離によって、PHYを作り直さず、上位プロトコルや信頼性方式を拡張しやすくなる。
##
PCIe over UCIe
#UCIeは、PCI Expressをチップレット間で運べる。
#PCIeは本来、CPU、GPU、SSD、NICなどを基板上で接続するために発展してきた規格である。
#UCIeでは、PCIeのトランザクションやソフトウェアモデルを維持しながら、物理的な伝送部分をパッケージ内Die-to-Die接続へ置き換える。
#PCIe Transaction
↓
UCIe Adapter
↓
UCIe PHY
↓
パッケージ内の相手ダイ#これにより、OSやドライバーから見ればPCIeデバイスとして扱いながら、実際には同一パッケージ内部のアクセラレータ・チップレットとして接続できる。
#UCIeがPCIeを採用したのは、既存の列挙、DMA、エラー処理、ソフトウェア資産を活用できるためである。
##
CXL over UCIe
#UCIeでは、CXLも利用できる。
#CXLには大きく、
#- CXL.io
- CXL.cache
- CXL.mem
という用途がある。
#CXL.io
#デバイスの検出、設定、DMAなどを扱う。基本的なソフトウェアモデルはPCIeに近い。
#CXL.cache
#アクセラレータなどが、ホスト側メモリーをキャッシュ可能にする。
#CXL.mem
#ホストが、相手側デバイスのメモリーへアクセスする。
#CXL.io
→ 検出・設定・通常I/O
CXL.cache
→ キャッシュコヒーレンシ
CXL.mem
→ メモリーアクセス#したがって、UCIe上にCXL.cacheを載せれば、チップレットをまたぐキャッシュコヒーレンシを構築できる。
#ただし、
#UCIe PHY自体がキャッシュコヒーレンシを実現するわけではない。#
UCIeは通信の土台であり、キャッシュの状態、アドレス、順序、スヌープなどを管理するのはCXL.cacheや別のコヒーレントプロトコルである。
##
Streaming Protocol
#すべてのチップレット間通信がPCIeやCXLに適しているわけではない。
#例えば、
#- AIテンソルデータ
- 映像ストリーム
- DSPデータ
- センサーデータ
- 独自NoCパケット
- Arm CHI
- ベンダー独自プロトコル
を、より直接的に転送したい場合がある。
#そのためUCIeには、Streaming系プロトコルをマッピングする仕組みがある。
#UCIe 1.1では、Streaming ProtocolでもUCIe AdapterのFLIT、CRC、エラー検出、再送機能を利用できる方式が拡張された。Arm CHIのようなプロトコルを、信頼性のあるUCIe FLITへ格納する利用も想定されている。(UCIe Consortium)
##
Raw Mode
#Raw Modeでは、Adapterの一部機能を迂回し、PHYに近い形でデータを流す。
#通常モード
Protocol
↓
Adapter
CRC・FLIT・再送
↓
PHY
Raw Mode
独自データ
↓
簡素なマッピング
↓
PHY#Raw Modeは、
#- 独自プロトコル
- 非常に低い遅延を求める用途
- 上位側で独自の信頼性機構を持つ用途
- 連続的なDSPデータ
などに向く。
#ただし、AdapterのCRCや再送を使わない構成では、データの信頼性を実装側で確保する必要がある。
#UCIe 3.0では連続伝送向けのマッピングが強化され、ADC、DAC、DSPなどのデータを、生成・消費速度に合わせて途切れず運ぶ用途が追加された。(UCIe Consortium)
##
FLITとは何か
#FLITはFlow Control Unitの略で、リンク内で扱うデータのまとまりである。
#┌──────────────┐
│ Header │
├──────────────┤
│ Payload │
├──────────────┤
│ CRCなど │
└──────────────┘#上位プロトコルのデータをFLITへ格納し、Adapterがリンクを通して転送する。
#FLIT化することで、
#- 異なるプロトコルを共通形式で運ぶ
- CRCを付ける
- 受信確認を行う
- エラー時に再送する
- 複数プロトコルを仲裁する
ことが可能になる。
#ただしFLIT化には、ヘッダー、CRC、制御情報などのオーバーヘッドが加わる。
#非常に低遅延な専用接続ではRaw Modeを使い、信頼性や相互運用性を重視する場合にはAdapterのFLIT転送を使う、という選択肢がある。
##
CRCと再送
#高速通信では、ノイズやタイミングずれによってbitが反転する可能性がある。
#CRCは、送信データから検査用の値を計算し、受信側で再計算して比較する。
#送信側
データ
↓
CRC計算
↓
データ+CRC
↓
送信
受信側
データ+CRC
↓
CRC再計算
↓
一致?#一致しなければ、転送中にエラーが起きた可能性が高い。
#UCIe Adapterでは、設定されたモードに応じて、リンクレベルでエラーを検出し、該当FLITを再送できる。これにより、上位のPCIeやCXLまでエラー処理を戻さず、比較的短い範囲で復旧できる。
##
サイドバンドとは何か
#UCIeには、主データを運ぶMainbandとは別に、制御・管理用のSidebandがある。
#Mainband
→ 大容量データ
Sideband
→ 初期化・管理・状態通知・デバッグ#サイドバンドは、
#- 接続相手の検出
- 初期化
- 能力交渉
- リンク状態管理
- テレメトリー
- ファームウェア管理
- デバッグ
- 緊急通知
などに使われる。
#UCIe 2.0では、チップレットごとのテスト、テレメトリー、デバッグを統一的に扱うUCIe DFx Architectureが導入された。UCIe 3.0では、ファームウェアダウンロード、優先サイドバンドパケット、緊急停止、Fast Throttleなどの管理機能が追加されている。(UCIe Consortium)
##
UCIe-Sとは何か
#UCIe-Sは、主にStandard Package向けのPHYプロファイルである。
#SはStandard Packageを表す。
#Chiplet A Chiplet B
┌─────────┐ ┌─────────┐
└────●────┘ └────●────┘
════════════════════════════════
有機パッケージ基板#主な特徴は、
#- 2D横方向接続
- 有機パッケージ基板
- 比較的粗いバンプピッチ
- 比較的長い配線
- 低いパッケージコスト
- 少なめのレーンを高速動作
- 強めの送受信回路
- 信号損失への対応
である。
#UCIe 1.0で示された代表的な想定では、Standard Packageのチャネル長は最大約25mm、エネルギー効率は電圧や周波数によって約0.5~1pJ/bitだった。これらは製品を一律に規定する保証値ではなく、初期仕様の設計目標を理解するための代表値である。(UCIe Consortium)
#なぜ配線が長くなるのか
#有機基板では、シリコンインターポーザーほど細かな配線を形成できない。
#チップレット間の端子間隔が広く、配線も迂回しやすいため、チャネルが長くなる。
#UCIe-S
ダイ
↓
バンプ
↓
有機基板内の複数配線層
============
↓
相手側ダイ#その結果、
#- 信号減衰
- 反射
- クロストーク
- ビアの寄生成分
- 電源ノイズ
が増えやすい。
#UCIe-SのPHYは、UCIe-Aよりも外部SerDesに近い信号補償を必要とする場合がある。
##
UCIe-Aとは何か
#UCIe-Aは、Advanced Package向けのPHYプロファイルである。
#AはAdvanced Packageを表す。
#Chiplet A Chiplet B
┌────────┐ ┌────────┐
└●●●●●●●─┘ └─●●●●●●●┘
════════════════════════════
シリコンインターポーザー/ブリッジ#想定される実装は、
#- シリコンインターポーザー
- シリコンブリッジ
- 微細RDL
- ファンアウト
- 2.5Dパッケージ
などである。
#主な特徴は、
#- 短い配線
- 細かな接続ピッチ
- 多数の並列レーン
- 高い帯域密度
- 小さな信号振幅
- 低いpJ/bit
- 低遅延
- 高いパッケージコスト
である。
#UCIe 1.0の代表的なAdvanced Package想定では、チャネル長は最大約2mm、エネルギー効率は約0.25~0.5pJ/bitだった。(UCIe Consortium)
#なぜUCIe-Aの方が低電力なのか
#配線が短いと、信号線の容量と損失を小さくできる。
#おおまかには、信号を充放電する電力は次の関係で増える。
#動的電力 ≒ 容量 × 電圧² × 周波数#UCIe-Aでは配線容量と動作電圧を下げやすいため、同じ量のデータをUCIe-Sより少ない電力で運びやすい。
#また、多数のレーンを使えるため、1本を極端に高速化せず、広い並列通信で総帯域を増やせる。
##
UCIe-SとUCIe-Aは同じPHYなのか
#UCIeという上位構造は共通だが、電気的には異なるPHYプロファイルである。
#共通
Protocol
Adapter
リンク管理
ソフトウェアモデル
異なる
チャネル長
バンプピッチ
レーン構成
送信駆動力
信号補償
電力
帯域密度#UCIe-S対応のダイなら、同じUCIe-S電気仕様と接続条件を満たす相手との相互運用を狙う。
#UCIe-A対応のダイなら、UCIe-Aの範囲で相互運用する。
#UCIe-SのPHYを、そのまま微細なシリコンインターポーザーへ載せれば最適になるわけではない。逆に、UCIe-Aの弱い低電圧ドライバーで長い有機基板配線を安定して駆動できるとは限らない。
##
UCIe-3Dとは何か
#UCIe-3Dは、上下に積層したダイを垂直方向へ接続するためのプロファイルである。
#UCIe 2.0で3Dパッケージへの対応が追加された。
#上側チップレット
┌────────────┐
│ Logic/SRAM │
└●●●●●●●●●●┘
Hybrid Bonding
┌●●●●●●●●●●┐
│ Logic/Base │
└────────────┘
下側チップレット#UCIe-3Dは、特にHybrid Bondingを想定して最適化されており、10~25µm級のピッチから、1µm以下の接続ピッチまでを視野に入れた拡張性を持つ。(UCIe Consortium)
#UCIe-3Dの特徴
#- 上下方向の極短距離接続
- 接合面全体を使える
- 非常に多数の並列接点
- 高い面積帯域密度
- 低い通信電力
- 低遅延
- Logic-on-Logic
- SRAM-on-Compute
- Memory-on-Logic
2Dと2.5Dでは、PHYを主にダイ外周へ配置する。
#3Dでは、接合面全体へ接続を分散できる。
#UCIe-S/UCIe-A
帯域密度
=ダイ辺1mm当たりが重要
UCIe-3D
帯域密度
=接合面1mm²当たりが重要#したがって、3Dでは「shorelineをどれだけ使うか」だけでなく、「接合面積の中に何本のI/Oを置けるか」が重要になる。
##
UCIe-3DとHybrid Bondingの違い
#Hybrid Bondingは接合技術である。
#UCIe-3Dは通信インターフェース規格である。
#Hybrid Bonding
Cu-to-Cu接合
+
誘電体接合
=物理的な接合面
UCIe-3D
信号
レーン
クロック
リンク管理
通信形式
=接合面を使う通信規格#Hybrid Bondingを使っても、通信方法が企業独自ならUCIe-3Dではない。
#逆に、UCIe-3Dを利用するためには、対応する接合ピッチ、バンプマップまたは銅パッド配置、PHY、Adapterなどをそろえる必要がある。
##
UCIe-S/A/3Dの比較
#| 項目 | UCIe-S | UCIe-A | UCIe-3D |
| 主方向 | 横方向 | 横方向 | 垂直方向 |
| パッケージ | Standard Package | Advanced Package | 3D積層 |
| 主な配線 | 有機基板 | インターポーザー、ブリッジ、RDL | Hybrid Bonding |
| 接続距離 | 比較的長い | 短い | 極めて短い |
| 接続密度 | 低~中 | 高い | 非常に高い |
| PHY方式 | 少数・高速寄り | 多数・並列寄り | 超多数・広並列寄り |
| 電力効率 | 比較的低い | 高い | さらに高くしやすい |
| コスト | 低め | 高い | 非常に高い |
| 主用途 | 汎用、コスト重視 | AI、HPC、HBM、アクセラレータ | SRAM積層、Logic-on-Logic |#ここでの比較は一般的な傾向であり、実際の性能はデータレート、電圧、ダイ配置、パッケージ材料、PHY実装によって変わる。
##
GT/sとは何か
#UCIeの速度は、GT/sで表される。
#GT/sはGiga Transfers per Secondの略で、1秒間に何十億回の転送を行うかを示す。
#UCIe 3.0は、UCIe-SとUCIe-Aの両方へ48GT/sと64GT/sを追加し、UCIe 2.0の最大32GT/sからデータレートを倍増させた。(UCIe Consortium)
#UCIe 3.0はNRZ信号を使用するため、単純化すると1回の転送で1bitを運ぶ。
#64GT/s
≒ 1レーン当たり64Gbit/s#Byteへ換算すると、
#64Gbit/s ÷ 8
= 8GB/s#これは1レーン、1方向、オーバーヘッドを無視した理論値である。
#例えば64レーンなら、
#64Gbit/s × 64レーン
= 4096Gbit/s
4096 ÷ 8
= 512GB/s#となる。
#双方向リンクでは、反対方向にも別のレーン群を持つため、送信512GB/s、受信512GB/sという構成が可能になる。
#ただし実効帯域は、FLITヘッダー、CRC、制御情報、アイドル、再送などによって理論値より小さくなる。
##
64GT/sにすれば簡単に帯域が2倍になるのか
#物理的には、データレートを上げるほど信号品質の確保が難しくなる。
#UCIe 3.0では48/64GT/sへ対応するため、
#- 送信側3-tap FFE
- 受信側CTLE
- オプションの1-tap DFE
- リンクトレーニングの強化
- イコライザー設定の選択
- タイミング補正
などが導入・強化されている。
#高速化
1bitの時間が短くなる
↓
タイミング余裕が減る
↓
反射・損失・ジッターの影響が増える
↓
PHYが複雑になる#したがって、データレートを2倍にしても、PHY面積と電力を一切増やさず帯域だけを2倍にできるわけではない。
#UCIe 3.0は、速度向上と同時に、帯域密度、イコライゼーション、電力管理を改善する設計になっている。
##
UCIeの世代
#UCIe 1.0
#2022年に最初の仕様が公開された。
#主な内容は、
#- UCIe-S相当のStandard Package
- UCIe-A相当のAdvanced Package
- Physical Layer
- Die-to-Die Adapter
- PCIe
- CXL
- Streaming/Raw Mode
- CRCと再送
- 適合性試験
である。(UCIe Consortium)
#UCIe 1.1
#信頼性と用途が拡張された。
#- Streaming ProtocolのFLIT対応
- 複数プロトコルの同時運用
- ランタイム監視
- 故障修復
- 車載・高信頼用途
- 低コスト向けバンプマップ
などが追加された。(UCIe Consortium)
#UCIe 2.0
#管理・検査と3D対応が大きな追加点である。
#- UCIe-3D
- Hybrid Bonding対応
- UCIe DFx Architecture
- テスト
- テレメトリー
- デバッグ
- SiP全体の管理
が導入された。(UCIe Consortium)
#UCIe 3.0
#2025年に公開され、性能とSiP管理が強化された。
#- 48GT/s
- 64GT/s
- 連続伝送
- ランタイム再調整
- L2低電力状態の最適化
- ファームウェアダウンロード
- 優先サイドバンドパケット
- 最大100mmの拡張サイドバンド
- Fast Throttle
- 緊急停止
- Open Drain Pin
などが追加された。100mmの拡張サイドバンドはUCIe-S向けで、複雑なSiPにおけるスター型管理トポロジーを想定している。(UCIe Consortium)
##
UCIeなら、どの企業のチップレットでも接続できるのか
#UCIeへの準拠は、相互運用性を高める重要な条件である。
#しかし、UCIe対応という表示だけで、どのチップレット同士でも無条件に接続できるわけではない。
#少なくとも次の条件を合わせる必要がある。
#PHYプロファイル
#- UCIe-S
- UCIe-A
- UCIe-3D
- 対応データレート
- レーン幅
物理配置
#- バンプマップ
- パッドピッチ
- ダイ辺の位置
- 向き
- パッケージ配線
上位プロトコル
#- PCIe
- CXL
- Streaming
- CHI
- 独自Raw Mode
システム条件
#- 電源電圧
- リセット
- クロック
- ファームウェア
- 温度管理
- セキュリティ
- 起動順序
製造条件
#- Known Good Die
- 接合歩留まり
- パッケージ反り
- テスト可能性
- 故障修復
UCIe準拠
≠
無条件で接続可能
UCIe準拠
=
共通仕様に基づき
相互運用を設計・検証できる#UCIeの目的は、魔法のような完全互換を保証することではない。
#各社が共通ルールでPHY、Adapter、プロトコル、検査を設計できる土台を作ること#
にある。
##
UCIeはキャッシュコヒーレンシを保証するのか
#UCIeだけでは保証しない。
#PHYとAdapterは、データを正しく届ける役割を持つ。
#キャッシュコヒーレンシには、
#- キャッシュラインの状態
- アドレス
- 所有権
- 共有状態
- 無効化
- スヌープ
- ディレクトリー
- 順序保証
が必要である。
#これらは、
#- CXL.cache
- Arm CHI
- ベンダー独自コヒーレントプロトコル
などが担当する。
#UCIe PHY
=bitを送る
UCIe Adapter
=リンクとして確実に運ぶ
CXL.cache/CHI
=キャッシュの一貫性を管理する#UCIe 1.1では、CHIのようなStreaming ProtocolをUCIe FLITへマッピングし、CRCと再送を共通利用する方向が示されている。(UCIe Consortium)
##
UCIeの本質
#UCIeは単なる配線規格でも、単なるPHY規格でもない。
#パッケージ
+
PHY
+
Adapter
+
Protocol
+
管理
+
テスト
+
ソフトウェア#を組み合わせ、複数のダイを1つのシステムとして動作させるための標準である。
#UCIe-Sは低コストな有機基板接続を可能にする。
#UCIe-Aは2.5Dパッケージの短距離・高密度接続を可能にする。
#UCIe-3DはHybrid Bondingによる垂直方向の超高密度接続へ対応する。
#UCIe-S
→ コスト重視の横方向接続
UCIe-A
→ 性能・電力効率重視の横方向接続
UCIe-3D
→ 面積密度重視の垂直接続#UCIeによって、チップレットは単なる「同じ企業が自社製品内で使う専用ダイ」から、複数企業や複数製造ノードをまたいで再利用できる部品へ近づく。
#ただし、真のオープンチップレット市場を成立させるには、UCIe規格だけでなく、パッケージ設計、電源、冷却、セキュリティ、EDA、Known Good Die、テスト、責任分界までを整備する必要がある。
##
今回の要点
#- UCIeは、Physical Layerだけでなく、Die-to-Die Adapter、Protocol、ソフトウェアモデル、管理、テストまでを扱う。
- PHYは電気信号を送り、Adapterはリンク状態、CRC、再送、プロトコル仲裁を管理する。
- PCIe、CXL、Streaming、Raw ModeなどをUCIe上で利用できる。
- UCIe自体がキャッシュコヒーレンシを実現するのではなく、CXL.cacheやCHIなどの上位プロトコルが担当する。
- UCIe-Sは、有機基板を使う比較的長距離・低コストな2D接続向けである。
- UCIe-Aは、インターポーザーやブリッジを使う短距離・高密度な2.5D接続向けである。
- UCIe-3Dは、Hybrid Bondingを使う垂直方向の超高密度接続向けである。
- UCIe 2.0で3DとSiP管理・DFxが追加され、UCIe 3.0ではUCIe-S/Aへ48GT/sと64GT/sが追加された。
- UCIe対応は無条件の互換性を意味せず、PHYプロファイル、バンプマップ、プロトコル、電源、クロック、ファームウェアをそろえる必要がある。
- UCIeの最終目標は、複数企業のチップレットを共通基盤上で組み合わせるオープンなエコシステムを作ることである。
次回は、UCIeやHybrid Bondingが実際の製品と製造技術でどのように使われているのかを、AMD 3D V-Cache、Intel Foveros Direct、TSMC SoICを比較しながら解説する。
#





















