讀請(qǐng)求的數(shù)據(jù)返回（Data Return for Read Requests）

?針對(duì)內(nèi)存讀取請(qǐng)求的單個(gè)完成可能提供少于請(qǐng)求的全部數(shù)據(jù)量，只要對(duì)于給定請(qǐng)求的所有完成在組合起來時(shí)返回了讀取請(qǐng)求中請(qǐng)求的數(shù)據(jù)量。

?不同請(qǐng)求的完成不能合并。

?I/O和Configuration read必須在一個(gè)Completion內(nèi)完成。

?Completion的Completion Status只對(duì)應(yīng)于與該Completion返回的數(shù)據(jù)相關(guān)的狀態(tài)

?Completion的狀態(tài)不是success Completion將終止單個(gè)Read Request的Completions

?在這種情況下，Length字段中的值是未定義的，必須被Receiver忽略

?Completion不能包含超過Max_Payload_Size允許的數(shù)據(jù)

?接收方必須檢查是否違反此規(guī)則。

注:這只是適用于所有帶數(shù)據(jù)有效負(fù)載的tlp的規(guī)則的一個(gè)特例

?內(nèi)存讀取請(qǐng)求可以通過一個(gè)或在某些情況下多個(gè)完成來完成

?讀取完成邊界（Read Completion Boundary，RCB）決定了完成者被允許將單個(gè)讀取請(qǐng)求的響應(yīng)分成多個(gè)完成的自然對(duì)齊地址邊界。

?對(duì)于根復(fù)合體，RCB為64字節(jié)或128字節(jié)。

注意:SW和EP可以實(shí)現(xiàn)相應(yīng)的命令位，該命令位可以由系統(tǒng)軟件設(shè)置，以指示根復(fù)合體的RCB值，允許網(wǎng)橋或端點(diǎn)在根復(fù)合體的RCB為128字節(jié)時(shí)優(yōu)化其行為。

?對(duì)于所有其他系統(tǒng)元素，RCB是128字節(jié)。

?對(duì)于沒有以RCB字節(jié)的整數(shù)倍跨越自然對(duì)齊的地址邊界的請(qǐng)求，Completion必須包含請(qǐng)求中指定的所有數(shù)據(jù)。

?在RCB字節(jié)的整數(shù)倍的地址邊界上的請(qǐng)求允許使用多個(gè)Completion完成，但遵循以下規(guī)則:

?第一個(gè)Completion必須從請(qǐng)求中指定的地址開始，如果成功，必須在以下其中一個(gè)結(jié)束:

?滿足整個(gè)請(qǐng)求的地址。

?請(qǐng)求開始和結(jié)束之間的地址邊界，位于RCB字節(jié)的整數(shù)倍

?如果最后的完成是成功的，它必須在滿足整個(gè)請(qǐng)求的地址結(jié)束

?在第一個(gè)和最后一個(gè)Completion之間的所有Completion (但不包括第一個(gè)和最后一個(gè)Completion)，其長(zhǎng)度必須是RCB字節(jié)長(zhǎng)度的整數(shù)倍

?接收方可以選擇檢查是否違反RCB。如果實(shí)現(xiàn)此檢查的Receiver確定Completion違反了此規(guī)則，則必須將Completion作為Malformed TLP處理。

?這是一個(gè)與接收端口相關(guān)的報(bào)告錯(cuò)誤(見6.2節(jié))。

?單個(gè)讀請(qǐng)求的多個(gè)內(nèi)存讀完成必須按遞增的地址順序返回?cái)?shù)據(jù)。

?如果單個(gè)讀請(qǐng)求的所有內(nèi)存讀完成狀態(tài)都是成功完成狀態(tài)，則它們的有效負(fù)載之和必須等于請(qǐng)求的大小。

?對(duì)于每個(gè)內(nèi)存讀完成，字節(jié)計(jì)數(shù)字段必須指示完成請(qǐng)求所需的剩余字節(jié)數(shù)，包括完成時(shí)返回的字節(jié)數(shù)，除非設(shè)置了BCM位（PCI-x）。

?完成一次Memory Read Request需要的總字節(jié)數(shù)計(jì)算如表2-38所示。

? ?如果內(nèi)存讀請(qǐng)求使用多個(gè)Completions完成，每個(gè)連續(xù)的Completion的字節(jié)計(jì)數(shù)值是由前一個(gè)Completion指示的值減去前一個(gè)Completion返回的字節(jié)數(shù)。

?完成數(shù)據(jù)區(qū)域從請(qǐng)求指定的DW地址開始。在第一個(gè)或唯一一個(gè)Completion的第一個(gè)或唯一一個(gè)Data DW中，只有在Request中的first BE字段中配置為有效的字節(jié)包含有效數(shù)據(jù)。在Request的First BE字段中配置為無效的字節(jié)將返回未定義的內(nèi)容。

?在最后一次成功完成的Last Data DW中，只有在Request的last BE字段中配置為有效的字節(jié)包含有效數(shù)據(jù)。在請(qǐng)求的Last BE字段中配置為無效的字節(jié)將返回未定義的內(nèi)容。

