【CXL协议-ARB/MUX层（5）】

5.0 Compute Express Link ARB/MUX

前言：
在CXL协议中，ARB/MUX层（Arbitration/Multiplexer layer）是负责管理资源共享和数据通路选择的一层。CXL协议包含了几个子协议，主要有CXL.io、CXL.cache 和 CXL.memory。ARB/MUX层在这些子协议之间起到了关键的调度和选择作用，以确保数据流和控制流的正确传输。
下面是ARB/MUX层的一些主要职能：
仲裁 (Arbitration): 在多个请求同时争用相同资源的情况下，仲裁逻辑确保了系统中的各种请求能够公平且有效地访问到共享资源。比如，当多个加速器试图通过CXL访问系统内存时，ARB层会决定哪一个请求先被处理。
多路复用 (Multiplexing): CXL协议支持多种类型的事务（如CXL.io、CXL.cache 和 CXL.memory事务）。MUX层负责将来自不同类型的事务的数据流按照其目的地进行路由，保证每种事务能够在正确的地址和时间到达目的地。
数据流控制: ARB/MUX层还需要处理不同速率的数据流，确保数据包能够按照正确的顺序进行转发，以及处理拥塞和压力情况。
接口协调: 在实际的硬件实现中，ARB/MUX层可能需要与物理层（PHY）协调，以匹配不同的传输速率和时序要求。
ARB/MUX层在CXL协议栈中起到了桥梁的作用，它使得数据包能够在CXL的不同协议组件之间高效、有序地传递，同时保持高效的带宽利用和低延迟。这一层对于保证CXL接口的性能和可靠性是至关重要的。由于CXL是建立在PCIe基础上的，所以ARB/MUX层也承担了与PCIe标准协议相兼容和转换的任务。

下图显示了CXL ARB/MUX在Flex Bus分层中的位置等级制度ARB/MUX提供CXL.io和CXL.cachemem的动态复用链路层控制和数据信号，以与Flex总线物理层接口。
图5-1 Flex Bus 分层 - CXL ARB/MUX (部分已经高亮)

在传输方向上，ARB/MUX在来自CXL链路的请求之间进行仲裁分层并多路复用数据。它还处理来自链路层：将它们解析为单个请求以转发到物理层，为每个链路层接口维护虚拟链路状态机（vLSM），以及生成ARB/MUX链路管理包（ALMP）以传送功率代表每个链路层跨链路的状态转换请求。
提到第10.3节、第10.4节和第10.5节，了解有关ALMP如何在用于功率状态转换的整个流程中使用。在PCIe*模式下，ARB/MUX旁路，因此ARB/MUX的ALMP生成被禁用
在接收方向上，ARB/MUX确定与CXL相关联的协议并将该微片转发到适当的链路层。它还处理ALMP，参与任何所需的握手并酌情更新其vLSM。
对于256B Flit模式，重放缓冲区是物理层的一部分。ALMP有与68B flit模式不同的微片格式，并受到前向纠错保护FEC）和循环冗余校验（CRC）。它们也必须分配给重播缓冲区，并遵循重放序列协议。因此，它们是保证无错误地传送到远程ARB/MUX。

5.1 vLSM状态

ARB/MUX为与其接口的每个CXL链路层维护vLSM从本地链路层接收的基于电源状态转换请求的状态或者来自代表远程链路层的远程ARB/MUX。
下表5-1列出了vLSM的不同可能状态。
PM状态和Retrain是虚拟状态可以在接口（CXL.io和CXL.cache以及CXL.mem）之间有所不同；
然而，所有其他诸如LinkReset、LinkDisable和LinkError之类的状态被转发到链路层，并且因此跨接口同步。
表5-1。每个链路层接口维护的vLSM状态

Note: 当物理层LTSSM进入热重置或禁用状态时，该状态为分别作为LinkReset或LinkDisable传送到所有链路层。没有ALMP交换，而不管是谁请求它们，以进行这些转换。LinkError必须将LTSSM设为检测或禁用。例如，允许映射CXL.io下游端口包含到链路错误（当LTSSM处于禁用状态时）
ARB/MUX查看每个vLSM的状态，以解析为单个状态请求转发到表5-2中指定的物理层。例如，如果vLSM[0]状态为L1.0（行=L1.0），当前vLSM[1]状态为Active（列=活跃），则从ARB/MUX到物理层的已解析请求将是活跃的
表5-2。ARB/MUX多vLSM分辨率表

