在傳輸端，Flex Bus物理層準備從PCIe鏈路層或CXL ARB/MUX接收的數據，以便通過Flex Bus鏈路進行傳輸。在接收端，Flex Bus物理層對Flex Bus鏈路上接收的數據進行串并轉換，并將其轉換為適當的格式，以轉發到PCIe鏈路層或ARB/MUX。

在初始鏈路訓練期間，邏輯PHY在PCIe模式下工作，在訓練至2.5 GT/s后，根據備用模式協商的結果，在適當的情況下切換到CXL模式。在CXL模式下，正常操作在本機鏈路寬度和32 GT/s鏈路速度下進行。降級運行模式包括8 GT/s或16 GT/s鏈路速度，和較小的x2和x1鏈路寬度。下表總結了協議支持的CXL鏈路寬度和鏈路速度組合。

6.2 Flex Bus的CXL幀和數據

6.2.1 有序集塊和數據塊

有序集塊（Ordered Set Block）和數據塊（Data Block）是PCIe里面的概念。有序集塊用于訓練、進入和退出電氣空閑、轉換到數據塊，以及時鐘容差補償等，這個放到講PCIe的時候再說。數據塊用于傳輸從CXL鏈路層接收的flit。16-bit協議ID字段與從鏈路層接收到的每個528-bit（512-bit數據負載+16-bit CRC） flit相關聯。

6.2.2 Protocol ID[15:0]

16位協議ID字段指定傳輸的flit是CXL.io、CXL.cache/CXL.mem還是其他有效負載。

當鏈路層沒有有效flit時，物理層插入NULL flit到數據流中。

6.2.3 x16數據包

下圖顯示了x16鏈接的數據包布局。首先，16-bit傳輸協議ID被分成兩個8-bit，在Lane 0和Lane 1上傳輸；隨后是528-bit flit的傳輸，同樣是按照8-bit粒度拆分。

6.2.4 x8數據包

6.2.5 x4數據包

6.2.6 x2數據包

x2數據包布局與x4數據包布局非常相似，協議ID與通道0對齊。16-bit協議ID和528-bit flit以8-bit粒度在兩條Lane上傳輸。

6.2.7 x1數據包

x1數據包布局僅在降級模式下使用。16-bit協議ID后跟528-bit flit在一條Lane上傳輸。

6.2.8 特殊情況：CXL.io – 何時TLP在Flit邊界上結束

對于CXL.io，如果TLP在flit邊界上結束，且沒有額外的CXL.io數據包要發送，但接收端仍然需要隨后的EDB（EnD Bad）指示，或IDLE flit，或DLLP，以在處理TLP之前確認此TLP是完好的還是無效的。

下圖展示了這種場景，第一個CXL.io flit剛好封裝了一個TLP。為保證接收端正確處理，發送端需要在發送一個包含PCIe IDLE令牌的CXL.io flit。

6.2.9 幀錯誤

物理層負責檢測幀錯誤，并隨后啟動Recovery以重新訓練鏈路。以下是物理層檢測到的幀錯誤：

• 同步頭錯誤
• 協議ID幀錯誤
• EDS插入錯誤
• 528-bit的CXL.io flit中存在PCIe幀錯誤

6.3 鏈路訓練

6.3.1 PCIe vs Flex Bus.CXL

當LTSSM從Detect狀態退出后，Flex Bus鏈路開始訓練，并根據PCIe LTSSM規則完成鏈路寬度協商和速度協商。在鏈路訓練期間，下游端口通過PCIe備用模式協商機制啟動Flex Bus模式協商。在以2.5 GT/s的速度進入L0之前，完成Flex Bus模式協商。

Flex Bus模式的動態硬件協商發生在LTSSM的Configuration狀態下的鏈路訓練期間，通過交換PCIe 5.0基本規范定義的Modified TS1和TS2有序集來促進。

6.4 Recovery.Idle和Config.Idle轉換到L0

