PCIe Chapter 1：拓撲、交易角色與逐 Link 判讀

一張卡、Function 與 Link，要分別記錄什麼？

component 是單一實體封裝；Device 是同一階層中具有共同 Bus Number 與 Device Number 的 Function 集合。Function 是可在設定空間個別定址的功能，Port 則是元件連接 Link 的介面。

Link 包含相鄰兩端 Port 與其間的 Lane。每條 Lane 有一組傳送差動對及一組接收差動對；x4 表示四條 Lane 組成一條 Link。本例 A 的兩個 Function 共用一個 Port 與 LA，所以兩份設定資料不會增加外部連線數量。

圖上以 Endpoint A 簡稱提供端點功能的元件；規格的 Endpoint 是 Function 類型。實體卡片、封裝、設定對象與外部連線各有用途，分析時先寫出當前所指的對象。

Base 6.0 Terms and Acronyms：component、Device、Function、Lane、Link、Port，文件頁／PDF 頁 83–85、87、89；§1.2，pp.100–102。

Read 往返時，哪些角色保持不變？

Switch 的 Upstream Port 朝向 Root Complex，Downstream Port 朝向下游；這些名稱由拓撲決定。Requester 是發起交易的 Function，Completer 負責處理原 Request 並產生所需回覆。Transmitter 與 Receiver 則依某一次 Link 傳輸指定。

本例只沿同一個 Root Port 的下游路徑往返，沒有套用 Root Complex 跨 Root Port 轉送時的特殊規則。普通 Switch 的轉送與原始 Requester 身分須分開記錄。

Base 6.0 Terms and Acronyms，文件頁／PDF 頁 82–84、90、93–94；§1.3.1，pp.103–104；§1.3.3／Figure 1-3，p.107；§2.2.6.2，p.157。

同一個 Switch，為什麼需要三組 Link 資料？

Switch 內部的虛線是邏輯連接，沒有多出第四條外部 Link。調查 A 時，先取得 LA 的兩端；Switch Upstream Port 的 Link Status 描述 LR。若再串接第二層 Switch，則為新增的每條 Link 重新配對相鄰 Port。

Base 6.0 §1.2–§1.3，Figure 1-2 Example PCI Express Topology、Figure 1-3 Logical Block Diagram of a Switch，文件頁／PDF 頁 100–107。

卡 A 支援 64.0 GT/s，主機到卡 A 的路徑也一樣嗎？

先逐條 Link 比較兩端支援能力，再另外記錄目前速率與寬度。下面沿用同一拓撲；數值是假設兩端同步取得、且 Link 已建立的解碼結果，尚未提供 Target、訓練歷史或板上 Lane 接線資料。

先讀 LA：A 的 Port 與 Downstream Port A 都支援 64.0 GT/s，但目前共同運作於 16.0 GT/s、x4。這是能力與目前結果的比較；要解釋為什麼採用這個結果，還需要有效的控制設定、實際接線與訓練紀錄。

再沿路讀 LR：卡 A 與主機之間還經過 LR，其兩端最高支援 32.0 GT/s。資料經 Switch 在不同 Link 之間轉送，各條 Link 分別訓練與運作；整條路徑不會共同協商成一個速率。因此，Endpoint 的 64.0 GT/s 能力描述的是自己的 Port，不能代替上游 Link 的資料。

這張表也不能直接推算應用效能。資料量、其他分支流量、封包與傳輸開銷都會影響實際進度。這裡只先建立逐 Link 比較的方法。

1. 先定位能力欄位
   Figure 7-27／Table 7-23：讀 Max Link Speed 與 Maximum Link Width；Figure 7-38／Table 7-35：讀 Supported Link Speeds Vector。
2. 再定位目前結果
   Figure 7-29／Table 7-26：讀 Current Link Speed 與 Negotiated Link Width；Link 未建立時，這兩個值的定義有條件。
3. 把讀值放回同一條 Link
   先比相鄰兩端，再沿拓撲換到下一條 Link；設定、目前狀態與事件紀錄分欄保留。

以上是規格查閱順序，不是 Link Training 的執行時序。欄位位移與速率編碼的完整讀法可接回 Chapter 0 的查詢案例；本節將重點放在讀值描述哪一個 Port 與哪一條 Link。

拓撲上的 PCI／PCI-X Bridge 與 Switch 是同一種元件嗎？

