Timer测试方案 Timer测试平台实现 测试平台debug注意事项

一、测试的基本概念

IC验证，一般也称“功能验证”，我们今天要讲的，不是这个，是它的简化版：模块测试，是设计工程师完成代码设计后，需要自己做的这部分验证工作。IC验证，我们将会在后续文章中，专门讲解。

为什么说设计工程师做的模块测试是IC验证的简化版？

在回答这个问题之前，我们先了解几个概念：

• 白盒测试（White-box Test）
• 黑盒测试（Black-box Test）
• 灰盒测试（Grey-box Test）

这个几个概念在软件工程中都有介绍，IC设计验证中一样存在这几个概念涉及的工作，所以直接借用。

白盒测试，一般是针对代码结构进行的测试，所以也有称白盒测试为“结构测试”。

黑盒测试，一般是行为测试，把设计当黑盒子，不用看代码不用针对代码结构进行测试。我们前面提到的IC验证，通常指的“功能验证”，就属于“黑盒测试”。

灰盒测试，介于白盒测试和黑盒测试之间，兼顾两者优点。

在实际工作中，设计工程师完成代码设计之后，交给验证工程师之前，除了检查语法、可综合性之外（当然还有其他检查，设计刚入门，不用关心这么多），还需要进行基本的测试，这个基本的测试，原则上应该是白盒测试。

实际上，因为全靠设计工程师构造测试例来做覆盖完成白盒测试的工作量太大，一般都用更实际的做法：简单的功能测试。

做法：确认设计的代码基本可以工作，基本的读写没有问题后，就交给验证工程师来做“IC验证”，也就是功能验证。当然，不同的团队对设计交付代码质量的要求不一样，那么测试的内容和工作量也有差异。

二、Timer测试方案

Timer的测试方案涵盖的内容包括：测试内容、测试例、测试平台结构，在实际操作中，有些团队略去了测试内容的梳理和测试平台结构的设计，仅仅构造了一些这对基本功能的测试例，我们这部分保留这些内容，但是做了精简。

1．测试内容

Timer模块的白盒测试，简化为基本的功能测试，如：

• 对总线接口的读写检查
• 对模块寄存器的复位值的检查；
• 对寄存器读写的检查；
• 对计数基本功能的检查；
• 对代码行、if语句各分支的执行检查等；

针对这些功能，构造相应的测试例进行测试。

2．测试例

根据规格书上梳理待测试的功能。实际操作时有的工程师会简化，经测试基本功能，确认设计可以动起来。如下表格是测试例的片段。

3．测试平台结构

完成待测试功能的梳理和测试例的构造，我们接着要做是，设计构造测试平台（Testbench）。

DUT：待测试对象（Device Under Test）,也就是我们前面用Verilog或VHDL写的RTL设计代码。

激励：DUT和testbench之间只能通过顶层接口连接，所以，所有的测试数据都必须按照顶层接口的时序要求，输入进DUT中。这里的测试数据也叫测试例或者测试向量。测试例，一般是采用直接测试例进行测试，这种测试方式针对性强，能够快速将模块驱动起来。

结果比较：等待DUT输出结果（DUT会有标识，或通过主机轮询，或DUT自己有标识接口），testbench必须按照顶层接口的时序要求，取出DUT的输出结果，再与期望值比较，最后将比较结果打印出来，便于查看。

三、Timer测试平台实现

实现语言： 可以用verilog语言，或者VHDL语言，或者SystemVerilog语言等。

仿真工具 ：Modelsim、VCS、NC-Verilog/NC-VHDL

下面是平台代码实现的片段。

1. 顶层文件代码

顶层包含：

• 时钟和复位信号的定义；
• 时钟周期的参数定义；
• 验证环境文件的导入；
• 时钟的产生；
• 复位信号的产生；
• 模块的例化；
• 在初始化中运行测试例任务；

2 .总线激励

假定Timer的总线接口是Z总线，下面的代码就是实现一个Z总线的写操作，将wdata写入zaddr这个地址里面。

3.测试例

测试例主要是将上面的总线驱动task调用起来对模块进行驱动，让模块正常工作起来。同时设定一定的循环次数，每一次新的运行需要等待中断到来之后进行新的寄存器配置。

4.结果比较

为了提高debug效率，将从DUT出来的结果和理想结果进行自动对比，并将对比结果打印出来。

结果比较一般流程是等待DUT的中断到来，然后读取Timer的寄存器的值与期望值做比较。

四、测试平台Debug注意事项

1. 在对整个testbench进行编译时候，初期语法错误较多，这时候需要多联系上下文来check，很多时候工具报的问题不在出错误的地方。
2. Debug经常遇到的问题是测试例跑死，这种情况一般是等待的事件没有等到，或者寄存器配置错误。