要求到了接收端，什麼時候才算完成？
要求到了接收端，什麼時候才算完成？
選擇步驟後，圖中對應的元件與下方解說會加上重點標示。完整圖與所有解說會持續顯示；也可用方向鍵切換步驟。
圖中兩條分支代表不同要求種類。先把其中一種要求走完，不把兩種操作接成同一次交易。
作者依 Base 6.0 繪製的教學示意；省略與本章無關的交換。
前章已能定位 TLP（Transaction Layer Packet，交易層封包）的欄位。現在沿接收端追蹤：先檢查封包，再決定目標是否接受。AtomicOp（Atomic Operation，原子操作）與 DMWr（Deferrable Memory Write，可延後的記憶體寫入）都有完成回覆，但各自保證的操作與回覆狀態不同。
先看封包處理的入口
鏈結層已驗過的封包，也可能在交易層出現格式或語意錯誤。
從 Figure 2-81 的 Start 往下讀，忽略 Reserved 欄位的值，按各欄位規則檢查格式，再分成要求與完成回覆；Request 接到 Figure 2-83。
Base 6.0 §2.3，pp.204–206，Figure 2-81，p.206；§2.3.1，Figure 2-83，p.213。
正常操作按要求種類執行
兩者均須先確認路徑與端點的相應能力，不由封包有編碼推定全系統支援。
CAS 只在比較相等時交換，兩種比較結果都回傳原值；DMWr 遇到暫時條件，可用 RRS 回覆並保持目標不變。下方各有完整帶讀。
Base 6.0 §6.15，pp.772–775；§6.32，pp.857–860。
由回覆結果接續後續工作
Completion Timeout（完成回覆逾時）的範圍不是正常服務延遲，不能拿它估算一般效能。
要求者須按操作種類解讀 Completion。CAS 回傳原值才能判斷是否交換；若逾時，尚未取得原操作是否執行的確定結果。
Base 6.0 §2.8，p.259。
要求到了接收端，還要經過哪些判斷？
前章已說明如何辨認封包結構。本章從接收端開始：Data Link Layer 已檢查傳輸完整性，接著由 Transaction Layer 按封包格式和要求種類處理。先看 Figure 2-81（p.206）的 Start，再沿符合格式的分支往下，最後分成 Request 與 Completion。
閱讀第一個判斷框時，留意 Ignoring Reserved Fields。接收端必須忽略 Reserved 欄位的值；封包中出現非零的 Reserved 值，並不能直接當成 Malformed TLP。至於有明確限制的格式欄位，仍須按各自的必要或可選檢查規則處理。這裡指標為 Reserved 的欄位，不包含 Fmt／Type 等有效欄位中的 Reserved 編碼；後者仍按適用模式的規則判斷。已判定為 Malformed 的 TLP 必須丟棄。
- TLP
- Transaction Layer Packet，交易層封包
確認是 Request 後，再接 Figure 2-83（p.213）：先判斷要求種類是否受支援，接著依該種類的規則執行。圖中虛線框是可選的 programming model 檢查；它允許特定裝置將違反自身存取限制的要求以 Completer Abort 處理，並非每筆要求都要依序走過的階段。這張圖提供分流，真正決定 CAS 或 DMWr 結果的細節，仍要回到 §6.15 或 §6.32。
規格閱讀：§2.3 Handling of Received TLPs，pp.204–206，Figure 2-81 Flowchart for Handling of Received TLPs，p.206；§2.3.1 Request Handling Rules，pp.208–213，Figure 2-83 Flowchart for Handling of Received Request，p.213。文件頁與 PDF 頁相同。
封包格式錯誤時，接收端會怎麼處理 credit？
接續 Figure 2-81：接收端已從 Data Link Layer 收到 TLP，現在檢查交易層格式。所有被判定為 Malformed 的 TLP 都必須丟棄。接著讀 §2.3 旁邊的文字，才能知道 Receiver Flow Control（接收端流量控制）資訊是否更新；不能只看圖上的「Discard TLP」。
【模擬資料】以下資料為教學用途建立，不代表特定硬體或平台。兩筆互不相依的封包都已被判定為 Malformed。假設接收端已有各筆封包所需的 VC（Virtual Channel，虛擬通道）與緩衝區觀察資料。
手機閱讀時，表格可以左右滑動。
| 接收端觀察 | 丟棄與 Flow Control 處理 |
|---|---|
| 無法確定應釋放哪個 buffer，或 TLP 對應未初始化／停用的 VC | 必須丟棄，且不得更新接收端的 Flow Control 資訊。 |
| 其他 Malformed TLP | 仍必須丟棄；接收端可以選擇不更新 Flow Control 資訊。 |
- VC
- Virtual Channel，虛擬通道
第二列的「可以選擇不更新」不等於必須更新，也不等於每種裝置都選擇不更新。這些規則描述接收端追蹤資訊，不能只憑一次丟棄就推論實體 buffer 的全部狀態或傳送端已收到新的 credit。正常額度更新流程見 Chapter 17。
判定格式時，也要分清 Reserved 欄位和保留的編碼。在 Non-Flit Mode，若 Extended Fmt Field Supported=1，使用 Reserved 的 Fmt／Type 編碼須按 Malformed 處理；若該能力位為 0，對 Fmt[2]=1 的接收處理是 undefined（未定義）。Fmt[2]=0 且 Type 值未定義時，則須按 Malformed 處理。這與「接收端忽略 Reserved 欄位的值」是不同規則；Prefix 的位元拆解見 Chapter 14。
PCI Express Base 6.0 §2.3、Figure 2-81，文件頁／PDF 頁 204–206；§7.5.3.15、Table 7-33，p.992。個別格式是否需要檢查，仍應查其對應條文。
要更新共用計數器或比較後交換，先確認哪些能力？
AtomicOp（Atomic Operation，原子操作）在一次交易中讀取目標、依操作更新目標，再回傳原值。這段讀改寫不可被其他對該位置的存取拆開觀察。先用 §6.15 確認操作語意，再沿實際路徑查看各元件。
| 操作 | Request 提供的資料 | 正常完成時的動作與回傳值 |
|---|---|---|
| FetchAdd | 一個加數 | 寫回相加結果，回傳原值 |
| Swap | 一個交換值 | 寫入交換值，回傳原值 |
| CAS（Compare and Swap，比較後交換） | 先放比較值，再放交換值 | 相等才寫入交換值；相等或不相等，都回傳原值 |
【模擬資料】以下資料為教學用途建立，不代表特定硬體或平台。本例由 Endpoint 03:00.0 經一個 Switch，向 Root Port 所服務的主記憶體發出 32-bit CAS。要求先進入 Switch Downstream Port 02:01.0，再從 Upstream Port 01:00.0 送往 Root Port 00:01.0。兩條 Link 都已可正常傳輸，目標為平台允許 AtomicOp 存取的位置 0x80001FFC。
| 沿本例路徑查詢 | 應核對的正式欄位 | 本例假設與用途 |
|---|---|---|
| 來源 Endpoint 03:00.0 | Device Control 2：AtomicOp Requester Enable，bit 6；Command：Bus Master Enable | 兩者均為 1，且已由裝置介面確認具有發起能力。Requester Enable 可寫入，仍不代表具有這項能力。 |
| Switch 路徑 | Device Capabilities 2：AtomicOp Routing Supported，bit 6；實際出口的 Device Control 2：AtomicOp Egress Blocking，bit 7 | 路徑相關 Ports 的 Routing Supported 為 1；本次出口是 Upstream Port 01:00.0，其 Egress Blocking 為 0。 |
| 目標 Root Port 00:01.0 | Device Capabilities 2：32-bit AtomicOp Completer Supported，bit 7 | 為 1，並已確認該主記憶體位置的存取權限與平台設定。這裡查的是完成端支援，不以 Routing Supported 代替。 |
Table 7-33 的這些能力欄位為 RO；Table 7-34 的兩個 AtomicOp 控制欄位在適用元件上為 RW。所有 offset 都相對於 PCI Express Capability：Device Capabilities 2 在 +24h，Device Control 2 在 +28h。請先走訪 Capability，再加相對位移。Base 6.0 沒有定義統一的 Requester 能力探索介面；也明確允許沒有發起能力的元件將 Requester Enable 做成可寫，因此讀回 1 仍須搭配裝置資料。
規格閱讀：§6.15 Atomic Operations (AtomicOps)，pp.772–773；§6.15.2 AtomicOp Transaction Protocol Summary，pp.774–775；§6.15.3.1 Root Ports with AtomicOp Completer Capabilities，p.775；§7.5.3.15 Device Capabilities 2 Register (Offset 24h)，Table 7-33，p.990；§7.5.3.16 Device Control 2 Register (Offset 28h)，Table 7-34，p.996。
CAS 回覆成功，目標就一定被換掉了嗎？
不一定。CAS（比較後交換）只在原值等於比較值時寫入交換值；比較不相等也是正常執行結果。要求者要把回傳的原值與自己送出的比較值相比，才能知道這次是否交換。Successful Completion（SC，交易正常完成）本身沒有另設「比較相等」的旗標。
【模擬資料】以下資料為教學用途建立，不代表特定硬體或平台。沿用前節路徑，兩條 Link 均使用 Non-Flit Mode。本節左右案例各自從目標原值 7 開始，沒有其他處理器或裝置同時更新它；兩例不是連續交易。封包格式合法、EP=0，TH=0，不使用 Prefix，並假設存取過程沒有錯誤。
本次 Request 的 Requester ID 為 0300h，Tag 為 2Ah，TC=0；目標地址為 0x80001FFC。正常交換的案例送出比較值 7、交換值 9，Request Data 依序包含這兩個 32-bit 運算值。此處列的是解碼後的數值，不預設目標記憶體採用哪種 endian 格式。
- TC
- Traffic Class，流量類別
| 同一組前提下的兩個獨立案例 | 比較相等並交換 | 比較不相等 |
|---|---|---|
| 執行前的原值 | 7 | 7 |
| Request Data：比較值／交換值 | 7／9 | 5／9 |
| 執行後目標值 | 9 | 7，保持原值 |
| Completion Status | SC，000b | SC，000b |
| Completion Data | 原值 7 | 原值 7 |
| 要求者如何判斷？ | 回傳 7 等於送出的比較值 7，這次完成交換 | 回傳 7 不等於送出的比較值 5，這次沒有交換 |
Request 帶 8 bytes，為什麼目標只占 4 bytes？
查 Table 2-15（p.162）時，先選 CAS 這一列，再看 32 Bits 這一欄，得到 Request Length=2 DW，也就是兩個運算值共 8 bytes。目標的讀取、可能的寫回，以及回傳原值，各自仍是單一 32-bit 值。DW（Double Word）為 4 bytes。
接著讀 p.163 的自然對齊與 4-KB 邊界規則。本例地址可被 4 整除，目標範圍為 0x80001FFC–0x80001FFF，剛好占該 4-KB 頁面最後 4 bytes，沒有跨頁。若直接把 Request 的 8-byte Data 長度加到地址上，就會錯把這筆 CAS 判成跨界。CAS 的兩個運算值共同作用於同一個目標，不是寫入兩個相鄰位置。
再看 Completion，哪些欄位要按 AtomicOp 解讀？
用 Figure 2-73（p.196）定位回覆的 Requester ID 與 Tag，核對仍是 0300h／2Ah；配對方法已在 Chapter 5 帶讀。這次成功回覆是 CplD，Length=1 DW，Byte Count=4，Data 為原值 7。Request 帶 2 DW，並不要求 Completion 也回傳 2 DW。
§2.2.9.1 特別規定：AtomicOp Completion 的 Byte Count 等於運算值大小，Lower Address 為 Reserved。因此即使地址低 7 bits 為 7Ch，也不拿 Lower Address 重建本次結果。Non-Flit Mode 的 AtomicOp Request 在 TH=0 時，其 First／Last DW BE 也為 Reserved；本例不套用 Memory Read 的有效 Byte 或 Split Completion 計算。
規格串接：§6.15，pp.772–773 確認 CAS 語意；§2.2.7.1 Non-Flit Mode，Table 2-15 Length Field Values for AtomicOp Requests，pp.162–163 確認兩個運算值、對齊與目標範圍；§2.2.9.1 Completion Rules for Non-Flit Mode，Figure 2-73 Completion Header Format - Non-Flit Mode，p.196，及 Table 2-37 Completion Status Field Values，p.197，確認回覆欄位與 SC 編碼。文件頁與 PDF 頁相同。
本例使用 Non-Flit 欄位布局。Flit Mode 下仍依 §6.15 解讀比較、交換與回傳原值，但封包要改用對應的 Header Base／OHC 規則，不能照搬本例的欄位位置；兩種布局的閱讀方法見 Chapter 14。
- OHC
- Orthogonal Header Content，Flit模式的擴充標頭內容
DMWr 的「重試」與 CAS 的「比較不相等」有何不同？
DMWr（Deferrable Memory Write，可由完成端延後接受的非 Posted 寫入）適合共享工作佇列。它有必要的 Completion，但不是用來讀改寫一個比較值。遇到暫時條件時，完成端可回覆 Request Retry Status（RRS，要求重試狀態），並保持目標不變。
【模擬資料】以下資料為教學用途建立，不代表特定硬體或平台。假設另一組路徑與完成端已支援並啟用 DMWr，來源的 DMWr Requester Enable 也為 1。第一次提交工作項目時，共享佇列暫時無法接受，完成端因此回覆 RRS，沒有加入這項工作。要求者稍後可依實作政策重新提交；若新要求成功，才按該佇列的介面接續追蹤工作。成功接受提交與工作內容已執行完畢，仍是不同時點。
| 觀察到的結果 | 完成端這次做了什麼？ | 要求者接下來的依據 |
|---|---|---|
| CAS：SC，但回傳值不等於比較值 | 已完成比較，沒有交換 | 這次交易已有確定結果；後續是否再競爭更新，由同步協定決定 |
| DMWr：因暫時條件回覆 RRS | 未接受這次更新，目標保持不變 | 允許重送，但不要求一定重送；何時重送、是否修改內容由實作決定 |
| 普通 Posted Memory Write | 沒有一般 Completion 可用來表達暫時拒收 | 是否已接受或完成裝置工作，須依裝置介面或其他同步機制確認 |
這裡的 RRS 是 §6.32 明確允許的暫時拒收結果，不是錯誤。完成端也不得假設要求者一定會再送一次。DMWr 的原子更新、大小、路由、Egress Blocking 與錯誤條件另有規則，不能只因為看見同一個 Status 名稱，就套用 Configuration Request 的重試流程。
規格閱讀：§6.32 Deferrable Memory Write，pp.857–860；p.858 為暫時條件、RRS 與目標保持規則，p.860 為 Requester Enable 及是否重送的規則。Table 2-37，p.197，將 RRS 編為 010b。
如果 CAS 逾時，能把同一筆要求再送一次嗎？
先確認是哪一層的重送。Data Link Replay 由相鄰兩端保護同一次傳輸，接收端會避免重複交付；要求者重新產生一筆 CAS，則會再執行一次操作。兩者的區別見 Chapter 8。
Completion Timeout（完成回覆逾時）是要求者等不到必要回覆時記錄的結果。即使沿用前面的 CAS，也有兩種不同時間線：Request 尚未到達目標；或目標已完成比較與交換，但 Completion 沒有被要求者收到。只有要求者的 Timeout，無法分辨這兩條時間線。
因此，原要求的結果尚未確認時，恢復程式不能把它直接當成「沒有執行」再送一次。應先保存原 Request、Requester ID／Tag、沿途 Trace 與錯誤資料，再依平台或裝置的同步與恢復協定決定後續動作。稍後讀到的記憶體值也可能經過其他處理器或裝置更新，不能替代遺失的 Completion。這是由回覆機制推得的分析邊界；Base 6.0 沒有提供通用的軟體重試演算法。
正常收到 SC 時，也要區分操作種類：CAS 回傳原值，供要求者判斷是否交換；Memory Read 若有多筆 Completion，則須收齊必要回覆才完成。§2.8 的逾時範圍用於偵測異常，不能拿來估計一般服務延遲。若後續 Request 必須等 AtomicOp 被完成端觀察到，§6.15.2 要求先等 AtomicOp Completion，再發出後續 Request。
本章的原子保證針對目標位置的操作。對支援 AtomicOp 的 Root Port，§6.15.3.1 另外要求：代辦主記憶體存取時，須與處理器或裝置對該範圍的存取維持原子性，並保留 CPU 原子操作的原子性。整個同步演算法、其他位置的資料發布順序，以及軟體使用的記憶體屬性，仍須搭配平台與 CPU 文件；不能只靠一次 CAS 推出全部條件都已滿足。
規格閱讀：§2.8 Completion Timeout Mechanism，pp.259–260；§6.15.2，p.774；§6.15.3.1，p.775。Replay 與軟體重試的區別在此作跨章節應用，不重複展開其狀態機。
Locked Transactions 是同一種原子機制嗎？
Locked Transactions（鎖定交易）在 §6.5.1 有不同限制：只有 Root Complex 可發起，PCI Express Endpoint 不得支援鎖定存取，新軟體也不得使用會對 I/O 裝置產生鎖定存取的指令。它不能當成某個 AtomicOp 不支援時，任意改用的替代方案。
版本與來源
本章以 PCI Express Base Specification Revision 6.0（6.0-1.0-PUB）為技術依據，文件印刷頁與 PDF 檢視器頁碼相同。圖與數值案例由作者依已標示的規則建立，並非規格原圖或實機量測。本輪集中帶讀 CAS 回覆與 DMWr 重試；完整 AtomicOp 格式、DMWr 能力和所有錯誤條件仍需後續深入。
完整來源定位與用途
- §2.3 Handling of Received TLPs，pp.204–206；Figure 2-81 Flowchart for Handling of Received TLPs，p.206：接收入口、Reserved 欄位與 Request／Completion 分流。
- §2.3.1 Request Handling Rules，pp.208–213；Figure 2-83 Flowchart for Handling of Received Request，p.213：要求支援、可選 programming model 檢查與回覆。
- §2.2.7.1 Non-Flit Mode，pp.162–163；Table 2-15 Length Field Values for AtomicOp Requests，p.162：運算值、Length、自然對齊及 CAS 目標範圍。
- §2.2.9.1 Completion Rules for Non-Flit Mode，pp.196–198；Figure 2-73 Completion Header Format - Non-Flit Mode，p.196；Table 2-37 Completion Status Field Values，p.197：AtomicOp Byte Count、Reserved Lower Address、Requester ID／Tag 與狀態編碼。
- §6.15 Atomic Operations (AtomicOps)，pp.772–773；§6.15.2 AtomicOp Transaction Protocol Summary，pp.774–775；§6.15.3.1 Root Ports with AtomicOp Completer Capabilities，p.775：操作語意、路徑、等待與主記憶體原子性。
- §7.5.3.15 Device Capabilities 2 Register (Offset 24h)，Table 7-33，p.990；§7.5.3.16 Device Control 2 Register (Offset 28h)，Table 7-34，p.996：AtomicOp 支援、啟用與阻擋欄位的作用範圍及屬性。
- §6.32 Deferrable Memory Write，pp.857–860：暫時 RRS、目標保持、啟用與要求者重送選擇。
- §2.8 Completion Timeout Mechanism，pp.259–260：未收到完整回覆的範圍與服務延遲限制；§6.5.1 Introduction，p.718：Locked Transactions 的發起與支援限制。