不是。PCI Express to PCI/PCI-X Bridge 的用途，是連接 PCI Express fabric 與另一側的 PCI／PCI-X hierarchy。Switch 則以多個虛擬 PCI-to-PCI Bridge 的組合呈現，讓多個 PCIe Port 之間轉送交易。兩者的設定空間可能都呈現 Bridge 結構，因此看到 Bridge Header 時，仍要確認它的 Device/Port Type 與實際下游連線。

【模擬資料】若工具的拓撲圖在 PCIe Port 後面畫出 PCI Express to PCI/PCI-X Bridge，先辨認 Bridge 的 PCIe 側和 PCI／PCI-X 側，再選擇各自適用的協定與設定規則。不能把 PCI／PCI-X 的下游匯流排畫成另一條 PCIe Link，也不能只憑 Header Type 判定它是 Switch Downstream Port。此處只建立識別入口；Bridge 的完整轉換與例外需查對應規格。

Base 6.0 §§1.3.3、1.3.5，Figure 1-3，pp.106–108；Device/Port Type 見 §7.5.3.2。

兩個 Endpoint 在不同 Root Port 下，一定能互相存取嗎？

【模擬資料】假設 Endpoint A、B 分別位於同一個 Root Complex（RC）的不同 Root Port 下。先沿 Figure 1-2 找出兩個 hierarchy domain：若 A 要存取 B，路徑需要經過 RC。Base 6.0 §1.3.1 把跨 domain 的 peer-to-peer 路由列為可選且取決於實作；兩個 Endpoint 都能被列舉，仍不足以證明 RC 提供這條路徑。

RC 支援這種路由時，可以採不同設計：例如接手 Request、重新形成必要的封包並處理返回的 Completion，也可以在內部採用實體或虛擬 Switch。§1.3.1 一般允許 RC 在跨 domain 轉送時拆分封包；相對地，§1.3.3 不允許 Switch 把一個封包拆成更小的封包。兩者都須遵守各自適用的封包規則，不能把某一種實作當成所有平台的路徑。

拆分也有例外：RC 轉送 Deferrable Memory Write Request 時不得拆分；Vendor-Defined Message 若要拆分，受 128-byte 邊界條件限制。實際分析還須確認平台路由、各 Bridge Window、目標 BAR 與存取政策；本題只由拓撲確認需要經過 RC，無法保證 Request 會到達 B。

BAR

Base Address Register，基底位址暫存器

Base 6.0 §1.3、Figure 1-2，pp.102–103；§§1.3.1、1.3.3，pp.103–104、106–107；Deferrable Memory Write 的細節見 §6.32。

找到 Endpoint，為什麼有時沒有可配對的 Link？

前面案例的插卡是接在 Port 外部的 Endpoint。Figure 1-2 還有另一種位置：Root Complex Integrated Endpoint（RCiEP，整合在 Root Complex 內的 Endpoint）。它仍是一個 Function，支援 Configuration Request，但它位於 Root Complex 內部，不出現在 Root Port 對外的 hierarchy domain 或 Switch 中。

【模擬資料】假設某個可讀取設定空間的 Function，Device/Port Type 識別為 RCiEP。此時應查 RCiEP 適用的欄位；規格要求它不實作 Link Capabilities、Link Control、Link Status 及其 2 版 Register。不能只因讀不到這些 Register，就判斷有一條 Link 斷線。若 Function 是另一種 Device/Port Type，仍須依該類型查它的適用規則。

RCiEP 也可能與可選的 Root Complex Event Collector（RCEC，Root Complex 事件收集器）關聯。RCEC 處理相關 RCiEP 的錯誤與 PME（Power Management Event，電源管理事件）訊息；要確認關聯，查 RCEC 的 Endpoint Association Extended Capability。RCEC 是可選的，不能假設每個 RCiEP 都有一個。若某個 RCiEP 已關聯 RCEC，規格要求其 PME 和錯誤經由該 RCEC，且它最多只關聯一個 RCEC。

三種 Endpoint 都使用 Type 0 Configuration Header，但限制並不相同。讀 §1.3.2.1–§1.3.2.3 時，可先比對下表，再按實際欄位回到對應規則。

手機閱讀時，可左右滑動表格查看完整內容。

這些條件各自針對 Function 的角色與能力；不能把「某次 Request 使用的位址」當成該 Function 的完整位址能力，也不能把三種 Endpoint 的限制混成同一條。

Base 6.0 §1.3、Figure 1-2，pp.102–103；§§1.3.2.1–1.3.2.3、1.3.4，pp.104–106、108；Device/Port Type 的欄位見 §7.5.3.2。

