在 Hot Chips 34 的演講中，英特爾詳細介紹了他們即將推出的 Meteor Lake 處理器如何使用Chiplet。與 AMD 一樣，英特爾正在尋求獲得與使用Chiplet相關的模塊化和更低的成本。與 AMD 不同，英特爾做出了一套不同的實施選擇，這使 Meteor Lake 特別適合處理不同的客戶群。
高層次戰略
在過去十年中，英特爾的客戶端針對不同的細分市場提供了不同的單片芯片。這些客戶端芯片并不是特別大，所以單片設計在一段時間內是有意義的。但英特爾一直在增加核心數量，引入混合架構，添加更多 SoC 功能（如 Thunderbolt 支持），并在集成顯卡方面一如既往地努力。這意味著可能的配置數量將急劇增加，并且在某些時候，使用tiles將使英特爾制造的獨特芯片數量減少。因此，將設計拆分為tiles將有助于簡化生產。
Wikichip 頁面上的Kaby Lake 屏幕截圖，顯示了通過不同的單片芯片實現的不同配置
這將我們帶到了Meteor Lake。Meteor Lake分為四個tiles。其中，CPU tile 包含 CPU 內核及其緩存，很像 AMD 的 CCD；集成 GPU 有自己的tile；SoC tile包含當前 Intel 客戶端 CPU 的系統代理中的大部分功能。最后，IO 擴展tile連接到 SoC tile。所有的tile都安裝在一個無源基座die的頂部，該die連接tile并處理電力傳輸。
來自 Intel 的 Hot Chips 幻燈片，展示 Meteor Lake 的不同tile
隨著英特爾為不同的客戶細分市場定制芯片，這種方法為tile重用提供了很大的潛力。例如，具有六個 P 核心和兩個 E 核心集群的核心塊可以用于各種外形尺寸。當與強調 PCIe 通道的 SoC tile配對時，它可以用于中端桌面芯片。或者，對于筆記本電腦，它可以與具有圖像處理單元的 SoC tile配對，以在大量使用網絡攝像頭的情況下延長電池壽命。
與 AMD 的方法對比
相比之下，AMD 的Chiplet方法允許在臺式機和服務器領域重復使用die，但目前在臺式機和移動設備上并沒有那么多。通過 PCB 的簡單封裝鏈接價格便宜，并且可以實現長距離傳輸，但對于降低功耗并不是最好的。因此，AMD 目前使用單獨的單片die來瞄準移動領域。
面向桌面需求的Zen 3芯片
面向移動設備的芯片
Meteor Lake 的封裝解決方案肯定更貴。英特爾需要包含一個單獨的基礎die。擴大 Meteor Lake 將更加困難——包括更大的 CPU tile或更多的 CPU tile將需要更大的基礎die。作為交換，英特爾的設計可以實現更高的 IO 密度并使用更少的功率在tile之間移動數據。正如我們所見，die to die 鏈接設計與兩家公司的方法密切相關。讓我們仔細看看。
Die to die的互連
英特爾將他們的 die to die 鏈接稱為“Foveros Die Interconnect”（FDI）。其更高的 IO 密度應允許在空間受限的超極本板上使用更小的封裝。此外，功耗在電池供電設計中至關重要，毫無疑問，與 AMD 的普通封裝互連相比，FDI 更適合打入移動領域。AMD 表示，Zen 1 的 die-to-die Infinity Fabric 鏈接的功耗為 2 pJ/bit，他們的 Zen 2 發布幻燈片表明 Infinity Fabric 可以以每比特低 27% 的功耗傳輸數據。顯然，我們不知道與其他邏輯相比，優化 cross die link有多少功耗降低，但可以合理地假設 AMD 的 die-to-die 傳輸貢多與 Intel Haswell 的 OPIO 互聯一樣多（甚至更多）。
英特爾在 HC34 上的 Meteor Lake 演示期間顯示的幻燈片
但令人驚訝的是，英特爾并沒有宣傳很大的延遲優勢。英特爾的幻燈片非常模糊，僅顯示延遲低于 10 ns。AMD 還聲稱使用普通的封裝鏈接可以實現低于 10 ns 的延遲。
“從 CCD 到 IOD 和返回的總往返延遲（包括數字控制邏輯）為 13 個 FCLK，或小于 9 ns”，AMD在ISSCC 2020上介紹其面向高性能服務器和臺式機產品的 AMD Chiplet 架構的時候說。
更具體地說，AMD 表示延遲是 13 個 Infinity Fabric (FCLK) 時鐘周期。該論文討論了 Matisse 和 Rome（分別為桌面和服務器形式的 Zen 2），并且似乎假設 1.46 GHz FCLK 來獲得 9 ns 的數字。這與在耦合模式下運行 DDR4-2933 一致。在通常運行更快的 DDR4 的臺式機上延遲會更低。在 1.6 GHz FCLK 時鐘下，延遲將接近 8 ns。將 FCLK 推到 1.8 GHz，這對于許多 Matisse 芯片都是可能的，13 個 FCLK 將是 7.22 ns。當然，英特爾的 <10 ns 數字可能表示低至 2-3 ns 的實際數字。但如果英特爾可以將延遲降低到那個水平，他們可能會更加突出地展示它。
帶寬數據也不清楚。英特爾表示 FDI 每秒可以進行 20 億次傳輸，但沒有具體說明每次傳輸的范圍。不過，基于英特爾如何使用 FDI，我懷疑帶寬并沒有明顯高于 OPIO 或 IFOP。
Tile Layout和通信協議
我們還可以檢查英特爾在哪里使用 FDI 來了解其性能特征。沒有任何 FDI 鏈路似乎處于高帶寬、延遲敏感的路徑中。CPU tile 和 SoC tile 之間的鏈接大多會看到 L3 miss traffic，應該只有幾十 GB/s，有數百個周期的延遲。SoC tile到 IO 擴展tile可能會處理 PCIe 流量，它具有更低的帶寬和更高的延遲。
需要注意的一件有趣的事情是，Meteor Lake 將 iGPU 放置在遠離 CPU 的 L3 緩存的地方，位于 SoC tile的另一側。之前的英特爾設計將 iGPU 置于ring bus stop上，自然而然地共享 CPU 的 L3 高速緩存。另一方面，如果 Meteor Lake 的 iGPU 想要hit CPU 的 L3，它必須通過中心 SoC tile走很長的路。為來自 iGPU 的每個請求走那么長的路是沒有意義的。所以我相信 iGPU tile 的行為可能與 CPU tile 一樣——也就是說，iGPU 到 SoC 的鏈接只會看到 iGPU 到 DRAM 的 traffic。我認為 L3 不像以前的英特爾設計那樣共享。
另一個提示是使用的通信協議，所以讓我們繞道討論一下。英特爾表示，CPU 和 SoC tile使用 IDI 協議進行通信，而 iGPU 模塊使用 iCXL 協議與 SoC 進行通信。SoC 和 IO 擴展tile通過 IOSF（Integrated On-chip system Fabric）和 DisplayPort 連接。我們都知道 DisplayPort 是什么，IOSF 與 PCI 共享一個ordering model。IO 擴展tile可能有一個 PCIe 控制器和一些 DisplayPort PHY，而跨芯片連接只是為這些接口供電。不過，IDI 和 iCXL 更有趣，它們可以為我們提供有關 iGPU 如何與 CPU tile 交互的提示。
來自 Hot Chips 的幻燈片，展示了正在使用的各種跨芯片通信協議
IDI 或 In-Die Interface最早出現在 Intel 的 Nehalem 架構中，它將核心連接到非核心的全局隊列和 L3。此后，IDI 繼續作為Intel 環形總線(ring bus)上的主要協議，隨著時間的推移進行各種更新和改進。它使用 MESIF 緩存一致性協議，這意味著緩存行的狀態可以是修改、獨占、共享、無效或轉發。IDI 協議本身似乎相當復雜，具有不同的數據包類型集，用于 L3 切片控制邏輯中的特定隊列。例如，每個 L3 切片都有一個入口請求隊列 (IRQ)。當來自核心的 IDI 數據包到達它所尋址的 L3 切片時，它將被拉出網格或環并添加到 IRQ。數據包類型代表來自內核的非常具體的內存訪問請求，讓 L3 切片控制器在保持高速緩存一致性的同時最大限度地提高性能。
一些記錄在案的 Skylake-X IDI 數據包操作碼，用于核心到 L3 切片（緩存代理）通信。
其他隊列包括處理窺探(snoops)的 Ingress Probe Queue 和處理來自內核的寫回的 Writeback Queue。總之，IDI 是一種用于處理網狀或環形總線流量的內部協議，其中包括 CPU 內核和 L3 緩存之間的高帶寬、低延遲通信。前幾代英特爾 iGPU 使用 IDI 協議，自然使它們成為 L3 緩存的代理，就像 CPU 內核一樣。Haswell iGPU 的文檔支持這一點——iGPU 驅動程序使用 IDI hash mask來配置 eDRAM 緩存。
但是 Meteor Lake 的 iGPU 換成了 iCXL，這是一種不使用 PHY 的 Compute Express Link (CXL) 的內部實現。CXL 基于 PCI Express，與 PCI Express 一樣，旨在將 CPU 連接到 IO 設備。與 PCIe 相比，CXL 3.0 允許更好地處理緩存一致性的硬件，添加延遲優化的消息格式 (flits)，并且可以通過實現三個子協議 - CXL.io、CXL.cache 和 CXL 來接受更廣泛的設備。這些子協議分別適用于通用設備、GPU 等相干加速器(coherent accelerators)和內存擴展設備。如果您查看 CXL.cache 請求類型，您會發現在 IDI 中有一些模糊的等價物。但 CXL 與 IDI 協議不同，并不意味著將處理核心連接到它們的緩存。
CXL 2.0 規范中的 CXL 請求類型
一些 CXL 數據包類型在 IDI 中具有模糊相似的對應物，但這些相似性主要出現在發往遠程請求隊列 (RRQ: Remote Request Queue ) 的 IDI 數據包中，該隊列處理來自遠程套接字(remote socket)的 UPI 請求。核心用于訪問 L3 的數據包類型（DrD、Crd、RFO 等）明顯不存在。另一個區別是 CXL 使用基本的 MESI 一致性協議。它沒有在 IDI 的 MESIF 協議中發現的 Forward 狀態，這會使 CXL 和 IDI 之間直接轉換的任何嘗試變得復雜。
不再有 iGPU L3 共享？
總而言之，我認為 iGPU 不像以前的英特爾設計那樣共享 CPU L3。如果英特爾想像自 Sandy Bridge 以來所做的那樣繼續與 iGPU 共享 L3，他們將保持與當前客戶端芯片相同的芯片布局。iGPU 將繼續使用 IDI 與外界通信。Meteor Lake 的布局和通信協議更改只有在英特爾不希望 iGPU 再共享 CPU 的 L3 時才有意義。這聽起來像是英特爾在倒退，但這種改變有充分的理由。
首先，Meteor Lake 的設計讓英特爾將 iGPU 從主 CPU 環形總線上取下來，這將減少環形停止的數量。更少的ring stops意味著減少延遲。它可以提供更好的電源效率，因為數據不會被移動得那么遠，并且 CPU 內核花費更少的時間等待數據。也許這會讓 Intel 為 Meteor Lake 提供更高的時鐘頻率，為 CPU 內核追求更好的 L3 性能。隨著 iGPU 與 CPU 塊分離，英特爾還可以通過在只有 iGPU 處于活動狀態時將整個 CPU 塊設置為低功耗狀態來延長電池壽命。我還懷疑 iGPU 方面的 L3 命中率一開始并不是很好。
外部內存訪問減少 28% 意味著 28% 的 iGPU 訪問來自 SLC（也就是 28% 的命中率）。ARM SoC 中的 SLC 填充了與 Intel L3 類似的功能——兩者都緩存
與當前 Intel 芯片中的 L3 一樣，ARM 的系統級緩存 (SLC) 為 CPU 和 iGPU 請求提供服務。當使用 8 MB SLC 時，他們看到 iGPU 方面的hitrate 為 28%，這非常低。AMD 同樣觀察到緩存大小低于 16 MB 的 GPU Infinity Cache hitrates不佳，這來自他們在“游戲開始的地方”中發布的數據。最后，我在 Haswell iGPU 上使用英特爾的圖形性能分析器 (GPA) 收集了數據。雖然指標很難解釋，但無論您如何看待它們，它們肯定都不能說明hitrates很高。
如果我正確解釋指標，英特爾 GPA 顯示 iGPU 和 LLC 之間傳輸了 256M 字節，其中 223M 字節來自 DRAM。這意味著 LLC 的命中率非常低。消息計數意味著更高的hitrates，但英特爾的網站稱這些指標可能不準確
低hitrates意味著您真的必須認真考慮額外的緩存層是否值得。iGPU 內存訪問通過 L3 控制器進行查找，但通常最終還是會進入 DRAM。然后，從 DRAM 中獲取的滿足未命中的數據被填充到 L3 中，同時被轉發到 iGPU。如果不仔細管理，您可能會與 CPU 端 L3 訪問發生容量和帶寬爭用。
英特爾將他們的 iGPU 緩存稱為 L3，與 CPU 的 L3 產生了很多混淆（從 GPU 的角度來看，這有點像 L4？）
英特爾還一直在為其 iGPU 配備更大的私有緩存，這使得 iGPU 對共享 L3 的依賴程度降低。較新的 Xe 部件具有比 AMD 的 Vega 和 RDNA 2 iGPU 更大的私有緩存，并且在緩存容量方面實際上接近一些中端獨立GPU。例如，Nvidia 的 RTX 3060 具有 3 MB 的二級緩存。如果這種趨勢繼續下去，Meteor Lake 的 iGPU 應該有足夠的緩存來獨立運行，而無需依賴 CPU 的 L3。畢竟，AMD 的 Renoir 和 Cezanne 提供了具有競爭力的 iGPU 性能，只有 1 MB L2 并且無法與 iGPU 共享 CPU 的 L3。
放大備份
雖然 Meteor Lake 在物理上看起來像是一個非常緊密集成的設計，但我認為最好將其視為 AMD Chiplet策略的一種變體，但要進行更多的分解，并以能效為代價。Meteor Lake 不是 Sapphire Rapids，它使用高帶寬、低延遲的die-to-die 連接來跨芯片運行 L3 的網狀互連。
有時，當“速度”以 GT/s 為單位給出而不指定傳輸大小時，我會感到惱火
相反，Meteor Lake 的 FDI 鏈路可能具有與 AMD 的 IFOP 鏈路相似的性能特征，只是功耗較低。因此，它們不用于任何性能關鍵路徑。SoC 到 IOE 鏈路處理 DisplayPort 和 PCIe 流量，這比 DRAM 流量具有更高的延遲和更低的帶寬。大多數 iGPU 內存訪問應該被 iGPU 的私有緩存捕獲，因此 iGPU 到 SoC 的鏈接正在處理（希望不頻繁）GPU cache miss 請求。同樣，CPU 的 L3 應捕獲來自內核的大多數內存訪問，這也應使 CPU 到 SoC 的流量也保持在較低水平。SoC 可能在 CPU tile 上有一個 ring stop，它確保跨芯片鏈接只看到發往 SoC 的 IDI 數據包，并保持“hotter” traffic通過 CPU tile 內的 ring stop。請注意，CPU tile的方向是 E-Core 最靠近 SoC tile，并且在 E-Core 環停止和芯片邊緣之間有相當多的邏輯。如果我不得不猜測，對于位于 CPU 塊上的 SoC tile的請求，有相當多的排隊和仲裁邏輯。
2P + 8E Meteor Lake CPU tile die shop
進一步猜測，我認為 Meteor Lake 可能會提高英特爾的 L3 性能。L3 的環形總線完全包含在裸片中，并且只有足夠的停靠點來處理內核的 L3 功能。這使它很像 Zen 3。
把它放在一起
展望未來，Meteor Lake 的 tile 戰略應該為英特爾提供成本節約和更好的模塊化。與 AMD 相比，英特爾將能夠在移動細分市場中使用Chiplet，在這些細分市場中，嚴格的功率限制會阻止 AMD 使用其更耗電的 IFOP 鏈路。
然而，據傳 AMD 為高性能移動市場（55 瓦以上）設計的 Dragon Range系列 CPU 使用與 AMD 桌面 CPU 相同的Chiplet架構。AMD 在其分析日新聞稿中還表示，Phoenix Point（AMD 將其投入 15 至 45 瓦范圍內）也將使用Chiplet架構。甚至 15 瓦 TDP CPU 轉向Chiplet表明 AMD 可能有一個新的潛在Chiplet實現，它可能更類似于英特爾的 Meteor Lake。除了“AMD Chiplet架構”之外沒有更多細節，我認為可以公平地說它是在可能的范圍內，無論如何我們都會很高興看到 AMD 如何在低功耗移動芯片上實現Chiplet。
6P + 8E Meteor Lake CPU tile，來自 Intel 的 Hot Chips 幻燈片。
與 AMD 相比，英特爾還對他們的設計進行了更多分解，使用單獨的 iGPU 和 IO 擴展塊。AMD 將它們打包到他們的 IO 芯片中。英特爾因此具有更多的tile重用潛力，當然我們必須等待幾年才能看到他們如何利用這一點。
更多信息可以來這里獲取==>>電子技術應用-AET<<
