Universal Chiplet Interconnect Express (UCIe)中文翻译第一章

前段时间因工作需要阅读了UCIe的协议规范，心想光看没用，不如动手做点内容，于是就随手写一下对应的中文吧。顺便就当csdn是网络笔记本了~
所以，翻译水平必然不会有专业文学水平，尤其是某些特定的专有名词可能会存在偏差，望见谅。

---

1.0 Introduction

此章节提供UCIe架构的一个概览。UCIe是一个开放，多协议支持，包交换的同封装上多die互联的标准，用于在同一个封装上连接多个die。此标准的意在打造一个充满活力的生态系统，支持可可使用UCIe互联的多die结构。UCIe在公共物理层与链路层上支持多种协议（PCIe 、CXL和可用于映射任何所选择协议的原始模式，只要两端都支持）。它包含构建SoC所需要的元素，比如应用层，以及与封装相关的物理因素（bump位置，功耗传输，散热方案）。该协议规范的定义是为了确保具有不同性能特征的各种设备之间的互操作性。提供了明确定义的调试和合规机制以确保互操作性。预计此协议规范将会以向后兼容的方式发展。
尽管UCIe支持广泛的使用模型，但是一些模型是为了说明其可以在计算行业中能够引领的功能创新。最初始能够映射到UCIe的协议是PCIe与CXL。所有协议的映射工作是通过Flit格式实现的，包括原始模式也是。PCIe和CXL在业界都被广泛使用，在UCIe中通过UCIe Adapter和PHY替换原有的PCIe SerDes PHY和PCIe/CXL 逻辑PHY以及链路级别重传功能来实现更多的封装集成方式，以提高功耗和性能特性。UCIe还支持与协议无关的原始模式，以支持映射其他的协议；同时允许在封装上额外集成独立的SerDes收发模块。
图1展示了一个SoC的封装，其中包含了通过UCIe连接的CPU Die，其他用途的加速器 Die和I/O Die。加速器Die或I/O Die能够通过运行在UCIe上的CXL与CPU Die相连接，能够实现CXL的I/O、一致性与内存协议（CXL.io、CXL.cache、CXL.mem）。I/O块能够提供面向外部的CXL引脚、PCIe引脚与DDR引脚。加速器Die也可以使用运行在UCIe的PCIe事务连接到CPU。封装上的CPU Die与CPU Die也可以通过UCIe进行互联，实现一致性协议。
​

UCIe Retimer能够用于把UCIe的连接拓展到封装之外的其他封装互联。封装之外的互联方式包括电缆或光缆或其他任何的用于机架级别的连接方式，如图2所示。UCIe协议规范要求UCIe Retimer部署在UCIe的本地封装接口上并且保证在两个封装之间的Die与Die交互的Flit是依照UCIe协议并且使用相应的通道拓展技术。（The UCIe specification requires the UCIe Retimer to implement the UCIe interface to the die that it connects on its local package and ensure that the Flits are delivered across the two dies across the packages following UCIe protocol using the channel extension technology of its choice.）
图2给出了使用CXL 2.0或更高版本协议的机架级别互联的示意图。图2a展示了一个机架级别的示意图，其中来自不同计算机刀片服务器的多个计算节点连接到交换机，同时该交换机连接到多个CXL加速器/type-3内存设备，同时上述的所有设备都能够防止在一个或多个抽屉式的机箱中。这种连接的逻辑关系如图2b所示，其中每一个host（H1、H2、…)都是上述的抽屉式机箱。每一个抽屉式机箱都通过UCIe Retimer使用封装外的CXL协议互联与交换机进行连接，如图2c所示。交换机同时具有封装在一起的Retimer，Retimer通过UCIe与同一封装下的交换机进行连接，Retimer的另一侧是通过PCIe/CXL的物理接口连接到其他封装的加速器/内存设备，如图2c所示。
​

此版本的UCIe协议不涉及3D封装。它允许两种不同的封装形式：标准封装（2D）和高级封装（2.5D）。这样就涵盖了从成本优先的选项到性能优先的选项。

• 标准封装：这种封装方式常用于低成本与在有机封装基板上实现长距离通信（10mm-25mm）的场景，但与封装外的SerDes通信方式相比能够提供更加好的误码率特性。图3展示了一个使用标准封装的例子。表4展示了使用标准封装的UCIe协议的传输特性。
  ​

• 高级封装：此封装提供了一种聚焦于高性能的应用场景。因此为了得到更高的带宽与更低的时延与更优秀的能耗比，牺牲了传输距离（小于2mm）。图4图5图6展示了使用高级封装的例子。表5展示了使用高级封装的UCIe协议的传输特性。
  
  

1.1 UCIe Components

UCIe是一个分层实现的协议，每一层都有其特定的功能实现。图7展示了UCIe协议栈的三个主要部分以及各层之间的功能划分。UCIe协议栈中的每一个部分都需要支持其所宣告的功能与数据带宽。
​

