UCIE Specification详解（十）

---

4.5.3.7 PHYRETRAIN（物理层重训练）

一个Die 可能由于多种原因进入PHY 重训练。Track、Data 和Valid 发送器保持低电平。Clock发送器保持差分低电平（对于差分时钟）或同时低电平（对于正交时钟）。PHY 进入PHY重训练的触发条件是以下场景之一：

 适配器指示的PHY 重训练：适配器可以出于其认为必要的任何原因指示PHY 重训练（有 关更多详细信息和适配器发起的Retrain 请求的示例，请参阅第10.3.3.4 节Retrain 状态规则）。

 PHY 发起的PHY 重训练：本地PHY 在检测到有效成帧错误时必须发起重训练。

 远程Die 请求的PHY 重训练：本地PHY 在接收到来自远程Die 的请求时必须进入PHY重训练。

 如果在MBTRAIN.LINKSPEED 期间检测到Runtime Link Testing Control 寄存器中的更改。

在进入PHYRETRAIN 时必须设置变量PHY_IN_RETRAIN。对于多模块配置，作为同一多模块链路一部分的所有模块的重训练编码（以及因此的重训练退出分辨率）必须相同。这是必需的，因为在多模块链路中，所有模块必须以相同的速度和宽度运行（然而，对于先进封装，不需要修复的模块有可能经过Repair 状态，并在相应的{apply repair}消息中发送“No Repair”编码）。

4.5.3.7.1 Adapter initiated PHY retrain

以下是适配器发起的PHY 重训练的步骤序列：

1. UCIe 模块从本地适配器接收Retrain 请求（RDI 状态请求移动到Retrain）。此后，UCIe模块必须按照第10.0 章中的描述在RDI 上完成Stallreq/Ack（pl_stallreq；lp_stallack）握手。

2. 完成Stallreq/Ack 握手并通过主带发送任何未完成的数据后，UCIe 模块必须向UCIe 模块Partner发送边带消息{LinkMgmt.RDI.Req.Retrain}。

3. 在收到边带消息{LinkMgmt.RDI.Req.Retrain}后，UCIe 模块Partner在完成Stallreq/Ack（pl_stallreq；lp_stallack）在其RDI 上的握手且接收方流水线中没有待处理的主带数据后，必须将其RDI 状态转换为Retrain。在完成Stallreq/Ack 握手并通过主带发送任何待处理的数据后，UCIe 模块Partner用{LinkMgmt.RDI.Rsp.Retrain}响应。

4. 一旦收到{LinkMgmt.RDI.Rsp.Retrain}且接收方流水线中没有待处理的主带数据，UCIe模块必须将其RDI 转换为Retrain。

5. UCIe 模块必须发送带有反映Runtime Link Testing Control 寄存器内容（除起始位外，如果Runtime Link Test Status 寄存器中的Busy 位已设置）的再训练编码的{PHYRETRAIN.retrain start req}。此后，UCIe 模块Partner将接收到的再训练编码与本地再训练编码进行比较。如果接收到的再训练编码与本地再训练编码相同，UCIe 模块Partner必须以{PHYRETRAIN.retrain start resp}响应。如果再训练编码不匹配，UCIe 模块Partner必须根据表4-10、表4-11 和表4-12中所示的再训练编码和解决方案进行解决，然后发送带有已解决的再训练编码的{PHYRETRAIN.retrain start resp}。

6. 一旦UCIe 模块发送和接收边带消息{PHYRETRAIN.retrain start resp}，它必须根据已解决的重训练寄存器编码退出到相应的训练状态。

4.5.3.7.2 PHY initiated PHY retrain

以下是PHY 发起的PHY 重训练的步骤序列：
1. 在检测到有效成帧错误时，UCIe 模块在传输时必须使pl_error 有效。

该Flit（或Flit 块）在RDI 上。此后，UCIe 模块（PHY）必须在RDI 上完成Stallreq/Ack（pl_stallreq；lp_stallack）握手。

2. UCIe 模块必须发送边带消息{LinkMgmt.RDI.Req.Retrain}。

3. 在接收到边带消息{LinkMgmt.RDI.Req.Retrain}后，UCIe 模块Partner必须在其RDI 上完成Stallreq/Ack（pl_stallreq; lp_stallack）握手后将其RDI 转换为Retrain。随后，UCIe 模块Partner以{LinkMgmt.RDI.Rsp.Retrain}响应。

