基于systemVerilog的UVM 调试问题及解决办法集锦

说在前头

目前接触的UVM内容都是基于systemVerilog的。所以,碰到的问题主要基于sv。

一、低级语法错误

此类错误是由于一些低级操作或常识不清导致的,并很容易解决。
多为语法错误。

1、信号赋值

信号主要分为wire型和reg型。
在进行信号赋值时,wire型信号不能出现在等号左边只能在右边,reg型信号可以出现在等号左边和右边。故,当不小心把wire型信号放在等号左边,就会报错。
信号赋值,左右两边的信号必须是相同类型,否则无法赋值。

当然,现在systemVerilog中引入了logic类型的变量,可看作是wire型和reg型的综合。使用logic类型的信号,就能避免上面的问题。

2、拼写错误

因为每天敲很多代码,经常由于错敲、多敲、漏敲字母导致信号名错误,使得编译报错:该信号未定义。
另外,由于屏幕分辨率及字体原因,导致小写的“i”与数字”1”不易区分,数字“0”和字母“O”不易区分,稍不留意就会认错。

3、语法错误

有时编译报错为语法错误,但是仔细反复检查那一行,却找不出问题。这时候,不妨往上一行看看。
原因是,经常由于上一行末尾少敲结尾的分号“;”,导致下一行编译报语法错误。

4、invalid错误

实际工程中,自己动手敲代码,编译发现invalid类型错误。
比如,某个类型的对象,编译提示该类型未定义,invalid。但是,去检查代码,自己明明定义了的。
原因是什么?
哈哈,其实很简单,不是你定义出问题了(若是,那也不会是invalid的了!)。
解决问题分两步:

第一,检查自己的类型名称拼写是否有错误。

对的,很有可能是敲错了!
名称对不上,自然是invalid。

第二,检查代码编译顺序。

已经排除拼写错误,那么自然类型定义是没有问题的。
那是什么原因?
因为编译时会将include的文件按照代码顺序编译,于是,很有可能因为顺序问题,导致应用类型的代码比定义类型的代码先编译,那么,基于先定义再使用的原则,显然该类型在编译到应用该类型时,自然是未定义的,也就是invalid。
解决办法:只需要将定义的代码说在文件的include顺序提前到应用类型的文件前面。
对,就是这么简单!
你以为多深奥?
再说一遍,核心办法是:查看在顶层中一大堆include“xxxx”的顺序,确定类型的先定义再应用的顺序。
经验之谈:一般,将最底层的文件放在开头,也就是自己纯定义类型,不应用别的类型;应用类型的文件,一定放在该类型的定义文件之后。

5、使用UVM机制

UVM中提供了各种功能强大的机制,提高工作效率。比如factory机制。
但是,要使用这些机制,定义的object、component都必须用特定的宏注册。
否则,无法使用对应机制。
并造成对应定义的object或component存在invalid问题。

6、类变量的invalid

UVM使用systemVerilog,与C++、Java等面向对象语言有很多相同点。比如,类的对象,声明后,在使用前,需要实例化。在SystemVerilog中使用new()函数实现.
有时候,代码通过编译,但是在仿真时因出错而停止,会出现“NULL pointer dereference”的错误提示.
这种错误是说:出现空指针的引用。
就说明,当前错误的地方是因为声明的该实例没有实例化。
当正确声明一个变量,使用时,需要先进行new操作,即实例化。实例化,会申请对应空间供变量使用。否则,声明的变量就只是一个单纯的该类型指针,没有实际空间,无法直接使用。
比如:
A a;// class A
a.copy(); // 报错:NULL pointer dereference

修改为:
A a;// class A;
a = new(“a”);
a.copy() // 正确

7、虚拟接口

UVM中提供了虚拟接口,用于避免使用绝对路径。
每一组虚拟接口,在定义后,都必须完善连接。否则,由于接口没有连接上,使用会报错。

8、函数调用错误

调用函数,不管是系统函数还是自定义函数,函数中的参数个数要匹配,否则,会报错。
错误信息大概如下:
The above function/task call is done with more arguments than needed.
这类错误比较容易解决,直接去参看原函数定义,检查参数类型及数量,一一对应修改即可。

9、uvm_info引起的错误

通常,为了方便调试,会添加uvm_info打印信息,功能等同与C语言中的printf函数。
这个当然很好。
但是,一不小心,就会引起错误。还很莫名其妙。
比如,在某个UVM component的某个phase中,需要在执行进入该phase中,就打印相关信息,提醒当前已经执行到这里。
想法很好,uvm_info的语法也简单。
一般不会有错。
但是,假如uvm_info后面有变量声明,那么,不好意思,编译时会报错,提示添加“=”or“<=”。
WTF?
莫名其妙嘛!
解决办法,将uvm_info语句移到变量声明的后面即可。

二、高级逻辑错误

所谓高级错误,是为了和前方的低级错误相区别。
化用伟人的话说,此类错误,已经脱离了低级趣味。
不再是简单的语法、常识错误,而是更深层次的逻辑错误。
表现为:能正常通过编译环节,但是在仿真阶段会出错。
这类错误往往更难处理,需要对UVM各部件本身及部件之间的连接关系有深刻理解。

UVM有许多component和object。这些部件之间的相互协作有一定的工作顺序,当前后顺序错误时,同样导致仿真阶段无法正常工作。

1、sequence

最近(2016-10-10)碰到的一个问题。
仿真给出的错误信息如下:
reg_seq [SEQ] neither the item’s sequencer nor dedicated sequencer has been supplied to start item in reg_seq
从字面意思看,就是说在处理reg_seq的时候,对应的sequencer并未预先设置完成。
都说sequence就是子弹夹,sequencer就是枪。
子弹夹已经就绪,枪还没有,所以无法开枪。
那该怎么办?
经过两天的查看,发现问题是由于需要用到的sequencer等尚未定义,因此,此处使用sequencer当然就还没有准备好。

2、null object access(NOA)

昨天晚上调试验证平台代码,仿真阶段出现了NOA错误,错误信息显示,需要使用的object并没有预先完成实例化。
这类错误主要由于在声明object之后,忘记实例化造成的。
有人会问,怎么这么粗心大意?
这都能忘?
我:……
这么低级的错误,本小白肯定还不至于这么不小心。
经过自己梳理平台中object、component之间的调用关系,以及验证平台的执行顺序后,发现是昨晚刚对底层的component的定义做了修改,由于功能需要,添加了新的object,及操作。
经过反复检查确认,新添加的代码,本身没有问题,需要调用的地方也没问题。
问题出在其他位置调用此component的情况。
需要调用新object的地方,对新object做了相应处理。
而旧的调用的地方,则并没有做处理,于是问题就出来了。
在并不需要新object的地方,并没有进行实例化。而该object依然进行了相应的操作,比如赋值,于是,出现了NOA错误。

总结教训:以后修改底层文件,一定要小心,修改底层文件,那么凡是调用这个文件的地方,都要做检查,按照需要进行相应修改,否则,各种NOA,让人莫名其妙,烦不胜烦。最好的办法,不到万不得已,千万不要修改底层文件!

你可能感兴趣的:(UVM)