PCIe Chapter 24：TPH、LTR 與 OBFF 的平台協調

先把同一個案例中的對象分清楚

本章沿用 Chapter 1 的 Port 與獨立 Link 概念；不必重讀仲裁細節。接下來觀察 Root Port → Switch → Endpoint A／B。每個 Endpoint 各只有 Function 0，位於 D0；各 Link 的基本傳輸與資源配置均已就緒。

【模擬資料】以下資料為教學用途建立，不代表特定硬體或平台。案例假設所需的 TPH、LTR 與 OBFF 路徑能力均已確認，平台已提供有效的 Steering Tag；OBFF 所經 Link 沒有可用的 WAKE#，因此採用 Message。這些假設分別支援下列案例，不表示找到其中一個 Capability 就同時具備三種能力。

讀規格時先問自己：現在要找的是資料用途、可等待多久，還是適合活動的時機？帶著這個問題選章節，才不會因為三者都與效能或省電有關，就把欄位混在一起。

裝置寫完資料後，主機很快會讀取，該查什麼？

先開 Table 6-13 Processing Hint Mapping。案例是 Device 寫、Host 隨後讀的使用模式，表中對應 Target，PH[1:0]=10b。這個提示描述資料的預期用途，不會把這筆 Memory Write 改成另一種 Transaction，也不會給 Requester 額外的存取權限。

若還希望提示某個處理資源，再讀 §6.17.2 的 Steering Tag（導引處理資源的系統特定標籤，以下簡稱 ST）。平台軟體負責取得適合本機的值；ST 不是通用 CPU 編號。§6.17.4 也要求 Requester、Completer 與所有中間路由元件支援相應的 TPH 能力。目標的 TPH Completer Supported 在 Device Capabilities 2 [13:12]；Switch 的這個欄位為 Reserved，不能拿它當成每個 Switch Port 的支援檢查位元。

能力、表格與選取模式如何串起來？

先沿 Extended Capability 鏈找到 ID=0017h、Version=1，將結構起點記為 T。Figure 7-289 定位 Capability、Control 與可選表格，再用 Tables 7-258、7-259 逐欄解碼。以下假設已配置四個標籤 0031h、0042h、0053h、0064h。

Capability 的 ST Table Location=01b，表示表格就在這個結構內；ST Table Size=3 採 N−1 編碼，因此有四筆。Figure 7-293 的表格從 T+0Ch 開始，每筆 2 bytes。案例使用 Interrupt Vector Mode，對應有效 MSI-X vector 2，所以選 entry 2：T+0Ch+2×2=T+10h，讀到 0053h。MSI-X 的向量範圍與表格大小均假設至少涵蓋這筆。

MSI-X

Message Signaled Interrupts Extension，表格式訊息中斷

控制值 00000101h 同時選擇 Interrupt Vector Mode 與一般 TPH；它沒有啟用 Extended TPH。由於能力宣告不支援 Extended TPH，entry 的高 byte 為 RsvdP，真正使用的 ST Lower 是 53h。這只能支持「這次選用哪個提示值」，資料最後放進哪一層 Cache、效能增加多少，仍須平台與實際量測資料。

如果 ST Table Location=10b，應改查 MSI-X Table；同一 Function 不可同時把表格放在兩處。No ST Mode 則必須使用全零標籤，仍可提供 Processing Hint。更新表格前，規格建議先讓 Function 暫停工作，或停用 TPH Requester，避免更新途中使用到不確定的標籤值；不能把這項建議寫成所有更新都必須採取的唯一程序。

Base 6.0 §§6.17.2–6.17.4，pp.779–781；§7.9.13，Figures 7-289–7-294、Tables 7-257–7-260，pp.1241–1245。基本 Memory Request 格式見 Chapter 14。

LTR 的讀值為何要先分清「暫存器」與「訊息」？

LTR 回報 Endpoint 對 Memory Read／Write 的服務延遲需求，讓平台安排中央資源的電源政策；它不直接控制 Link 或 Switch 內部的低功耗狀態。先查 Device Capabilities 2 [11] 的 LTR Mechanism Supported，再查 Device Control 2 [10] 的 LTR Mechanism Enable。Root Complex 和所有中間 Switch 都須支援，才能啟用 Endpoint；階層中靠近 Root Port 的裝置必須先啟用。

接著開 Figure 7-142 LTR Extended Capability Structure。ID=0018h、Version=1 的結構供軟體提供平台延遲資訊；若起點為 L，Max Snoop Latency 在 L+04h，Max No-Snoop Latency 在 L+06h。這些是軟體可寫的上限設定，不是裝置最近一次送出的需求紀錄。一般多 Function 裝置只有 Function 0 實作此結構；Root Port 和 Switch Downstream Port 不適用這個結構，仍可透過 Device Capabilities 2／Control 2 支援與處理 LTR。