4. 一旦收到{LinkMgmt.RDI.Rsp.Retrain}，UCIe 模块必须将其RDI 转换为Retrain。

5. UCIe 模块必须发送带有反映Runtime Link Testing Control 寄存器的内容（除起始位外，如果Runtime Link Test Status 寄存器中的Busy 位被设置）的{PHYRETRAIN.retrain start req}。此后，UCIe 模块Partner将接收到的重训练编码与本地重训练编码进行比较。如果接收到的重训练编码与本地重训练编码相同，UCIe 模块Partner必须用{PHYRETRAIN.retrain start resp}响应。如果重训练编码不匹配，UCIe 模块Partner必须根据表4-10、表4-11 和表4-12 中所示的重训练编码和解决方案进行解决，然后发送{PHYRETRAIN.retrain start resp}以及已解决的重训练编码。

6. 一旦UCIe 模块已发送和接收边带消息{PHYRETRAIN.retrain start resp}，它必须根据已解决的重训练编码退出到相应的训练状态。

4.5.3.7.3 Remote Die requested PHY retrain

1. 在接收到{LinkMgmt.RDI.Req.Retrain} 时，UCIe 模块必须在其RDI 上完成Stallreq/Ack（pl_stallreq; lp_stallack）握手后，将本地RDI 转换为Retrain。之后，UCIe 模块用{LinkMgmt.RDI.Rsp.Retrain} 响应。

2. 一旦收到{LinkMgmt.RDI.Rsp.Retrain}，UCIe 模块Partner必须将其RDI 转换为Retrain。

3. UCIe 模块必须发送带有反映Runtime Link Testing Control 寄存器的内容（除起始位外，如果Runtime Link Test Status 寄存器中的Busy 位已设置）的{PHYRETRAIN.retrain start req}。在此之后，UCIe 模块Partner将接收到的重训练编码与本地重训练编码进行比较。如果接收到的重训练编码与本地重训练编码相同，UCIe 模块Partner用{PHYRETRAIN.retrain start resp}响应。如果重训练编码不匹配，UCIe 模块Partner必须根据重训练编码和表4-10、表4-11 和表4-12 中所示的解决方案进行解决，然后发送带有已解决的重训练编码的 {PHYRETRAIN.retrain start resp}。

4. 一旦一个Die 已发送和接收边带消息{PHYRETRAIN.retrain start resp}，它必须根据已解决的重训练编码退出到相应的训练状态。

4.5.3.7.4 PHY retrain from LINKSPEED

1. UCIe 模块必须发送带有反映Runtime Link Testing Control 寄存器内容（除起始位外，如果Runtime Link Test Status 寄存器中的Busy 位被设置）的重训练编码的{PHYRETRAIN.retrain start req}。在此之后，UCIe 模块Partner将接收到的重训练编码与本地重训练编码进行比较。

如果接收到的重训练编码与本地重训练编码相同，UCIe 模块Partner必须用 {PHYRETRAIN.retrain start resp} 响应。如果重训练编码不匹配，UCIe 模块Partner必须根据表4-10、表4-11 和表4-12 中所示的重训练编码和解决方案进行解决，然后发送带有已解决的重训练编码的{PHYRETRAIN.retrain start resp} 。

2. 一旦一个Die 发送并接收了边带消息{PHYRETRAIN.retrain start resp}，它必须根据已解决的重训练编码退出到相应的训练状态。

4.5.3.8 TRAIN ERROR

由于任何致命或非致命事件需要将状态机带回RESET 状态，此状态用作过渡状态。这可能在初始化和训练期间发生，或者如果状态机不在RESET 时设置了来自UCIe Link Control 寄存器的“Start UCIe Link Training”位。它还用于任何将链路从Link Up 转换为Link Down 状态的事件。Data、Valid、Clock 和Track 发送器处于三态，并且允许禁用其接收器。

从TRAINERROR 到RESET 的退出是特定于实现的。对于没有错误的情况升级（即，RDI不在LinkError 中），建议尽快退出TRAINERROR。对于存在错误升级的情况（即，RDI在LinkError 中），只要RDI 在LinkError 中，物理层就需要处于TRAINERROR 中。为避免在发送边带数据包时，任何正在进行的边带数据包必须在进入RESET 状态之前完成传输。有关RDI 上可纠正、非致命和致命错误升级，请参阅第10.0 章。

此状态对于先进封装和标准封装配置是通用的。

