最近幾個月，UCIe 周圍出現了幾個挺有意思的動作。
4 月初，UALink 聯盟一口氣發布了四份規範，其中的 UALink Chiplet Specification 1.0 明確寫了一句話：
Fully compliant with the UCIe 3.0 Specification for simplified integration.
8 月的 FMS 上，SK hynix 和 SanDisk 透過 OCP 發布了首版 High Bandwidth Flash（HBF） 標準。HBF 面向 AI 推論場景，把大容量 NAND 放到處理器附近，而處理器與 HBF 之間採用 UCIe 連接。
再往前看，CXL 也是 UCIe 最早、最重要的承載協議之一。
從 AI 加速器之間的 Scale-up 互連 UALink，到靠近 xPU 的高頻寬 Flash HBF，再到承擔記憶體與裝置一致性連接的 CXL，都在不約而同地靠向 UCIe，答案或許很簡單。
UCIe 從一開始就是為多種上層協議而設計。
其目標，本就是在封裝內部提供一套標準化的 Die-to-Die 互連底座，讓不同類型的晶粒能夠透過統一的實體與鏈路機制連接起來。
一、UCIe 為什麼能承載多協議？
很多人第一次接觸 UCIe，會把它理解成「一套更快的 Die-to-Die PHY」。
這其實只說對了一半。
UCIe 的架構一開始就是分層設計：
Physical Layer（PHY）→ D2D Adapter → Protocol Layer
Adapter 的存在意義，就是讓多個不同的協議堆疊可靠地共享同一條鏈路。
因此，它並不只是在 PHY 和上層協議之間做一層「翻譯」。
當協議層只管「發什麼資料」，實體層只管「怎麼把電氣訊號送出去」時，中間大量的工作——可靠度、仲裁、狀態管理、多協議調度——都落在 Adapter 上。
對於一條實體鏈路上需要同時承載多個協議堆疊的場景，Adapter 提供兩種複用方式。
A、Stack Multiplexing（常規模式）
| 項目 | 說明 |
協議堆疊數量 | 2 個 |
協議要求 | 必須完全相同（同協議、同能力、完全對稱） |
頻寬分配 | 各占實體層總頻寬的 50%，固定對半 |
Flit 格式 | 統一 |
這裡有一個很關鍵的約束：
發送端不能連續發送同一協議堆疊的 Flit。
必要時，Adapter 需要插入 NOP Flit，讓兩個協議堆疊的流量交錯傳送。
所以，常規模式並不是簡單地把頻寬「各分 50%」。
B、Enhanced Multi_Protocol_Enable（增強模式）
| 項目 | 說明 |
協議堆疊數量 | 2 個 |
協議要求 | 可以不同（例如一個跑 PCIe、一個跑 Streaming） |
頻寬分配 | 更靈活，以分時方式共享，單一協議堆疊可使用完整鏈路頻寬 |
Flit 格式 | 所有協議堆疊必須統一使用同一種 Flit 格式 |
因為協議不同，這種模式下 Adapter 的仲裁邏輯更加複雜，需要處理異質交易的調度以及 Flit 格式對齊。
| 常規模式
| 增强模式 |
|---|
協議是否相同 | 必須相同 | 可以不同 |
頻寬 | 各 50%，固定 | 分時共享，單一協議堆疊可跑滿 |
Flit 格式 | 統一 | 必須統一 |
實作複雜度 | 較低（對稱） | 較高（異質仲裁） |
典型場景 | 兩個相同的 CXL 記憶體控制器 | 共享一組 Lane 的 PCIe + Streaming、混合負載 |
Adapter 是體現 UCIe 價值的關鍵之一：負責封裝 Flit、執行 CRC 與 Retry、管理鏈路狀態、協商參數，並在多協議共存時負責仲裁與交錯調度。
UCIe 提供的不只是一條多車道高速公路，也賦予了這條高速公路一套「交通樞紐管理能力」。
二、Flit Format：「同一條路怎麼讓不同協議一起跑？」
要讓不同協議真正共享一條 UCIe，光有管理還不夠。
還有一個更基礎的問題亟待解決：
不同協議的資料，怎麼裝進同一種傳輸框架？
這就是 Flit Format 發揮作用的地方。
UCIe 定義了 Raw、68B、256B 等多種 Flit Format。
它們不只是幾種「不同大小的資料封包」，而是在有效負載、協議開銷、可靠度與傳輸效率之間做出不同取捨。
| Flit 格式 | 結構組成 | Adapter 是否介入可靠性 | 對應協議規格 | 典型用途 |
Raw | 64B 負載直通，不加 Header、不加校驗 | 不介入，由上層協議自行負責 | Streaming 類（AXI、CHI、對稱一致性等） | 流式資料；自帶可靠性機制的協議 |
68B | 2B Flit Header + 64B 負載 + 2B CRC | 介入（CRC + Retry） | CXL 1.1/2.0/3.0、PCIe non-flit mode | 相容既有協議堆疊 |
256B | 256B Flit，另有延遲最佳化變體 | 介入（CRC + Retry） | CXL 3.0、PCIe 6.0 | 新一代高頻寬／低延遲場景 |
這張表也順帶解釋了兩件事。
第一，為什麼 Enhanced 模式要求各協議堆疊統一 Flit Format？
Raw 不帶校驗，68B 與 256B 的 Header 與尾端結構又完全不同。
混在同一條鏈路上，Adapter 就無法使用同一套規則進行拆包、校驗與重傳。
所以，真正需要統一的，並不是上層協議本身：
PCIe 還是 PCIe，CXL 還是 CXL，UALink 也還是 UALink。
但到了 UCIe 這條鏈路上，它們需要按照共同的傳輸規則，被組織、仲裁與複用。
第二，為什麼產業會往 256B 走？
對於 PCIe/CXL 這類採用 68B Flit 的協議，UCIe 3.0 把這種模式的適用速率限制在 32 GT/s 及以下。
要在更高的資料速率上運行，就需要採用相應的 256B Flit 模式。
而對於 Raw Mode，UCIe 3.0 則進一步引入 continuous transmission，以支援對連續資料傳輸更加敏感的應用。
所以從系統角度看，UCIe 做的事情其實很清楚：
四層配合起來，才讓一條實體鏈路真正具備了承載多種協議的能力。
此外，在最新的 UCIe 3.0 中，又進一步加入了連續傳輸相關能力，並支援 48 GT/s 和 64 GT/s 資料速率。
也就是說，UCIe 正在從「把幾種協議裝進一條鏈路」，逐漸走向「讓更多類型的流量在統一基礎設施上高效運行」。
三、為什麼越來越多協議開始把這件事交給 UCIe？
原因其實很現實。
自己做一套完整的 D2D 互連方案，並不只是「把 PHY 電路做出來」。
還要處理：
Link Training
Lane Mapping
Sideband
參數協商
CRC
Retry
功耗狀態
Repair
不同晶粒之間的互操作
這些工作一旦每個協議都自己來做，就會出現一個很熟悉的問題：
大家都在重複造輪子。
UCIe 的意義，就是把這部分基礎設施逐步標準化。
所以，UALink 的 Chiplet 規範選擇直接與 UCIe 3.0 對齊，並不意味著 UALink 和 UCIe 是同一個協議。
恰恰相反：
UALink 仍然是面向加速器 Scale-up 的上層互連規範，而 UCIe 更多承擔封裝內 Die-to-Die 的承載與互操作基礎。
HBF 的思路也是類似。
所以，與其說「UALink 和 HBF 都在使用 UCIe」，不如說：
越來越多原本彼此無關的系統協議，開始接受一套共同的封裝內互連基礎設施。
四、真正難的地方，開始從 PHY 往上移
UCIe 解決「不同晶粒怎麼連」，Adapter 解決「不同協議怎麼共用這條鏈路」。
而當我們回到 IP 實作上，工程複雜度一點沒有降低，反而開始往上走。
第一，驗證空間是在做乘法，不是加法
協議種類、鏈路寬度、速率檔位、Flit Format，再疊加模組類型、電源狀態、鏈路訓練、Repair、錯誤恢復……
每多支援一種協議，並不是簡單地「多驗一套介面」。
不同協議之間的複用、仲裁，Flit 的交錯方式，以及異常情況下的 CRC、Retry 與狀態恢復，都會和原有功能產生新的組合。
所以真正難的不是把某一種協議「跑通」，而是：
讓多種協議在各種邊界條件下同時跑對。
第二，Chiplet：互操作本身就是產品的一部分
單體 SoC 時代，介面 IP 只要在自己的晶片裡正常工作，很多問題都可以在系統內部消化。
Chiplet 不一樣。
你的 Die 要和另一家公司的 Die 放進同一個封裝，雙方可能來自不同的設計團隊、不同的 IP 供應商，甚至不同的製程平台。
這時候，「功能正確」只是第一步。
參數協商是否正確、Link Training 能否收斂、協議映射是否符合規範、多協議場景下的行為是否一致，最終都要落到互操作與合規驗證上。
所以，互操作已經不是交付之後才需要考慮的問題，而是介面 IP 本身的一部分。
第三，介面 IP 的差異化也正在發生變化
過去談高速介面，很容易先看幾項指標：
多少 GT/s、多少 Tb/s/mm、多少 pJ/bit。
但當產業開始基於同一套標準搭建 Chiplet 互連之後，真正拉開差距的，將不只是 PHY 參數本身。
協議映射做得全不全、Flit Format 支援得好不好、多協議仲裁是否正確、異常恢復是否可靠，以及驗證覆蓋是否足夠——
這些原本藏在產品規格表後面的能力，會越來越直接地影響一套介面 IP 能不能真正落地。
UCIe 的競爭，正在從「PHY 能跑多快」，逐漸走向「整個 D2D 鏈路能承載多少協議、處理多少場景，以及能不能穩定地跑起來」。
寫在最後
回到開頭的問題：
為什麼都在靠近 UCIe？
答案不是簡單地數一個數字。
更準確地說，UCIe 正在變成一套可以承載多種協議、適配多類 Chiplet 場景的共同互連底座。
UALink 需要它來連接計算晶粒，CXL 需要它承載一致性與記憶體語義，HBF 則把它帶到了 NAND 這一全新的記憶體／儲存層級。
它們都建立在相同的 Die-to-Die 基礎設施之上。
這背後其實對應著 Chiplet 產業一個很明顯的變化：
介面正在從「連接兩顆晶片」，變成「連接一個生態」。
對介面 IP 廠商來說，競爭也隨之發生變化。
過去大家問的是：你能跑多快？
現在開始有人問：你能接多少種協議？能不能跨廠商互操作？多協議同時跑的時候穩不穩？
奎芯科技自 UCIe 標準化早期即投入 D2D 介面 IP 研發，並推出 M2LINK 晶粒互連方案。
圍繞協議映射、多協議處理以及互操作驗證所累積的能力，也正在成為 Chiplet 時代介面 IP 的重要組成部分。