Maggie • 来自相关话题

19天前

验证环境中经常使用的参数$test$plusargs和$value$plusargs

   $test$plusargs和$value$plusargs是Verilog和SystemVerilog仿真运行时调用的系统函数,可以在仿真命令行直接进行赋值,并且不局限于不同仿真器对于参数在仿真命令中定义格式不同的限制,也避免了调换 ...查看全部

   $test$plusargs和$value$plusargs是Verilog和SystemVerilog仿真运行时调用的系统函数,可以在仿真命令行直接进行赋值,并且不局限于不同仿真器对于参数在仿真命令中定义格式不同的限制,也避免了调换参数带来的频繁编译等问题。使用这两条函数对于搭建测试平台有一定的便利,同时对于理解Factory中用例是如何传递进Proxy Class有一定的帮助。

    本文将对$test$plusargs和$value$plusargs使用过程中遇到的问题进行小结。

    首先,在进行宏定义时,我们经常使用`ifdef等命令在代码中,参看下例:

     test.v

     initial begin

          `ifdef dumpon

                $dumpfile("results.vcd");

                 $dumpvars;

             `endif

         end

如果要能够成功调用$dump等函数,需要在编译(compile)时指定`define的宏定义,其使用方法如下:

 -define dumpon test.v

    但是,在仿真过程中不需要该部分定义时该如何处理呢?

当需要改变编译条件时,经常需要重新编译。并且一旦编译通过,在编译阶段指定的宏定义在整个仿真运行过程中一直有效,因此,如果需要修改宏定义,则需要重新进行编译,从而降低了仿真的效率。

   为此,可以使用$test$plusargs和$value$plusargs进行解决,该函数的调用发生在仿真运行(run)阶段。这样仅需要对设计进行一次编译即可,如果需要改变相应的条件,可以在run的时候动态指定,这样有利于脚本处理进行回归的验证,同时也有利于object的动态construct。


1.$test$plusargs

    在运行(run)仿真时指定要选择的条件,即只需要在仿真运行命令(run-options)中指定参数需要选择的条件即可,例如下例中,如果要将test01.dat、test02.dat、test03.dat分别load到各自的men中,仅需要如下命令在运行命令中加入“<+test01+test02+test03>”即可,当仿真运行时,$test$plusargs会在命令行中搜索指定的字符,若找到相应字符,在函数返回“1”,否则返回“0”。如果下次仿真时不需要test01时,仅需要将test01从运行命令中删除即可。

     test.v

      initial begin

           if($test$plusargs("test01"))

               $readmemh("test01.dat",mem01);

           if($test$plusargs("test02"))

                $readmemh("test02.dat",mem02);

           if($test$plusargs("test03"))

                $readmemh("test03.dat",mem03);

          end

+test01+test02+test03...


2.$value$plusargs

$value$plusargs可以讲运行命令(run-options)中的参数值传递给指定的信号或者字符,其语法格式如下:

Integer=$value$plusargs(“string”,signalname);

其中string=”plusarg_format”+”format_string”,”plusarg_format”指定了用户定义的要进行传递的值,”format_string”指定了要传递的值的格式(类似$display中定义的%s、%h、etc.),并且string中”plusarg_format”和”format_string”格式应该为”plusarg_format”(=/+)”format_string”。如果转换后的位宽和传递的值不一致,则按照如下规则转换:

plusarg位宽与sigalname的关系Signalname值
<
plusarg左补零
>plusarg截位
plusarg为负数按照正数处理
不匹配若为指定默认值,则reg类型为x

$value$plusargs使用示例如下:

        test.v

         if($value$plusargs("FINISH=%d",stop_clk)) begin

                  repeat(stop_clk) @(posedge);

                  $finish;

                end

             if($value$plusargs("TESTNAME=%s",testname))

                begin

                    $display("Running test %0s",testname);

                     ...

                 end

              if($vaue$plusargs("FREQ=",frequency)) begin

                   frequency=8.333333;

                   ...

          end


