记录最近Debug AMBA VIP的两次经历

最近在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可以乱序完成。