PCIe規范要求從Recovery.Idle切換到L0，或從Config.Idle切換到L0，鏈路雙方需要傳輸和接收特定數量的連續空閑數據符號。當Flex Bus的邏輯PHY處于CXL模式時，會監測NULL flits而不是空閑字符來啟動到L0的轉換。當處于CXL模式下Recovery.Idle或Config.Idle時，如果接收到四個連續的NULL flit并且在接收到一個NULL flit之后發送了八個NULL flit時，則下一個狀態為L0。

第七章 交換機（Switching）

7.1 概覽

7.1.1 單VCS（Virtual CXL Switch）交換機

圖中的vPPB是virtual PCI-to-PCI bridge。單VCS交換機指的是有一個上游端口，若干個下游端口。單VCS交換機須遵守規則：

• 必須有一個上游端口（Upstream Switch Port，USP）
• 必須有一個或多個下游端口（Downstream Switch Port，DSP）
• DSP必須支持PCIe模式和CXL模式
• 所有non-MLD（包括PCIe和SLD）端口都支持vPPB下的單個虛擬層次結構
• DSP必須能夠支持CXL 1.1鏈路
• 必須支持CXL 2.0擴展DVSEC
• DVSEC定義了寄存器，支持CXL.io解碼和CXL.mem解碼
• Fabric Manager是可選的

解釋一下，Fabric Manager是一個獨立于交換機或主機固件的實體，它控制與端口和設備的綁定和管理相關的系統方面。

7.1.2 多VCS（Virtual CXL Switch）交換機

多VCS交換機須遵守規則：

• 多于1個USP
• 每個VCS有一個或多個DSP
• 上游vPPB到物理端口的綁定和VCS的結構取決于交換機供應商具體實現
• 每個DSP必須綁定到PPB或vPPB
• Fabric Manager是可選的
• 配置時，每個USP及其關聯的DSP形成一個VCS交換機
• DSP必須支持在CXL或PCIe操作模式下運行。
• 所有non-MLD端口都支持下游交換機端口下方的單個虛擬層次結構。
• DSP必須能夠支持CXL 1.1鏈路

7.1.3 具有MLD端口的多VCS交換機

具有MLD端口的多VCS交換機由多個上游端口交換機和一個或多個下游MLD端口的組合組成。

具體規則不再列出。

7.2 交換機配置和組成

7.2.1 CXL交換機初始化選項

CXL交換機三種初始化方法：

1.靜態
2.FM在主機前啟動
3.FM和主機同時啟動

7.2.1.1 靜態初始化

下圖是靜態初始化的例子，下游vPB靜態綁定到端口，使用標準的PCIe機制支持設備熱插拔。

靜態交換機特性：

• 不支持MLD端口
• 不支持將端口重新綁定到不同的VCS
• 不需要FM
• 在交換機啟動時，使用特定的機制（例如SPI閃存中的配置文件）靜態配置所有VCS和下游端口綁定
• 支持CXL 1.1、CXL 2.0或PCIe下游端口
• VCS（包括vPBs）的行為與PCIe交換機相同，同時添加了對CXL協議的支持
• 當主機啟動時，每個VCS都準備好進行枚舉
• 支持熱插拔
• 不支持異步移除CXL 2.0設備

7.2.1.2 FM先啟動

在FM先于主機啟動的情況下，允許按照以下示例所述初始化交換機。

1. Switch和FM啟動
2. 在本例中，下游vPPB靜態綁定到端口，使用標準PCIe機制支持設備的熱插拔
3. 所有下游端口都沒有綁定到VCS，它們歸FM所有
4. DSP鏈路建立，交換機通知FM
5. FM向交換機發送BIND命令（VCS0、VPPB1、PHY_PORT_ID1）。交換機配置虛擬到物理綁定，如項中所述
6. 交換機將vPPB虛擬端口號重新映射為物理端口號
7. 交換機將vPPB連接器定義（PERST#、PRSNT#）重新映射到物理連接器
8. 交換機禁用鏈路
9. 所有物理的下游PPB功能都直接映射到vPPB
10. FM擁有的PPB不再存在于該端口
11. 當主機啟動時，交換機已準備好進行枚舉。

