在 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重用潜力，当然我们必须等待几年才能看到他们如何利用这一点。
