UCIE Specification详解(十二)
文章目录
- 7 Sideband
- 7.1 Protocol Specification(协议规范)
- 7.1.1 Packet Types
- 7.1.2 Packet Formats
- 7.1.2.1 Register Access Packets
- 7.1.2.2 Messages without Data
- 7.1.2.3 Messages with data payloads
- 7.1.2.4 Management Port Message (MPM) with Data
- 7.1.2.4.1Common Fields in MPM Header of MPM with Data Messages on
- 7.1.2.4.2 Encapsulated MTP Message
- 7.1.2.4.3 Vendor-defined Management Port Gateway Message
- 7.1.2.5 MPMs without Data
- 7.1.2.5.1 Common Header Fields of MPM without Data Messages on Sideband
- 7.1.2.5.2 Management Port Gateway Capabilities Message
- 7.1.2.5.3 Credit Return Message
- 7.1.2.5.4 Init Done Message
- 7.1.2.5.5 PM Message
- 7.1.2.5.6 Vendor-defined Management Port Gateway Message
- 7.1.3 Flow Control and Data Integrity
- 7.1.3.1 Flow Control and Data Integrity over FDI and RDI
- 7.1.3.2 Flow Control and Data Integrity over UCIe sideband Link between dies
- 7.1.3.3 End-to-End flow control and forward progress for UCIe Link sideband
- 7.1.4 Operation on RDI and FDI
7 Sideband
7.1 Protocol Specification(协议规范)
边带链路的用途是为链路训练提供带外通道,以及为链路伙伴的寄存器提供边带访问接口。
它还用于链路管理数据包以及与远程链路伙伴的参数交换。
相同的协议也用于通过FDI 和RDI 进行本地Die 边带访问。相关时,使用“FDI 边带:”指出FDI 特定规则。相关时,使用“RDI 边带:”指出RDI 特定规则。相关时,使用“UCIe 链路边带:”指出UCIe 链路特定规则。如果未提及前缀,则是FDI、RDI 和UCIe 链路的通用规则。物理层负责在UCIe 链路上对边带数据包进行成帧和传输。对远程Die 的直接边带访问可以源自适配器或物理层。适配器通过RDI 将对远程Die 的边带访问转发到物理层进行成帧和传输。这些包括寄存器访问请求、完成或消息。
协议层使用边带邮箱机制间接访问远程Die 寄存器。邮箱寄存器位于适配器中,当适配器通过FDI接收到邮箱寄存器的相应访问触发时,发起远程Die寄存器访问请求是适配器的责任。FDI 边带:在多协议栈的情况下,适配器必须跟踪哪个协议栈发送了原始请求,并将完成信息路由回相应的协议栈。
FDI 边带:由于协议层仅被允许间接访问远程Die 寄存器,以及直接访问本地Die 寄存器,目前在FDI 边带上仅允许寄存器访问请求和完成。
所有期望响应的边带请求都有8 ms 的超时。为相关数据包为重定时器提供了“Stall”编码,以防止重定时器需要额外时间响应请求时超时。当暂停以防止超时时,重定时器有责任每4 ms 发送一次相应的暂停响应。重定时器还必须确保不会无限期暂停,并在经过合理尝试完成需要暂停请求方的解决后升级链路关闭事件。如果请求方收到带有“Stall”编码的响应,它将复位超时计数器。
在某些情况下,有必要在不同层之间对寄存器进行分段;即,给定寄存器的某些位实际位于协议层,其他位位于适配器,其他位位于物理层。UCIe 对这些寄存器采用分层解码。对于分段寄存器,如果某一位不在给定层中实际存在,则将该位实现为只读并绑定为0。因此,从该层读取这些位将返回0,而写入对这些位没有影响。例如,对于读取,协议层将在FDI上把这些请求转发给适配器,并且协议层在响应软件之前将适配器响应的数据与其本地寄存器进行或(OR)运算。如果该寄存器的任何位位于物理层,适配器在响应协议层之前必须执行相同的操作。
7.1.1 Packet Types
允许三种不同类别的数据包:
寄存器访问:这些可以是Configuration(CFG)或内存映射访问,支持读或写。这些可以与32 位或64 位的数据相关联。所有寄存器访问(读或写)都有相关的完成。
无数据的消息:这些可以是Link Management(LM)或供应商定义的数据包。这些不携带额外的数据有效载荷。
带数据的消息:这些可以是Parameter Exchange(PE)、链路训练相关或供应商定义的, 并携带64 位的数据。
管理传输消息:如果支持Management Transport 协议,则支持带数据或不带数据的管理 传输消息(分别参见第7.1.2.4 节和第7.1.2.5 节)。
每个数据包携带一个5 位的操作码、一个3 位的源标识符(srcid)和一个3 位的目标标识符(dstid)。5 位的操作码指示数据包类型,以及数据包是否携带数据、32 位的数据或64 位的数据。
表7-1 给出了操作码编码到数据包类型的映射。
表7-2、表7-3 和表7-4 给出了源标识符和目标标识符的编码。链路一侧的协议层不允许通过边带直接访问远程链路伙伴的协议层(这应通过主带完成)。
a. srcid 和dstid 对于通过FDI 传输的完成消息是保留的。协议层必须使用Tag 字段将完成与原始请求相关联。目前,不允许通过FDI 边带从适配器向协议层发出请求。
a. srcid 和dstid 对于通过RDI 传输的本地寄存器访问完成的完成消息是保留的。对于寄存器访问完成,无论dstid 字段如何,适配器都必须使用Tag 字段将完成与原始请求相关联。本地和远程寄存器访问请求均由具有唯一标记编码的适配器控制。
Table 7-4. UCIe Link sideband: srcid and dstid encodings for UCIe Link
7.1.2 Packet Formats
本节中的所有图都假设RDI/FDI 传输的边带数据包为32 位接口,因此报头和数据以32 位的阶段显示。
请注意,本章中提供的边带数据包格式图显示了跨越多个32 位阶段的数据包格式。目的仅用于表示。对于通过UCIe 边带凸点(串行接口)的传输,传输一次作为64 位串行数据包进行。对于报头,传输顺序是阶段0 的位0 作为串行数据包的位0(图4-8 中的D0),阶段0 的位1 作为串行数据包的位1 等等,接着阶段1 的位0 作为串行数据包的位32,阶段1的位1 作为串行数据包的位33 等等,直到阶段1 的位31 作为串行数据包的位63。数据(如果存在)作为后续的串行数据包发送,阶段2 的位0 作为串行数据包的位0(图4-8中的D0),阶段2 的位1 作为串行数据包的位1 等等,接着阶段3 的位0 作为串行数据包的位32,阶段3 的位1 作为串行数据包的位33 等等,直到阶段3 的位31 作为串行数据包的位63。
7.1.2.1 Register Access Packets
图7-1 展示了寄存器访问请求的数据包格式。表7-5 给出了除操作码、srcid 和dstid 之外的字段的描述。
图7-2 给出了寄存器访问完成的格式。
表7-7 给出了完成的字段描述。
7.1.2.2 Messages without Data
图7-3 显示了无数据有效载荷的消息格式。这些可以是链路管理数据包、NOP 或供应商定义的消息数据包。
opcode、srcid、dstid、dp 和cp 字段的定义与寄存器访问数据包相同。表7-8 和表7-9 给出了在UCIe 上发送的不同的无数据消息的编码。关于不同的消息类别的一些说明如下:
{NOP.Crd} — 用于端到端信用返回。目的地必须是D2D 适配器。
{LinkMgmt.RDI.*} — 用于协调RDI 状态转换,源和目的地是物理层。
{LinkMgmt.Adapter0.*} — 用于协调与栈0 协议层对应的Adapter LSM 的状态转换。源和目的地是D2D 适配器。
{LinkMgmt.Adapter1.*} — 用于协调与栈1 协议层对应的Adapter LSM 的状态转换。源 和目的地是D2D 适配器。
{ParityFeature.*} — 用于协调奇偶校验插入功能的启用。此消息的源和目的地必须是 D2D 适配器。
{ErrMsg} — 用于远程链路伙伴的错误报告和升级。这从重定时器或设备Die 发送到主机,目的地必须是D2D 适配器。
7.1.2.3 Messages with data payloads
图7-4 显示了具有数据有效载荷的消息的格式。opcode、srcid、dstid、dp 和cp 字段的定义与寄存器访问数据包相同。
表7-10 和表7-11 给出了消息编码。
7.1.2.4 Management Port Message (MPM) with Data
与所有边带消息一样,带有数据的管理端口消息也携带一个1-QWORD 报头。在本节的其余部分,这被称为“MPM header”(见图7-5)。在本节的其余部分,这些消息中的有效载荷被称为“MPM payload”。
带有数据消息的MPM Hdr 的第一个DW 中的位[21:14],形成一个8b 的msgcode,表示特定的带有数据的MPM 消息。表7-12 总结了通过边带支持的带有数据的MPM 消息。对这些消息的支持是可选的,并如第8.2.3.1 节所述进行协商。
7.1.2.4.1Common Fields in MPM Header of MPM with Data Messages on
图7-5 展示了、且表7-13 描述了边带上带有数据消息的MPM Header 中的公共字段。
7.1.2.4.2 Encapsulated MTP Message
边带上Encapsulated MTP 是消息代码为01h 的带有数据的MPM 消息。
a. MPM Header。
b. MPM 有效载荷。
c. 管理传输数据包(MTP)。
d. MPM Header 中的长度。
e. DWORD 填充。
a. 有关边带上所有带有数据的MPM 通用的报头字段的详细信息,请参阅第7.1.2.4.1 节。
7.1.2.4.3 Vendor-defined Management Port Gateway Message
带有数据的供应商定义的管理端口网关消息是为UCIe 边带链路两端的MPG 之间的自定义通信而定义的。这些消息不是Management Transport 协议的一部分,并且这些消息从一个MPG 开始,并在UCIe 边带链路另一端的MPG 终止。这些消息与Encapsulated MTP 消息共享相同的RxQ-ID 请求缓冲区和信用。如果MPG 不支持这些消息或不支持来自给定供应商(由报头中的UCIe Vendor ID 标识)的供应商定义的消息,则MPG 会默默地丢弃这些消息。这些供应商定义的消息的长度遵循第8.2.5.1.2 节中所述的相同规则。通过多个边带链路发送的这些消息的排序遵循第8.2.4.3 节中针对Encapsulated MTP 所给出的相同规则。
a. MPM Header。
b. MPM 有效载荷。
c. MPM Header 中的长度。
a. 有关边带上所有带有数据的MPM 通用的报头字段的详情,请参阅第7.1.2.4.1 节。
7.1.2.5 MPMs without Data
在无数据的MPM 消息的MPM Header 的第一个DWORD 中的位[21:14]形成一个8b 的消息代码,表示特定的无数据的MPM 消息。表7-16 列出了支持的消息代码。
7.1.2.5.1 Common Header Fields of MPM without Data Messages on Sideband
图7-8 展示了并且表7-17 描述了边带上无数据的MPM 消息的MPM Header 中的通用字段。
7.1.2.5.2 Management Port Gateway Capabilities Message
有关在边带管理传输路径初始化期间此消息的使用,请参阅第8.2.3.1.2 节。
图7-9 展示了并且表7-18 描述了边带上的管理端口网关能力消息格式。
a. 有关边带上所有无数据的MPM 通用的报头字段的详情,请参阅表7-17。
7.1.2.5.3 Credit Return Message
有关在边带管理传输路径初始化期间此消息的使用,请参阅第8.2.3.1.2 节。
图7-10 展示了并且表7-19 描述了边带上的信用返回消息格式。如果信用返回a 和b 携带相同的vc:resp 字段,那么对于该rxqid:vc:resp 信用类型返回的总信用是cr_ret_a 和cr_ret_b 的总和。
7.1.2.5.4 Init Done Message
有关在边带管理传输路径初始化期间此消息的使用,请参阅第8.2.5.1.4 节。图7-11 展示了并且表7-20 描述了边带上的Init Done 消息格式。
a. 有关边带上所有无数据的MPM 通用报头字段的详情,请参阅表7-17。
7.1.2.5.5 PM Message
有关在边带管理传输PM 流期间此消息的使用,请参阅第8.2.5.1.4 节。图7-12 展示了并且表7-21 描述了边带上的PM 消息格式。
a. 有关边带上所有无数据的MPM 通用的报头字段详情,请参阅表7-17。
7.1.2.5.6 Vendor-defined Management Port Gateway Message
无数据的供应商定义的管理端口网关消息是为UCIe 边带链路两端的MPG 之间的自定义通信而定义的。这些消息不是Management Transport 协议的一部分,并且这些消息从一个MPG开始,并在UCIe 边带链路另一端的MPG 终止。这些消息与Encapsulated MTP 消息共享相同的RxQ-ID 请求缓冲区。如果一个MPG 不支持这些消息或不支持来自给定供应商(由报头中的UCIe Vendor ID 标识)的这些消息,则MPG 默默地丢弃这些消息。
边带上无数据的供应商定义的管理端口网关消息具有图7-13 所示的格式。
7.1.3 Flow Control and Data Integrity
边带数据包可以通过FDI、RDI 或UCIe 边带链路传输。它们中的每一个都有独立的流量控制。
7.1.3.1 Flow Control and Data Integrity over FDI and RDI
对于与FDI 或RDI 相关联的每个发送器,使用接口的设计时间参数来确定接收器通告的信用数量,最大为32 个信用。每个信用对应64 位的报头和64 位可能相关的数据。因此,对于所有边带数据包,无论它们携带多少数据,都只有一种信用类型。每个发送器/接收器对都有一个独立的信用循环。例如,在RDI 上,对于从适配器传输到物理层的边带数据包,信用从物理层通告到适配器;对于从物理层传输到适配器的边带数据包,信用也从适配器通告到物理层。
发送器在发送寄存器访问请求和消息之前必须检查可用信用。发送器在发送寄存器访问完成之前不必检查信用,并且接收器必须保证无条件接收任何寄存器访问完成数据包。
在FDI 和RDI 上,携带请求或响应的消息会消耗一个信用,但接收器必须保证它们向前推进,而不会被寄存器访问请求阻挡。RDI 和FDI 都为这些接口上的边带信用返回提供了专用信号。
与RDI 和FDI 相关联的所有接收器必须检查接收到的消息的数据或控制奇偶校验错误,并且这些错误必须映射到不可纠正的内部错误(UIE)并将RDI 转换为LinkError 状态。在通过边带支持管理端口消息时,物理层针对其支持的每个RxQ-ID 维护单独的信用缓冲区(这是一个设计时间参数),通过RDI 配置总线从管理端口网关接收管理端口消息。无论通过FDI 还是RDI 接收,管理端口消息在管理端口网关中总是无条件接收。
7.1.3.2 Flow Control and Data Integrity over UCIe sideband Link between dies
边带链路的误码率为1e-27 或更好。因此,边带数据包不提供重试机制。边带数据包的接收器必须检查数据或控制奇偶校验错误,任何此类错误都映射到致命的UIE。
7.1.3.3 End-to-End flow control and forward progress for UCIe Link sideband
为避免死锁,重要的是要确保接收器有足够的空间来接收来自发送器的所有可能未完成的请求,以使请求不会在任何中间缓冲区被阻塞,从而防止后续的完成无法推进。
对远程链路伙伴的适配器或物理层寄存器的边带访问仅可通过间接邮箱机制进行,未完成事务的数量一次限制为四个。虽然提供了四个信用,但只有一个邮箱寄存器,这将能够使用此机制的未完成请求的数量一次限制为一个。额外的信用在寄存器访问超时的情况下允许额外的与调试相关的寄存器访问请求。这些信用与本地FDI 或RDI 访问是分开的,因此物理层必须提供至少一个来自远程Die 的寄存器访问请求和完成,以及来自本地适配器的请求,以及其他边带请求信用(见下面的实现说明)。适配器至少为来自远程Die 适配器的四个远程寄存器访问请求提供支持。每个信用对应64 位的报头和64 位的数据。即使是不发送数据或仅发送32 位数据的请求也会消耗一个信用。寄存器访问完成不消耗信用并且必须始终接收。如果不支持Management Transport 协议,则在域复位退出时或每当RDI 从Reset 转换为Active时,用于寄存器访问请求的适配器信用计数器初始化为4。
如果支持Management Transport 协议,则用于寄存器访问请求的适配器信用计数器在[Domain Reset exit]时或每当[RDI 从复位转换为活动且SB_MGMT_UP = 0]时初始化为4。如果UCIe 实现能够在RDI 转换到Active 状态后总共接收N 个请求,则允许向远程链路伙伴发送额外的(N-4)个信用返回。适配器必须实现一个能够累积至少4 个信用的饱和信用计数器,从而防止过多的信用返回使计数器溢出。
除供应商定义的消息外,所有其他消息都必须始终接收并向前推进,并且不能阻塞边带接口上位于它们后面的任何消息。所有链路管理消息请求都有相关的响应,并且这些消息的源每次只能有一个未完成的请求(即,每个“Link Management Request” MsgCode 编码只有一个未完成的消息)。对于供应商定义的消息,必须有供应商定义的未完成数量上限消息,并且接收器必须保证有足够的空间,以免在任何接口上阻塞供应商定义消息后面的任何消息。
实现说明
图7-14 展示了一个端到端寄存器访问远程Die 的请求示例以及相应的返回完成示例。
在图7-14 所示的步骤1 中,协议层在向适配器Die 0 发送请求之前检查FDI 信用。适配器Die 0 在更新邮箱寄存器后立即完成邮箱请求(如步骤1a 所示)。一旦其内部缓冲区空间空闲,FDI 信用就会返回。在步骤2 中,适配器Die 0 在步骤3 向物理层Die 0 发送远程Die请求之前,检查远程适配器的信用以及本地RDI 的信用。物理层通过UCIe 边带安排请求,并在释放其内部缓冲区空间后将RDI 信用返回给适配器Die 0。
在步骤5 中,物理层Die 1 在通过RDI 发送请求之前检查适配器Die 1 在RDI 上的信用。适配器Die 1 解码该请求,查看它必须访问物理层Die 1 上的寄存器;在步骤6 中,适配器Die 1 在通过RDI 发送请求之前检查物理层Die 1 的RDI 信用。如果需要,适配器Die 1 必须为此请求重新映射标签,并保存远程Die 请求的原始标签以及为完成预分配空间。物理层Die 1 完成寄存器访问请求并以相应的完成响应。由于完成是通过RDI 发送的,因此无需检查或消耗RDI 信用。在步骤7 中,适配器Die 1 为远程Die 请求生成完成并通过RDI 发送(通过RDI 完成无需检查或消耗信用)。完成在如图7-14 所示的不同跳中传输,并最终在适配器Die 0 中接收以更新邮箱信息。在不同跳中完成时无需检查RDI 信用。
为了实现前向进展,两个Die 上的适配器和物理层必须确保它们能够接收足够的请求、完成和消息,以保证不同类型的边带数据包(即远程寄存器访问请求、远程寄存器访问完成、Adapter LSM 的链路状态转换消息、RDI 的链路状态转换消息和链路训练相关消息)之间不存在链路层级别依赖。在所有情况下,由于每个操作最多允许一个或两个未完成的消息,因此相对容易提供大于或等于从RDI 接收的缓冲区数量。例如,在图7-14 所示的场景中,物理层Die 1 必须确保它有专用空间来接收步骤6 中的请求,而与从Die 1 到Die 0 的任何正在进行的远程寄存器访问请求或完成,或任何其他用于状态转换的边带消息等无关。同样,物理层Die 1 必须在步骤7 中有用于远程Die 寄存器访问完成的专用空间。
在RDI 状态的一个子集(见第10.0 章)中,适配器或物理层允许动态粗时钟门控。因此,在适用时,通过RDI 或FDI 的任何边带传输都必须遵循第10.0 章中定义的时钟门控退出握手规则。如果实现需要解耦接口状态和边带传输之间的依赖关系,建议对边带传输始终执行时钟退出门控握手。
物理层和适配器的实现必须确保通过UCIe 边带链路发送的消息不会出现接收器缓冲区溢出。这可以通过确保退出时钟门控的时间有上限并且小于通过UCIe 边带链路传输边带数据包的时间来实现,或者物理层有足够的存储空间来应对每个边带消息功能(即远程寄存器访问请求、远程寄存器访问完成、Adapter LSM 的链路状态转换消息、RDI 的链路状态转换消息和链路训练相关消息)的最坏情况备份。后者以缓冲区为代价提供了更通用的互操作性。
7.1.4 Operation on RDI and FDI
RDI 和FDI 遵循相同的格式和操作规则。该协议是对称的——请求、完成和消息可以在lp_cfg 以及pl_cfg 信号上发送。
实现必须通过允许足够数量的边带数据包接收并为其他数据包解除边带总线的阻塞来确保
无死锁操作。在接口处,根据配置接口宽度(编译时间参数),这些事务被打包为多个阶段。支持的接口宽度为8、16 或32 位。lp_cfg_vld 和pl_cfg_vld 在每个阶段独立变有效。它们必须在连续的时钟周期内变有效,以传输同一数据包的连续阶段。在传输不同数据包的阶段时,它们可能在、也可能不在连续的时钟周期内有效。对于带有数据的数据包,64b 的数据总是通过RDI 或FDI 传输;对于32b 的有效载荷,在传输前,数据包的最高有效32b(阶段4)被赋值为0b。