如果边带处于Active 状态，从除SBINIT 之外的任何状态进TRAINERROR 状态必须执行边带握手。以下被定义为TRAINERROR 握手：

 请求退出到TRAINERROR 的UCIe 模块必须发送{TRAINERROR Entry req} 边带消息并等待响应。UCIe 模块Partner必须退出到TRAINERROR 并用{TRAINERROR Entry resp}响应。一旦收到{TRAINERROR Entry resp} 边带消息，UCIe 模块必须退出到 TRAINERROR。如果8 ms 内未收到响应，LTSM 转换到TRAINERROR。

4.5.3.9 L1/L2

PM 状态允许比ACTIVE 中的动态时钟门控更低的功率状态。Data、Valid、Clock 和Track发送器处于三态，并且允许禁用其接收器。

 当RDI 如第10.0 章所述转换到PM 状态时进入此状态。此状态下的PHY 节能特性是特定于实现的。

当本地适配器在RDI 上请求激活或远程链路Partner请求退出L1 时，PHY 必须退出到MBTRAIN.SPEEDIDLE。L1 退出与RDI 上相应的L1 状态退出转换相协调。

 当本地适配器在RDI 上请求激活或远程链路Partner请求退出L2 时，PHY 必须退出到 RESET。L2 退出与RDI 上相应的L2 状态退出转换相协调。

4.6 Runtime Recalibration

在ACTIVE 状态下，接收器可以使用Track 信号来执行周期性的运行时校准。在运行时重新校准期间，必须继续对主带数据进行采样和处理（当伴有正确有效的帧时）。对于未端接的链路，当不发送所需模式时，在连续的Track 重新校准迭代中，Track 信号必须在保持低电平和保持高电平之间交替（用于抗老化）。对于端接链路，当不发送所需模式时，Track 发送器必须进入高阻态。

以下序列用于请求Track 模式：
1. UCIe 模块在其接收器上启用Track 信号缓冲区，并发送{RECAL.track pattern init req} 边带消息，然后等待响应。

2. UCIe 模块Partner发送{RECAL.track pattern init resp} 并启用其Track 信号发送器（如果需要，预先设置为驱动低电平）。在此之后，UCIe 模块Partner的Track 发送器开始发送第5.5.1节中描述的模式，以及转发的时钟。如果链路处于时钟门控模式，UCIe 模块Partner应启用时钟并管理在Track 更新完成后链路是否应返回时钟门控模式。

3. UCIe 模块在其接收器上执行所需的重新校准，并发送{RECAL.track pattern done req} 边带消息。

4. 收到此消息后，UCIe 模块Partner的Track 发送器停止发送模式，并发送{RECAL.track pattern done resp} 边带消息。

5. UCIe 模块在收到{RECAL.track pattern done resp} 边带消息后允许禁用Track 接收器。

4.7 Multi-module Link

如第1.0 章所述，多模块链路的允许配置为一模块、两模块和四模块配置。在多模块链路中，每个模块都被分配一个专用模块标识符（Module ID），在MBINIT.PARAM 期间向远程链路Partner通告。

第5.0 章定义了多模块实例化不同场景的Module ID 分配的允许组合，多模块实现必须支持

这些组合。

4.7.1 Multi-module initialization

在多模块配置中，每个模块都必须使用其边带独立地进行初始化和训练。如果使用两个或四个模块，一个单独的多模块PHY 逻辑块将在模块之间进行协调，如第1.2.2 节所述。MMPL负责协调数据传输以及多个模块中发送器的任何相关字节混洗，以使远程链路Partner的接收器观察到正确的字节到通道映射（即，对于任何有效传输，字节从最低有效位到最高有效位按
Module ID 和Lane ID 在所有活动通道上的升序排列）。图4-42、图4-43、图4-44 和图4-45说明了上述字节混洗对于某些标准封装配置的示例。图中的M0、M1、M2 和M3 分别对应于Module ID 0、Module ID 1、Module ID 2 和Module ID 3。这些图提供了RDI 字节到模块的映射。图4-42 展示了远程链路Partner的Module ID 相同的场景。图4-43 显示了远程链路Partner的Module ID 不同的场景示例。图4-44 显示了远程链路Partner的Module ID 不同的标准封装的宽度降级示例（请注意，在所有情况下，在接收器处，字节在所有活动通道上按Module ID 和Lane ID 的升序排列）。图4-45 显示了两个模块被禁用的场景。这对应于第5.0 章中概述的一种情况，其中堆叠配置与非堆叠配置相连，并且M0 和M2 模块被禁用；RDI 的其余字节在后续的8-UI 间隔内发送，以便远程链路Partner的M1 接收最低有效字节。