若使用的运行命令如下:

    +FINISH=10000+TESTNAME=this_test+FREQ=5.6666

则上例的运行结果为:

    stop_clk : 10000

    testname:this_test

    frequency:5.6666(如果run-options中没有增加“FREQ=5.6666”,那么frequency为8.333333)。

芯片家 • 来自相关话题

26天前

Soc debug经验<4>

  在soc芯片验证的时候,有时候需要我们验证一段数据通路,我们需要发送一个数据包,让这笔数据包从起始端,到达我们想要的目的端。这里有两个比较重要的点是需要注意的,第一个点是如何保证这笔数据包按照我们想要的数据通路走;第二个点是如果已经按照我们想要的 ...查看全部

  在soc芯片验证的时候,有时候需要我们验证一段数据通路,我们需要发送一个数据包,让这笔数据包从起始端,到达我们想要的目的端。这里有两个比较重要的点是需要注意的,第一个点是如何保证这笔数据包按照我们想要的数据通路走;第二个点是如果已经按照我们想要的数据通路走下去了,如何保证这笔数据能成功穿过每一个模块而不丢掉。

1.       如何保证这笔数据按照我们想要的数据通路走。

例如数据通路A<->B<->C<->D<->E。我们想让数据通过A->B->C->D->C->B->F。在Soc芯片中,如果我们想从A模块发送数据到F中,在编译的时候需要A模块是一个A模块的UVC,也就不是A模块的rtl代码,这样我们就可以利用A模块的UVC发送数据包 。从A发出来的数据包到达了D之后,可以有两路通路,一个是到E模块,另一个可以是从D返回去,也就是D->C->B->F,到达F模块。那这里如何保证数据包到达D模块之后,让数据包沿着D->C->B->F,到达F模块。

     在模块D中,会有各种各样的Decoder小模块,这些Decoder决定了到达模块D之后,数据包接下来的走向。这些Decoder是根据来源不同划分的,比如从模块A发出来的数据包可以叫A_Decoder,从其他模块A1发出来的,可以叫A1_DecoderAA1大概率属于不同类型的模块。这两个Decoder的逻辑很相似,里面都会有一个信号destination,该信号的值决定了要到达哪一个模块。

   举例:

   assign Destination= ~enable? 0:F_mem? `to_F : E_mem? `to_E: 0;

可以看到,我们要想让数据包成功到达F,必须让F_mem拉高。我们继续追踪F_mem

可能会发现这个F_mem的逻辑是对地址的范围判断。

   举例:

   assign F_mem=(addr >=F_mem_low)&&(addr<=F_mem_high);

这里就是说,我们从A模块发送到F模块的地址是有限制的,如果这个地址在F模块的memory区间里,接下来D模块就会发送数据到F,沿着D->C->B->F模块走。这里可能牵扯到在我们的case 里面,要先配置F_mem_low F_mem_high之后,才去从模块A发送数据包。如果你知道配置哪一个寄存器可以配置F_mem_low F_mem_high,那更好了,如果你不知道配置哪一个寄存器,这也没有关系,你可以读完接下来我要说的第二点去找到该寄存器。

 

