在使用 AXI 總線移動大量數據的 SoC 中，AXI 總線的性能可能會成為整體系統性能的瓶頸。SoC 中日益增加的復雜性和軟件內容，因此需要使用實際數據有效載荷在硅前進行左移性能驗證。硬件輔助驗證平臺 - Synopsys ZeBu?仿真系統和Synopsys HAPS? FPGA原型系統 - 是運行如此大的有效載荷的必要條件。

如何提高 AXI 總線的吞吐量

如果使用 AXI 總線進行頻繁的批量數據傳輸，則實現良好的吞吐量非常重要。吞吐量可以通過計算觀察窗口期間在AXI接口上捕獲的每個節拍（RVALID/BVALID）中所有數據字節（AxSIZE）的總和，然后將總和除以觀察窗口的持續時間來計算。顯示低吞吐量的窗口通常并不意味著問題，除非期望快速移動大量數據。吞吐量降低的幾個原因可能是：

經理行為：理想情況下，經理應該在同一周期斷言 AWVALID 和 WVALID。此外，管理器應該能夠通過在連續周期上保持 WVALID 高電平來驅動多個節拍。如果不是這種情況，則管理器將限制寫入事務的吞吐量。

有效/就緒握手：如果 xREADY 在經理和下屬端始終處于高電平，則可以實現最佳性能。但是，當內部管道已滿時，現實世界的 DUT 最終必須取消斷言 xREADY。因此，理想情況下，經理/下屬應將未完成的交易保持在 DUT 流水線限制內，以確保不會停滯不前。

請求到響應延遲：從屬可能需要幾個周期來響應寫入/讀取請求。當響應在下一個周期到從屬對請求進行采樣時，將達到峰值性能。但是，復雜的互連路由和內存訪問通常需要幾個周期才能驅動響應。

如何提升AXI總線的事務性能？

Arm AMBA 3 AXI 和 Arm AMBA 4 AXI 互連支持未完成事務，沒有任何限制，甚至允許使用同一 ID 進行多個未完成事務。ID（或其中的幾位）通常用于將響應從屬路由到具有唯一 ID 的正確經理。如果經理可以發出多個未完成的交易，則只有在下屬也支持的情況下才應這樣做，否則它將簡單地取消斷言 xREADY 信號并導致停滯。即使從屬支持未完成的事務，也只能在其內部管道未滿的情況下執行此操作。因此，如果管理器發出等于或小于次級管道深度的未完成事務，則可以獲得最佳性能，這允許互連處理多個事務而無需任何序列化。

圖 2：Synopsys 平臺架構師中顯示的每個觀察窗口的未完成事務計數

圖 4：讀取 Synopsys 平臺架構師中顯示的事務計數/吞吐量

用于 Arm AMBA AXI 接口的智能監視器允許用戶測量 AXI 總線性能，以便在實際硅流片之前優化設計以獲得所需的性能。為了進一步調試到窗口中，需要分析 AXI 流量以跟蹤導致性能下降的事務。最后，需要檢查設計是否存在可能導致交易中觀察到偏差的原因。

適用于 Synopsys ZeBu EP1 的智能監視器如何幫助分析 AXI 總線性能

用于 Arm AMBA AXI 接口的智能監視器是基于 DPI 的事務處理器，但它們是僅用于捕獲總線流量的無源組件。監視器可以處理協議數據以進行功能驗證或性能分析。對于性能分析，顯示器支持 3 種模式。

基于 Python 的批處理可視化

面向驗證工程師的基于 Synopsys Verdi? 性能分析儀的性能可視化

Synopsys 平臺架構師?為軟件工程師提供基于虛擬原型解決方案的性能可視化

這些模式中的任何一種都可以根據需要用于分析 AXI 總線性能。

智能監視器提供生成以下性能指標的功能：

讀/寫數據字節計數

讀/寫數據吞吐量

讀/寫請求計數

讀/寫已完成事務計數

讀/寫未完成事務

請求 （AW/AR） 到響應 （B/R） 延遲

Synopsys ZeBu EP1 仿真和原型系統支持在 SoC 上運行實時軟件有效負載。智能監視器架構允許用戶以與不使用監視器幾乎相同的運行時性能生成性能測量數據。此外，監視器可以動態配置為在用戶希望查看功能調試的事務詳細信息的情況下轉儲詳細的事務數據。

審核編輯：郭婷