作者案例：Max Snoop Latency 讀到 080Ah，表示 Value=10、Scale=010b，換算為 10×1,024 ns＝10,240 ns。這裡的 [15:13] 是 RsvdP，沒有 Requirement bit。相較之下，LTR Message 的 Snoop Latency=880Ah 才是 Requirement=1 的有效 10,240 ns 需求。不能把 880Ah 原樣寫回這個暫存器。

Base 6.0 §6.18，pp.781–782；§7.5.3.15，p.991；§7.5.3.16，p.996；§7.8.2，Figures 7-142–7-145、Tables 7-126–7-128，pp.1101–1103。

在 Trace 裡，如何讀出兩類延遲需求？

先確認目前模式。Non-Flit Mode 查 Figure 2-57，Flit Mode 在完成承載處理與 TLP 重組後查 Figure 2-58；兩張圖的基本 Header 不同。依 Table 2-33 確認 Message Code=10h、Routing=100b，訊息使用 TC0，且沒有 Data Payload。Snoop／No-Snoop 欄位放在 Header 內，不能因為看見兩個數值就把它判成 MsgD。

接著用 Figure 6-15 Latency Fields Format for LTR Messages 拆每個 16-bit 欄位：bit15 是 Requirement，[14:13] 為 Reserved，[12:10] 是 Scale，[9:0] 是 Value。Requirement=1 才依倍率換算；有效的 Scale 為 000b–101b，單位依序為 1、32、1,024、32,768、1,048,576、33,554,432 ns。

A 的 No-Snoop 欄位雖然保留 Value=10、Scale=010b，Requirement=0 已表示該類沒有延遲需求，因此忽略這兩個值。它與 Requirement=1、Value=0 的情況相反：後者表示任何延遲都會造成影響，要求平台提供盡可能好的服務；不能解讀成硬體保證零延遲。

Base 6.0 §2.2.8.8，Table 2-33、Figures 2-57／2-58，pp.187–188；§6.18，Figure 6-15，pp.781–782。

Switch 為何會送出與 Endpoint 不同的數字？

Table 2-33 的 Routing=100b 表示在相鄰接收端終止。Switch 依 §6.18 收集已啟用 Downstream Ports 的需求，分別計算 Snoop 與 No-Snoop 的最小值，再扣除 Switch 自己引入的延遲 Lswitch。結果小於零就用零。Switch 從自己的 Upstream Port 送出彙整訊息，不是把 A 的原訊息直接轉寄。

案例假設 Lswitch 固定為 1,024 ns，且表中的兩個 Endpoint 是唯一有效來源。A 的 Snoop 需求較緊；No-Snoop 則只有 B 宣告需求。上游應讀到：

這樣平台提供 9,216 ns 的 Snoop 服務時間，加上 Switch 的 1,024 ns，才符合 A 所回報的 10,240 ns。若 B 所在 Port 進入 DL_Down，B 的舊回報必須失效：Snoop 彙整值仍由 A 決定，No-Snoop 則沒有任何有效需求，新的上游訊息必須清除那一類的 Requirement。不能讓已離線裝置的舊值繼續限制平台。

當 Requirement=1、Value=0 時，Switch 必須將該來源視為零，不受 Scale 影響；彙整結果為零時，上游 Value 與 Scale 都必須清為零。Not Permitted Scale 也不能照公式計算，§6.18 對 Switch 彙整另規定將該來源視為 effectively infinite。本文的正常案例沒有使用這種編碼。

若 Switch 的延遲會隨運作模式改變，還須檢查 Lswitch 不超過下游最小需求 20% 的限制；若最低延遲模式仍超過，必須使用最低延遲模式。多 Function 裝置也要分別取各類最嚴格需求，Snoop 與 No-Snoop 可來自不同 Function。這些條件會改變彙整結果，不能只取任一 Function 的讀值代表整個 Component。

Base 6.0 §6.18，pp.782–784；Table 2-33，p.187。

需求改變後，何時才用新的延遲分析交易？

同一串 Request 期間更新需求，Root Complex 必須在服務後續 Request 前將新值納入考量，且最晚在舊回報延遲以內生效。規格的 Implementation Note 建議：需求變嚴格時，提早送更新，讓平台有舊延遲長度的調整時間；需求變寬鬆時，在最後一筆仍需舊需求的 Request 之後送出。這是閱讀 Trace 時應保留更新前後時間點的原因。

若最後一次有效回報含有需求，透過 PMCSR Write 進入非 D0 前，裝置必須先送出兩類 Requirement 均為零的新訊息。以 Configuration Write 清除 LTR Mechanism Enable 時，也有撤回舊需求的要求；FLR 的對應規則在本版標為 MUST@FLIT，必須連同模式條件閱讀。Downstream Port 的 DL_Down 會使舊需求失效，並將該 Port 的 LTR Mechanism Enable 重設為預設值。

FLR

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

