拓撲、交易角色與逐 Link 判讀

一張卡、多個 Function，究竟共用了什麼？

Function 是軟體可在 Configuration Space（設定空間）中個別定址的功能。一個 Device 是一組具有共同 Bus Number 與 Device Number 的 Function；實體卡則是組裝單位，可能裝有一個或多個 component。這三種對象的數量各有意義，需要分開記錄。

回到卡 A：作者假設同一個 Device 有 Function 0 與 Function 1，兩者共用圖中的 Endpoint Port。軟體分別讀兩個 Function 的設定空間，並沒有因此多出第二條實體 Link。讀某個 Link 欄位前，先確認它描述個別 Function，還是這個共用 Port。

Lane（單一組雙向傳輸路徑）內的傳送與接收各用一組差動對。四條 Lane 組成 x4 Link 時，兩個方向都有四組差動對；它們屬於同一條 Link。圖中的 Endpoint A 是提供端點功能的元件簡稱；規格的 Endpoint 則是 Function 類型。這裡先理解連接單位，Lane Number、Lane Reversal 與寬度訓練留到對應章節。

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

資料往回傳時，Requester 和 Port 的名稱會改變嗎？

先以 Root Complex（連接主機與 I/O 階層的根部）為方向基準。Switch 的 Upstream Port 朝向根部，Downstream Port 朝向下游；封包改變方向時，Port 的名稱仍由拓撲決定。

接著追蹤卡 A 的 Function 1 發出的 Memory Read（讀取 Memory Space 的要求）。Requester 是發起這筆交易的 Function；Completer 負責處理 Request，並在需要時產生 Completion。Transmitter 與 Receiver 則描述某一次 Link 傳輸的傳送端與接收端。下面沿往返路徑逐段對照。

圖中 Switch 的 Downstream Port A，接收 Request 時是 Receiver，送回 Completion 時是 Transmitter。它一直是朝下游的那個 Port。原始 Requester（這筆 Read 的發起者）也一直是 A 的 Function 1，即使 Function 1 正在接收回覆。

本例只沿同一條 Root Port 路徑往返，不經過 Root Complex 跨 Root Port 的轉送。後者有另外的規則，不能把本例的 Switch 轉送方式直接套用。

Switch 為什麼會在設定空間裡變成多個 Bridge？

回到開頭的圖。Root Port 在本章的設定模型中呈現為一個 PCI-to-PCI Bridge，也就是連接上、下游匯流排的橋接功能。Switch 則呈現為多個邏輯 Bridge：Upstream Port 接到內部邏輯 Bus，各個 Downstream Port 再接出外部 Link。軟體可以沿這些關係找到下游。

PCI-to-PCI Bridge 是設定模型裡連接上、下游匯流排的橋接功能。Upstream 指朝向 Root Complex 的方向；Downstream 指離開 Root Complex、朝階層下游的方向。Switch 的 internal bus 是邏輯表示，不是把外部 PCIe Link 改成共享的平行匯流排。

先從上方一路往下讀：Root Port 的下一層是 Bus 01；到了 Switch Upstream Port，下一層才是內部 Bus 02；兩個 Downstream Port 再分別接到 Bus 03 和 Bus 04。所以 02:01.0 是橋接功能本身的位置，03:00.1 才是它下游的目標 Function。

依 Base 6.0 §7.1，本模型的 Switch 內部 Bus 只能出現代表 Downstream Port 的 Bridge，不能把一般 Type 0 Endpoint 畫在 Bus 02，與這些 Bridge 並列。圖上的卡 A、卡 B 因而放在各 Downstream Port 的下一層。

Switch 接了三條 Link，應該在哪裡查狀態？

先把開頭拓撲的三條外部實線列出來。每列配對相鄰的兩端 Port，這一對才是同一條 Link 的 Link Partner（直接相連的對端）。Switch 的 Upstream Port 與 Downstream Port A 雖在同一個 component 內，卻各自面向不同的外部 Link。