1.1.1 Protocol Layer

虽然协议层与特定的应用程序有着强相关，UCIe协议规范提供了通过UCIe链路传输CXL或PCIe协议的例子。UCIe支持以下协议以启用不同的应用场景：
PCIe协议规范中定义的PCIe 6.0 Flit 模式。
CXL协议规范中定义的CXL 2.0和更高版本的协议。
Streaming协议：此模式为使用UCIe传输的用户自定义的协议提供了通用的传输模式。
对于上述的每一个协议，通过UCIe传输时可以使用不同的优化与相关的Flit传输方式。第2章与第3章将会对不同协议的细节与Flit格式。

1.1.2 Die-To-Die Adapter

D2D Adapter在UCIe链路中负责协调协议层与物理层之间成功地进行数据传输功能。它尽可能地减少主要数据路径上的逻辑，为协议Flit提供低延迟，高度优化的数据路径。在传输CXL协议时，多个协议module同时实现所需要的ARB/MUX功能也是由D2D Adapter提供的。对于原始误码率小于1e-27的场景，Adapter能够实现CRC校验码检测与重传功能以保证误码率指标。重传的规则请查阅第3.7节。
D2D Adapter负责与远程链路伙伴协调更高级别的链路状态机与bring up、协议选项相关参数交换，以及与远程链路伙伴进行电源管理。第3章讲述了D2D Adapter相关内容。

1.1.3 Physical Layer

物理层的子部分如图8所示。
​
UCIe在物理bump上的主要数据路径按组别划分，每一组中有多个lane，每一组被称为Module。一个Module是UCIe中AFE的最小粒度单位。标准封装和高级封装中每个模块的lane数量在第4章中讲述。一个给定的协议层或D2D Adapter能够通过多个Module进行数据传输。
UCIe的物理链路由两个部分组成：

• Sideband（边带）：
  此连接用于参数交换，寄存器访问与和远程链路伙伴进行协调设置和管理。其每个传输方向都由对应的时钟信号引脚与数据信号引脚组成。无论主带数据路径的传输速度如何，边带时钟信号都固定在800Mhz。UCIe物理层的边带逻辑必须使用备用电源和处于"always on"的电源域中。每个module都拥有属于自己的边带信号引脚。
  对于高级封装，每个方向上的边带信号引脚都有对应冗余引脚以用于故障修复。
• Mainband（主带）：
  此连接组成了UCIe的主要数据路径。其中每个module由一个时钟信号，一个数据有效信号和N个数据lane组成。
  对于采用高级封装的场景，上述数据lane的数量N为64，同时有额外的4个用于故障修复的冗余数据lane。
  对于采用标准封装的场景，上述数据lane的数量N为16，但并没有额外用于故障修复的冗余数据lane。
  逻辑物理层通过不同的功能和相关执行顺序建立起适当的链路管理功能与数据传输功能。（例如边带传输，主带训练或主带修复）。第4章与第5章讲述了物理层操作的相关细节。

1.1.4 Interfaces

UCIe定义物理层与D2D Adapter之间的接口为RDI（Raw D2D Interface），定义D2D Adapter与协议层之间的接口为FDI（Flit-aware D2D Interface），详细请参详第8章。
执行如此定义的原因如下：
允许供应商与SoC制造商能够以较低的成本和更快的上市时间以混合和匹配来自不同供应商的不同层级。例如，让协议层与D2D Adapter和来自其他不同供应商的且符合本协议规范中定义的接口的物理层一起工作。
考虑到硅后验证的巨大开销与成本，对于此协议规范中所定义的接口拥有一致的BFM理解和开发能够使得支持UCIe的IP开发更简单。

1.2 UCIe Configurations

此部分讲述UCIe中不同的配置与排列。

1.2.1 Single Module Configuration

使用标准封装的单module实现方式提供16个数据lane，如图9所示。使用高级封装的单module实现方式提供64个数据lane，如图10所示。如果同时例化多个单module，每一个module需要独立运行，比如运行在不同的传输频率下。
​

1.2.2 Multi Module Configuration

此协议允许2个或4个module的配置方式。处于multi-module下的子module不能单独运行。图11和图12分别展示了2个和4个module配置的实例。
​

1.3 UCIe Retimers

如前面所描述，UCIe Retimer用于支持不同类型的封装互联，以拓展处于不同封装中的两个UCIe Die之间进行互联。每一个UCIe Retimer拥有一个本地UCIe链路以连接本地UCIe Die，同时拥有一个外部的UCIe链路以连接其他片外的封装片。图13展示了一个利用UCIe Retimer进行不同封装片外的UCIe Die 0与UCIe Die1之间互联的例子。UCIe Retimer 0和UCIe Die 0通过UCIe 链路0在封装0上相连接。UCIe Retimer 1和UCIe Die 1通过UCIe 链路0在封装1上相连接。术语“remote Retimer partner”（远程Retimer伙伴）用于指代连接到封装外的互联远端的UCIe Retimer Die。
​
UCIe Retimer的职责包括如下：

