記錄最近Debug AMBA VIP的兩次經(jīng)歷

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

1. AXI VIP通過調(diào)整latency對設(shè)計進(jìn)行反壓

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

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

2.ace_lite_vip發(fā)送多個WriteNoSnoop操作

在sequence中打印log發(fā)現(xiàn)，sequence已經(jīng)把transaction發(fā)出了，但是ace_lite_vip的driver卻沒有將這一筆數(shù)據(jù)驅(qū)動到interface，driver后續(xù)也不再往interface上驅(qū)動transaction了。如下圖所示，從紅色矩形框往后，總線上就沒有任何toggle了。

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

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

解決方法：

a.將后面的transaction的IdTag設(shè)置為與前面事務(wù)的IdTag都不相同。

b.或者將”DENALI_CDN_AXI_FLD_Atomic”字段設(shè)置為

”DENALI_CDN_AXI_ATOMICTRANSACTION_NonAtomicOperation”。

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

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

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