從系統全貌到第一次規格查詢

1. CPU 已經能存取記憶體，為什麼還需要 PCIe？

假設程式已在記憶體中準備好要傳送的資料。CPU 先安排工作，網路裝置再取得資料並執行傳送，軟體最後依裝置介面取得結果。PCIe（PCI Express，周邊互連） 提供元件交換要求與資料的共同方式；工作內容仍由裝置介面決定。

PCI Express，簡稱 PCIe（PCI Express，周邊互連），是連接系統與周邊裝置的互連架構。它定義如何發現與設定裝置，也定義元件之間如何以封包傳遞讀取、寫入及其他要求。至於「傳送哪一種網路封包」或「讀取哪一個儲存區塊」，還需要裝置本身的介面規格與驅動程式。

接下來沿這項工作分三層閱讀：先確認系統中的角色，再了解軟體查詢與配置的對象，最後追蹤要求如何到達對方。這一章先完成前兩層所需的背景，並用連線速率查詢把它們接起來。

2. 從 CPU 到裝置，途中有哪些角色？

沿開頭的圖往下看：Root Complex 負責把主機子系統接到 I/O 階層，Root Port 提供向外的連接介面，Switch 延伸下游路徑，Endpoint 提供裝置功能。先固定這組角色，後文再把觀察範圍縮到裝置端的設定資料。

I/O

Input/Output，輸入與輸出。在這裡指系統與周邊裝置之間的互動。

Port、Link 與 Lane

Port 是連接介面；Link 是相鄰兩端之間的連線；Lane 是構成 Link 的傳輸通道。每個 Lane 各有一組傳送與接收差動訊號對。x4 表示這條 Link 使用 4 個 Lane，不表示接了 4 個裝置。

圖中分開畫出的 CPU、Root Complex 與記憶體是邏輯角色。實際產品可以將其中幾個角色整合在同一顆晶片內；讀拓樸時，先追蹤它們的連接與職責，再另查產品的實體配置。

一張卡就是一個 Function 嗎？

不一定。軟體辨識與設定的基本對象是 Function。一個實體裝置可以提供多個 Function，各自有設定空間。傳統編址會用 Bus、Device、Function 三個號碼定位，常合稱 BDF（Bus、Device、Function 識別號）；如果系統有多個 Segment（匯流排的邏輯分組），還要先指定 Segment（匯流排的邏輯分組）。Segment 是由韌體管理、供 OS 使用的邏輯分組；不同 Segment 可以重複使用相同的 Bus 號碼，但同一個 Segment 內的 Bus 號碼必須唯一。它不是圖上額外插入的一個硬體元件。

BDF

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

3. 裝置接上以後，為什麼還不能立刻使用？

沿路徑找到裝置後，還要依序檢查連線、發現、資源配置與驅動準備。下表用開機時需要使用的裝置整理這些工作的依賴關係；實際平台可以分階段處理，韌體與 OS 也可能各完成一部分。

這裡的韌體是主機平台韌體，和網卡或 SSD 裡執行的裝置韌體不是同一個角色。UEFI（Unified Extensible Firmware Interface）定義 OS 與平台韌體之間的介面；UEFI 環境也提供 PCI 裝置存取服務。OS 是 Operating System，也就是作業系統。

交接時也不能假設「韌體早已把每個裝置都設好了」。Firmware 3.3 §3.5 要求韌體設定開機與主控台所需裝置，以及通往它們的完整路徑；同節另要求設定所有 Host Bridge。Host Bridge 是主機與 PCI 位址空間之間的橋接角色；不要把「所有 Host Bridge」讀成「所有 Endpoint」。

ACPI（Advanced Configuration and Power Interface）則提供硬體、軟體介面及資料結構，支援 OS 主導的組態與電源管理。它和 UEFI 各有工作範圍；後續課程會在需要查平台資源與控制權時，再展開相關表格與方法。

4. 讀設定空間、讀裝置暫存器與 DMA，有什麼不同？

DMA

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

