NVMe IP放棄XDMA原因

選用XDMA做NVMe IP的關鍵傳輸模塊，可以加速IP的設計，但是XDMA對于開發者來說，還是不方便，原因是它就象一個黑匣子，調試也非一番周折，尤其是后面PCIe4.0升級。因此決定直接采用PCIe設計，雖然要費一番周折，但是目前看，還是值得的，我們uvm驗證也更清晰。

PCIe 寫應答模塊設計

應答模塊的具體任務是接收來自PCIe鏈路上的設備的TLP請求，并響應請求。由于基于PCIe協議的NVMe數據傳輸只使用PCIe協議的存儲器讀請求TLP和存儲器寫請求TLP，應答模塊分別針對兩種TLP設置處理引擎來提高并行性和處理速度。

對于存儲器寫請求TLP，該類型的TLP使用Posted方式傳輸，即不需要返回完成報文，因此只需要接收并做處理，這一過程由寫處理模塊來執行，寫處理模塊的結構如圖1所示。

圖1 TLP寫處理結構

當axis_cq 總線中出現數據流傳輸時，應答模塊首先對傳輸的TLP報頭的類型字段進行解析，如果為存儲器寫請求則由寫處理模塊進一步解析。寫處理模塊提取出TLP 報頭的地址字段、長度字段等，然后將數據字段寫入數據緩存中。提取出的地址字段用于進行地址映射，在NVMe協議中，設備端的請求寫分為兩種，分別是寫完

成隊列和寫數據，因此地址映射的定向對應為隊列管理模塊的完成條目處理單元和數據傳輸AXI總線的寫通道。完成條目的字段長度為128比特，因此無需進行數據緩存，跟隨地址映射發送到隊列管理模塊。AXIMaster驅動負責將解析的字段與緩存的數據組成AXI寫傳輸事務發送到AXI寫通道，實現數據的寫傳輸。

PCIe 讀應答模塊設計

對于存儲器讀請求TLP，使用Non-Posted方式傳輸，即在接收到讀請求后，不僅要進行處理，還需要通過axis_cc總線返回CplD，這一過程由讀處理模塊執行，讀處理模塊的結構如圖2所示。

圖2 TLP讀處理模塊結構

當axis_cq 總線接收到存儲器讀請求時，數據流被轉發到讀處理模塊。讀請求TLP只包含128比特的請求報頭，而axis總線位寬也是128比特，因此在短時間內可能接收到多個讀請求，為了應對這種情況，讀處理模塊采用了帶有outstanding能力和事務并行處理的結構設計，能夠有效提高讀請求事務處理效率和數據傳輸吞吐量。

首先當讀請求數據流到達讀處理模塊時，經過解析和地址映射的兩級流水后，放入響應處理單元outstanding 緩存中，響應處理單元從緩存中獲取事務一一處理，將讀取的數據打包成CplD，并將CplD放置到發送緩存中等待axis_cc總線的發送。根據地址的不同，讀請求事務被分為三類，分別是讀隊列請求，讀PRP請求和讀數據請求，每種請求對應一個響應處理單元。

在實際應用環境中，由于隊列、PRP、數據的存儲往往在不同的位置，因此完成讀取過程的延遲也不同，在本課題中，將隊列管理與PRP都放置在了近PCIe端存儲，因此讀取隊列與PRP的延遲遠遠小于讀取數據的延遲。并且當大量不同的讀請求交叉處理時，讀處理模塊的并行處理結構更能夠充分利用PCIe的亂序傳輸能力來提高

吞吐量。為了清晰的說明讀處理模塊對吞吐量的提升，設置如圖3所示的簡單時序樣例，樣例中PCIeTLP的tag最大為3。

圖3 TLP 讀處理時序圖

在對應圖3中第1、2行時序的低性能處理模式下，同一時間只能處理一個讀事務，并且不帶有outstanding能力，此時從接收到讀請求到成功響應所經歷的延遲將會累積，造成axis_cq 請求總線的阻塞。在對應圖中第3、4行時序的僅帶有outstanding 能力的處理模式下，雖然可以連續接收多個讀請求處理，但同一時間內只能處理一個事務，仍會由于較大的處理延遲導致axis總線存在較多的空閑周期，實際的數據傳輸效率并不高。在對應圖中第5、6行時序的讀處理模塊處理模式下，利用多個響應處理單元的并行處理能力和發送緩存，先行處理完成的CplD可以優先發送，緊接著可以處理下一事務，使總線的傳輸效率和吞吐量明顯提高。