UVM实战练习

1、import uvm_pkg:: ;忘了写；。结果导致报错:System verilog keyword ‘class’ is not expected to be used in this context
2、dump波形到verdi的坎坷之路
2.1 -fsdb 和 -P xxx/novas.tab xxx…/pli.a同时加到option中，会包系统函数重复的warning。后来看了下是因为- fsdb -debug_access -P这三种都可以实现dump波形的功能，我估计是用了两个导致的warning。
2.2 报错dumping vcs annotated stack。原因有两个第一个是因为没有在vcs的option中加-full64，导致使用了32bit的vcs，但是-P的时候使用的是64bit的NOVAS的pli接口。后来将-P改成32bit的NOVAS就没有报错了，最后加上-full64并在-P中使用64bit的NOVAS也可以正常使用。
2.3 vcs没有报错，但是fsdb是空的没有波形。看了下novas_dump.log文件，其中有报错，它爆出了我$fsdbDunpvars([depth,][instance][,option])的第二个参数错误。有两种解决方法：
一是首先生产vcd文件，然后通过命令转成fsdb文件.
$dumpfile(“top.vcd”);
$dumpvars(0,top);
vcd2fsdb fsdbfile
第二种就是加-debug_pp选项
3、一个class没有加endclass的报错
创建了一个sequence的class，但是忘记写endclass了，导致使用这个sequence的时候报错：不是一个type。没有直接报sequence本身的问题。检查了很久的代码才发现这个问题。（如果怀疑前面定义的东西有问题，可以将其复制到当前文件，这样就能报出具体错在哪里(语法上的)）。
4、在运行UVM实战3.3.4的代码时发现一个问题，它将crc也进行了UVM_NOPACK操作，很疑惑于是去掉了UVM_NOPACK发现会报错。多次尝试后发现其实是my_monitor的问题，在my_monitor中有如下的代码。tr.pload=new[data_size-18];//exclude da sa e_type crc 。在使用pload的时候必须先给定其长度，其长度就是整个包的长度减去 da sa e_type crc 的长度，在在3.3.4中增加了一个vlan这个vlan的长度为4个字节，所以如果不对crc进行UVM_NOPACK那么必须修改为tr.pload=new[data_size-22];//exclude da sa e_type cr vlan，不然tr.pload的长度就多4个字节。我猜作者的重点是my_transaction，不想再文中去修改my_monitor的代码，所以干脆偷个懒，将crc也unpack，总长度就不变了，（增加了vlan减少了crc）。
5、在验证ISE生成的FIFO中遇到的timescale的问题。
搭建了一个验证FIFO的验证环境，结果发现波形有问题。查找了一下，感觉是时间单位和精度不对。通过$printtimescale()这个系统函数，将driver中的timescale打印出来，发现居然是1ps/1ps，和我预想的1ns/1ps差别很大。
为了解决这个问题，在vcs的option中加上了-overrid_timescale=1ns/1ps，强制将所有的scale设置成1ns/1ps。这样driver倒是OK了，但是将FIFO调用的子模块也修改了，调用的子模块的scale本来是1ps/1ps，被强制修改成1ns/1ps,里面有#1000的延时语句，导致仿真的波形还是错误的。不能通过-overrid_timescale=1ns/1ps来粗暴的解决这个问题。
后来通过反复的实验和查找资料，发现，timescale和编译顺序有关系。通过调整filelist的顺序，发现driver的scale是1ns/1ps，FIFO调用的模块也是1ps/1ps没有被修改。对比之前的编译log，发现两者的区别是glbl之前是放在最后编译的，而后来的是放在最开始编译的。感觉上验证环境的timescale是由最后一个被编译的带timescale的模块决定的。