提供可靠的跨封装Flit传输，以下三种选项用于实现此职责：

• Retimer能够使用当前所进行传输的协议（如PCIe或CXL）底层定义的FEC与CRC进行传输保障，前提是使用的封装外连接能够正确识别当前协议栈下传输中可能出现的错误模型。此时UCIe链路将会被设置为使用原始模式来传输其所使用的协议的bit流。在这种情况下，需要在UCIe Die上调整队列大小以满足底层数据往返延迟。
• Retimer允许提供必要的FEC，CRC和重传功能以满足片外互联的误码率要求。在这样的情况下，Flit将会通过三个独立的链路传输。每一个UCIe Retimer对其同一封装下的UCIe Die执行独立的Ack/Nak握手并且与远程Retimer伙伴也执行独立的Ack/Nak握手。
• Retimer通过使用自定义的FEC替代原有PCIe或CXL定义的FEC，或者在已有PCIe或CXL定义的FEC的基础上增加自定义的FEC，但使用当前底层协议实现的CRC和重传机制。在这种情况下，需要在UCIe Die上调整队列大小以满足底层数据往返延迟。
• 与远程Retimer伙伴解决链路和协议的参数以保证UCIe Die端到端之间的互操作性。例如，允许Retimer在图13中的封装0与封装1上强制使用相同的链路宽度、速度、协议（包括任何相关的协议特定参数）和Flit格式。具体的解析机制包括不同封装之间的参数交换引发的信息传输的实现方式需要依据具体Retimer情况而言，并且需要保证所使用的信息交互方式能够被两边的封装都能支持。然而，为了确保UCIe链路的鲁棒性，以避免由于通过片外互联与远程Retimer伙伴进行参数交互通信时引致的长时间等待而触发不必要的超时，UCIe 协议规范定义了“Stall”的响应方式以等待可能出现延迟的边带信息。Retimer需要依照UCIe规范中定义的规则响应"Stall"以避免在与远程Retimer伙伴进行协商或等待其响应时出现不必要的超时。Retimer有责任确保UCIe链路不会无限期停止。
• 与远程Retimer伙伴协同对Adapter链路状态与RDI状态进行解析以确保端到端操作符合规范。参考第3章以获得更多信息。

对于流控与反压机制：

• 从UCIe Die发送到UCIe Retimer的数据流控机制通过Credits实现。这些Credit是基于已有的底层协议的Credit机制（比如PCIe中的PRH与PRD credit）。这些UCIe D2D credit需要被用于跨越两个UCIe Retimer的流控并且传输到UCIe Retimer的任何数据最终必须要由远程UCIe Die所使用，而不是被其他设备使用。每一个UCIe Retimer需要为从其同一封装内的UCIe Die接收到的Flit实现一个接收缓冲区（Receive Buffer）。接收缓冲器的credit需要在初始参数交换时宣布到UCIe Die上，并且UCIe Die在收到接收缓冲器的credit前不能够往Retimer发送任何的数据。一个credit对应着256字节的数据（包括所有的FEC、CRC）。在每次传输完成之后将会根据valid信号重载credit数量（参照第4.1.2节）。当RDI状态从Active跳出时，credit计数器将会回退到初始宣布的数值。UCIe Retimer需要在RDI重新进入Active状态前清空或转移其接收缓冲器中的数据。
• 在D2D Adapter层中从UCIe Retimer传输到其他的UCIe Retimer将不会受到流控的限制。如果需要实现流控，UCIe Retimer可以与另一个UCIe Retimer建立独立地流控机制，这内容超过了本协议规范的范围。

1.4 UCIe Key Performance Targets

表6给出了UCIe的性能目标。


Die Edge Bandwidth Density（第5章中定义）为45um（高级封装）和110um（标准封装）的bump pitch。
Energy Efficiency包含所有物理层相关的电路：发送，接收，锁相环，时钟分配等。通道长短带来不同的能耗将会在第5章中讨论。
Latency包含Adapter上的延时与物理层发送与接收的延时。参照第5章以得到更多关于物理层时延的内容。

1.5 Interoperability

封装设计者需要确保连接在封装上的Die能够互相操作。这包括采用兼容性的封装互联（标准封装或高级封装）、协议、电压等级等。强烈建议Die的发送电压小于0.85V；这样他们就可以在可预见的未来与更多的工艺节点继续宁互联操作。
此协议规范涵盖了针对高级封装的各种bump pitch范围的互操作性。预计随着时间的推移，使用的bump pitch将会越来越小。通过更小的bump pitch，设计能够降低传输频率以优化面积，并且在减少面积的情况解决高带宽传输的功率传输与热限制。表7中总结了4组对应的bump pitch。
依据第5章中讲述的PHY定义，保证了每个组内以及跨组的互操作性。表6中提供的性能指标采用45um的bump pitch，这是基于此协议发布时广泛采用的技术。
​