軟體會在不同位置讀取或設定硬體欄位。先看這次操作的目的：查裝置能力時讀設定空間，操作裝置工作介面時使用其資源位址，裝置搬移資料時則使用準備好的記憶體映射。規格中的 register 指暫存器；它所屬的空間決定了查找方法。

BAR

Base Address Register，基底位址暫存器，位於設定空間，用來描述或設定裝置的位址資源。BAR 不是資料緩衝區本身。

MMIO

Memory-Mapped I/O，記憶體映射 I/O。CPU 透過被映射的位址存取裝置介面；這種存取不能一概視為普通 RAM 讀寫。

DMA

Direct Memory Access，直接記憶體存取。在本章的情境中，由裝置發起資料存取；CPU 仍需先安排工作、緩衝區與必要設定。

例如，讀取 Link Status 是在查設定空間；寫入網路裝置的工作暫存器，則可能走 BAR（描述裝置位址資源的基底位址暫存器） 所對應的 MMIO（以記憶體映射操作裝置） 範圍。裝置接著讀取傳送資料，是另一筆由裝置發起的存取。這三件事可能出現在同一項工作裡，但它們回答的問題不同。

MMIO

Memory-Mapped I/O，記憶體映射輸入輸出

本章只讀設定空間，不做資源配置或實際 DMA（由裝置直接存取記憶體）。CPU 看到的位址和裝置使用的位址也不保證相同；後續談資源配置與位址轉譯時，會把這個差別展開。

同一筆讀取，為什麼要分三層查？

接續前面的記憶體讀取：Endpoint 發出 Request，經過 Switch 到達目標，再等待 Completion（完成回覆）。Figure 1-4 把每個元件的收送功能分成三個邏輯層；Figure 1-5 則用封包流向說明各層如何接手。這是閱讀規格的分工，不要求硬體內部一定照圖切成三塊電路。

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

分析時可以先沿這條路線：確認正在觀察哪一條 Link → 看實體連線及 Link 狀態 → 檢查該段傳輸與 Flow Control → 最後配對 Request 和 Completion。某段 Link 的傳輸成功，只能支持該段的結果；要確認整筆讀取，還要看回覆是否真的到達 Requester。

Figure 1-5 是分層概念圖；實際封包如何承載與保護，還要依 Non-Flit Mode 或 Flit Mode 查對應章節，不能把圖中每個傳輸細節直接套到所有模式。

相鄰層還要交換資料邊界、傳送握手、電源與 Link 狀態等資訊；哪些訊息在兩個介面之間傳遞，可接著查 §1.5.4.4。這些是邏輯服務，內部介面的具體實作不由這張分層圖決定。

Base 6.0 §1.5、Figures 1-4／1-5，pp.109–110；§§1.5.1–1.5.4.4，pp.110–114。此處的讀取與 Switch 路徑為教學情境。

5. 打開規格後，怎麼知道該先看哪裡？

現在把問題限定為同一個裝置端的 Port：它宣告支援哪些速率，而相鄰 Link 目前使用哪個速率？先查能力，再查狀態。若要了解軟體設定的速率上限，還要另外查看控制欄位；這個延伸問題會在連線章處理。

PCIe 每個 Function 的設定空間擴充為 4096 bytes。前 256 bytes 保留 PCI 相容區域，其中有設定標頭與傳統 Capability（描述或控制能力的結構） 清單；後面的區域可放 PCI Express Extended Capabilities。PCI Express Capability（描述或控制能力的結構） 本身位於前 256 bytes 的清單裡，不要因為名稱帶有 PCI Express，就直接跳去找 Extended Capability。

Capability 是一組用來描述或控制特定能力的結構。它在設定空間中的起點不必固定；軟體要先沿指標找到它，再加上結構內的相對位移。因此，規格標示的「Offset 2Ch」還不是本例的最終存取位置。

這裡先看 Figure 7-38，再回到 Figure 7-29，因為我們先問能力，再問狀態。Figure 幫你找到結構與位元位置；Table 和相鄰條文則說明編碼、適用對象及例外。只看到圖上的欄位名稱，還不足以判斷讀值。