7.2.1.3 FM和主機同時啟動

FM和主機同時啟動：

1.VCS是靜態定義的

2.每個VCS內的vPPB被解除綁定，并作為鏈路斷開呈現給主機

3.交換機發現下游設備并將其呈現給FM

4.主機枚舉VH并在上游PPB中配置DVSEC

5.FM執行到vPPB的端口綁定

6.交換機執行虛擬到物理的綁定

7.每個被綁定的端口都產生對主機的熱添加指示

7.2.2 邊帶信號操作

下表表提供了支持熱插拔的最小邊帶信號集，其它邊帶信號可選。這些邊帶信號的行為與PCIe協議中定義的一致。

7.2.3 綁定和解綁

本節是關于CXL設備到vPPB的綁定和解綁。

7.2.4 MLD端口PPB和vPPB行為

MLD端口提供虛擬化接口，以便多個vPPB可以通過共享物理接口訪問LDs。因此，綁定到MLD端口的vPPB的特性和行為與綁定到SLD端口的vPPB的特性和行為不同。本節定義了它們之間的區別。

7.2.5 MLD ACS擴展功能

CXL.io的請求事務和完成事務被路由到USP。

7.2.6 MLD PCIe擴展功能

vPPB的PCIe擴展能力結構（Capability Structure）中的所有字段的行為應與PCIe相同，但以下小結中的情況除外。

7.2.7 MLD AER（Advanced Error Reporting）擴展功能

MLD端口中的AER分為Triggering、Notification和Reporting。

7.2.8 MLD DPC擴展功能

7.3 CXL.io, CXL.cache/CXL.mem解碼和轉發

7.3.1 CXL.io

在VCS中，CXL.io流量必須遵守PCI Express規范中定義的交換機的相同請求、完成、地址解碼和轉發規則。

7.3.1.1 CXL.io解碼

當TLP由PPB解碼時，它根據PCIe基本規范中定義的規則，確定要路由TLP的目標PPB。除非另有規定，PCIe基本規范中定義的所有規則都適用于CXL.io TLP的路由。

7.3.1.2 CXL 1.1 支持

FM擁有的PPB端口不支持CXL 1.1設備。CXL 1.1設備連接到交換機的話，在軟件中必須顯示為RCiEP設備。

7.3.2 CXL.cache

僅允許啟用VCS中的一個CXL SLD端口來支持Type 1或Type 2設備。USP上接收到的請求和響應被路由到相關的DSP，反之亦然。因此，CXL.cache不需要額外的解碼寄存器。

7.3.3 CXL.mem

HDM解碼DVSEC功能包含定義內存地址解碼范圍的寄存器。CXL.mem請求來自主機/RP，并通過交換機向下游流向設備，響應來自設備，并向上游流向RP。

7.3.4 FM Owned PPB CXL Handling

暫時略過。

7.4 CXL交換機電源管理（PM）

7.4.1 CXL Switch ASPM L1

對ASPM L1的支持在第十章中描述。

ASPM（Active State Power Management）是PCIe協議中的一種硬件電源管理機制。

7.4.2 CXL Switch PCI-PM and L2

VCS中的vPPB對PME消息的處理規則與PCIe vPPB相同。

7.4.3 CXL Switch Message Management

CXL VDM屬于“Local – Terminate at Receiver”類型。當層次結構中存在交換機時，該交換機實現消息聚合功能。所有主機生成的消息都終止于該交換機，交換機聚合功能負責向下游端口重新生成這些消息。CXL設備生成的所有消息和響應都由交換機聚合和合并，合并后的消息或響應由交換機的上游端口生成，發送給主機。

PM消息信用交換發生在主機和交換機聚合端口之間，并且分別發生在交換機聚合端口和設備之間。

7.5 CXL交換機RAS

7.6 Fabric Manager應用程序編程接口

暫時略過，留給軟件開發人員去頭疼吧。

總結：本章中的很多概念是基于PCIe基本規范的，不過在PCIe基本規范中并沒有專門為Switch設立一章。但是在CXL協議中，Switch承擔了很多事情。