基于来自一个或多个链路层的请求状态，ARB/MUX将将所述状态请求改变到所述物理层以获得期望的链路状态。
对于链路层支持将ARB/MUX定向到LinkReset或LinkError或LinkDisable，ARB/MUX必须无条件传播这些从请求链路层到物理层的请求；这个优先超过表5-2
表5-3描述了vLSM从一种状态转换到下一个在触发条件中的所有步骤之后发生到下一个状态的转换列已完成。一些触发条件是连续的，表明来自多个来源的一系列操作。例如，在从“活动”转换为上游端口上的L1.x状态，直到vLSM接收到来自链路层的进入L1.x的请求，随后vLSM发送向远程vLSM请求ALMP｛L1.x｝。接下来，vLSM必须等待接收状态来自远程vLSM的ALMP｛L1.x｝。一旦所有这些条件依次满足vLSM将根据请求转换到L1.x状态。某些触发条件是仅在68B Flit模式下运行时适用，并且这些在表中突出显示“仅适用于68B Flit模式”

表5-3。ARB/MUX状态转换表（第1页，共2页）

表5-3。ARB/MUX状态转换表（第2页，共2页）

5.1.1本地vLSM转换的附加规则

1.对于68B Flit模式，如果任何链路层请求进入到ARB/MUX的Retrain，ARB/MUX必须将请求转发到物理层以启动LTSSM过渡到恢复。根据Active to Retrain转换触发器条件下，LTSSM处于恢复状态后，ARB/MUX应将Retrain反映为所有处于活动状态的vLSM。对于256B Flit模式，没有Active to Retrain arc在ARB/MUX vLSM中，因为物理层LTSSM转换到恢复不会影响vLSM状态。
注意：对于256B Flit模式：不将物理层LTSSM转换为恢复暴露到链路层vLSM允许Rx重试缓冲区可能耗尽的优化而LTSSM处于恢复中。它还避免了vLSM变成与远程链接伙伴不同步。处理错误情况，如UpdateFCDLLP超时，实现必须具有来自链接的边带机制用于触发LT的物理层的层SSM过渡到恢复。
2.一旦vLSM处于Retrain状态，预计相应的链路层将最终请求ARB/MUX转换到活动。
3.如果LTSSM移动到检测，则每个vLSM最终必须转换到重置。

5.1.2 vLSM跨链路状态转换规则

本节涉及vLSM状态转换。

5.1.2.1 一般规则

如果CXL.io协议断开，则链路无法对任何其他协议进行操作（CXL.io操作是最低要求）

5.1.2.2进入主动交换协议

进入活动状态所需的ALMP协议由4个ALMP交换机组成在本地和远程vLSM之间，如图5-2所示。进入Active以开头发送到远程vLSM的活动状态请求ALMP状态ALMP。对活动状态请求的唯一有效响应是活动一旦相应的链路层准备好接收协议微片，状态状态。这个远程vLSM还必须向本地vLSM发送活动状态请求ALMP以活动状态ALMP进行响应
在初始链路训练期间，上游端口（图5-2中的UP）必须等待非物理层微片（即，不是由下游端口（图5-2中的DP））第6.4.1节）。因此，在初始链路训练期间，第一个ALMP总是从下行端口到上行端口。如果有其他活动交换机握手随后发生（例如，作为PM退出的一部分），可以启动活动请求ALMP从两侧。
一旦vLSM发送并接收到活动状态ALMP，vLSM转换到活动状态。
图5-2。进入活动协议交换

5.1.2.3状态同步协议

对于256B Flit模式，由于重试缓冲区位于物理层，因此所有ALMP保证无错误地传送到远程ARB/MUX。此外，所有ALMP保证会得到回应。因此，不存在上游端口和下游端口vLSM可能不同步。
状态同步协议仅适用于68B Flit模式。以下内容描述和规则适用于68B Flit模式。
在初始链路训练期间达到协商的最高操作速度之后随后的LTSSM恢复转换必须用信号通知ARB/MUX。vLSM状态退出恢复后必须执行同步协议。链接层不能在LTSSM恢复后的链路上进行任何其他通信，直到相应vLSM的状态同步协议已完成。图5-3显示了状态同步协议的示例。
状态同步协议完成需要中的以下事件列出的订单：
1.状态交换：传输状态状态ALMP，并接收无错误状态状态ALMP。传输的状态状态ALMP中指示的状态为vLSM状态的快照。参见第5.1.2.3.1节。
2.基于发送和接收状态的相应状态状态决议同步交换期间的状态ALMP。确定见表5-4已解析的vLSM状态。
3.新状态请求和状态ALMP交换（如适用）。如果解析的vLSM状态与链路层请求的状态不同。

