如何编写Testbench
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
2 如何编写Testbench
1) 何时使用initial和always
initial和always 是2个基本的过程结构语句,在仿真的一开始即开始相互并行执行。通常被动的检测响应使用always语句,而主动的产生激励使用initial语句。
initial和always的区别是always 语句不断地重复执行,initial语句则只执行一次。但是,如果希望在initial里的多次运行一个语句块,怎么办?这时可以在initial里嵌入循环语句(while,repeat,for,forever 等),如:
initial
begin
forever /* 无条件连续执行*/
begin
……
end
end
其它循环语句请参考一些教材,这里不作赘述。
另外,如果希望在仿真的某一时刻同时启动多个任务,可以使用fork....join语句。例如,在仿真开始的100 ns 后,希望同时启动发送和接收任务,而不是发送完毕后再进行接收,如下所示:
initial
begin
#100 ;
fork /*并行执行*/
Send_task ;
Receive_task ;
join
End
2) 如何作多种工作模式的遍历测试
如果设计的工作模式很多,免不了做各种模式的遍历测试,而遍历测试是需要非常大的工作量的。我们经常遇到这样的情况:很多时候,各种模式之间仅仅是部分寄存器配置值的不同,而各模式间的测试都是雷同的。有什么方法可以减轻这种遍历测试的工作量?不妨试
试for循环语句,采用循环变量来传递各种模式的配置值,会帮助减少很多测试代码,而且不会漏掉每一种模式.
initial
begin
for ( i = 0 ; i < m ; i = i + 1 ) /*遍历模式1至模式m*/
for ( j = 0 ; j < n ; j = j +1 ) /*遍历子模式1至子模式n */
begin
case ( j ) /* 设置每种模式所需的配置值*/
0 : 配置值=a ;
1 : 配置值=b ;
2 : 配置值=c ;
……
endcase
/*共同的测试向量*/
end
end
3) 如何加速问题定位过程
在这部分里,通过一些实际例子,介绍在出现问题时如何借助testbench 加快问题的定位过程。
1、监测存分配
存分配和回收示意图
在这个例子里,假设总共有2K的存块,希望在测试程序里监测存分配和回收的块号是否正确,监测是否存在同一块号重复分配、重复回收的情况。设置一个2K位的变量对存的使用情况进行记录,每一位对应一个存块,空闲的块号记为1,被占用的块号记为0。该变量的
初始值为全1,当分配一个块号出去时先判断该位是否为空闲,若是空闲则将该位设置为被占用,否则就为重复分配错误。相反,当回收一个块号时,先判断该位是否被占用,若是被占用则将该位设置为空闲,否则就为重复回收错误。程序如下:
always (posedge Clk or negedge Rst )
begin
if ( Rst == 1'b0 )
Mem_status <= 2048 {1'b1} ;
else
begin
if ( 层次路径. rd ) /* 监测存分配,block_rd 是分配的存块号*/
if ( Mem_status [ block_rd ] == 1'b1 )
Mem_status [ block_rd ] <= 1'b0 ;
else
begin
$display ( "Error! 重复分配同一存块!") ;
$stop ;
end
if ( 层次路径. wr ) /* 监测存回收,block_wr 是回收的存块号*/
if ( Mem_status [ block_wr ] == 1'b0 )
Mem_status [ block_wr ] <= 1'b1 ;
else
begin
$display ( "Error! 重复回收同一存块!") ;
$stop ;
end
end
End
2、监测部接口
如果你是位验证工程师,在做芯片级的仿真时,相信你会或曾遇到过这样的问题:在一个端口输入了激励数据,但另一端口却得不到正确的响应,而且这条路径涉及到很多模块和很多个不同设计者,为了定位问题,你可能很盲目地逐个找来设计人员,逐个模块地记录仿真波形,到解决问题时,可能几天已经过去了。
我们都知道,如果问题定位在越小的围,就越便于解决问题。所以,我们可以把模块接口间交换的数据记录到文件里,当出现问题时,就可以查看各接口的记录数据,看问题到底出现在哪个区间,简单地查看记录文件后,你就明确该找那位designer来解决问题。
3、记录有用的DEBUG信息
记录有用的debug信息,输出到标准的I/O设备上(屏幕或文件),会给你的debug 带来很大的便利,由上面的例子也可见一斑,在检测到有错误时也可使用$stop令仿真停下来。
值得注意的是,UNIX系统只有32个I/O,每个输出文件占用1个I/O设备号,其中第1个是屏幕显示,设备号是32'b1,其它I/O设备号由输出文件占用,一个信息可同时输出到屏幕和文件,如:
initial
begin
Ptr_log = $fopen ("log.txt ") ; /* 创建一个文件,获得文件指针*/
Ptr_log = Ptr_log | 32'b1 ; /* 指针同时指向log.txt 文件和屏幕*/
end
always (……)
begin
$fwrite ( Ptr_log, "useul message ",……) ; /*信息除了记录到文件同时,还显示到屏幕*/ ……
end
虽然记录文件会给debug带来很多便利,但文件操作会降低仿真的速度,因此应当适可而止。
另外写文件通常有2种方式,不同的仿真工具有所差异。一种是每写一个字节打开关闭一次文件,如Verilog-XL。另一种是先把字符暂存到存,等累积到一定数量(如8K字节)后再通过DMA方式把字符从存写到文件,如Verilog-NC。因此,后一种方式就大降低了文件的操作次数,有利于提高仿真速度。
3 编写Testbench的一些高级技巧
Verilog HDL提供很多方便和高效的建模语句,这在大多数参考书上都有介绍,在这节,只介绍一些参考教材很少介绍而较有用的建模语句。
1) force 和release