AXI Master與Slave VIP對接驗證平臺搭建
在SoC驗證中，AXI總線幾乎是繞不開的。無論是CPU訪問DDR，還是DMA搬運數據，都離不開AXI協議。而AXI VIP正是Synopsys提供的標準化驗證組件，用來替代手寫AXI BFMs，幫助驗證工程師快速搭建總線協議驗證環境。
本文記錄了一次AXI Master VIP與AXI Slave VIP對接驗證平臺的搭建過程，重點說清楚環境怎么搭、Sequence怎么封裝，以及實際踩過的幾個坑
從基礎讀寫開始
搭建的第一步是跑通最基本的讀寫流程。
在Synopsys AXI VIP的示例代碼中，已有基礎sequence實現了簡單的讀寫操作。把這些示例跑起來，確認：
Master能發請求
Slave能回響應
仿真不報錯，順利結束
這一步是驗證鏈路通不通的關鍵。如果基礎讀寫都過不了，說明環境連接或配置有問題，后面做再多封裝都沒意義。
把讀寫操作封裝成獨立Sequence
基礎sequence的問題在于：地址和數據寫死在代碼里，每次換測試場景都要改代碼，復用性差。
比如要讀不同地址、寫不同數據，原來需要在sequence內部手動修改參數，然后再重新編譯跑仿真。這種做法在驗證一個簡單模塊時還能接受，但一旦測試用例多了，維護成本直線上升。
解決思路很直接：把讀和寫拆成兩個獨立的sequence，地址和數據全部做成可配置變量。
寫Sequence示例：
systemverilogclassaxi_write_seqextendsuvm_sequence; rand bit [31:0] start_addr; rand bit [31:0] data []; // 參數從外部傳入，不寫死在代碼里endclass
systemverilog
classaxi_write_seqextendsuvm_sequence;
rand bit [31:0] start_addr;
rand bit [31:0] data [];
// 參數從外部傳入，不寫死在代碼里
endclass
讀Sequence同理，把讀取地址設成變量，外部傳入。
這樣改完之后，同一個sequence可以被不同testcase調用，只需要修改傳入的地址和數據即可，不需要再改代碼。
統一管理Sequence
兩個獨立sequence做好之后，還需要一個統一的調用接口。不然每次都要在test.sv里單獨例化，還是會顯得亂。
做法是在單獨的文件中對所有sequence進行聲明和統一管理，Test層只需要調用對應sequence并傳入參數，不需要關心底層transaction的具體創建過程。
這樣分層使Test層更簡潔，測試人員只需關注測試需求，增加新場景時直接復用已有sequence，快速組裝。
實際踩過的幾個坑
坑一：Slave VIP不響應
一開始跑的時候，Master發了請求，但Slave沒有任何反應，仿真一直卡在等待響應狀態。
排查過程：
先確認波形，Master確實發了請求
檢查Slave VIP的配置，發現部分初始化參數沒配全，導致Slave沒有處于正確的響應狀態
補全agent配置和interface連接參數后，恢復正常
教訓：VIP雖然是標準化組件，但配置環節不能大意。任何一個參數沒配對，整個鏈路都可能卡住。
坑二：工程腳本適配
VIP的sequence做好之后，需要把新增文件接入公司現有的編譯腳本和目錄結構里。這部分看起來是小事，但在實際項目里經常會因為目錄路徑不對、filelist漏加而編譯不過。
建議在做sequence開發的同時，同步把filelist和目錄結構調整好，不要等代碼寫完了再回頭改編譯環境。
一些經驗
通過這次AXI VIP平臺搭建，有幾點體會可以分享：
第一，VIP本身封裝了協議細節，用起來省力，但不能只當黑盒用。至少要知道它內部有哪些組件、各個組件怎么配置、連接關系是什么，否則出了問題很難定位。
第二，驗證代碼要考慮復用，不是為了跑通當前一個case就行了。把讀寫拆成獨立sequence看起來是小事，后續增加測試場景時會省很多時間。
第三，驗證平臺結構要分層清晰。sequence只管產生激勵，test只管組織測試流程，底層的driver、monitor由VIP負責。各層各司其職，環境才不會越改越亂。
END