6. 完整案例：支援哪些速率，現在又跑多少？

表格顯示的是按照指定寬度取得的數值。若改成逐 byte 顯示，0x7001 在 offset 0x40 的 byte 是 0x01，下一個 byte 才是 0x70；不要把數值左側的十六進位數字當成最低位址的 byte。

第一步：我真的可以從這個標頭找 Capability 嗎？

先用 Header Type 的低 7 bits 判斷標頭形式：0x00 & 0x7F = 0，所以使用 Figure 7-10 的 Type 0 配置。bit 7 另有多功能裝置的意義，不應混進標頭類型。接著查 Status 的 bit 4：(0x0010 & 0x0010) != 0，確認 Capabilities List 為 1。

現在依 §7.5.1.1.11，讀取 offset 0x34 的 Capabilities Pointer。規格要求軟體在使用這個指標前遮掉最低兩個 bits，因此本例得到 0x40 & 0xFC = 0x40。這個值告訴我們第一個結構從哪裡開始，還沒有告訴我們它是 PCIe Capability。

第二步：第一個 Capability 不是我要的，接著去哪裡？

在 0x40 讀到 0x7001。低 8 bits 的 ID 是 0x01，本例對照 Figure 7-18／Table 7-14，得知這是 Power Management（電源管理）Capability。高 8 bits 的 Next Pointer 是 0x70，所以接著移到 0x70。不需要為了通過這個節點，就把它的所有電源欄位讀完。

在 0x70 讀到 0x0010。依 Figure 7-22／Table 7-18，ID 0x10 表示 PCI Express Capability；高 8 bits 為 0，表示此結構沒有下一個清單節點。我們已找到目標，記下結構起點 cap_base = 0x70。

1. 設定標頭
   0x34 → 0x40
   找到清單入口
2. PM Capability
   ID 0x01 / Next 0x70
   依 Next Pointer 往下找
3. PCIe Capability
   ID 0x10 / Next 0
   記下起點 0x70

這條路徑是本例的安排。其他裝置的 Capability 起點與順序可以不同，不能把 0x70 寫成通用常數。如果清單走到結尾仍未找到目標，或出現循環等不合理資料，就沒有足夠依據繼續套用這份結構。這是讀取資料時的檢查原則，不代表所有「讀不到」都能解成不支援。

第三步：找到 PCIe Capability，就能直接讀任何欄位嗎？

還要核對版本與適用對象。在 cap_base + 0x02 = 0x72 讀到 0x0002。依 Figure 7-23／Table 7-19，bits 3:0 為 2，表示 Capability Version 2；bits 7:4 為 0，表示 PCI Express Endpoint，與本例假設一致。

這裡的 Version 2 是這個 Capability 結構的版本，不表示裝置是「PCIe Gen2」，也不是在宣告支援 Base 2.0 的全部功能。相同地，本章拿 Base 6.0 當參考文件，不代表這個例子一定支援 64 GT/s。

Base 6.0 §7.5.3 會依元件類型說明哪些暫存器適用。RCiEP 就不能照本例套用一般外部 Link 的欄位。另外，Version 2 本身不保證較早期硬體已實作 Link Capabilities 2 的速率向量；§7.5.3.18 的實作說明（p.1000）另外交代舊硬體的判讀方式。本例假設該欄位已實作，後面也會取得非零的向量值，因此不需要在此展開舊硬體分支。

第四步：怎麼從結構起點算出讀取位置？

Figure 7-21 把 Link Capabilities 2 放在相對位移 0x2C，Link Status（連線狀態暫存器） 放在 0x12。兩個值都要加到剛找到的 cap_base：

Link Capabilities 2：0x70 + 0x2C = 0x9C（讀 32 bits）
Link Status        ：0x70 + 0x12 = 0x82（讀 16 bits）

0x70 + 0x0C = 0x7C 是另一個 Register：Link Capabilities。名稱相近，位置卻不同。本題要列出支援速率集合，因此使用 Link Capabilities 2 裡的 Supported Link Speeds Vector。

