查看: 1333|回复: 0

[经验] Soc芯片debug 经验

[复制链接]

该用户从未签到

发表于 2021-1-13 23:39:24 | 显示全部楼层 |阅读模式
分享到:

在介绍bug之前,继续讲解一下在在wave中debug中经常用到的小技巧。

1,标亮Wave中的信号

选中Wave中的信号(左键点击一下),按下字母c,打开“Change Color”对话框。选择想要的颜色。

2,Bus Operations

   右键点击信号,选择Bus Operations,可以看到很多Bus操作。这里着重讲解一下Create Bus 操作。例,在dut中定义了一个信号addr [39:4],该信号在wave中只显示位宽[39:4],该地址只是case中写地址的一部分,我们要想确定该地址addr[39:4]是不是对应着case中的写地址,我们可以打开Create Bus对话框,使用Add Logic Low按钮,补全低四位。这样在Wave中的信号列表中显示的数据就是完整的case 中的地址。

3,Waveform->Signal value Radix

Wave中拉出来的信号默认显示是16进制,但dut中有时候会使用十进制的数据10’d等。使用Signal value Radix 可以改变该信号显示的进制。

接下来开始讲解Soc 验证中遇到的问题。

       1. 在soc系统中,集成了很多IP,有时候需要验证一个IP发送出去数据包的datapath是否正确。一般情况下,使用的是该IP的UVC去发送数据包,编译的是该IP的一个model,里面只有接口,没有实际的功能,把该IP的model 输入输出接口,连接到该IP UVC的interface上,这样如果启动验证环境,IP UVC的接口上有了数据包,就相当于该IP 发送了数据包。该IP数据包的验证通路要想成功的到达最终的地方,在发送该数据包之前,需要配置很多关键的寄存器。如果没有配置该寄存器,该数据可能在中途就会丢失。导致该case不能成功到达。

举例:A->B->C数据通路,ABC之间的数据传递使用的协议接口,A 的输出连接到B的输入,并且A的数据成功的传递到B的输入上,但是在B内部,经过复杂的逻辑之后,B没有了输出。我们在波形中一直去追踪B的输出,可能最终会发现如下代码,信号名字都是随手写的。

If (cntl)

   Valid<=iwdata[3];

我们可能会发现cntl没有起来,这个说明我们要配置一个寄存器的第3位,把第三位置为1,具体是哪一个寄存器,我们可以继续追踪cntl。我们可能会发现如下代码。

case (x_cntl_x)

    404: cntl=1;

    403:cntl_a=1;

default: cntl_b=1;

endcase

          这段代码,我们可以看到,寄存器的地址偏移是404,关键词是x_cntl_x。这个时候,我们就可以去寄存器地址文件表(一般情况下,所有的寄存器地址定义的define都在一个文件里)里去匹配关键词x_cntl_x,去找到后缀是404的寄存器。然后在自己的case里面,先去配置该寄存器,把该寄存器的域3,配置成1。我们也可以去看看对该寄存器的域的说明,去UVM寄存器模型里面搜索该寄存器,会找到该寄存器的所有域的说明以及总的位宽。假设该寄存器的位宽是32,我们可以通过读出该寄存器的值,然后把值和32‘h0008相或,把或之后的值写入该寄存器即可。代码如下。

         read_data=read_cntl_reg(xx_cntl_xx);

          read_data=read_data|32’b0008;

          write_cntl_reg(xx_cntl_xx, read_data);

2. 在编写数据包的时候,数据包是要连接到IP uvc 的interface上的,这些interface上的接口都是协议接口,协议接口文件里面定义了很多assertion,也有部分assertion是单独编写的,单独例化的。这些assertion可能对于写数据的一些属性有固定要求或者有约束范围,如果我们没有按照要求给激励,在仿真环节会出现违背assertion 的error。

  例如错误现象:UVM_ERROR: $datapath/src/verif/assertion.sv #16.

       A==0

Hierarchy.a.b.c.A

我们通过Hierarchy.a.b.c.A 在波形Wave中拉出来信号A,发现他是0。然后我们打开文件assertion.sv,找到了assertion的第16行对A进行了assertion约束。具体写法略。

我们去追踪该信号,可能会发现如下例化代码。

.A(write_valid&&write_AWSIZE!=3)

我们就可以发现我们在写协议包属性的时候,把AWSIZE写成3了。最后我们要去查看该IP对应的技术文档,去确定技术文档里面,这个接口信号是不是标注了不能等于3,如果找不到,要去找对应的IP 部门去确认修改。

3. 在Soc系统中,有时候不止使用了一种协议,可能是多个协议。这里面就有了协议的转换。例如A->B->C这么一段datapath,A的输入接口是AXI协议,A的输出是其他类型协议,这样在A内部就有一个协议转换。如果发现A的输出valid没有起来,那我们一直追下去,可能会发现如下代码。

Always @ (posedge clk)

      if(axi_valid)

         valid<=1;

我们把axi_valid和clk在波形中拉出来,发现axi_valid和clk都有,但是axi_valid翻转的脉冲很短,这个clk相对较慢,在clk的上升沿,axi_valid完美的错位过去了。这个现象是由于产生axi_valid的时钟是一个比较快的时钟,那这个axi_valid如果出现在clk上升沿之内,valid可能无法正确获得1。


回复

使用道具 举报

您需要登录后才可以回帖 注册/登录

本版积分规则

关闭

站长推荐上一条 /4 下一条



手机版|小黑屋|与非网

GMT+8, 2024-11-23 15:43 , Processed in 0.105577 second(s), 15 queries , MemCache On.

ICP经营许可证 苏B2-20140176  苏ICP备14012660号-2   苏州灵动帧格网络科技有限公司 版权所有.

苏公网安备 32059002001037号

Powered by Discuz! X3.4

Copyright © 2001-2024, Tencent Cloud.