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

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

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

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

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

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

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

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

解決方法：

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

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

”DENALI_CDN_AXI_ATOMICTRANSACTION_NonAtomicOperation”。

最后，通過試驗(yàn)驗(yàn)證了方法a是可行的。

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

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