5.1.2.3.1 vLSM快照规则

STATUS_EXCHANGE_PENDING变量用于确定可以采用vLSM。以下规则适用：
•如果为该vLSM清除STATUS_EXCHANGE_PENDING变量
•一旦拍摄快照，就会为vLSM设置STATUS_EXCHANGE_PENDING变量
•STATUS_EXCHANGE_PENDING变量在重置或完成时被清除
状态交换（即，传输状态ALMP，并接收无错误状态ALMP）这是为了说明在状态期间损坏的状态ALMP的情况Exchange可以通过恢复导致更多LTSSM转换。见图5-16以该流程为例

图5-3。状态交换示例

表5-4。状态交换后的vLSM状态解析（第1张，共2张）

表5-4。状态交换后的vLSM状态解析（第2页，共2页）

5.1.2.3.2状态交换后状态解析说明（表5-4）

1、对于解析状态为活动的行，相应的ARB/MUX必须确保在状态状态ALMP之后立即从远程ARB/MUX可以由相应vLSM的链路层来服务。保证这一点的一种方法是确保对于这些情况，链路层接收器在状态交换期间发送状态状态ALMP之前已准备就绪。
2、第7行和第11行将导致L1退出流遵循状态解析。这个相应的ARB/MUX必须通过新状态启动向活动的转换请求ALMP。一旦上游端口VLSM和下游端口VLSM处于活动状态时，如果需要，链路层可以重新进行PM条目协商。类似地，对于行10，如果在PM协商期间达到，则要求两个vLSM都启动主动请求ALMP。
3、如果支持，第3行和第8行将导致L2出口流遵循状态解析。由于LTSSM最终将移动到Detect，因此每个vLSM最终都将转换到重置状态。
4、第7行和第8行仅适用于上游端口。由于进入PM总是由上游端口启动，并且它不能将其vLSM转换为PM，除非下游港口已经这样做了，不存在这些行可以申请的情况下游端口。
5、行为未定义，并且实现特定于中未捕获的组合表5-4。
5.1.2.4状态请求ALMP
以下规则适用于发送状态请求ALMP。状态请求ALMP是发送以请求将状态更改为活动或PM。对于PM，只能启动请求通过上游端口上的ARB/MUX。

5.1.2.4.1进入活动