?所有完成數(shù)據(jù)字節(jié)，包括那些內(nèi)容未定義的字節(jié)，在所有的CRC（循環(huán)冗余校驗(yàn)）計(jì)算中都會(huì)被包含。

?舉例如圖2-44所示。該示例假設(shè)返回一個(gè)Completion TLP。

BCM位永遠(yuǎn)不會(huì)在讀取完成的后續(xù)數(shù)據(jù)包中設(shè)置，因此這些后續(xù)數(shù)據(jù)包中的字節(jié)計(jì)數(shù)字段將始終指示每個(gè)實(shí)例中剩余的字節(jié)計(jì)數(shù)。因此，請(qǐng)求者可以使用這些數(shù)據(jù)包中的字節(jié)計(jì)數(shù)字段來確定是否缺少讀取完成的其他數(shù)據(jù)包。

PCI Express Completer永遠(yuǎn)不會(huì)設(shè)置BCM位。

通過Length和Byte Enable字段計(jì)算字節(jié)計(jì)數(shù)

?對(duì)于所有的Memory Read Completion, Lower Address字段必須表示與Completion一起返回的使能的首字節(jié)數(shù)據(jù)的字節(jié)地址的低位。

?對(duì)于第一個(gè)(或唯一的)Completion, Completer可以從Request地址的最低有效的5位與2位字節(jié)級(jí)地址連接產(chǎn)生該字段，如表2-39所示。

?對(duì)于任何后續(xù)的Completions, Lower Address字段將始終為零，除了由具有64字節(jié)RCB（讀取完成邊界）值的根復(fù)合體生成的Completions。在這種情況下，Lower Address字段的最低有效位將始終為零，而Lower Address字段的最高有效位將根據(jù)64字節(jié)數(shù)據(jù)負(fù)載的對(duì)齊方式進(jìn)行切換。

?當(dāng)生成的狀態(tài)不是成功完成的讀取完成時(shí)：

?沒有數(shù)據(jù)包含在完成

?Cpl(或CplLk)編碼被使用，而不是CplD(或CplDLk)

?此完成是請(qǐng)求的最終完成

?? ??Completer不得為此請(qǐng)求傳輸額外的完成

?? ??示例:完成者將請(qǐng)求分成四個(gè)部分進(jìn)行;第二個(gè)Completion的Completion狀態(tài)為“Completion中止Completion狀態(tài)”; Completer終止了對(duì)該請(qǐng)求的服務(wù)，并且沒有傳輸剩余的兩次Completion。

?字節(jié)計(jì)數(shù)字段必須表明完成請(qǐng)求需要的剩余的字節(jié)數(shù) (如果完成狀態(tài)是成功完成)

?低地址字段必須指示如果完成狀態(tài)是成功完成，將與完成一起返回的使能的首字節(jié)數(shù)據(jù)的字節(jié)地址的低位。

Completion Handling Rules

?當(dāng)設(shè)備接收到與該設(shè)備發(fā)出的任何未完成請(qǐng)求的事務(wù)ID不匹配的完成時(shí)，該完成稱為“意外完成”（Unexpected Completion，UC）。

?如果接收到的完成與未完成請(qǐng)求的事務(wù)ID匹配，但在某些其他方面與相應(yīng)的請(qǐng)求不匹配(例如，屬性，流量類，字節(jié)計(jì)數(shù)，低地址等問題)，強(qiáng)烈建議接收方將完成作為畸形TLP處理。

?完成者不能檢查完成中的IDO屬性(屬性位2)，因?yàn)檎?qǐng)求者不需要將請(qǐng)求中的IDO值復(fù)制到完成中，如2.2.6.4和2.2.9節(jié)所述。

?然而，如果Completion以其他方式正確形成，則允許Receiver將Completion處理為Unexpected Completion。

?當(dāng)交換機(jī)的入口端口接收到無法轉(zhuǎn)發(fā)的完成時(shí)，該入口端口必須將該完成作為意外完成處理（UC）。這包括對(duì)以下目標(biāo)的完成:

?與上游端口關(guān)聯(lián)的設(shè)備中不存在的功能，

?與上游端口關(guān)聯(lián)的總線上不存在的設(shè)備，

?Switch內(nèi)部結(jié)構(gòu)中不存在的設(shè)備或功能，或

?上游端口的總線號(hào)范圍內(nèi)但未被任何下游端口聲稱的總線號(hào)。

?接收一個(gè)意外完成是一個(gè)錯(cuò)誤，必須根據(jù)以下規(guī)則處理:

?接收意外完成的組件必須丟棄完成。

?意外完成是與接收端口相關(guān)聯(lián)的報(bào)告錯(cuò)誤 (見6.2節(jié))。

?完成狀態(tài)不是成功完成或配置請(qǐng)求重試狀態(tài)(僅響應(yīng)配置請(qǐng)求)的完成必須導(dǎo)致請(qǐng)求者:

?釋放與請(qǐng)求相關(guān)的完成緩沖區(qū)空間和其他資源。

