原创 Writing testbench——文件调用

Writing testbench——文件调用<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

       最近在做一个FPGA工程的测试工作，接口比较繁杂。Testbench做起来更多的是感受到用Verilog做行为级设计的局限性。比如做一个CPU的读写时序，其实很难做到两个工程的直接便捷的移植，这也在无形中加大了测试人员的工作量。下面只是随笔，随便谈谈写testbench时自己对多个文件调用的一些实践看法，当然如果特权同学提出的一些看法和技巧有待改进的地方，还望高人指点。

       对于一个顶层的testbench，对待测试的工程做例化是必须的。而如果想把这个顶层testbench对被测试工程的输入信号分给多个文件的testbench来完成，即希望把我们的testbench分几个文件来完成（单纯的只是把一个文件分为多个文件），那似乎是不可能的事。至少特权同学目前在工程实践中是无法实现这一构想。

       一般的RTL级设计中可以使用`include “xxx.v”来包含定义了参数的头文件。而《writing testbench》一书中提出在testbench也能如此使用，即在xxx.v文件中定义了一些task，然后在顶层testbench直接调用这些task，但是工程实践上却无法通过modelsim的编译，不知道是否是因为我用的5.7SE版本太老不支持的缘故。而对于这样的不设计被测试工程信号的task，可以使用模块例化的方法来达到这个目的，即xxx  uuu();这种形式就可以在顶层testbench中使用xxx.v里的一些tast,function等，不过使用时必须加上uuu.（例如我要调用xxx.v里的名为a的认为，那么我应该写成uuu.a）。

       此外，个人感觉testbench的编写很难做到所谓的分层或者说是模块化，只能是凌乱一片，有时还真很难有头绪。而且对于像特权同学现在接手的这种功能繁多，而且信号交织的逻辑设计的验证，还是尽量做单元化的测试比较可行。所谓单元化，就是使用一个完成的工程编译后的网表作为测试对象，但是具体测试时，一个功能一个功能的去添加激励，然后测试这个功能的仿真验证结果是否达到要求。

      说白了，写testbench有时就像对单片机编程，一方面你可以做一个task(类比为单片机中直接控制IO口时序的子函数)把被测试工程的一些输入信号的操作进行封装，然后在initial或者always里调用这些task（类比为上层结构里直接调用这些底层驱动的单片机子函数）。对于单片机软件开发人员来说，不仅做软件，又要对硬件接口时序熟悉。而对testbench设计者而言，何尝不是。但是一个testbench里又充满了并行和顺序的陷阱，对于设计者更是一个挑战。做得不细心或是功底不到家，往往会让测试者感觉到底是做测试还是被测试。