編 者 按

續(xù)接上文，接續(xù)扒一扒PCIe中的Flow Control

鏈路層把TLP分為幾類？

在處理TLP報文時，根據(jù)Fmt字段以及Type字段可以將TLP報文分為二十多種，當TLP報文送至數(shù)據(jù)鏈路層時，數(shù)據(jù)鏈路層在進行流量控制處理時則不會考慮這么多種情況。數(shù)據(jù)鏈路層里面的Flow Control，則會將報文分為三類：

Post:不需要Target端返回響應報文的TLP請求。

Non-Post:需要Target端返回響應報文的TLP請求。

Cmpl:響應TLP報文。

而同時，數(shù)據(jù)鏈路層在進行流量管理時會將TLP的數(shù)據(jù)報文頭、數(shù)據(jù)負載分開進行流量控制。也就意味著數(shù)據(jù)鏈路層的流量控制每個VC分為了六個通道：

Post Header

Post Data

Non-Post Header

Non-Post Data

Cmpl Header

Cmpl Data

這在cocotb-ext中的FcChannelState中可以看出：

Flow Control初始化

Flow Control的初始化在DL_INIT中：

所用到的DLLP報文為：

按照Spec里面的規(guī)定，F(xiàn)low Control的初始化順序為：

InitFC1-P (first)

InitFC1-NP (second)

InitFC1-Cpl (third)

無論是InitFC1、InitFC2,其報文格式定義基本相同。InitFC1、InitFC2所做的事情也基本相同，就是告知發(fā)送端Header、Data的令牌數(shù)?？吹揭欢尉W(wǎng)上的解釋：“FC_Init1和FC_Init2干的活不是差不多嘛，為什么還需要FC_Init2呢？原因是，不同的設備完成FC_Init1的時間可能是不同的，增加FC_Init2是為了保證每個設備都能收到FC初始化DLLP?！?/p>

如果FC為0，則表示該通道不受令牌限制，即無流量控制(EP設備以及不支持P2P的RC的Cmpl常設為0，故建議在涉及時對于Cmpl時建議仔細考慮。像Xilinx PCIe IP EP模式的的RC接口，不建議做反壓)。

這里著重看下 Scale和FC域，F(xiàn)C域為12bit，隨著PCIe鏈路速度的提升，Spec規(guī)定了Scale域以擴大令牌數(shù)：

按照協(xié)議里，最大可以支持到16bit。而FC域僅有12bit，協(xié)議里規(guī)定了FC的定義：

在cocotbext-pcie里，關(guān)于FC位寬的定義，Header、Data采用12、16bits：

Flow Control的初始化在cocotbext-pcie中也很明了簡單：

可以看到，由于FC_INIT1、FC_INIT2內(nèi)容基本一致，F(xiàn)C2基本沒有做什么處理(具體真實的實現(xiàn)不了解)。

》令牌消耗

發(fā)送端發(fā)送一個TLP報文，在數(shù)據(jù)鏈路層需消耗Header、Data令牌。每一個TLP報文需消耗一個TLP，而如果有數(shù)據(jù)負載則每四個DW消耗一個Data令牌：

數(shù)據(jù)鏈路層進行判定是否能發(fā)送該數(shù)據(jù)出去：

》令牌更新

令牌周期性的更新所用到的DLLP格式為：

接收端按照HdrFC、DataFC中的內(nèi)容更新其令牌：

這里面看起來有一點不太合適的地方就是沒有考慮Scale，按照DLLP里面的報文解析：

由于FC只有12bit，這里對于16bit的場景支持欠妥。

更新周期

無論是Flow Control還是之前所說到的ACK/NAK，協(xié)議中都規(guī)定了最大發(fā)送間隔時間。在cocotbext-pcie中的計算方式如下：

這里面的計算單位是Symbol Time(物理層發(fā)送1Byte數(shù)據(jù)的時間)。這里面可能乍看懵逼，這部分在PCIe Spec 5.0里對應Appendixes H里：

Flow Control Latency：

ACK Latency：

審核編輯：湯梓紅