PCIe Chapter 5：一次讀寫如何變成 PCIe 交易

先看本章的角色與路徑

一次 MMIO（Memory-Mapped I/O，記憶體映射輸入輸出）讀取，會由主機端提出要求，再由目標端回覆資料。PCIe 用 TLP（Transaction Layer Packet，交易層封包）承載這些交換。

前情提要：Chapter 4 已完成本例的 BAR、Bridge Window 與解碼配置。現在沿同一路徑觀察一筆 4-byte 讀取。

BAR

Base Address Register，基底位址暫存器

規格路線：交易類別 Table 2-1 → Request 的 ID／Tag 與 Memory Request 格式 → Completion 格式 → 分段與邊界條件。

先辨認交易，再決定要等待什麼

Transaction Layer Packet（TLP）承載交易。Requester 提出要求，Completer 服務目標；這些角色隨交易改變。Memory Request 依位址送往目標，Completion 則依原 Requester ID 回送。Requester ID 與 Tag 配對尚待完成的交易，同一 Requester 不得讓兩筆同時未完成、需要 Completion 的要求共用 Tag。Base 6.0 另有較大 Tag 的能力與啟用條件，不能把它永遠視為 8 bits。

Configuration 依 ID 路由；I/O 依 I/O 位址；Message 依其規定採位址、ID 或隱含路由。普通 MWr 沒收到 Completion 不構成重送理由，也不代表裝置工作已完成；工作結果仍依裝置介面判斷。

把 4-byte 讀取對到封包欄位

假設平台以 Requester ID=0x0000、Tag=0x12，讀取裝置 0x80004120 的 4 bytes。這個 Requester ID 是平台假設，不能由 Root Port BDF 直接推定。MRd 使用 Fmt=000b、Type=00000b、Length=1 DW、First BE=1111b、Last BE=0000b；Request 本身沒有資料 Payload。3 DW Header 的選擇來自本例的 32-bit 目標位址格式，不是因為資料剛好是 32 bits。

BDF

Bus／Device／Function，匯流排、裝置與功能識別

DW

Double Word，4 bytes的資料單位

成功 CplD 使用 Fmt=010b、Type=01010b，保留原 Requester ID／Tag，Completer ID=0x0300。Length=1 DW、Status=SC、Byte Count=4，Lower Address=0x20。若四個有效 bytes 為 78 56 34 12，且本例 Register 定義為 little-endian，值為 0x12345678。

若另讀取 0x80004121–0x80004126 的 6 bytes，並假設裝置允許該存取，Request 要用對齊位址 0x80004120、Length=2、First BE=1110b、Last BE=0111b。成功回覆 Payload 占 2 DW，但有效資料只有 6 bytes；Byte Count=6、Lower Address=0x21。未啟用的 non-Prefetchable bytes 不得在 Completer 被讀取。

Byte Count 不一定等於這個回覆的 Payload

另假設 Endpoint 從有效 DMA 位址 0x40001000 讀 256 bytes，Requester ID=0x0300、Tag=0x13，BME 與映射都已準備好。Requester 的最大讀取要求為 512 bytes；Completer 的有效 Payload 上限及 RCB 都為 128 bytes，路徑接收能力相容。這筆 Length=64 DW 的要求，可按下表回覆：

DMA

Direct Memory Access，裝置直接存取記憶體

兩個回覆皆為 SC、BCM=0，並保留相同的 Requester ID／Tag。Byte Count 包含目前片段及後續尚待回傳的資料。同一要求的回覆按位址遞增；不同 Transaction ID 的回覆可交換順序，也不得合併成一個 Completion。

另一項獨立限制是 Memory Request 不得跨 4 KiB：從 0x40001FF0 讀 32 bytes 會到 0x4000200F，必須拆成兩筆各 16 bytes 的要求。接收端可以選擇檢查跨界；若已實作的檢查發現違規，便視為 Malformed TLP（格式錯誤的封包）。沒有錯誤紀錄不代表原要求一定合法。這是 Non-Flit Mode 的一般 Memory Read；AtomicOp 的對齊另見 Chapter 15。

若讀取回覆失敗，Cpl 不帶有效讀取資料並終止該要求；UR／CA 不能當成讀到零，RRS 也不是 MMIO 的通用重試結果。

兩個裝置用了相同 Tag，回覆要怎麼分？

先把每個 Completion 的 Requester ID（原要求者識別號）和 Tag（要求者分配的交易標籤）一起對回原始 Request，再用 Status、Length、Byte Count 和 Lower Address 檢查資料範圍。完成分組後，才知道哪筆讀取還缺哪些資料。

規格閱讀順序：Figure 2-28 先建立 Transaction ID；Figure 2-73 找到 Completion 的 Requester ID、Tag、Status、Byte Count 和 Lower Address，再讀 §2.3.1.1 的 Byte Count 與遞增位址規則。不同 Transaction ID 的 Completion 允許互相超越，不表示一定會重新排序。核對完整封包時還要確認 Completer ID、TC、Attributes、資料長度與適用條件。（Base 6.0，文件頁／PDF 頁 153、196–198、215、218、224。）