要調查卡 A 的連線，先取得 LA 兩端的資料。Switch Upstream Port 的 Link Status 描述 LR；那份資料可以補充上游路徑，不能用來填入 LA 的另一端。連線訓練、Data Link 狀態與錯誤也依各自作用範圍記錄。

如果中間再加一層 Switch 呢？

條件變更：把卡 A 原本直接接到的 LA，改成接到第二個 Switch 的 Upstream Port，再由第二個 Switch 的一個 Downstream Port 接回卡 A。這條分支就有三條外部 Link：Root Port 到第一個 Switch、兩個 Switch 之間，以及第二個 Switch 到 A。逐條列出相鄰 Port 後，每條 Link 都有自己的能力與狀態；Switch 內部邏輯 Bus 不另外算成外部 Link。

Base 6.0 §1.2 PCI Express Link，文件頁／PDF 頁 100–102；§1.3 PCI Express Fabric Topology／Figure 1-2，pp.102–103；§1.3.3／Figure 1-3，pp.106–107。多一層 Switch 是作者的拓撲推演。

拓撲上的 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。

只知道 BDF，怎麼查它是 Endpoint 還是 Port？

Device/Port Type 是 Function 類型欄位。先以 Figure 1-2 的系統圖認識角色，再依 Figure 7-23／Table 7-19 核對軟體讀到的類型，才知道後續哪些欄位適用。Type 0 Header 也可能是 Root Complex Integrated Endpoint（整合在根部內的端點）或 Root Complex Event Collector（收集整合端點事件的功能），不能把 Type 0 一律解讀成外部插卡。

先用 BDF 選定 02:01.0 的設定空間，再讀兩組欄位。Header Type（決定標頭布局並指示多功能的欄位） 的低位元決定要採用哪一種標頭布局；PCI Express Capability 內的 Device/Port Type 才區分 Root Port、Switch Port 與 Endpoint。下面依這個順序讀取。

1. 先分清 Header 的兩個欄位
   Figure 7-8 與 Table 7-7：低 7 bits 是 Header Layout，bit 7 是 Multi-Function Device。
2. 找到 PCIe 類型欄位
   Figure 7-21：從已找到的 Capability 起點加 0x02，定位 16-bit PCI Express Capabilities Register。
3. 解碼角色
   Figure 7-23 定位 bits 7:4，Table 7-19 查 Device/Port Type 編碼與適用 Header。

以 Downstream A 為例，0x01 & 0x7F = 1 先選出 Type 1 Header。設讀到的 16-bit Capabilities Register 為 cap，則 (cap & 0x00F0) >> 4 = 6，才得到 Switch Downstream Port。cap & 0x000F = 2 則表示 Capability Version 2，與 Type 6 是不同欄位，也不是連線的 PCIe 世代。

Header Type 為 0x80，就代表有 8 個 Function 嗎？

不是。先做 0x80 & 0x7F = 0，可知 Header Layout 仍是 Type 0；bit 7 為 1，只表示這個 Device 可能含有多個 Function，允許軟體探查其他 Function，並未回報數量。卡 A 的 Function 1 存在，是題目已確認的另一筆資料，不能只從 0x80 推出。

Table 7-7 也規定，若此 bit 為 0，軟體不得探查 Function 0 以外的 Function，除非 ARI、SR-IOV 等其他機制另有指示。本章已排除這些機制；不能為了練習，就把「一律掃完 0–7」當成通用規則。

ARI

Alternative Routing-ID Interpretation，替代路由識別碼解讀

SR-IOV

Single Root I/O Virtualization，單根I/O虛擬化

確認類型後，為什麼還要看欄位適用性？

以 Data Link Layer Link Active（回報 Data Link 是否處於 DL_Active 的位元）為例：先讀 Link Capabilities 的 Data Link Layer Link Active Reporting Capable，確認這個 Port 是否提供回報。未實作回報時，Link Status 的對應位元固定讀為零；這個零值不能拿來判定 Link 失效。對端點所在的 LA，應先查看 Downstream Port A 的有效回報，再依需要補上端點與協定紀錄。