回報值是服務需求。Root Complex 並非必須滿足所要求的服務延遲，規格強烈鼓勵它做到；不能把數值當成所有 Read 必定在此時間內完成的承諾。§6.18 的 Non-Posted service latency 量到第一個 Completion 的開始，不是全部 Split Completion 的結束；Posted 的定義則對應因 Credit 用盡而受阻後，取得可繼續傳送 Credit 的時間。Clock Power Management 還可能加入時鐘恢復的等待；Figures 6-16／6-17 用來看這些時間分量與更新安排，詳細 Link 退出流程連回 Chapter 10。

Base 6.0 §6.18，pp.782–787，Figures 6-16 CLKREQ# and Clock Power Management、6-17 Use of LTR and Clock Power Management；§7.5.3.16，p.996。

平台提示適合活動，為何低功耗 Link 上可能沒有訊息？

先看 Figure 6-19 的拓撲：某些區段能共用 WAKE#，某些區段需要 Message，Switch 可依配置轉換兩種表示方式。本章案例所經 Link 沒有可用的 WAKE#，且平台已確認 Message 可送達 Endpoint。軟體不能僅憑 Endpoint 支援就啟用 OBFF。

在 Device Capabilities 2 [19:18] 讀支援的訊號方式；在 Device Control 2 [14:13] 讀實際選擇。Enable=00b 停用、01b 選 Message Variation A、10b 選 Message Variation B、11b 選 WAKE#。其中 A 與 B 是同一個 Downstream Port 的兩種替代配置：

因此，在 L1 期間沒有捕捉到活動提示，可能正是 Variation A 的規定。先核對這個出口 Port 的 Enable 與當時 Link 狀態，再判讀 Trace；若是 Variation B，則要把返回 L0 與後續 Message 一起看。設定 Message 路徑時，各段分別傳達提示；它不是一個由 Root Port 廣播、沿途不變的端到端訊息。

啟用順序也有自己的規則：OBFF 建議先啟用所有 Upstream Ports，再啟用 Downstream Ports；Root Ports 必須在其他 Ports 都啟用後才啟用。這與 LTR 靠近 Root Port 的裝置先啟用不同，不能共用一套順序。初次配置 OBFF 時，必須先假定為 CPU Active，直到觀察到第一個轉換，不能只看當下 WAKE# 電位就當成 Idle。

Base 6.0 §6.19，Figure 6-19，pp.787–790；§7.5.3.15，p.992；§7.5.3.16，p.997。

收到 OBFF Code 後，裝置應怎麼理解？

依模式開 Figure 2-59 或 2-60，並用 Table 2-34 確認 Message Code=12h、Routing=100b、TC0、沒有 Data Payload。訊息只允許往 Downstream 傳，Requester ID 必須是本段 Transmitting Port 的 ID。Figure 6-18 再把 OBFF Code 與 WAKE# 波形對照起來；WAKE# 的電氣參數須查適用的 Card Electromechanical 規格，本章不由邏輯圖推測實際電壓或時序合規。

若接收端已啟用 OBFF Message signaling，收到 Reserved OBFF Code 時，必須按 CPU Active 處理；若該 Port 不支援或未啟用，OBFF Message 則按 Unsupported Request 處理。已選 WAKE# 卻又收到 OBFF Message 的行為為 undefined，不能自行補成上述其中一種正常結果。

非 D0 Function 不得回應 OBFF／CPU Active 提示。對已能正常工作的 Function，提示用來安排活動：它沒有禁止原本已獲允許的 bus mastering 或中斷。規格建議平台開啟活動時窗後，至少 10 μs 再回到 Idle；同時也建議 Endpoint 不要假設時窗一定維持多久。這些規範強度不同於保證每次都有 10 μs 可用時間。

Base 6.0 §2.2.8.9，Table 2-34、Figures 2-59／2-60，pp.188–189；§6.19，Figure 6-18 Codes and Equivalent WAKE# Patterns，pp.787–790。

下一次遇到提示未生效，沿哪條路找？

先確認是哪一種提示，再把觀察接回它的主線。資料用途不符合預期，沿 TPH 的 PH、ST Mode、表格、Requester Enable 與目標／路徑能力查；服務需求不一致，沿 LTR 的 Support、Enable、訊息欄位、Switch 彙整與更新歷史查；活動提示沒出現，沿 OBFF 的實際訊號方式、出口 Variation、Link 狀態與接收 Port 查。最後才觀察平台策略與效益。

如果工具顯示「LTR 啟用，所以 Link 應進入 L1」，先回到兩個不同問題：LTR 描述中央資源服務需求；Link 的 ASPM 仍由其能力、控制與進出條件決定。如果工具顯示「ST=53h，所以資料已在 CPU 53 的 Cache」，目前只有提示值，還缺平台標籤對應與處理結果。把資料對回正式欄位，才能知道下一步要補哪一份證據。

版本與來源

本章以 PCI Express Base Specification Revision 6.0（6.0-1.0-PUB）為準，以上文件印刷頁與 PDF 檢視器頁碼相同。所有拓撲、暫存器讀值與延遲算例均為作者建立；未執行硬體設定或效能量測。本章沒有引用外部網站作技術依據。