第五步：如何把能力讀值轉成支援速率？

在 0x9C 讀到 0x0180001E。Figure 7-38／Table 7-35 把 Supported Link Speeds Vector 放在整個 Register 的 bits 7:1。先遮掉其他 bits，再把欄位移到最低位置：

保留 bits 7:1：0x0180001E & 0x000000FE = 0x0000001E
右移 1 bit   ：0x0000001E >> 1 = 0x0F = 0001111b

右移後，表格所說的「欄位內 bit 0」才對應 0x0F 的最低位元。它原本位於 Register 的 bit 1。這兩種編號差 1，讀表時要先看清楚表格是在說整個 Register，還是欄位內的位置。

因此，這個 Port 宣告支援 2.5、5.0、8.0 與 16.0 GT/s。在 PCIe 規格中，GT/s 以每個 Lane、每個方向的編碼位元傳輸速率計算；它不是應用程式每秒取得的 GB 數。若要估算有效資料量，還要考慮 Lane 數、編碼方式、封包開銷與實際工作負載，本題先不做這個換算。

第六步：目前速率是另一個 bitmap 嗎？

不是。Link Status 的 bits 3:0 是 Current Link Speed，儲存的是編碼值。本例在 0x82 讀到 0x0043，所以：

目前速率代碼：0x0043 & 0x000F = 3
協商後寬度  ：(0x0043 & 0x03F0) >> 4 = 4

Table 7-26 把速率代碼 3 對應到 Supported Link Speeds Vector 的欄位內 bit 2，也就是 8.0 GT/s；寬度值 4 表示 x4。不能把代碼 3 當成 3 GT/s，也不能把它當成同時設定了兩個支援位元。

同一張表也指出，Link 未建立時，Current Link Speed 與 Negotiated Link Width 的值是 undefined，不能用來判斷目前有效連線。本例已把 Link 建立且穩定列為前提；單靠這個 0x0043 並不能自行證明前提成立。這個 16-bit 假設值中，bits 15:10 都是 0；但不能因此把 bit 13 的 Data Link Layer Link Active 為 0 解讀成 Link 已中斷，因為該 bit 是否實作還取決於元件的回報能力。實際查詢仍須依適用狀態確認連線。

第七步：現在可以下什麼結論？

案例推演：在本例前提成立時，所查 Port 宣告支援 2.5／5.0／8.0／16.0 GT/s，而其 Link 目前以 8.0 GT/s、x4 運作。這個讀值尚未說明為什麼沒有使用 16.0 GT/s。

還需要另一端的能力、相關控制設定與連線狀態，才能繼續分析。x4 是目前協商的寬度，並不能證明最大支援寬度也是 x4。也不能只憑這些欄位就宣稱裝置故障、平台已啟用所有功能，或應用程式一定能達到某個吞吐量。這些都是不同的問題，需要各自的證據。

7. 把完整查詢帶到不同條件

把剛才的查詢接成一條完整路徑：選定 Function，取得清單入口，找到能力結構，核對版本與類型，再分別解碼支援集合與目前狀態。以下延伸說明沿用這條路徑，只改動一項條件，指出應重新檢查的位置。

8. 接下來先補哪一塊？

下一章會沿著拓樸往下看：實體裝置、Function 與 Bridge 如何對應，BDF 又能辨識到什麼範圍。接著在 Chapter 2 建立設定空間的完整地圖，再追問：「這個 BDF 一開始是怎麼被發現的？BAR 的位址又是誰分配的？」

完整安排見課程閱讀路線。現有課程涵蓋 Chapter 0–37；可以從 Chapter 1 開始，依主題逐步深入。全規格的逐節核對仍在進行，已有章節不代表所有細節都已完成教學。

版本與來源

外部來源查核日期：2026-10-19。規格頁碼會隨版本改變，本章的 Figure、Table 與頁碼只對應上述指定版本。原始 PDF 不隨教材散布；自製關係圖、示例讀值與情境推演均已在相鄰內容標示。