2.       如果已经按照我们想要的数据通路走下去了,如何保证这笔数据能成功穿过每一个模块而不丢掉。

       假设我们想验证A->B->C->D->C->B->F这段数据通路。从模块A发送出来的地址到达模块C 的输入端口之后,这个时候发现数据包在CD的输出端口上没有了。我们去追踪该输出地址接口,可能会发现如下逻辑。

  Case (state)

  `idle:

       If(enable)

        begin

            C_D_addr<=C_D_addr_;

            state<=`send;

        end

   `send:

        …..

     我们可能发现C_D_addr_是有数据的,但是这个enable是等于0的,这个状态机只停留在idle状态,C_D_addr没有数据。

    这里enable没有起来,所以我们会继续追踪enable为什么没有被拉起来。(这个就像第一个点里面F_mem_lowF_mem_high没有数据是一样的)我们一直追踪enable,会发现如下decoder代码。

case(addr[7:0])

20:  enable_C_D_reg_control <=1;

30:  …….

…….

    我们如果追踪addr,能看到完整的地址,在波形中的这些地址都是我们已经配置的寄存器,这里显然没有我们想要的那个寄存器。实际也没有必要去追踪addr了。首先我们要明白,enable_C_D_reg_control是我们要配置寄存器的一个域,然后要配置寄存器地址的后面8位是20。所有寄存器地址define一般都会放在一个文件里。我们可以通过匹配一些关键词去找到该寄存器。

格式如下:

` enable_C_D_reg  10122120

 …….

    比如我们找到了该寄存器叫enable_C_D_reg,我们还需要确定域enable_C_D_reg_controlenable_C_D_reg是第几位。一般情况下,我们可以去查询寄存器的spec,去了解一下enable_C_D_reg寄存器,也可以通过查询UVM的寄存器模型去了解该寄存器。假设我们查到了该域enable_C_D_reg_control32位寄存器enable_C_D_reg的第二位。那在我们从A端发送数据包之前,需要在自己的case cpp里面配置该寄存器。每个验证环境配置具体函数不一样,但是大致思路都是一样的。配置思路代码如下:

data= api.read(enable_C_D_reg);

data=data|0x00000002;

Api.write(enable_C_D_reg,data);

芯片家 • 来自相关话题

29天前

IC验证--Systemverilog之assetionVCS/Verdi实战

    最近top level的同事提了验证需求,让我在RTL中加assert coverage,开始懵逼,后来查阅一些资料和代码,很快上手了。 这里用一个小例子记录一下,免得日后忘记了。先上代码://tb_top.sv的内容:module ...查看全部

    最近top level的同事提了验证需求,让我在RTL中加assert coverage,开始懵逼,后来查阅一些资料和代码,很快上手了。 这里用一个小例子记录一下,免得日后忘记了。先上代码:
