最近在Debug C家AMBA VIP的過程中遇到一些問題。有兩個問題感覺值得記錄一下，免得以后忘記了，或者其他朋友也可能遇到類似的情況，也許幫助自己的同時還能順便幫助到別人。第一個問題是關于AXI VIP的；第二個問題是關于ace_lite_vip發送多個WriteNoSnoop操作相關的問題。

1. AXI VIP通過調整latency對設計進行反壓

當把latency(xx_yy_ready_delay)調的特別高時，或者是隨機到比較大的數值時，C家的VIP就會報下面的UVM_WARNING

[CDN_AXI_NONFATAL_WARN_EOS_QUEUE_IS_NOT_EMPTY],仔細看下面還有ERROR的提示以及建議。最后通過把latency調整到比較小的值，就沒有這個現象了。

2.ace_lite_vip發送多個WriteNoSnoop操作

在sequence中打印log發現，sequence已經把transaction發出了，但是ace_lite_vip的driver卻沒有將這一筆數據驅動到interface，driver后續也不再往interface上驅動transaction了。如下圖所示，從紅色矩形框往后，總線上就沒有任何toggle了。

后來經過仔細分析trace file(denali.trc，話說denali.trc對分析vip的幫助實在是太大了，以后結合具體的例子再深入的研究一下)信息發現，在紅色矩形框后面的某個時間點，VIP接收到帶有IdTag=xx的transaction，這是個writeNoSnoop的原子事務，但其帶有的字段”DENALI_CDN_AXI_FLD_Atomic”被設置為了“DENALI_CDN_AXI_ATOMICTRANSACTION_AtomicLoad_LITTLE_EOR”的枚舉值。因為加載了這個原子操作，所以就需要Slave在寫入后也響應數據，由于沒有來自slave的數據響應，因此這筆原子操作沒有完成。

這時候最后一個transaction來了，并且和前面分析的那筆transaction擁有相同的IdTag。因為之前的那筆具有相同ID的原子操作還沒有完成，因此，VIP放棄了這筆交易，這就是掛起的原因。如果將verbosity registor設置為FULL，在log中就會看到這個消息。

解決方法：

a.將后面的transaction的IdTag設置為與前面事務的IdTag都不相同。

b.或者將”DENALI_CDN_AXI_FLD_Atomic”字段設置為

”DENALI_CDN_AXI_ATOMICTRANSACTION_NonAtomicOperation”。

最后，通過試驗驗證了方法a是可行的。

回顧總結一下，犯這個錯誤的主要原因是，在寫sequence的時候只對部分字段做了約束，其他字段隨機，而TagID就在隨機之列。如果運氣好，TagID沒有重復的話，這個問題還暴露不出來了呢。所以理解協議是多么重要呀。換個角度再想想，你我皆凡人，不踩坑，不看別人踩坑，很難漲知識呀。你看到了，希望你也能從中受益。查看更多精彩內容，請關注微信公眾號《芯片驗證日記》。

AXI/ACE協議支持亂序傳輸。他給每一個通過接口的事務一個IDtag。協議要求相同ID tag的事務必須有序完成，而不同ID tag可以亂序完成。