多模块链路中的每个模块必须以相同的宽度和速度运行。在初始化或重训练期间，如果任何模块训练失败，MMPL 必须确保多模块配置降级到下一个允许的宽度或速度降级配置（见图4-46 和图4-47）。随后，不同模块之间在宽度和速度上的任何差异必须使用以下规则解决：

1. 对于标准封装的多模块配置，如果任何模块报告宽度降级：

a. 如果在当前链路速度下，报告宽度降级的模块数量小于或等于模块总数的一半，相应的模块必须被禁用。MMPL 必须确保多模块配置降级到下一个允许的宽度或速度降级配置（见图4-46 和图4-47）。例如，如果四个模块中有三个处于Active 状态，MMPL必须将链路降级到两模块配置。

b. 如果在当前链路速度下，大多数模块报告宽度降级，见下面的伪代码：

2. 对于高级或标准封装的多模块配置，如果任何模块报告速度差异，见下面的伪代码：

图4-46 和图4-47 分别以流程图的形式综合展示了上述两条规则，先进封装和标准封装的实现必须遵循。请注意，HMLS/2 > CMLS 问题的“Yes”条件是为了涵盖4 GT/s 的基本情况。换句话说，如果某些模块通过了MBINIT 但在链路速度中4 GT/s 失败，那么“Yes” arc 将导致模块禁用而不是训练错误（因为对于该情况CMLS 将为0），并为在4 GT/s 仍能运行的模块提供在4 GT/s 保持运行的机会。

4.7.1.1 Sideband Assignment and Retimer Credits for Multi-module Configurations

在链路初始化、训练和重训练期间（见第4.5 节），某些边带数据包在各个模块的边带接口上发送。这些包括表7-9 和表7-11 中的所有消息，以及任何定义为如此的供应商定义消息。

其他边带数据包使用单个边带来发送边带数据包。这些包括寄存器访问数据包（请求以及完成）、表7-8 和表7-10 中的所有非供应商定义的消息，以及任何定义为如此的供应商定义消息。设备必须在数字上最小的Module ID 的边带接口上发送这些边带数据包，其LTSM 不在RESET 或SBINIT 中。在给定Module ID 上发送的数据包可能会在Sideband 接收器的不同Module ID 上接收。

同样，重定时器信用在数字上最小的Module ID 的有效信号上返回，其LTSM 处于Active状态。在给定Module ID 上发送的信用可能会在远程链路Partner的不同Module ID 上接收。

4.7.1.2 Examples of MMPL Synchronization

当一个模块是多模块UCIe 链路的一部分时，它使用自己的边带链路独立于其他模块执行MBTRAIN.LINKSPEED 的第2 步的各个训练步骤。这对于链路初始化和链路重训练都是如此。在MBINIT.PARAM 中交换的公共链路参数对于作为多模块链路一部分的所有模块都是相同的（例如“Maximum Data Rate”）。因此，在MBTRAIN.LINKSPEED 中，多模块链路的所有模块都以相同的数据速率运行。

MMPL 的同步协调在MBTRAIN.LINKSPEED 状态中根据第4.7.1 节中概述的规则进行。如第4.5.3.4.12 节所述，在MBTRAIN.LINKSPEED 的第2 步完成且PHY_IN_RETRAIN 未设置之后：

 如果一个模块未遇到错误，则向远程链路Partner模块发送{MBTRAIN.LINKSPEED done req}

 如果某个模块遇到错误，则执行{MBTRAIN.LINKSPEED error req} /
{MBTRAIN.LINKSPEED error resp} 握手，然后在该模块的边带发送
{MBTRAIN.LINKSPEED exit to repair req} 或{MBTRAIN.LINKSPEED exit to speed degrade req} 。

各个模块将这些边带消息中发送和接收的信息通知给MMPL。MMPL 从链路中运行的所有模块收集此信息，并根据第4.7.1 节中概述的规则的解决情况确定下一个状态。当然，没有错误的情况是所有模块发送和接收{MBTRAIN.LINKSPEED done req} 消息且链路宽度没有变化。在这种情况下，MMPL 指示它们进入MBTRAIN.LINKSPEED 的第6 步。