//tb_top.sv的内容:
module tb_top();
reg clk, rst;
wire [3:0] out;
always #5 clk=~clk;
initial
begin
rst=1'b0;
clk=1'b0;
#30;
rst=1'b1;
#150;
$finish;
end
always@(out)
$display('counter is %d',out);
counter(.reset(rst),
.clk(clk),
.q(out));
endmodule
module counter(reset,clk,q);
input reset,clk;
output[3:0] q;
reg[3:0]q;
reg[3:0]count;
always@(posedge clk)
if(!reset) q<=4'b0;
else if(q==4'b1111)
q<=4'b0;
else
q<=q+1;
property p1;
@ (posedge clk) (q[0]|-> ##5 q[3]);
endproperty
a1: assert property(p1)
$display('succeed! time=%t',$time);
else
$display('failure! time=%t',$time);
;
c1: cover property(p1);
endmodule
这里是编译仿真以及查看覆盖率的命令们: r> vcs -sverilog -R -fsdb -ucli -do run_vcs.tcl -cm line+branch+assert tb_top.sv
urg -dir simv.vdb
verdi -workMode hardwareDebug -ssf counter.fsdb -f test_coverage.f
dve -cov -dir ./simv.vdb
verdi -cov -covdir ./simv.vdb
log 结果是:
ucli% run
counter is 0
counter is 1
counter is 2
counter is 3
counter is 4
counter is 5
counter is 6
counter is 7
'tb_top.sv', 41: tb_top.counter.a1: started at 45s failed at 95s
Offending 'q[3]'
failure! time= 95
counter is 8
counter is 9
succeed! time= 115
counter is 10
counter is 11
succeed! time= 135
counter is 12
counter is 13
succeed! time= 155
counter is 14
counter is 15
succeed! time= 175
$finish called from file 'tb_top.sv', line 14.
$finish at simulation time 180
'tb_top.sv', 41: tb_top.counter.a1: started at 165s notfinished
'tb_top.sv', 41: tb_top.counter.a1: started at 145s not finished
'tb_top.sv', 46: tb_top.counter.c1: started at 165s not finished
'tb_top.sv', 46: tb_top.counter.c1: started at 145s not finished
'tb_top.sv', 46: tb_top.counter.c1, 18 attempts, 4 match
---------------------------------------------------------------------------
  VCS Coverage Metrics: during simulation line, branch was monitored
先看波形,可以看到和log对应,95ns处fail, 115,135,155,175ns处成功触发了assertion的内容。后面天蓝色线表示145/165ns处开始但是还没有结束的监测。

亮.jpg

run_vcs.tcl 的内容是:
config timebase 1ns
scope tb_top
run 1ns
call \$fsdbDumpfile(\'counter.fsdb\');
call \$fsdbDumpvars(0,tb_top);
call \$fsdbDumpSVA;
# Run to completion
run
quit
注意,这里 “call \$fsdbDumpSVA;”表示控制dump SVA的东西到fsdb文件去,如果没有这一句,波形文件counter.fsdb里面就不会有a1/c1 .
所有的控制fsdb dump方式都有两种,这个也不例外,你还可以在TB顶层加如下语句去控制dump SVA的东西:
initial begin
$fsdbDumpSVA;
end
  但是个人不倾向于使用这种方式,因为这样就等于代码过多和EDA工具捆在一起了,看起来不干净,不易读。
  另外再看看coverage 报告:(dve -cov -dir ./simv.vdb),可以看到名字为c1的coverage有被cover到,说明这种序列在此次test中被cover了四次。特别要说明的是,通常assert property() 和 cover property()会成对出现,表示我有这样的信号时序行为要求,如果违规assert就要报错,同时还要求我这种时序行为一定要cover到,没有cover到表示我这种时序行为没有测到,coverage report里会显示没有cover到。所以 cover property()也是要写的,否则assert没有报错并不代表说这种“时序行为”测到了,可能根本没有触发这个序列的第一个条件。

亮2.jpg

  例如我把上面代码中counter更新的逻辑删除,那么counter reset成0 一直保持,那么assetion根本不会报错,因为根本没有触发p1里面的q[0]==1, 下面是log(同时log里能看出来c1根本没有cover到:18 attempts, 0 match):
ucli% run
counter is 0
$finish called from file 'tb_top.sv', line 14.
$finish at simulation time 180
'tb_top.sv', 42: tb_top.counter.c1, 18 attempts, 0 match

菜菜 • 来自相关话题

1月前

成都--模拟IC设计工程师、模拟版图工程师

微信:861112547成都--模拟ic设计工程师,模拟版图工程师,欢迎自荐和推荐,欢迎自荐和推荐。

微信:861112547




成都--模拟ic设计工程师,模拟版图工程师,欢迎自荐和推荐,欢迎自荐和推荐。

菜菜 • 来自相关话题

1月前

西安、北京--数字IC设计工程师、数字ic验证工程师、RFIC、FPGA、

西安、北京、数字IC设计工程师、数字IC验证工程师、RFIC、FPGA,欢迎自荐和推荐微信:861112547

西安、北京、数字IC设计工程师、数字IC验证工程师、RFIC、FPGA,欢迎自荐和推荐


微信:861112547

admin • 来自相关话题

1月前

高通内推职位--包含应届生

高通招聘设计、验证、后端、ATE等其它岗位,有内推需求的可以联系我们,微信号chipist1

高通招聘设计、验证、后端、ATE等其它岗位,有内推需求的可以联系我们,微信号chipist1

芯片家 • 来自相关话题

1月前

Soc芯片debug 经验<3>

在介绍bug之前,继续讲解一下在在wave中debug中经常用到的小技巧。1,标亮Wave中的信号选中Wave中的信号(左键点击一下),按下字母c,打开“Change Color”对话框。选择想要的颜色。2,Bus Operations   ...查看全部

在介绍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。这个需要把问题发出来让其他部门的人一起来看看。