文章目錄
- 3.6 Data Integrity Mechansisms
- 3.6.1 Introduction
- 3.6.2 LCRC, Sequence Number, and Retry Management (TLP Transmitter)
- 3.6.2.1 LCRC and Sequence Number Rules (TLP Transmitter)
- 3.6.2.2 Handling of Received DLLPs
- 3.6.3 LCRC and Sequence Number (TLP Receiver)
- 3.6.3.1 LCRC and Sequence Number Rules (TLP Receiver)
3.6 Data Integrity Mechansisms
3.6.1 Introduction
事務層向數據鏈路層提供TLP邊界信息。這允許數據鏈路層將TLP Sequence Number和LCRC應用于TLP的錯誤檢測。接收數據鏈路層通過檢查TLP Sequence Number,LCRC和來自接收物理層的任何錯誤指示來驗證接收到的TLP。如果這些錯誤中的任何一個在TLP中,則使用數據鏈路層重試進行恢復。
Figure 3-14顯示了添加了TLP Sequence Number和LCRC的TLP格式。
在支持協議復用的端口上,在 Symbol+0中包含非零值的數據包,bit 7:4是PMUX數據包。對于TLP,這些位必須為0000b。有關詳細信息,請參見Appendix G。
在不支持協議多路復用的端口上,Symbol+0 的bit 7:4被保留。
Figure 3-14 TLP with LCRC and TLP Sequence Number Applied
3.6.2 LCRC, Sequence Number, and Retry Management (TLP Transmitter)
數據鏈路層通過添加TLP Sequence Number和LCRC來確保每個TLP傳輸的完整性。TLP存儲在一個重試緩沖區中,除非從其他組件收到了肯定的接收確認,否則數據鏈路層會嘗試重傳。如果重復嘗試發送TLP失敗,則發送器認為鏈路不能正確運行,于是指示物理層重新訓練鏈路。如果鏈路重新訓練失敗,則物理層將指示鏈路不再可用,從而導致DLCMSM轉移到 DLnactive 狀態。
概念上的 "counters"和“'flags"來描述TLP LCRC和TLP Sequence Number 以及支持數據鏈路層重試的機制。此描述不暗示也不要求特定的實現,僅用于闡明要求。
3.6.2.1 LCRC and Sequence Number Rules (TLP Transmitter)
以下計數器和計時器用于解釋本節中的其余規則:
- 使用了兩個12-bit的計數器:
- NEXT_TRANSMIT_SEQ-存儲用于TLP的Sequence Number。該計數器為每個將發送的新的TLP分配序列號,每個新TLP其值加1,計數到4095時重新返回0。
- 在DL_Inactive 狀態設置為0。
- ACKD_SEQ-存儲最近收到的Ack或Nak DLLP中的序列號(即AckNak_Seq_Num字段的值,NEXT_TRANSMIT_SEQ
與此值的差值的模表示有多少TLP未被響應)。- 在DL_Inactive狀態設置為FFFh。
- NEXT_TRANSMIT_SEQ-存儲用于TLP的Sequence Number。該計數器為每個將發送的新的TLP分配序列號,每個新TLP其值加1,計數到4095時重新返回0。
- 使用了一個2-bit的計數器:
- REPLAY_NUM-計算重試緩沖區已重新發送該TLP的次數。當REPLAY_NUM從2’b11翻轉到2’b00時會觸發一次物理層的鏈路重新訓練,在重新訓練之后,再次嘗試重發該TLP。無論何時收到ACK,此計數器也會復位為2’b00。
- 在DL_Inactive 狀態設置為0。
- REPLAY_NUM-計算重試緩沖區已重新發送該TLP的次數。當REPLAY_NUM從2’b11翻轉到2’b00時會觸發一次物理層的鏈路重新訓練,在重新訓練之后,再次嘗試重發該TLP。無論何時收到ACK,此計數器也會復位為2’b00。
- 使用了下述計時器:
- REPLAY_TIMER-根據以下規則計算需要重試的時間。或者理解為用來度量從發出TLP到收到對應的ACK或NAK DLLP的時間。
- 從任何TLP傳輸或重傳的最后一個符號開始。
- 對于每個重試,在發送要重傳的第一個TLP的最后一個符號時,重置并重新啟動REPLAY_TIMER。
- 在還有更多未確認的TLP要發送時,當且僅當接收到的Ack DLLP確認重試緩沖區中的某些TLP時,對于收到的每個Ack DLLP重置并重新啟動 REPLAY_TIMER。
- 注意:這樣可確保僅在TLP正在傳遞過程時重置REPLAY_TIMER。
- 當收到Nak、或當REPLAY_TIMER到期,需要重置REPLAY_TIMER直到重發條件滿足。
- 鏈路重新訓練期間REPLAY_TIMER值不增加(即當LTSSM處于 Recovery或Configuration狀態時保持其值)。請參閱Section 4.2.5.3和Section 4.2.5.4。
- 如果支持協議多路復用,則可以選擇在接收PMUX數據包期間不增加REPLAY_TIMER的值(PMUX請參閱Appendix G)。
- 如果以Nak響應的TLP都解決了,則REPLAY_TIMER重置并保持。
- REPLAY_TIMER-根據以下規則計算需要重試的時間。或者理解為用來度量從發出TLP到收到對應的ACK或NAK DLLP的時間。
以下規則描述了TLP在傳遞到物理層之前如何準備進行傳輸:
- 事務層在傳輸TLP時會向數據鏈路層指示TLP的開始和結束。
- 數據鏈路層將TLP視為“黑盒”,并且不處理或修改TLP的內容。 - 當數據鏈路層從事務層的發送端接受每個TLP時,會為其分配一個12位序列號。
- 在從事務層接受TLP時,通過以下方式將數據包序列號應用于TLP:
- 把12-bit的NEXT_TRANSMIT_SEQ添加到TLP的頭部。
- 在序列號之前添加4bit保留位(請參見Figure 3-15)。
- 如果(NEXT_TRANSMIT_SEQ – ACKD_SEQ) mod 4096 >= 2048為真,發送器必須停止從事務層接受TLP,直到等式不再成立為止。這還會報告一個致命的、無法修正的數據鏈路層協議錯誤。
- 在將NEXT_TRANSMIT_SEQ應用于從事務層的發送方接受的TLP之后,NEXT_TRANSMIT_SEQ遞增(除非TLP為空):NEXT_TRANSMITSEQ:=(NEXTTRANSMITSEQ+1)mod4096
- 在從事務層接受TLP時,通過以下方式將數據包序列號應用于TLP:
Figure 3-15 TLP Following Application of TLP Sequence Number and Reserved Bits
-
數據鏈路層使用32-bit LCRC保護TLP數據完整性。
-
使用以下機制計算LCRC值(see Figure 3-16):
-
多項式系數為04C11DB7h。
-
seed值為 FFFFFFFh
-
序列號和TLP用于計算LCRC(see Figure 3-15)。
-
LCRC計算從byte 0的bit 0(TLP序列號的bit 8)開始,并從每個連續字節的bit0到bit7進行。
- 請注意,LCRC計算使用TLP的所有位,而與字段類型無關,包括保留字段。
-
補全LCRC計算的其余部分,并將補全后的結果位映射到32位LCRC字段中,如Table 3-6所示。
-
Table 3-6 Mapping of Bits into LCRC Field
◆ -從事務層收到這些字節之后,將32位LCRC字段附加到TLP(請參見Figure 3-16)。
為了支持TLP的直通路由,允許發送器修改發送的TLP,以指示接收器必須忽略該TLP(“作廢”TLP)。
-
允許發送器作廢正在發送的TLP;為了防止誤解或損壞TLP,發送器必須執行以下操作:
-
當物理層使用128b/130b編碼時,發送TLP的所有DW(請參閱Section 4.2.2.3.1)。
-
使用計算出的LCRC值的其余部分并且不進行反轉(正常使用時LCRC值會邏輯反轉)。
-
向物理層指示該TLP無效。
-
-
完成此操作后,發送器不會遞增NEXT_TRANSMIT_SEQ。
以下規則描述了數據鏈路層重試緩沖區的操作,必要時將從中重新發送TLP:
- 傳輸的TLP副本必須存儲在數據鏈路層重試緩沖區中,但無效的TLP除外。
當由于接收到Nak或由于REPLAY_TIMER到期而觸發重發時,以下規則描述了必須遵循的操作順序:
-
如果已確認所有傳輸的TLP(Retry Buffer為空),請終止重發,否則繼續。
-
REPLAY_NUM遞增。當通過接收確認重試緩沖區中某些TLP的Nak觸發重發時,將重置REPLAY_NUM。然后允許(但不是必需)遞增。
-
如果REPLAY_NUM從11b翻轉到00b,發送器將向物理層發送信號以重新訓練鏈路,并在重新進行重發之前等待重新訓練的完成。這會報告與端口相關的錯誤(請參見Section6.2)。
Note:除非物理層報告 Physical LinkUp=0b(導致數據鏈路控制和管理狀態機轉換到DL_Inactive狀態),否則此操作不會重置數據鏈路層狀態(包括重試緩沖區的內容)。
-
如果REPLAY_NUM不能從11b翻轉到00b,請繼續重發。
-
-
阻止從事務層接受新的TLP。
-
完成當前正在傳輸的任何TLP的傳輸。
-
重傳響應了Nak的TLP,從最早響應Nak的TLP開始,以最初傳輸順序發送。
-
發送第一個要重傳的TLP的最后一個符號時,重置并重新啟動REPLAY_TIMER。
-
一旦所有響應Nak的TLP被重新發送,請返回正常操作。
-
如果在重發期間收到任何Ack或Nak DLLP,則允許發送器完成重發而無需考慮Ack或Nak DLLP,或者跳過任何新確認的TLP。
- 發送器一旦開始重新發送TLP,則在所有情況下都必須完成該TLP的發送。
-
重發期間收到的Ack和Nak DLLP必須進行處理,并且可能會折疊。
-
如果收到多個Ack,則僅應考慮指定最新序列號值的Ack-指定較早序列號值的Ack實際上會“折疊”到該Ack 中。
-
在重發期間,會收到Nak,接著是一個Ack,該Ack指定了后面的序列號-Ack取代了Nak,而Nak被忽略。
注意:由于發送器的流控制選通邏輯已在接收器中為重試緩沖區中的所有條目分配了空間,因此無需進一步進行流控制同步。
-
-
-
事務層重新啟用TLP的接收。
重發可以通過REPLAY_TIMER到期或接收到Nak來啟動。以下規則涵蓋REPLAY_TIMER的有效期:
TLP傳輸過程中有一個重傳(Replay)機制,當經過“一段時間"后,發送端仍然沒有收到接收端返回的Ack或者Nak信息,就會觸發重新發送TLP。這里的"一段時間"有個專業名字叫做"REPLAY_TIMER"。在PCle 3.0 Spec中,對于REPLAY_TIMER的定義,不偏不倚,2.5GT/s,5GT/s,8GT/s三個傳輸速率均有專屬的定義,參【PCIE3.0】Table 3-4、Table 3-5和 Table 3-6。
到了PCle 4.0,PCI-SIG協會自己都不想再為16GT/s單獨增加另外一個REPLAY_TIMER Table。于是,提出了更加簡便的REPLAY_TIMER Limits。這下,對于所有的速率就都只有兩個選擇了,如下Extended Synch 字段所描述。Extended Synch字段在Link Control Register 中設置。
對于這個簡化的REPLAY_TIMER,當PCle鏈路運行在2.5GT/5.0GT/8.0GT時,實現時可以選擇無視,依然選擇原本的定義方式。但是,當PCle鏈路運行在16GT/s或以上時,就必須實現 Simplified REPLAY_TIMER Limit。
- 如果發送重試緩沖區包含未收到Ack或Nak DLLP的TLP,并且(如REPLAY_TIMER所示)在超過REPLAY_TIMER限制的時間內未收到Ack或Nak DLLP,則發送器將啟動Replay。
- Simplified REPLAY_TIMER Limit 為:
- 當Extended Synch字段清0時,為24000到31000個Symbol Time。
- 當Extended Synch字段置1時,為80000到100000個Symbol Time。
- 如果Extended Synch字段在未確認的TLP處于outstanding時改變狀態,則允許實現在Extended Synch字段改變狀態時或下次復位REPLAY_TIMER時調整其REPLAY_TIMER Limit。
- 支持16.0GT/s或更高數據速率的實現必須使用Simplified REPLAY_TIMER Limit,以便在所有數據速率下進行操作。
- 強烈建議僅支持低于16.0 GT/s的數據速率的實現在所有數據速率下使用Simplified REPLAY_TIMER Limit,但依然允許它們使用[PCle-3.1]中描述的REPLAY_TIMER Limit。
- Simplified REPLAY_TIMER Limit 為:
這是一個重發計時器超時錯誤,是與端口相關的報告錯誤(請參見Section 6.2)。
IMPLEMENTATION NOTE
Determining REPLAY_TIMER Limit Values Replay 主要由 Nak DLLP 啟動,而REPLAY_TIMER作為輔助機制。由于它是輔助機制,因此REPLAY_TIMER Limit 對跨鏈路傳輸 TLP 所需的平均時間影響相對較小。本規范又定義了Simplified REPLAY _TIMER Limit ,因此與本規范的先前版本一樣,無需對ASPM LOs , Retimer 或其他項進行調整。 |
TLP發送器和一致性測試必須根據在TLP發送器端口上測量的重發時序。該時序以發送的TLP的最后一個符號或接收到的Ack DLLP 的最后一個符號開始,主要看哪個是最早響應Nak的TLP。該時序以TLP重傳的第一個符號結尾。
在測量重發時序到TLP重發開始的時間點時,一致性測試必須允許在該方向上已經在進行任何其他TLP或DLLP傳輸(從而防止TLP重發)。
IMPLEMENTATION NOTE
Recommended Priority of Scheduled Transmissions
如果計劃傳輸多個相同類型的DLLP但尚未傳輸,則在多數情況下有可能將它們“折疊”為單個DLLP。例如,如果已調度的Ack DLLP 傳輸停頓以等待另一次傳輸完成,并且在此期間已調度另-Ack進行傳輸,則僅需要傳輸第二個Ack,因為它提供的信息將取代第一個Ack中的信息。
除了來自事務層(或重試緩沖區,如果正在進行重發)的任何TLP之外,還可以同時調度多個不同類型的DLLP進行傳輸,此時必須對這些DLLP區分優先級進行傳輸。以下列表顯示了選擇傳輸信息的首選優先級順序。請注意,未列出特定于供應商的DLLP 的優先級,因為這完全是特定于實現的,因此沒有建議的優先級。請注意,此優先級順序是一個準則,并且在所有情況下都強烈建議采用一種公平機制,以確保任何類型的業務流不會導致任何其他類型的業務流長時間或無限期地被阻塞。請注意,Ack Latency 值和 REPLAY_TIMER限制指定了在組件的端口上測量的要求,并且組件的內部仲裁策略必須確保滿足這些外部測量的要求
1. 當前正在進行的任何傳輸(TLP 或DLLP )的完成包(最高優先級)。 2. Nak DLLP。 3. 由于以下原因,需要盡快安排Ack DLLP 傳輸:收到一個副本TLP (重傳過來的TLP )或Ack 延遲計時器到期(see Section 3 . 6 . 3 . 1 )。 4. 滿足 Section 2.6 要求的FC DLLP 傳輸。 5. 重試緩沖區重傳。 6. 來自事務層的TLP 。 7. 不滿足Section 2.6 要求的FC DLLP 傳輸。 8. 所有其他DLLP 的傳輸(最低優先級)。3.6.2.2 Handling of Received DLLPs
由于Ack/Nak和Flow Control DLLP影響對端發送過來的TLP,因此數據鏈路層中的TLP傳輸機制還負責處理從鏈路上其他組件接收的Ack/Nak和Flow Control DLLP。這些DLLP是根據以下規則處理的(請參閱Figure 3-17):
- 如果物理層指示接收器錯誤,則丟棄當前正在接收的任何DLLP并釋放為該DLLP分配的任何存儲。請注意,將此類錯誤報告給軟件是由物理層完成的(因此,數據鏈路層不會報告)。
- 對所有收到的DLLP執行以下CRC檢查過程:
- 對接收的DLLP應用于發送相同的DLLP的算法,不包括接收的DLLP的16-bit CRC字段。
- 比較該計算值與DLLP中攜帶的16-bit CRC的值。
- 如果不相等,則DLLP被損壞。
- 接收到損壞了的DLLP將被丟棄,并且是與端口相關的報告錯誤(請參見Section 6.2)。
- 接收到的未損壞但使用不受支持的DLLP Type編碼的DLLP會被丟棄,而無需采取進一步措施。這不被視為錯誤。
- 保留字段中的非零值將被忽略。
- 接收者必須按照接收到的速率處理所有接收到的DLLP。
Figure 3-17 Received DLLP Error Check Flowchart
-
把接收到的FCDLLP傳遞到事務層。
-
把接收到的PM DLLP傳遞到組件的電源管理控制邏輯。
-
對于Ack和Nak DLLP,請遵循以下處理步驟(請參閱Figure 3-18):
- 如果由AckNak_Seq_Num指示的Sequence Number不與任何響應Nak的TLP對應,或不與ACKD_SEQ值對應,則DLLP 將被丟棄。
- 這是一個數據鏈路協議錯誤,是一個與端口相關的報告錯誤(參見Section 6.2)。
Note:只要指示的Sequence Number與ACKD_SEQ值匹配,當TLP(包括復位和第一次TLP傳輸之間的時間)全部被確認,接收Ack DLLP并不是錯誤。
-
如果AckNak_Seq_Num沒有指示為一個最近響應Ack的TLP的Sequence Number,則用Ack
DLLP響應重試緩沖區中的某些TLP:-
從重試緩沖區中清除所有TLP,從最早的到對應于AckNak_Seq_Num的TLP。
-
使用AckNak_Seq_Num字段中的值加載ACKD_SEQ。
-
重置REPLAY_NUM和 REPLAY_TIMER。
-
如果DLLP是Nak,則觸發 Replay過程(請參見上文)。
-
- 如果由AckNak_Seq_Num指示的Sequence Number不與任何響應Nak的TLP對應,或不與ACKD_SEQ值對應,則DLLP 將被丟棄。
Note:收到Nak不報告錯誤。
Figure 3-18 Ack/Nak DLLP Processing Flowchart
以下規則描述了數據鏈路層重試緩沖區的操作,必要時將從中重新發送TLP:
- 發送的TLP副本必須存儲在數據鏈路層重試緩沖區中。
3.6.3 LCRC and Sequence Number (TLP Receiver)
數據鏈路層的TLP Receiver負責檢查LCRC和TLP Sequence Number,并決定是否傳遞給事務層、或者請求重發。
概念上的 "counters"和 flags"來描述TLP LCRC和 TLP Sequence Number 以及支持數據鏈路層重試的機制。此描述不暗示也不要求特定的實現,僅用于闡明要求。
3.6.3.1 LCRC and Sequence Number Rules (TLP Receiver)
-
使用了一個12-bit的計數器:
- NEXT_RCV_SEQ-存儲下一個TLP的期望 Sequence Number值。
- 在DL_Inactive狀態重置為 0°
- NEXT_RCV_SEQ-存儲下一個TLP的期望 Sequence Number值。
-
使用了下述flag:
- NAK_SCHEDULED
- 在DL_Inactive 狀態重置為0b。
- NAK_SCHEDULED
-
使用了下述計時器:
- AckNak_LATENCY_TIMER-根據以下規則對Ack DLLP何時調度傳輸的時間進行計數:
- 在DL_Inactive 狀態重置為0。
- 每次調度發送Ack或Nak DLLP時該值都從0重新開始;用Ack DLLP確認收到的所有TLP時重置為0。
- 如果最初沒有未確認的TLP,然后接收到TLP,則只有當TLP已轉發到接收事務層時,AckNak_LATENCY_TIMER才開始計數。
- AckNak_LATENCY_TIMER-根據以下規則對Ack DLLP何時調度傳輸的時間進行計數:
依次應用以下規則來描述如何處理接收到的TLP,以及哪些事件觸發了Ack和Nak DLLP的傳輸(請參見 Figure3-19):
-
如果物理層報告一個Receiver Error,則丟棄當前正在接收的任何TLP,并釋放為該TLP分配的任何存儲。請注意,將此類錯誤報告給軟件是由物理層完成的(因此,數據鏈路層不會報告)。
- 如果物理層在報告Receiver Error時正在接收TLP,并且NAK_SCHEDULED標志清為0,
- 立即調度一個Nak DLLP發送出去。
- 把NAK_SCHEDULED是為1。
- 如果物理層在報告Receiver Error時正在接收TLP,并且NAK_SCHEDULED標志清為0,
-
如果物理層報告接收到的TLP為空,并且LCRC為計算值的邏輯非,則丟棄TLP并釋放為TLP分配的任何存儲。這不被視為錯誤。
-
如果TLP無效,但LCRC與計算值的邏輯非匹配,則TLP損壞-丟棄TLP并釋放為TLP分配的任何存儲。
-
如果NAK_SCHEDULED標志清為0,
-
立即調度一個Nak DLLP發送出去。
-
把NAK_SCHEDULED是為1。
-
這是Bad TLP錯誤,是報告的與端口相關的錯誤(請參見Section 6.2)。
-
-
按以下方式檢查LCRC:
-
對接收到的TLP應用與上述計算相同的算法,不包括接收到的TLP的32位LCRC字段。
-
把計算的值與數據鏈路層TLP攜帶的LCRC比較:
-
如果不相等,則TLP損壞-丟棄TLP并釋放為TLP分配的任何存儲。
-
如果NAK_SCHEDULED標志清為0,
-
立即調度一個Nak DLLP發送出去。
-
把NAK_SCHEDULED是為1。
-
-
-
這是Bad TLP錯誤,是報告的與端口相關的錯誤(請參見Section 6.2)。
-
-
如果TLP Sequence Number 不等于期望值,則存儲在NEXT_RCV_SEQ中:
-
丟棄TLP并釋放為TLP分配的任何存儲。
-
如果TLP Sequence Number 滿足以下方程式:
(NEXT_RCV_SEQ - TLP Sequence Number) mod 4096 <= 2048
則TLP是對方重發過來的,需要為此傳輸Ack DLLP(根據傳輸優先級規則)。
-
否則,TLP順序不正確(指示一個或多個丟失的TLP):
-
如果NAK_SCHEDULED標志清為0,
-
立即調度一個Nak DLLP發送出去。
-
把NAK_SCHEDULED是為1。
-
-
這是Bad TLP錯誤,是報告的與端口相關的錯誤(請參見Section 6.2)。
-
無論NAK_SCHEDULED的狀態如何,都可以將其報告為與端口相關的錯誤(請參見Section 6.2節),并且這種允許的行為如Figure 3-17所示。但是,為了防止錯誤污染,建議僅當NAK_SCHEDULED 標志清零時,端口才報告此類錯誤。
- 如果TLP Sequence Number等于存儲在NEXTCVEQ中的期望值:
-
刪除4-bit的保留位、TLP Sequence Number和LCRC(見Figure 3-12),并發送到事務處理層。
- 數據鏈路層在傳輸TLP時向事務層指示TLP的開始和結束。
- 數據鏈路層將TLP視為“黑盒”,并且不處理或修改TLP的內容。
- 請注意,在將TLP轉發到事務層之前,接收方流控制機制不會考慮任何接收到的TLP。
- 數據鏈路層在傳輸TLP時向事務層指示TLP的開始和結束。
-
NEXTCVEQ遞增。
-
如果NAK_SCHEDULED為1,則清為0°
-
Figure 3-19 Receive Data Link Layer Handling of TLPS
-
TLP接收器必須調度一個Ack DLLP,以便在滿足以下所有條件的情況下進行傳輸:
-
數據鏈路控制和管理狀態機處于DL_Active狀態。
-
TLP已轉發到接收事務層,但尚未通過發送Ack DLLP進行確認。
-
AckNak_LATENCY_TIMER達到或超過Table 3-7(對于2.5 GT/s操作模式),Table 3-8(對于5.0 GT/s操作模式)和Table 3-9(對于8.0GT/s以上操作模式)指定的值。
-
用于Ack DLLP傳輸的鏈路已處于LO狀中或已轉換到LO狀態。
-
Note:如果鏈路尚未在LO中,則鏈路必須轉換為LO才能傳輸Ack DLLP。
-
當前沒有在用于Ack DLLP傳輸的鏈路上傳輸另一個TLP或DLLP。
-
NAK_SCHEDULED清為0。
-
Note:每次調度發送Ack或Nak DLLP時,都必須從0重新啟動AckNak_LATENCY_TIMER。
-
-
數據鏈路層Ack DLLP的調度時間可能比所需的時間更頻繁。
-
為數據鏈路層Ack和Nak DLLP的AckNak_Seq_Num字段指定(NEXT_RCV_SEQ-1)值。
Table 3-7,Table 3-8和Table 3-9定義了 AckNak_LATENCY_TIMER的閾值,在任何特定情況下,該閾值都稱為Ack Latency Limit。
TLP接收器和一致性測試必須根據在TLP Receiver的端口上測量的Ack Latency時序為基礎,從接收到TLP的最后一個符號開始到Ack<DLLP第一個符號發送出去結束。
在發送Ack DLLP之前進行測量時,一致性測試必須允許已經有TLP或其他DLLP在該方向上傳輸(從而保證了Ack DLLP傳輸)。如果LOs使能,則一致性測試必須允許Ack DLLP傳輸方向上鏈路的LOs退出延遲。如果Link Control寄存器的Extended Synch字段被設置,則一致性測試還必須考慮其對LOs退出延遲的影響。
不需要TLP接收器根據LOs退出延遲或Extended Synch的值來調整其Ack DLLP的調度。
Table 3-7 Maximum Ack Latency Limits for 2.5 GT/s (Symbol Times)
IMPLEMENTATION NOTE
Retry Buffer Sizing
Retry Buffer 應足夠大,以確保在正常操作條件下不會因為重試緩沖區滿而導致傳輸被限制。在確定最佳緩沖區大小時,必須考慮Ack Latency值、由接收器已經發送另-TLP引起的Ack延遲、由物理鏈路互連引起的延遲以及處理接收到的Ack DLLP所需的時間。
給定兩個組件A和B,在調整A的發送重試緩沖區的大小時,應考慮A的Receiver要求的LOs退出延遲,如下例所示:
- A在其到B的傳輸路徑上退出LOs,然后開始向B發送長突發的寫請求。
- B會在其通往A的傳輸路徑上發起LOs退出,但是A的接收方所需的LOs退出時間很長。
- 同時,B無法將Ack DLLP發送給A,并且A由于缺少重試緩沖區空間而停止。
- 從B到A的傳輸路徑返回到LO,B向A傳輸Ack DLLP,并且停頓得到解決。
通過使組件的發送器重試緩沖區的大小與組件的接收器所需的LOs退出延遲匹配,或者從相反角度考慮,通過使接收器LOs的退出延遲與所需的重試緩沖區大小匹配,可以避免這種停頓。
選擇AckFactor值是為了允許實現良好的性能,而不需要高成本的大重試緩沖區。為了在具有不同實現和應用程序的通用互連中實現一致的性能,有必要對所有組件設置相同的要求,而不考慮任何特定組件的應用程序空間。如果組件不需要鏈路的全部傳輸帶寬,則可以將其重試緩沖區的大小減小到指定的Ack Latency值保持可用的重試緩沖區空間所需的最小大小以下。
請注意,指定的Ack Latency值可確保允許的outstanding TLP序列號的范圍永遠不會成為導致傳輸停頓的限制因素。