以下部分涵盖了具有四个模块和标准封装配置且遇到错误的链路的这种解决方案的几个示例。

4.7.1.2.1 Example 1: MMPL Resolution results in a Width Degrade per

Module(MMPL 解决方案导致每个模块的宽度降级) 在这个示例中，UCIe 链路的四个模块处于8 GT/s 的MBTRAIN.LINKSPEED 状态。表4-13显示了一个Die 的交换消息（在遇到错误的情况下，假定{MBTRAIN.LINKSPEED error req} / {MBTRAIN.LINKSPEED error resp} 在显示的消息之前已完成）。由于解决方案在使用发送和接收的消息方面是一致的，链路的两个Die 将达到相同的解决方案。

在这个示例中，4 个模块中的3 个已经发送或接收了{MBTRAIN.LINKSPEED exit to repair req} 消息，这表明标准封装配置的宽度降级。“CLS”（Current Link Speed，当前链路速度）的值为8 GT/s，“CLS-1”的值为4 GT/s。“M”（Number of Active Modules，活动模块数量）的值为4。因为BW（4 个链路以4 GT/s 运行）不大于BW（2 个链路以8 GT/s 运行），图4-46 中的流程图将导致MMPL 通知所有模块通过进入MBTRAIN.REPAIR 进行宽度降级作为下一个状态（即，{MBTRAIN.LINKSPEED exit to repair resp} 将在每个模块上发送）。请注意，每次链路处于MBTRAIN.LINKSPEED 并且有相应的MMPL 解决方案时，都会使用更新的信息重新计算“CLS”和“M”。对于此UCIe 链路中的每个模块，按照MBTRAIN.REPAIR中的步骤应用每个模块的宽度降级。对于未遇到错误的模块，当向远程链路Partner模块发送{MBTRAIN.REPAIR apply degrade req} 时，发送器允许选择通道0 到7 或通道8 到15 作为操作通道。从MBTRAIN.REPAIR 退出后，训练通过MBTRAIN 的子状态继续，并且在MBTRAIN.LINKSPEED 的下一次迭代中，如果未遇到错误，MMPL 将指示模块进入MBTRAIN.LINKSPEED 的第6 步。

请注意，此示例涵盖了在LINKSPEED 状态期间发生错误的情况。如果一个模块的宽度已经低于作为多模块链路一部分的其余运行模块（例如，如果一个模块在MBINIT.REPAIRMB本身期间宽度降级），则它可能在LINKSPEED 期间发送和接收了{MBTRAIN.LINKSPEED done req} 。然而，从MMPL 解决方案的角度来看，MMPL 必须将其视为报告需要宽度降
级的错误的模块。这是因为多模块链路要求所有模块以相同的宽度和速度运行。

4.7.1.2.2 Example 2: MMPL Resolution results in a Speed Degrade

在这个示例中，UCIe 链路的四个模块处于16 GT/s 的MBTRAIN.LINKSPEED 状态。表4-14显示了一个Die 的交换消息（在遇到错误的情况下，假定{MBTRAIN.LINKSPEED error req} / {MBTRAIN.LINKSPEED error resp} 在显示的消息之前已完成）。由于解决方案在使用发送和接收的消息方面是一致的，链路的两个Die 将达到相同的解决方案。

在这个示例中，Module 3 收到了一条消息，表明远程Partner想要速度降级。“CMLS”总是映射到下一个降级的链路速度，所以在这种情况下“CMLS”是12 GT/s。“HMLS”总是最终映射到当前链路速度，所以在这种情况下它是16 GT/s。因为Module 3 收到了速度降级请求，按照图4-47 中的流程图，这将导致MMPL 通知所有模块通过进入MBTRAIN.SPEEDIDLE 进行速度降级（即，{MBTRAIN.LINKSPEED exit to speed degrade resp}将在每个模块上发送）。

从MBTRAIN.SPEEDIDLE 退出后，训练通过MBTRAIN 的子状态继续，并且在 MBTRAIN.LINKSPEED 的下一次迭代中，如果未遇到错误，MMPL 将指示模块进入MBTRAIN.LINKSPEED 的第6 步。请注意，每次链路处于MBTRAIN.LINKSPEED 并且有相应的MMPL 解决方案时，“CMLS”和“HMLS”都会使用更新的信息。在这个示例中，对于下一次迭代，CMLS 将是8 GT/s，HMLS 将是12 GT/s。