若讀到的是 Root Complex Integrated Endpoint，就先回到 §1.3.2.3：這種 Function 沒有外部 Link，規格禁止它實作 Link Capabilities、Link Control、Link Status 及其對應的 2 Registers。同一份解碼表用在不同 Function 上，必須先選出實際適用的欄位。

Base 6.0 §7.5.3.2／Figure 7-23／Table 7-19，文件頁／PDF 頁 953–954；§7.5.3.6／Table 7-23，p.969；§7.5.3.8／Table 7-26，p.979；§1.3.2.3 Root Complex Integrated Endpoint Rules，pp.105–106。

卡 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。

03:00.1 的每一段究竟選了誰？

Bus、Device、Function 合稱 BDF。在傳統編址下，Bus Number 有 8 bits，Device Number 有 5 bits，Function Number 有 3 bits。先選定 PCI Segment Group（本章簡稱 Segment），再選其中的 Bus，接著選 Device 與 Function，才能定位本章的設定對象。

可編碼的位置也不能當成實體連接數量。依本章未使用 ARI／FPB 的普通 Link 規則，對端使用 Device 0；Switch 的 Downstream Port 則可在內部 Bus 上使用其他 Device Number。因此圖中的 Endpoint 與 Switch Upstream Port 都是 Device 00，而兩個 Downstream Port 分別是 Device 01、02。（Base 6.0 §7.3.1，p.911。）

ARI

Alternative Routing-ID Interpretation，替代路由識別碼解讀

FPB

Flattening Portal Bridge，扁平化入口橋接器

前綴 0000: 是本章用來標出 Segment 的寫法。它提供查詢所需的範圍，並不是一個額外的 Bridge，也不能拿來推算 CPU 插槽數量。

另一個 Segment 也有 03:00.0，會衝突嗎？

新增教學假設：系統另有 Segment 0001，其中一條 Root Port 路徑接到 0001:03:00.0。這與圖中的 0000:03:00.0 是兩個不同的設定對象；只有省略 Segment，才會看起來相同。紀錄資料時，應把 Segment 與 BDF 一起保留。

反過來，同一份穩定快照、同一個 Segment 裡，03:00.0 和 03:00.1 具有相同的 Bus 與 Device，指向同一個 Device 的兩個 Function。至於它們在實體上裝在哪張卡，還需要實體配置的資訊；本例是題目另行給定卡 A 的組裝方式。

要找 Bus 03，為什麼沿著 Downstream A？

角色已經查清楚，接著要確認橋接關係。對本章採用的一般 Type 1 Bridge 而言，Secondary Bus Number 指出緊接在下游的 Bus；Subordinate Bus Number 則標出其下游階層涵蓋的最高 Bus Number。兩個值一起讀，才分得清「下一層是哪個 Bus」與「整個下游範圍到哪裡」。

閱讀順序是：先由 Header Layout 確認 Type 1，再看 Type 1 Configuration Space Header 的 Figure 7-14，找到 0x19 與 0x1A，最後讀 §7.5.1.3.3 與 §7.5.1.3.4 的欄位定義。兩個 offset 都從該 Function 的設定空間起點計算，各讀 8 bits；它們不以 PCIe Capability 為起點。

案例推演：目標 0000:03:00.1 位於 Segment 0000 的 Bus 03。Bus 03 落在 Root Port 的 01–04 範圍，也落在 Upstream Port 的 02–04 範圍；到了兩個 Downstream Port，只有 A 的 03–03 範圍符合。因此圖中的分支是 A，最後仍須以 Device 00、Function 1 選定對象。

這裡練習的是把已知快照與欄位對上，沒有執行 Configuration Write。Bus Number 怎麼分配、尚未配置時如何搜尋，以及 Configuration Request 如何轉送，分別留到枚舉與交易章。也不要把這張 Bus 範圍表當成 Memory BAR 的位址窗口；它們處理的識別與資源不同。

封包裡的 Requester ID 和 BDF 有什麼關係？

當某個 Function 發出交易要求時，Requester ID 用來識別要求者。本章的傳統格式把 Bus、Device、Function 放進 16 bits；因此，先理解 BDF，後面閱讀交易封包才知道這個欄位在指誰。封包如何配對要求與回覆，會在 Chapter 5 再談。