?通過request -specific機(jī)制處理錯(cuò)誤(參見6.2.3.2.5節(jié))。

如果在FLR啟動(dòng)和目標(biāo)函數(shù)完成FLR之間到達(dá)完成，則允許將完成作為意外完成處理或被靜默丟棄(在流控制積分更新之后)，而不將其記錄或標(biāo)記為錯(cuò)誤。一旦FLR完成，收到的與在FLR之前發(fā)出的請(qǐng)求相對(duì)應(yīng)的Completion必須作為UC處理，除非該函數(shù)已重新啟用以發(fā)出請(qǐng)求。

?RC完成的處理與配置請(qǐng)求重試狀態(tài)的配置請(qǐng)求是具體實(shí)現(xiàn)的，除了系統(tǒng)重置后的時(shí)期(見章節(jié)6.6)。對(duì)于支持CRS軟件可見性的RC，適用以下規(guī)則:

?如果CRS軟件可見性未啟用，RC必須重新發(fā)出配置請(qǐng)求作為一個(gè)新的請(qǐng)求。

?如果CRS軟件可見性是啟用:

?? ?對(duì)于包含設(shè)備功能配置空間頭的Vendor ID字段的兩個(gè)字節(jié)的配置讀取請(qǐng)求，RC必須通過返回Vendor ID字段的讀取數(shù)據(jù)值0001h和請(qǐng)求中包含的任何其他字節(jié)的所有' 1 '來完成對(duì)主機(jī)的請(qǐng)求。這個(gè)讀數(shù)據(jù)值是專門為PCI-SIG保留的，不對(duì)應(yīng)于任何分配的Vendor ID。

?對(duì)于配置寫請(qǐng)求或任何其他配置讀請(qǐng)求，RC必須重新發(fā)出配置請(qǐng)求作為一個(gè)新的請(qǐng)求。

RC的實(shí)現(xiàn)可以選擇限制配置請(qǐng)求/ CRS完成狀態(tài)循環(huán)的數(shù)量，然后再確定請(qǐng)求的目標(biāo)有問題并采取適當(dāng)?shù)男袆?dòng)，例如，將發(fā)送給主機(jī)的請(qǐng)求作為失敗的事務(wù)完成。

CRS軟件可見性可以通過根控制寄存器中的CRS軟件可見性啟用位(見章節(jié)7.5.3.12)來在單個(gè)根端口的基礎(chǔ)上控制根復(fù)核行為。或者，根復(fù)合行為可以通過根復(fù)合寄存器塊(RCRB)控制寄存器中的CRS軟件可見性使能位進(jìn)行管理，如章節(jié)7.9.7.4所述，允許一個(gè)或多個(gè)根端口或rciep的行為由單個(gè)使能位控制。對(duì)于這種替代情況，每個(gè)根端口或RCiEP通過根復(fù)合鏈路聲明能力(見章節(jié)7.9.8)中的RCRB頭關(guān)聯(lián)聲明其與特定Enable位的關(guān)聯(lián)。每個(gè)根端口或RCiEP最多允許被一個(gè)Enable位控制。因此，例如，禁止根端口的根控制寄存器包含Enable位來聲明與RCRB頭關(guān)聯(lián)的RCRB頭在其RCRB頭能力中也包含Enable位。根端口或RCRB報(bào)頭能力中的Enable位的存在由相應(yīng)的CRS軟件可見性位

?對(duì)于非配置請(qǐng)求的請(qǐng)求，使用配置請(qǐng)求重試狀態(tài)的完成是非法的。接收方可以選擇將這些違規(guī)行為報(bào)告為畸形tlp。

?這是一個(gè)與接收端口相關(guān)的報(bào)告錯(cuò)誤(見6.2節(jié))。

?具有保留完成狀態(tài)值的完成被視為完成狀態(tài)為不支持的請(qǐng)求(UR)。

?完成狀態(tài)為Unsupported Request或Completer Abort的完成使用傳統(tǒng)的PCI報(bào)告機(jī)制進(jìn)行報(bào)告(參見章節(jié)7.5.1.1.4)。

?請(qǐng)注意，觸發(fā)生成這樣一個(gè)完成的錯(cuò)誤條件是Completer報(bào)告如6.2節(jié)所述。

?當(dāng)接收到的讀取完成或原子操作完成的狀態(tài)不是成功完成時(shí)：

?沒有數(shù)據(jù)包含在完成

?Cpl(或CplLk)編碼被使用，而不是CplD (CplDLk)

?此完成是請(qǐng)求的最終完成

?請(qǐng)求者必須考慮請(qǐng)求終止，而不是期望額外的完成

?先前收到的部分完成的處理是特定于實(shí)現(xiàn)的

示例:請(qǐng)求方收到了一個(gè)128字節(jié)的Read Request的32字節(jié)的Read數(shù)據(jù)，然后它收到一個(gè)Completion，并帶有Completer Abort Completion Status。然后，請(qǐng)求者必須釋放為該特定讀請(qǐng)求分配的內(nèi)部資源。