Protocol Multiplexing 與替代協定

同一條 Link 承載其他協定，PCIe 的哪些規則還適用？

PCIe 與 PMUX 封包共用 Link，哪些部分仍各自獨立？

先看 Figure G-2：同一條 PMUX Link 上，傳送端分別排入 PCIe 與 PMUX（Protocol Multiplexing，協定多工）佇列，再由仲裁器安排傳送；接收端依封包種類解多工。Figure G-3 接著顯示 PMUX Packet 經過協定專用的 Protocol Layer、簡化的 Data Link Layer 和 Physical Layer。

PMUX Packet 有自己的 LCRC（Link Cyclic Redundancy Check，逐 Link 完整性檢查碼），但不使用 PCIe TLP 的 Sequence Number、Ack／Nak 或 TLP Credit。12-bit PMUX Packet Metadata 由多工協定使用，不能因數值相同就當作 TLP Sequence Number。若封包需要確認、重送或流量控制，要查該多工協定自己的定義；Appendix G 也不定義 PMUX Packet 跨元件的定址或路由。

本章依 Base 6.0 Appendix G 的 PMUX 能力討論 2.5–32.0 GT/s；其 PMUX Supported Link Speeds 欄位沒有定義 64.0 GT/s 支援位元。不能把本章的封包與欄位直接當成 64.0 GT/s Flit Mode 的格式。

PCIe Base 6.0 Appendix G，Figures G-1–G-3，印刷／PDF pp.1561–1563；§G.5.2、Table G-7，pp.1575–1576。

兩端的 Channel 0 要如何指向同一個協定？

【模擬資料】以下資料為教學用途建立，不代表特定硬體或平台。假設一條 Link 目前為 16.0 GT/s、x4，兩端分別是 Downstream Port 與 Upstream Port 的 Function 0；兩端都找到 PMUX Extended Capability ID=001Ah、Version=1。以各自的結構起點 P 表示，Capability P+04h 均為 00000C02h：Protocol Array Size=2，且 PMUX 支援 8.0 與 16.0 GT/s。兩端的 Link 本身也支援這些速度；另假設協定文件允許本例速度和寬度。

依 Figure G-7 找 Array，再看 Figure G-12／Table G-10：每個 entry 的高 16 bits 是 Authority ID、低 16 bits 是 Protocol ID。假設兩端支援相同的兩個協定，但 Array 排列不同；以下識別值都是教學假設，尚未賦予廠商協定語意。

兩端要讓 Channel 0 使用同一個協定，分別在 Control P+08h 的 bits5:0 寫入 1 與 2。這兩個索引都指向 Authority ID=1234h、Protocol ID=0001h；比較的是對應協定及其相容性，不是索引數字必須一樣。Assignment=0 表示沒有指定協定，Array 從索引 1 開始；entry 值 00000000h 表示未實作。Array Size 也允許為零，表示該 Port 沒有列出支援的 PMUX 協定。

再讀 Status P+0Ch：假設兩端 Channel 0 的 Disabled: Link Speed、Link Width、Protocol Specific 都為零，且其他協定專屬初始化已完成，Channel 0 才符合本例傳送條件。Status 的三個零值只有在 Assignment 有效時才足以排除這三種停用原因；Assignment=0 時，這些狀態位元也會是零。

兩端都必須支援 PMUX，Channel 也須在兩端明確配置。若兩端配置的是不相容的協定，結果為 undefined（規格未定義）。通道尚未啟用時不能傳送 PMUX Packet；支援 PMUX 的 Port 收到未啟用通道的封包會靜默忽略。

PCIe Base 6.0 §§G.4–G.5.5，Figures G-7–G-12、Tables G-6–G-10，印刷／PDF pp.1573–1580。

Recovery、速度變更和 Reset，結果一樣嗎？

沿用上一個 Channel 0 案例。若 Link 進入 Recovery 後返回 L0，Table G-1 對 Recovery 列為「對 PMUX 無影響」；但仍要確認過程中是否另有 DL_Down 或速度變更，不能只憑最後 L0 判定完整歷史。

如果 Link 改以 32.0 GT/s 運作，本例 PMUX Capability 的 bit12=0，不支援該速度；Channel 0 會因速度條件而停用，Status 可呈現 Disabled: Link Speed=1。相反地，即使 PMUX 支援某個速度，個別協定仍可能不支援該速度或寬度，需查協定自己的文件。

DL_Down、Hot Reset、PERST# 或 Upstream Port Function 0 的 FLR 會停用該 Link 的所有 PMUX Channels；其他 Function 的 FLR 對通道沒有這項影響。恢復後須重新確認兩端支援、協定對應、速度、寬度與通道設定，再依所選協定完成初始化。

FLR

Function Level Reset，以功能為範圍的重設

PCIe Base 6.0 §G.1，Table G-1 PCI Express Attribute Impact on Protocol Multiplexing，印刷／PDF pp.1563–1565；§G.5.4，Table G-9，pp.1578–1579。

Alternate Protocol 的索引查詢，與 PMUX Channel 相同嗎？

Alternate Protocol Extended Capability 是另一個探索與協商介面。先找 ID=002Bh、Version=1，再用 Figure 7-336 定位 Capability、Control、Data 1／2。它可以出現在 Downstream Port Function，或 Upstream Port 的 Function 0；不能把其中的 Index Select 當成前面 PMUX Array 的 Channel Assignment。

【模擬資料】假設一個 Downstream Port 的 Alternate Protocol Capabilities=00000103h：Count=3，Selective Enable Supported=1，因此存在 Selective Enable Mask。Index 00h 固定代表 PCIe；假設 Index 01h 被停用，讀 Data 1 得到 Vendor ID=FFFFh，其 Usage、Details 與 Data 2 內容為 undefined；Index 02h 的其他欄位則要依回報的 Vendor ID 和對應協定文件解讀。這個例子沒有宣稱該協定可用或已生效。

Count 是支援項目的數量，不是目前運作模式。Table 7-298 指出 Index 大於或等於 Count 時 Vendor ID 回 FFFFh；Table 7-297 另指出寫入大於 Count 的 Index Select 行為未定義。範例中正常查詢索引為 00h–02h，不應把 03h 當成第四個有效項目。

如果 Global Enable=1，Selective Enable Mask 對應 bit=1，且該項目沒有被停用，下一次協商才允許考慮該項目。修改 Mask 影響的是下一次協商，不會直接改變目前 Link 運作。Upstream Port 的 Selective Enable Supported 固定為零，不能套用 Downstream Port 的相同配置假設。

PCIe Base 6.0 §§7.9.20–7.9.20.6，Figures 7-336–7-342、Tables 7-295–7-300，印刷／PDF pp.1282–1286。

版本與來源

本章以 PCI Express Base Specification Revision 6.0（6.0-1.0-PUB）為準，文件頁與 PDF 頁相同。案例的配置與讀值均為作者假設，並非實機測量。