Requester ID = (Bus << 8) | (Device << 3) | Function
03:00.1 → (0x03 << 8) | (0x00 << 3) | 1 = 0x0301
02:02.0 → (0x02 << 8) | (0x02 << 3) | 0 = 0x0210

案例推演：要把 0x0210 還原，先取 (id >> 8) & 0xFF = 0x02 得到 Bus，再取 (id >> 3) & 0x1F = 0x02 得到 Device，最後取 id & 0x07 = 0 得到 Function。它對應圖中的 Downstream B，而不是 Bus 02 上的 Function 0x10。

這個算式把要求來源的 BDF 編成識別號。封包經過 Downstream B 時，要求者仍是原先發出要求的 Function；Switch 轉送時必須保留 Transaction ID。因此要分別記錄「誰發出要求」與「要求經過哪些 Bridge」。

此外，0000:03:00.0 與 0001:03:00.0 的傳統 16-bit 編碼都會是 0x0300。因此只拿到這 16 bits，仍缺少判定 Segment 的情境。這不等於宣稱封包完全沒有 Segment 資訊：PCIe 6.0 的部分 Flit Mode 格式另有 Segment 欄位，不能與這個 16-bit 欄位混為一談。

記住 BDF，下一次開機就能認出同一張卡嗎？

跨次開機比對硬體時，先保留每筆紀錄所屬的配置快照。BDF 描述目前設定拓樸中的位置；Bus Number 由配置流程建立，同一硬體可能因拓樸或分配方式改變而取得不同位置。若要追蹤實體個體，還要取得可信的裝置身分或平台位置資訊。

若要跨開機追蹤實體裝置，就需要另外取得可信的裝置身分或平台位置資訊。Vendor ID、Device ID 描述廠商與裝置類型，不能單獨充當每一件產品的唯一序號。這類長期識別需求與本章的「選定目前哪個 Function」不同，不能用一組 BDF 同時回答。

資料還不齊時，先把觀察位置補完整

讀者收到的報告未必同時包含拓撲、對端與完整欄位。先保留原始讀值與時間，再補上它所描述的對象，下一個人才能沿同一條路徑繼續分析。

本章沒有提供完整訓練歷史、錯誤時間線或裝置內部處理紀錄。這些資料要在對應情境中另外取得，不能從一張拓撲或一次設定快照補成既定事實。

知道查誰之後，下一步看什麼？

現在可以先用 Segment 與 BDF 選定 Function，再用 Header Layout 與 Device/Port Type 判斷該怎麼讀它。Chapter 2 將整理設定空間的完整查詢方法：傳統與 Extended Capability 從哪裡開始、指標怎麼走，以及欄位寬度、版本與存取屬性如何影響解讀。

Chapter 2 接續處理設定查詢，再走到枚舉與資源配置。需要深入同一條 Link 的訓練與狀態，可讀 Link 建立與可靠傳遞；Request 與 Completion 的詳細關係則接到 交易章。完整主題與各章狀態見 課程閱讀路線。

版本與來源

主要依據是讀者提供的 PCI Express Base Specification Revision 6.0（6.0-1.0-PUB）與 PCI Firmware Specification Revision 3.3。Firmware 3.3 的參考文件列的是 Base 5.0（§1.2，p.7），本章沒有把它當成 Base 6.0 的配套版本；實際欄位均以 Base 6.0 為準。

本章先使用 Base 6.0 的架構、角色與 Register 規則；Firmware 3.3 僅用於後半部 Segment 的補充，不是架構主線的依據。各節來源中的頁碼同時表示文件印刷頁與 PDF 檢視器頁，這份文件的兩者相同。

各節另列 BDF、Bridge Bus 與識別號所用的必要條文。自製圖表與假設讀值均為教學設計；沒有用這些資料宣稱實機發生了特定故障。原始 PDF 不隨教材公開。架構、角色與逐 Link 比較的查核日期：2026-10-24。