《電子技術(shù)應(yīng)用》
您所在的位置:首頁 > 電子元件 > 業(yè)界動(dòng)態(tài) > Intel和AMD的Chiplet對(duì)比

Intel和AMD的Chiplet對(duì)比

2022-09-13
來源: 半導(dǎo)體行業(yè)觀察
關(guān)鍵詞: Intel AMD chiplet MeteorLake

  在 Hot Chips 34 的演講中,英特爾詳細(xì)介紹了他們即將推出的 Meteor Lake 處理器如何使用Chiplet。與 AMD 一樣,英特爾正在尋求獲得與使用Chiplet相關(guān)的模塊化和更低的成本。與 AMD 不同,英特爾做出了一套不同的實(shí)施選擇,這使 Meteor Lake 特別適合處理不同的客戶群。

  高層次戰(zhàn)略

  在過去十年中,英特爾的客戶端針對(duì)不同的細(xì)分市場(chǎng)提供了不同的單片芯片。這些客戶端芯片并不是特別大,所以單片設(shè)計(jì)在一段時(shí)間內(nèi)是有意義的。但英特爾一直在增加核心數(shù)量,引入混合架構(gòu),添加更多 SoC 功能(如 Thunderbolt 支持),并在集成顯卡方面一如既往地努力。這意味著可能的配置數(shù)量將急劇增加,并且在某些時(shí)候,使用tiles將使英特爾制造的獨(dú)特芯片數(shù)量減少。因此,將設(shè)計(jì)拆分為tiles將有助于簡化生產(chǎn)。

  微信圖片_20220913115001.png

  Wikichip 頁面上的Kaby Lake 屏幕截圖,顯示了通過不同的單片芯片實(shí)現(xiàn)的不同配置

  這將我們帶到了Meteor Lake。Meteor Lake分為四個(gè)tiles。其中,CPU tile 包含 CPU 內(nèi)核及其緩存,很像 AMD 的 CCD;集成 GPU 有自己的tile;SoC tile包含當(dāng)前 Intel 客戶端 CPU 的系統(tǒng)代理中的大部分功能。最后,IO 擴(kuò)展tile連接到 SoC tile。所有的tile都安裝在一個(gè)無源基座die的頂部,該die連接tile并處理電力傳輸。

  微信圖片_20220913115030.png

  來自 Intel 的 Hot Chips 幻燈片,展示 Meteor Lake 的不同tile

  隨著英特爾為不同的客戶細(xì)分市場(chǎng)定制芯片,這種方法為tile重用提供了很大的潛力。例如,具有六個(gè) P 核心和兩個(gè) E 核心集群的核心塊可以用于各種外形尺寸。當(dāng)與強(qiáng)調(diào) PCIe 通道的 SoC tile配對(duì)時(shí),它可以用于中端桌面芯片?;蛘?,對(duì)于筆記本電腦,它可以與具有圖像處理單元的 SoC tile配對(duì),以在大量使用網(wǎng)絡(luò)攝像頭的情況下延長電池壽命。

  與 AMD 的方法對(duì)比

  相比之下,AMD 的Chiplet方法允許在臺(tái)式機(jī)和服務(wù)器領(lǐng)域重復(fù)使用die,但目前在臺(tái)式機(jī)和移動(dòng)設(shè)備上并沒有那么多。通過 PCB 的簡單封裝鏈接價(jià)格便宜,并且可以實(shí)現(xiàn)長距離傳輸,但對(duì)于降低功耗并不是最好的。因此,AMD 目前使用單獨(dú)的單片die來瞄準(zhǔn)移動(dòng)領(lǐng)域。

  微信圖片_20220913115054.png

  面向桌面需求的Zen 3芯片

  微信圖片_20220913115127.png

  面向移動(dòng)設(shè)備的芯片

  Meteor Lake 的封裝解決方案肯定更貴。英特爾需要包含一個(gè)單獨(dú)的基礎(chǔ)die。擴(kuò)大 Meteor Lake 將更加困難——包括更大的 CPU tile或更多的 CPU tile將需要更大的基礎(chǔ)die。作為交換,英特爾的設(shè)計(jì)可以實(shí)現(xiàn)更高的 IO 密度并使用更少的功率在tile之間移動(dòng)數(shù)據(jù)。正如我們所見,die to die 鏈接設(shè)計(jì)與兩家公司的方法密切相關(guān)。讓我們仔細(xì)看看。

  Die to die的互連

  英特爾將他們的 die to die 鏈接稱為“Foveros Die Interconnect”(FDI)。其更高的 IO 密度應(yīng)允許在空間受限的超極本板上使用更小的封裝。此外,功耗在電池供電設(shè)計(jì)中至關(guān)重要,毫無疑問,與 AMD 的普通封裝互連相比,F(xiàn)DI 更適合打入移動(dòng)領(lǐng)域。AMD 表示,Zen 1 的 die-to-die Infinity Fabric 鏈接的功耗為 2 pJ/bit,他們的 Zen 2 發(fā)布幻燈片表明 Infinity Fabric 可以以每比特低 27% 的功耗傳輸數(shù)據(jù)。顯然,我們不知道與其他邏輯相比,優(yōu)化 cross die link有多少功耗降低,但可以合理地假設(shè) AMD 的 die-to-die 傳輸貢多與 Intel Haswell 的 OPIO 互聯(lián)一樣多(甚至更多)。

  微信圖片_20220913115224.jpg

  英特爾在 HC34 上的 Meteor Lake 演示期間顯示的幻燈片

  但令人驚訝的是,英特爾并沒有宣傳很大的延遲優(yōu)勢(shì)。英特爾的幻燈片非常模糊,僅顯示延遲低于 10 ns。AMD 還聲稱使用普通的封裝鏈接可以實(shí)現(xiàn)低于 10 ns 的延遲。

  “從 CCD 到 IOD 和返回的總往返延遲(包括數(shù)字控制邏輯)為 13 個(gè) FCLK,或小于 9 ns”,AMD在ISSCC 2020上介紹其面向高性能服務(wù)器和臺(tái)式機(jī)產(chǎn)品的 AMD Chiplet 架構(gòu)的時(shí)候說。

  更具體地說,AMD 表示延遲是 13 個(gè) Infinity Fabric (FCLK) 時(shí)鐘周期。該論文討論了 Matisse 和 Rome(分別為桌面和服務(wù)器形式的 Zen 2),并且似乎假設(shè) 1.46 GHz FCLK 來獲得 9 ns 的數(shù)字。這與在耦合模式下運(yùn)行 DDR4-2933 一致。在通常運(yùn)行更快的 DDR4 的臺(tái)式機(jī)上延遲會(huì)更低。在 1.6 GHz FCLK 時(shí)鐘下,延遲將接近 8 ns。將 FCLK 推到 1.8 GHz,這對(duì)于許多 Matisse 芯片都是可能的,13 個(gè) FCLK 將是 7.22 ns。當(dāng)然,英特爾的 <10 ns 數(shù)字可能表示低至 2-3 ns 的實(shí)際數(shù)字。但如果英特爾可以將延遲降低到那個(gè)水平,他們可能會(huì)更加突出地展示它。

  帶寬數(shù)據(jù)也不清楚。英特爾表示 FDI 每秒可以進(jìn)行 20 億次傳輸,但沒有具體說明每次傳輸?shù)姆秶?。不過,基于英特爾如何使用 FDI,我懷疑帶寬并沒有明顯高于 OPIO 或 IFOP。

  Tile Layout和通信協(xié)議

  我們還可以檢查英特爾在哪里使用 FDI 來了解其性能特征。沒有任何 FDI 鏈路似乎處于高帶寬、延遲敏感的路徑中。CPU tile 和 SoC tile 之間的鏈接大多會(huì)看到 L3 miss traffic,應(yīng)該只有幾十 GB/s,有數(shù)百個(gè)周期的延遲。SoC tile到 IO 擴(kuò)展tile可能會(huì)處理 PCIe 流量,它具有更低的帶寬和更高的延遲。

  需要注意的一件有趣的事情是,Meteor Lake 將 iGPU 放置在遠(yuǎn)離 CPU 的 L3 緩存的地方,位于 SoC tile的另一側(cè)。之前的英特爾設(shè)計(jì)將 iGPU 置于ring bus stop上,自然而然地共享 CPU 的 L3 高速緩存。另一方面,如果 Meteor Lake 的 iGPU 想要hit  CPU 的 L3,它必須通過中心 SoC tile走很長的路。為來自 iGPU 的每個(gè)請(qǐng)求走那么長的路是沒有意義的。所以我相信 iGPU tile 的行為可能與 CPU tile 一樣——也就是說,iGPU 到 SoC 的鏈接只會(huì)看到 iGPU 到 DRAM 的 traffic。我認(rèn)為 L3 不像以前的英特爾設(shè)計(jì)那樣共享。

  另一個(gè)提示是使用的通信協(xié)議,所以讓我們繞道討論一下。英特爾表示,CPU 和 SoC tile使用 IDI 協(xié)議進(jìn)行通信,而 iGPU 模塊使用 iCXL 協(xié)議與 SoC 進(jìn)行通信。SoC 和 IO 擴(kuò)展tile通過 IOSF(Integrated On-chip system Fabric)和 DisplayPort 連接。我們都知道 DisplayPort 是什么,IOSF 與 PCI 共享一個(gè)ordering model。IO 擴(kuò)展tile可能有一個(gè) PCIe 控制器和一些 DisplayPort PHY,而跨芯片連接只是為這些接口供電。不過,IDI 和 iCXL 更有趣,它們可以為我們提供有關(guān) iGPU 如何與 CPU tile 交互的提示。

  微信圖片_20220913115259.jpg

  來自 Hot Chips 的幻燈片,展示了正在使用的各種跨芯片通信協(xié)議

  IDI 或 In-Die Interface最早出現(xiàn)在 Intel 的 Nehalem 架構(gòu)中,它將核心連接到非核心的全局隊(duì)列和 L3。此后,IDI 繼續(xù)作為Intel 環(huán)形總線(ring bus)上的主要協(xié)議,隨著時(shí)間的推移進(jìn)行各種更新和改進(jìn)。它使用 MESIF 緩存一致性協(xié)議,這意味著緩存行的狀態(tài)可以是修改、獨(dú)占、共享、無效或轉(zhuǎn)發(fā)。IDI 協(xié)議本身似乎相當(dāng)復(fù)雜,具有不同的數(shù)據(jù)包類型集,用于 L3 切片控制邏輯中的特定隊(duì)列。例如,每個(gè) L3 切片都有一個(gè)入口請(qǐng)求隊(duì)列 (IRQ)。當(dāng)來自核心的 IDI 數(shù)據(jù)包到達(dá)它所尋址的 L3 切片時(shí),它將被拉出網(wǎng)格或環(huán)并添加到 IRQ。數(shù)據(jù)包類型代表來自內(nèi)核的非常具體的內(nèi)存訪問請(qǐng)求,讓 L3 切片控制器在保持高速緩存一致性的同時(shí)最大限度地提高性能。

  微信圖片_20220913115317.png

  一些記錄在案的 Skylake-X IDI 數(shù)據(jù)包操作碼,用于核心到 L3 切片(緩存代理)通信。

  其他隊(duì)列包括處理窺探(snoops)的 Ingress Probe Queue 和處理來自內(nèi)核的寫回的 Writeback Queue。總之,IDI 是一種用于處理網(wǎng)狀或環(huán)形總線流量的內(nèi)部協(xié)議,其中包括 CPU 內(nèi)核和 L3 緩存之間的高帶寬、低延遲通信。前幾代英特爾 iGPU 使用 IDI 協(xié)議,自然使它們成為 L3 緩存的代理,就像 CPU 內(nèi)核一樣。Haswell iGPU 的文檔支持這一點(diǎn)——iGPU 驅(qū)動(dòng)程序使用 IDI hash mask來配置 eDRAM 緩存。

  但是 Meteor Lake 的 iGPU 換成了 iCXL,這是一種不使用 PHY 的 Compute Express Link (CXL) 的內(nèi)部實(shí)現(xiàn)。CXL 基于 PCI Express,與 PCI Express 一樣,旨在將 CPU 連接到 IO 設(shè)備。與 PCIe 相比,CXL 3.0 允許更好地處理緩存一致性的硬件,添加延遲優(yōu)化的消息格式 (flits),并且可以通過實(shí)現(xiàn)三個(gè)子協(xié)議 - CXL.io、CXL.cache 和 CXL 來接受更廣泛的設(shè)備。這些子協(xié)議分別適用于通用設(shè)備、GPU 等相干加速器(coherent accelerators)和內(nèi)存擴(kuò)展設(shè)備。如果您查看 CXL.cache 請(qǐng)求類型,您會(huì)發(fā)現(xiàn)在 IDI 中有一些模糊的等價(jià)物。但 CXL 與 IDI 協(xié)議不同,并不意味著將處理核心連接到它們的緩存。

  微信圖片_20220913115339.png

  CXL 2.0 規(guī)范中的 CXL 請(qǐng)求類型

  一些 CXL 數(shù)據(jù)包類型在 IDI 中具有模糊相似的對(duì)應(yīng)物,但這些相似性主要出現(xiàn)在發(fā)往遠(yuǎn)程請(qǐng)求隊(duì)列 (RRQ: Remote Request Queue ) 的 IDI 數(shù)據(jù)包中,該隊(duì)列處理來自遠(yuǎn)程套接字(remote socket)的 UPI 請(qǐng)求。核心用于訪問 L3 的數(shù)據(jù)包類型(DrD、Crd、RFO 等)明顯不存在。另一個(gè)區(qū)別是 CXL 使用基本的 MESI 一致性協(xié)議。它沒有在 IDI 的 MESIF 協(xié)議中發(fā)現(xiàn)的 Forward 狀態(tài),這會(huì)使 CXL 和 IDI 之間直接轉(zhuǎn)換的任何嘗試變得復(fù)雜。

  不再有 iGPU L3 共享?

  總而言之,我認(rèn)為 iGPU 不像以前的英特爾設(shè)計(jì)那樣共享 CPU L3。如果英特爾想像自 Sandy Bridge 以來所做的那樣繼續(xù)與 iGPU 共享 L3,他們將保持與當(dāng)前客戶端芯片相同的芯片布局。iGPU 將繼續(xù)使用 IDI 與外界通信。Meteor Lake 的布局和通信協(xié)議更改只有在英特爾不希望 iGPU 再共享 CPU 的 L3 時(shí)才有意義。這聽起來像是英特爾在倒退,但這種改變有充分的理由。

  首先,Meteor Lake 的設(shè)計(jì)讓英特爾將 iGPU 從主 CPU 環(huán)形總線上取下來,這將減少環(huán)形停止的數(shù)量。更少的ring stops意味著減少延遲。它可以提供更好的電源效率,因?yàn)閿?shù)據(jù)不會(huì)被移動(dòng)得那么遠(yuǎn),并且 CPU 內(nèi)核花費(fèi)更少的時(shí)間等待數(shù)據(jù)。也許這會(huì)讓 Intel 為 Meteor Lake 提供更高的時(shí)鐘頻率,為 CPU 內(nèi)核追求更好的 L3 性能。隨著 iGPU 與 CPU 塊分離,英特爾還可以通過在只有 iGPU 處于活動(dòng)狀態(tài)時(shí)將整個(gè) CPU 塊設(shè)置為低功耗狀態(tài)來延長電池壽命。我還懷疑 iGPU 方面的 L3 命中率一開始并不是很好。