4.7.1.2.3 Example 3: MMPL Resolution results in a Module Disable

在这个示例中，UCIe 链路的四个模块处于16 GT/s 的MBTRAIN.LINKSPEED 状态。表4-15展示了一个Die 的交换消息（在遇到错误的情况下，假定{MBTRAIN.LINKSPEED error req} / {MBTRAIN.LINKSPEED error resp}在所示消息之前已完成）。由于在使用发送和接收的消息方面解决方案是一致的，链路的两个Die 将达成相同的解决方案。

因为报告错误并请求宽度降级的模块不到一半，按照图4-47 中的流程图，MMPL 会将配置设置为两个模块的配置。按照第5.7.3.4.1 节中的规则，Module 0 和Module 1 将发送{MBTRAIN.LINKSPEED multi-module disable module resp}，使这些模块进入TRAINERROR和RESET。Module 2 和Module 3 将发送{MBTRAIN.LINKSPEED done resp}，使它们进入LINKINIT。

4.7.2 Multi-module Interoperability between x64 and x32 Advanced

Packages（x64 和x32 Advanced 封装之间的多模块互操作性）

当一个多模块x64 Advanced Package 模块连接到相应的多模块x32 Advanced Package 模块时，MMPL 负责进行适当的字节交换和宽度调整。多模块配置中的所有模块必须是相同的类型（在这种情况下，多模块集中的所有模块必须是x64 Advanced 或x32 Advanced）。所有与模块命名约定和禁用配置相关的规则也适用于x32 Advanced Package 模块。

UCIe-A x64 和UCIe-A x32 之间互操作的一个示例是，当UCIe-A x64 栈（包括RDI 和FDI最大吞吐量）通过给定接口的远程链路Partner的最大吞吐量进行带宽匹配（全宽模式）时。图4-48 展示了两个x64 模块的示例，它们能够作为具有独立适配器和协议层的两个独立UCIe栈运行（在图4-48 中的配置（a）中旁路MMPL 逻辑），并且当连接到x32 Advanced 封装的相应多模块配置以实现单个x64 模块的等效带宽时，也能够作为多模块配置运行（图4-48中的配置（b））。在后一种配置中，其中一个适配器（以灰色显示）被禁用。

软件和固件被允许使用UCIe DVSEC Link Capability 和Control 寄存器来确定在何种配置下训练链路。

UCIe-A x64 和UCIe-A x32 之间互操作的另一个示例是，当UCIe-A x64 栈降低带宽（降级宽度模式）以匹配远程链路Partner的最大吞吐量时。图4-49 展示了一个示例，是关于x64 Advanced Package 模块的四模块集与x32 Advanced Package 模块的四模块集互操作的RDI 字节到模块分配。该示例针对x64 集上的256B RDI 宽度和x32 集上的128B RDI。在x64 模块的发送器侧，MMPL 根据需要限制RDI，因为MMPL 在8 个UI 内只能发送一半的字节；而在接收器侧，MMPL 在通过RDI 转发之前累积16 个UI 的数据（假设数据传输是以256B 的块进行，或者在数据流内由MMPL/适配器应用和检测到适当的数据流指示暂停）。

对于图4-49 所示的示例，单个适配器与所有四个模块一起运行。D2D 栈使用具有4 个模块的MMPL，每个x64 模块都在降级宽度模式下运行，每个模块仅路由32 条通道。能力寄存器和链路训练参数中的相应值如表4-16 所列。

有关x64 和x32 Advanced Package 模块之间互操作的综合规则，请参见第5.7.2.4 节。

4.8 Sideband PHY Arbitration between MPMs and Link Management Packets

虽然确切的仲裁策略取决于具体实现，但应注意避免长时间延迟传输任何挂起的链路管理数据包，以免可能导致超时。有关带有数据的MPM 的长度限制，请参见第8.2.5.1.2 节，这允许PHY 仲裁为发送链路管理数据包或可能在带有数据包的MPM 后面等待的更高优先级MPM 数据包的延迟量提供上限。此外，PHY 发送器必须在最多512 UI（协商边带高性能模式操作时）和最多768 UI（未协商边带高性能模式操作时）内完全完成带有数据的MPM 的传输。有关边带传输UI 符号的详细信息，请参见第4.1.5 节。有关高性能模式操作（Performant Mode Operation，PMO）的详细信息，请参见第4.1.5.1 节。