TC

Traffic Class，流量類別

Tag 位數變大後，可以任意選數值嗎？

先回到 Figure 2-28：Requester ID 與 Tag 一起識別未完成的交易；在同一個 PCIe Hierarchy（階層）中，同一個 Requester ID 的未完成 Non-Posted Requests，不論 Traffic Class，都必須使用不同的 Tag。現在要擴大可用範圍時，還需要把 Requester 設定、完成端能力與中間路徑一起帶入 Table 2-11。Flit Mode 的跨 Hierarchy Segment 識別另有規則，本例不展開。

表格左邊三欄依序是 14-Bit Tag Requester Enable、10-Bit Tag Requester Enable 和 Extended Tag Field Enable；右邊依完成端及路徑共同支援的最大 Tag 能力分欄。先確認 Requester 本身支援並允許使用該能力，再選正確欄位。Enable=1 不是完成端支援能力的證明，也不是一定會同時送出該數量的要求。

查設定時，Extended Tag Field Enable 在 PCI Express Capability 的 Device Control；10-Bit Tag Requester Enable 在 Device Control 2；14-Bit Tag Requester Enable 則在 Device 3 Extended Capability 的 Device Control 3。應先走訪對應 Capability，再查各欄位的適用條件；VF 另有 PF 的控制規則。軟體若在 Function 尚有未完成 Non-Posted Requests 時修改 10-bit 或 14-bit Requester Enable，結果為 undefined（未定義）。

VF

Virtual Function，虛擬功能

PF

Physical Function，實體功能

若同時向較大與較小 Tag 能力的目標發送要求，還須依 Table 2-11 使用各自範圍，並避免較大 Tag 因不支援的完成端截斷而與仍未完成的小 Tag 混淆。發送前確認完整路徑，比等到 Completion 的 Tag 異常後再推測更容易定位問題。

PCI Express Base 6.0 §2.2.6.2、Figure 2-28／Table 2-11，文件頁／PDF 頁 153–156；§7.5.3.4、Table 7-21，p.960；§7.5.3.15–§7.5.3.16、Tables 7-33–7-34，pp.991、997；§7.7.9.2–§7.7.9.3、Tables 7-108–7-109，pp.1073、1075。

同時使用大小 Tag，為什麼還要檢查低位元？

前一節的範圍是發送要求前的選擇。§2.2.6.2 還要求：若 Requester 同時向較大與較小 Tag 能力的目標發送要求，即使某筆較大 Tag 要求意外由不具足夠能力的完成端回覆，也要避免它與仍未完成的小 Tag 交易混淆。

這是規格提供的一種實作方法，不要求所有 Requester 都用同一種切分。規格要求的是避免上述混淆；實際可同時追蹤的交易數還受裝置資源及路徑條件限制。前一節的 Table 2-11 仍要先用來判斷每筆要求允許使用的 Tag 範圍。

PCI Express Base 6.0 §2.2.6.2，文件頁／PDF 頁 154–155；Implementation Note: Using Larger Tags and Smaller Tags Concurrently，p.159；Table 2-11，pp.155–156。

跨 Hierarchy 的讀取，Completion 要回到哪裡？

前面的例子在同一個 PCIe Hierarchy（階層）內用 Requester ID 與 Tag 配對。Flit Mode 跨 Hierarchy 時，還要先看 Segment：它幫助路徑辨認封包屬於哪個階層，再由 Requester ID 找到要求者。Chapter 3 的 Segment 捕捉例子先說明 Function 如何取得自己的 Segment。

這個例子有兩個重要前提。第一，對非 IDE Memory Request，Requester 是否帶入 Requester Segment 可以是可選的；若 B 收到的 Non-Posted Memory Request 沒有 Requester Segment，B 在有 OHC-A5 的回覆中須將 DSV 清為 0、Destination Segment 設為 00h。第二，RC 接手交易時有另一套識別與還原規則；不要把本例「不接手」的結果直接套到所有路徑。

IDE

Integrity and Data Encryption，完整性與資料加密

閱讀時先看 §2.2.1.2 的 Figure 2-13 找到 Request 的 Requester Segment 與 RSV，再讀同節的 Requester、Completer 及 RC 規則，最後用 Figure 2-11 對照 Completion 的 OHC-A5。§2.2.9.2 補充哪些 Completion 條件需要 OHC-A5。還要分別確認觀察點、路徑模式、Segment Captured 與 RC 是否接手；單看封包內的 Segment 值無法確認整筆交易成功。

PCI Express Base Specification Revision 6.0，§2.2.1.2、Figures 2-11、2-13，文件頁／PDF 頁 133–134、138–141；§2.2.9.2，p.199。

用兩個問題確認理解