想知道某個 Function 扮演什麼角色，應先讀哪兩種欄位？

選定 Function 後，先讀設定空間 0x0E 的 8-bit Header Type。低 7 bits 選出標頭布局，bit 7 指示可能有多個功能。再沿清單找到 PCI Express Capability（描述或控制能力的結構），讀起點加 0x02 的 16-bit Register，以 bits 7:4 的 Device/Port Type 確認角色。先選布局，再判斷角色。

Header 格式：0x80 & 0x7F = 0
Multi-Function Device：(0x80 & 0x80) >> 7 = 1
Device/Port Type：(PCIe_Capabilities & 0x00F0) >> 4

0x80 不能解成「Type 128」，也不能解成「已有 8 個 Function」。Multi-Function Device bit 為 1 表示裝置可能有多個 Function；實際有哪些 Function，仍須以發現結果為準。本例的 Endpoint A 指提供端點功能的元件；另假設其 Function 0 與 Function 1 都已被找到。

Device/Port Type 描述 Function 類型：RCiEP 使用 Type 0 Header，卻不得實作列出的 Link Capabilities／Control／Status 及其 2 Registers。讀 Data Link Layer Link Active 時也要先確認 Reporting Capable；固定讀零可能是未提供回報，不能直接當成連線失效。（Base 6.0 §1.3.2.3，pp.105–106；Table 7-19，pp.953–954；Tables 7-23、7-26，pp.969、979。）

目標是 0000:03:00.1，怎麼確認它位於哪條下游路徑？

本例在 Segment（匯流排的邏輯分組） 0000 中放置一個 Root Port 和一個有兩個 Downstream Port 的 Switch。Endpoint A 的兩個 Function 位於 Bus 03，Endpoint B 位於 Bus 04。下表是已完成配置的快照；本章先讀懂結果，Bus Number 的配置程序留到枚舉章節。

Secondary Bus Number 表示緊接在 Bridge 下游的 Bus，Subordinate Bus Number 則界定其下游 Bus Number 範圍的上限。目標 Bus 03 落在 Root Port 的 01–04、Upstream Port 的 02–04 及 Downstream Port A 的 03–03 範圍內；Downstream Port B 的範圍只有 04–04，因此不在本例通往目標的路徑上。

這裡用範圍核對已知拓樸，不代表範圍內每個號碼都必須有裝置。Bridge 自己的 BDF（Bus、Device、Function 識別號） 與它通往哪個 Bus 也要分開：02:01.0 本身位於 Bus 02，其 Secondary 為 03。本章不以 Primary Bus Number 推導 Bridge 自己的 BDF；Base 6.0 將該欄位保留作舊式相容用途，PCIe 通常不使用它。

BDF、Segment 與 Requester ID，各自保留了哪些資訊？

在本章的傳統編址下，BDF 包含 8-bit Bus Number、5-bit Device Number 與 3-bit Function Number。0000:03:00.1 的前四位是 Segment；同一個 Segment 內，後面的 03:00.1 才是 BDF。這些數字表示邏輯識別位置，不是實體插槽的編號。

另假設 Segment 0001 中也已發現 03:00.0。這是作者加入的第二個邏輯範圍，並非前一張表的下游分支；不能省略 Segment 後把兩筆紀錄合併。

當 0000:03:00.1 是要求的來源時，本例的 16-bit Requester ID（封包要求來源的識別號） 按以下方式組成：

Requester ID = (Bus << 8) | (Device << 3) | Function
             = (0x03 << 8) | (0x00 << 3) | 0x1
             = 0x0301

案例推演：0x0301 保留 BDF，沒有把 Segment 0000 編進這 16 bits。這項結論僅限 Requester ID（封包要求來源的識別號） 欄位，不能擴大成「所有 PCIe 封包都沒有 Segment 資訊」；Base 6.0 的部分 Flit Mode 封包另有相關欄位。本章也不把 BDF 當作永久硬體身分：若不同時間的紀錄使用了不同配置，僅憑 BDF 相同或不同，仍不足以判斷是不是同一個實體裝置。

下一步需要的觀察資料

只收到速率與寬度時，先補上 Port、直接對端、時間與欄位名稱；只收到工具的「Endpoint」標籤時，回到 Header Type 與 Device/Port Type 的讀值；只看到一段 Request 時，先標出 Link 與方向。這樣才能把後續訓練、錯誤與 Completion 資料接到同一個對象。

本章的模擬快照不提供完整訓練歷史與故障證據，也沒有用 BDF 保證永久硬體身分。