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

如何提高 AXI 總線的吞吐量

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

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

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

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

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

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

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

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

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

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

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

基于 Python 的批處理可視化

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

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

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

智能監(jiān)視器提供生成以下性能指標的功能：

讀/寫數(shù)據(jù)字節(jié)計數(shù)

讀/寫數(shù)據(jù)吞吐量

讀/寫請求計數(shù)

讀/寫已完成事務計數(shù)

讀/寫未完成事務

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

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

審核編輯：郭婷