1、所有恢复状态操作必须在进入活动序列之前完成启动。对于68B Flit模式，这包括完成状态同步LTSSM从恢复转换到L0后的协议
2、发送ALMP状态请求以启动进入活动状态。
3、vLSM必须发送请求并接收状态，然后发射器才能被认为是活跃的。这并不等同于vLSM活动状态。
4、只有当vLSM达到活动状态时，才能传输协议层微片状态
图5-4显示了进入活动状态的示例。图5-4中的流程显示四个不一定在中发生的独立操作（ALMP握手）所示的顺序或小时间段。vLSM发射机和接收机可能会彼此独立地活动。发射器和接收器必须在vLSM状态为活动。vLSM发送后，发送器变为活动状态请求ALMP｛Active｝并且接收到状态ALMP{Active｝。接收器变成在vLSM接收到请求ALMP｛active｝并发送状态ALMP{active｝之后处于活动状态作为回应有关活动状态请求/状态的规则，请参阅第5.1.2.2节握手协议。
图5-4。CXL进入活动示例流

5.1.2.4.2进入PM状态（L1/L2）

1、发送ALMP状态请求以启动进入PM状态。仅上游端口可以启动进入PM态。
2、对于上游端口，vLSM必须在对于相应的vLSM，PM协商被认为是完成的。
图5-5显示了由上游端口启动的进入PM状态（L1）的示例（图中向上）ARB/MUX。一旦vLSM已发送请求ALMP｛L1｝，并收到状态ALMP{L1｝作为返回或vLSM已接收到请求ALMP｛L1｝并发送状态ALMP{L1｝作为返回。vLSM独立操作，操作可能无法按顺序或在时间表显示。一旦所有vLSM都准备好进入PM状态（L1），通道将完成EIOS交换并输入L1。
图5-5。CXL进入PM状态示例

5.1.2.5 State Status ALMP

5.1.2.5.1 When State Request ALMP is received（当收到状态请求 ALMP 时）

• 当接受进入PM 状态时，在接收到进入活动状态或PM 状态的状态请求ALMP 后，发送状态ALMP。 如果不接受 PM 状态，则不发送状态 ALMP。 有关更多详细信息，请参见第 10.3 节“Compute Express Link 电源管理”。

5.1.2.5.2 Recovery State

• 如果在 vLSM 未首先发送状态请求的情况下接收到状态 ALMP，则 vLSM 将触发链路恢复，除非出于同步目的而接收到状态 ALMP（即在链路退出恢复之后）。
图 89 显示了恢复退出的一般示例。 状态同步协议的详细内容请参见5.1.2.3 节。

退出恢复时，通道两侧的 vLSM 将发送状态 ALMP 以便同步 vLSM。 如果解析的状态和链路层请求的状态不相同，则用于同步的状态 ALMP 可能会触发状态请求 ALMP，如图 90 所示。请参阅第 5.1.2.3 节了解状态同步期间应用的规则。 在出现意外 ALMP 的情况下，用于同步的 ALMP 可能会触发重新进入恢复。 使用第 5.1.3.1 节中的初始链路训练流程示例对此进行了解释。 如果两个 vLSM 解析的状态与链路层请求的状态相同，则 vLSM 被视为已同步并将继续正常操作。

图 90 显示了通过恢复退出 PM 状态 (L1) 的示例。 L1状态的DP vLSM[0]收到Active Request，链路进入Recovery状态。 退出恢复后，每个vLSM都会发送Status ALMP{L1}以同步vLSM。
由于同步后的resolved状态不等于请求状态，所以Request ALMP{Active}和Status ALMP{Active}握手完成，进入Active状态。

5.1.2.6 Unexpected ALMPs

以下情况描述了意外 ALMP 将触发链路恢复的情况：
• 当退出恢复后执行状态同步协议时，除状态ALMP 之外的任何ALMP 均被视为意外ALMP，并将触发恢复。
• 发送主动请求ALMP 后，收到除主动状态ALMP 或主动请求ALMP 之外的任何ALMP 均被视为意外ALMP，并将触发恢复。
• 如第 5.1.2.5.2 节所述，在未首先发送状态请求 ALMP 的情况下接收到的状态 ALMP 是意外 ALMP，除非在状态同步协议期间。

5.1.3 vLSM状态转换规则的应用

5.1.3.1 初始链路训练

当链路从 Gen1 速度训练到最高支持速度（CXL 的 Gen3 或更高速度）时，LTSSM 可能会经历多次恢复到 L0 到恢复的转换。
实现不需要将 ARB/MUX 暴露给所有这些恢复转换。 根据这些初始恢复转换是否对 ARB/MUX 隐藏，初始 ALMP 握手可能会发生四种不同的情况。 在所有情况下，vLSM 状态转换规则保证情况会自行解决，vLSM 达到活动状态。 这些场景如下图所示。 请注意，这些图是说明性示例，实现必须遵循前面几节中概述的规则。 图中只显示了一次 vLSM 握手，但第二次 vLSM 也可能发生类似的握手。
图 91 显示了 DP 和 UP 都隐藏来自 ARB/MUX 的初始恢复转换的场景示例。 由于它们都没有看到恢复条目的通知，因此它们继续交换 Active 请求和状态 ALMP 以转换为 Active 状态。 请注意，第一个 ALMP（Active request ALMP）是从 DP 发送到 UP 的。

图 92 显示了一个示例，其中 DP 和 UP 在初始链路训练期间向 ARB/MUX 通知至少一个恢复转换。 在这种情况下，首先交换状态同步 ALMP（指示重置状态），然后定期交换活动请求和状态 ALMP（未明确显示）。 请注意，第一个 ALMP（复位状态）是从 DP 发送到 UP 的。

图 93 显示了 DP 隐藏来自 ARB/MUX 的初始恢复转换但 UP 不隐藏的场景示例。 在这种情况下，DP ARB/MUX 尚未看到恢复转换，因此它首先向 UP 发送活动状态请求 ALMP。 这被 UP 解释为意外的 ALMP，并触发链路恢复（现在必须通知 ARB/MUX，因为它是在以最高支持的链路速度达到操作之后）。 使用 state=Reset 进行状态同步，然后执行常规的 Active 请求和状态握手（未明确显示）。

图 94 显示了 UP 隐藏初始恢复转换但 DP 不隐藏的场景示例。 在这种情况下，DP首先发送复位状态ALMP。
这将导致 UP 根据第 5.1.2.5 节中的规则触发链路恢复（现在必须通知 ARB/MUX，因为它是在以最高支持的链路速度达到操作之后）。 使用 state=Reset 进行状态同步，然后执行常规的 Active 请求和状态握手（未明确显示）。

5.1.3.2 Status Exchange Snapshot Example（状态交换快照示例）

图 95 显示了 UP 上 vLSM[1] 的状态交换期间状态 ALMP 损坏的情况示例。 损坏的 ALMP 是指较低的四个 DW 与接收到的 ALMP 不匹配； 它表示传输期间 ALMP 的低 4 个 DW 上出现位错误。 ARB/MUX 会因此触发 LTSSM 恢复。 当收到第二个恢复条目的恢复条目通知时，UP 上的 vLSM[1] 快照仍处于活动状态 - 因为状态交换尚未成功完成。

5.1.3.3 L1 中止示例

图 96 显示了物理链路 L1 转换期间可能出现的场景示例。 首先，两个 vLSM 通过相应的 PM 请求和状态 ALMP 握手成功进入 L1。 ARB/MUX 甚至请求物理层将 LTSSM 带到 DP 和 UP 的 L1。 然而，恰好存在竞争，并且在 DP 物理层接收到 EIOS 之前，其中一个 vLSM 请求“活动”。 这会导致 ARB/MUX 删除 L1 条目请求（L1 中止），同时向 UP 发送主动请求 ALMP。 当EIOS最终被物理层接收时，由于DP侧的ARB/MUX没有请求L1（并且没有
支持 CXL 中的 L0），物理层必须将 LTSSM 恢复以解决此情况。 在恢复退出时，DP 和 UP ARB/MUX 都会发送其相应的 vLSM 状态作为同步协议的一部分。 对于vLSM[1]，由于已解决的状态状态（Retrain）与期望的状态状态（Active）不同，因此DP必须向UP发送另一个Active请求ALMP。 类似地，在 UP 侧，接收到的状态状态（L1）与期望的状态状态（Active - 因为 vLSM 移动到 Retrain 会触发 UP 链路层请求 Active）不同，UP ARB/MUX 将发起 向 DP 发出主动请求 ALMP。 一旦发送和接收了 Active 状态 ALMP，相应的 ARB/MUX 会将 vLSM 移至 Active，并且可以开始协议级 flit 传输。

5.2 ARB/MUX Link Management Packets

ARB/MUX 使用 ALMP 将与每个链路层相关的虚拟链路状态转换请求和响应传送到远程 ARB/MUX。
ALMP 是一个 1DW 数据包，其格式如下图 97 所示。 该 1DW 数据包在 528 位 flit 的低 16 字节上复制四次，以提供数据完整性保护； flit 在高位上用零填充。 如果 ARB/MUX 检测到 ALMP 中的错误，它会启动链路重新训练。

ALMP数据包的字节1、2和3如下表62所示。 ALMP 的字节 1 中使用的消息代码是 0000_1000b。 ALMP 可以是请求类型或状态类型。 本地 ARB/MUX 使用请求 ALMP 启动远程 vLSM 的转换。 接收到请求ALMP后，本地ARB/MUX处理转换请求并返回状态ALMP以指示转换已经发生。 如果不接受转换请求，则不会发送状态 ALMP，并且本地和远程 vLSM 均保持其当前状态。

5.2.1 ARB/MUX 旁路功能

当 Flex Bus 链路在 PCIe 模式下运行时，ARB/MUX 必须禁用 ALMP 的生成。 可以通过 hwinit 或在链路训练期间确定旁路条件。

5.3 仲裁和数据复用/解复用

ARB/MUX 负责在来自 CXL 链路层的请求之间进行仲裁，并根据仲裁结果复用数据。 仲裁策略是特定于实现的，只要它满足通过 Flex 总线链路传输的更高级别协议的时序要求即可。 此外，必须有一种方法来编程与 CXL.io 和 CXL.cache+CXL.mem 链路层相关的相对仲裁权重，因为它们仲裁通过 Flex Bus 链路传输流量。 更多详细信息，请参见第 8.2.6.1 节。 不同 CXL 协议之间的流量交错是在 528 位 flit 边界处完成的。