微信圖片_20220913121520.jpg  

  外部內(nèi)存訪問減少 28% 意味著 28% 的 iGPU 訪問來自 SLC(也就是 28% 的命中率)。ARM SoC 中的 SLC 填充了與 Intel L3 類似的功能——兩者都緩存

  與當(dāng)前 Intel 芯片中的 L3 一樣,ARM 的系統(tǒng)級(jí)緩存 (SLC) 為 CPU 和 iGPU 請(qǐng)求提供服務(wù)。當(dāng)使用 8 MB SLC 時(shí),他們看到 iGPU 方面的hitrate 為 28%,這非常低。AMD 同樣觀察到緩存大小低于 16 MB 的 GPU Infinity Cache hitrates不佳,這來自他們?cè)凇坝螒蜷_始的地方”中發(fā)布的數(shù)據(jù)。最后,我在 Haswell iGPU 上使用英特爾的圖形性能分析器 (GPA) 收集了數(shù)據(jù)。雖然指標(biāo)很難解釋,但無論您如何看待它們,它們肯定都不能說明hitrates很高。

  微信圖片_20220913121852.jpg

  如果我正確解釋指標(biāo),英特爾 GPA 顯示 iGPU 和 LLC 之間傳輸了 256M 字節(jié),其中 223M 字節(jié)來自 DRAM。這意味著 LLC 的命中率非常低。消息計(jì)數(shù)意味著更高的hitrates,但英特爾的網(wǎng)站稱這些指標(biāo)可能不準(zhǔn)確

  低hitrates意味著您真的必須認(rèn)真考慮額外的緩存層是否值得。iGPU 內(nèi)存訪問通過 L3 控制器進(jìn)行查找,但通常最終還是會(huì)進(jìn)入 DRAM。然后,從 DRAM 中獲取的滿足未命中的數(shù)據(jù)被填充到 L3 中,同時(shí)被轉(zhuǎn)發(fā)到 iGPU。如果不仔細(xì)管理,您可能會(huì)與 CPU 端 L3 訪問發(fā)生容量和帶寬爭用。

  微信圖片_20220913121915.png

  英特爾將他們的 iGPU 緩存稱為 L3,與 CPU 的 L3 產(chǎn)生了很多混淆(從 GPU 的角度來看,這有點(diǎn)像 L4?)

  英特爾還一直在為其 iGPU 配備更大的私有緩存,這使得 iGPU 對(duì)共享 L3 的依賴程度降低。較新的 Xe 部件具有比 AMD 的 Vega 和 RDNA 2 iGPU 更大的私有緩存,并且在緩存容量方面實(shí)際上接近一些中端獨(dú)立GPU。例如,Nvidia 的 RTX 3060 具有 3 MB 的二級(jí)緩存。如果這種趨勢(shì)繼續(xù)下去,Meteor Lake 的 iGPU 應(yīng)該有足夠的緩存來獨(dú)立運(yùn)行,而無需依賴 CPU 的 L3。畢竟,AMD 的 Renoir 和 Cezanne 提供了具有競(jìng)爭力的 iGPU 性能,只有 1 MB L2 并且無法與 iGPU 共享 CPU 的 L3。

  放大備份

  雖然 Meteor Lake 在物理上看起來像是一個(gè)非常緊密集成的設(shè)計(jì),但我認(rèn)為最好將其視為 AMD Chiplet策略的一種變體,但要進(jìn)行更多的分解,并以能效為代價(jià)。Meteor Lake 不是 Sapphire Rapids,它使用高帶寬、低延遲的die-to-die 連接來跨芯片運(yùn)行 L3 的網(wǎng)狀互連。

  微信圖片_20220913122100.png

  有時(shí),當(dāng)“速度”以 GT/s 為單位給出而不指定傳輸大小時(shí),我會(huì)感到惱火

  相反,Meteor Lake 的 FDI 鏈路可能具有與 AMD 的 IFOP 鏈路相似的性能特征,只是功耗較低。因此,它們不用于任何性能關(guān)鍵路徑。SoC 到 IOE 鏈路處理 DisplayPort 和 PCIe 流量,這比 DRAM 流量具有更高的延遲和更低的帶寬。大多數(shù) iGPU 內(nèi)存訪問應(yīng)該被 iGPU 的私有緩存捕獲,因此 iGPU 到 SoC 的鏈接正在處理(希望不頻繁)GPU  cache miss 請(qǐng)求。同樣,CPU 的 L3 應(yīng)捕獲來自內(nèi)核的大多數(shù)內(nèi)存訪問,這也應(yīng)使 CPU 到 SoC 的流量也保持在較低水平。SoC 可能在 CPU tile 上有一個(gè) ring stop,它確??缧酒溄又豢吹桨l(fā)往 SoC 的 IDI 數(shù)據(jù)包,并保持“hotter” traffic通過 CPU tile 內(nèi)的 ring stop。請(qǐng)注意,CPU tile的方向是 E-Core 最靠近 SoC tile,并且在 E-Core 環(huán)停止和芯片邊緣之間有相當(dāng)多的邏輯。如果我不得不猜測(cè),對(duì)于位于 CPU 塊上的 SoC tile的請(qǐng)求,有相當(dāng)多的排隊(duì)和仲裁邏輯。

  微信圖片_20220913122119.jpg

  2P + 8E Meteor Lake CPU tile die shop

  進(jìn)一步猜測(cè),我認(rèn)為 Meteor Lake 可能會(huì)提高英特爾的 L3 性能。L3 的環(huán)形總線完全包含在裸片中,并且只有足夠的停靠點(diǎn)來處理內(nèi)核的 L3 功能。這使它很像 Zen 3。

  把它放在一起

  展望未來,Meteor Lake 的 tile 戰(zhàn)略應(yīng)該為英特爾提供成本節(jié)約和更好的模塊化。與 AMD 相比,英特爾將能夠在移動(dòng)細(xì)分市場(chǎng)中使用Chiplet,在這些細(xì)分市場(chǎng)中,嚴(yán)格的功率限制會(huì)阻止 AMD 使用其更耗電的 IFOP 鏈路。

  然而,據(jù)傳 AMD 為高性能移動(dòng)市場(chǎng)(55 瓦以上)設(shè)計(jì)的 Dragon Range系列 CPU 使用與 AMD 桌面 CPU 相同的Chiplet架構(gòu)。AMD 在其分析日新聞稿中還表示,Phoenix Point(AMD 將其投入 15 至 45 瓦范圍內(nèi))也將使用Chiplet架構(gòu)。甚至 15 瓦 TDP CPU 轉(zhuǎn)向Chiplet表明 AMD 可能有一個(gè)新的潛在Chiplet實(shí)現(xiàn),它可能更類似于英特爾的 Meteor Lake。除了“AMD Chiplet架構(gòu)”之外沒有更多細(xì)節(jié),我認(rèn)為可以公平地說它是在可能的范圍內(nèi),無論如何我們都會(huì)很高興看到 AMD 如何在低功耗移動(dòng)芯片上實(shí)現(xiàn)Chiplet。

  微信圖片_20220913122146.jpg

  6P + 8E Meteor Lake CPU tile,來自 Intel 的 Hot Chips 幻燈片。

  與 AMD 相比,英特爾還對(duì)他們的設(shè)計(jì)進(jìn)行了更多分解,使用單獨(dú)的 iGPU 和 IO 擴(kuò)展塊。AMD 將它們打包到他們的 IO 芯片中。英特爾因此具有更多的tile重用潛力,當(dāng)然我們必須等待幾年才能看到他們?nèi)绾卫眠@一點(diǎn)。

  微信圖片_20220913122205.jpg

 更多信息可以來這里獲取==>>電子技術(shù)應(yīng)用-AET<<

微信圖片_20210517164139.jpg

本站內(nèi)容除特別聲明的原創(chuàng)文章之外,轉(zhuǎn)載內(nèi)容只為傳遞更多信息,并不代表本網(wǎng)站贊同其觀點(diǎn)。轉(zhuǎn)載的所有的文章、圖片、音/視頻文件等資料的版權(quán)歸版權(quán)所有權(quán)人所有。本站采用的非本站原創(chuàng)文章及圖片等內(nèi)容無法一一聯(lián)系確認(rèn)版權(quán)者。如涉及作品內(nèi)容、版權(quán)和其它問題,請(qǐng)及時(shí)通過電子郵件或電話通知我們,以便迅速采取適當(dāng)措施,避免給雙方造成不必要的經(jīng)濟(jì)損失。聯(lián)系電話:010-82306118;郵箱:aet@chinaaet.com。