关于IC验证经验的总结.doc

关于IC验证经验的总结完整的、详细的设计规范是验证工作的重要起点。 　　验证工作根据设计规范（Specification）进行，详细的Spec是RTL代码的编写工作的依据，也是验证工作的依据。当验证过程发现DUT的响应与testbench预计的不符时，需要根据Spec判断是DUT出现错误还是testbench出现错误。 参数化的全局定义 Register相关位及其数值的全局宏定义。reg_define.v 相关路径的全局宏定义。define_board.v 系统重要变量的显示信息。display.v 与Register相关的比较任务和报错任务。reg_cmp 时钟周期参数的定义，一般局部定义，用parameter定义。 存取波形及相应变量的数据，使用`ifdef为全局定义使用 1.波形源头文件是VCD波形，但过于庞大，可用来做功耗分析。 　　$dumpfile(“wave.vcd”); 　　$dumpvars(0, xxx); 　　$dump0ff; 　　$dumpflush; 2.SHM波形是Cadence的，可以用simvision打开。 　　$shm_open(“wave.shm”); 　　$shm_probe(xxx, “AST”); 　　$shm_close; 3.FSDB波形是Novas的，可以用nwave打开。 　　$fsdbDumpfile(“wave.fsdb”); 　　$fsdbDumpvars(0, xxx); 4.VPD波形是Synopsys的，可以用dve打开。 　　$vcdplusfile(“wave.vpd”); 　　$vcdpluson(0, xxx); 5.变量的存取，可以使用宏来选择变量的存取与否与存取时间使用。 　　`ifdef SAVE_LROUT ?????????? start_save = 1’b1; ?????????? #(10e6)??? stop_save = 1’b1; 　　`endif 　　xxx = $fopen(“xxx”, “w”); 　　if (start_save !stop_save) 　　$fwrite(xxx, “%f\n”, x); 　　$fclose; 测试案例，case 　　1．case本身尽可能模块化。`include”verify.v” 　　2．自动的、自检的case，自动报错，以节省测试时间。 　　3．覆盖率问题：覆盖率分为功能覆盖率，代码覆盖率，还有人为添加的一些覆盖点的覆盖率。它提供关于仿真的统计信息，包括所经历的结构和转移，以及如何经历。可以决定设计的哪些部分没有被仿真，以知道验证中的薄弱处。最容易实现100%的是代码覆盖率，但是如果verilog代码中使用了case的default，那就很难实现100%覆盖了。功能覆盖率就是一些函数的功能，还有状态机的状态覆盖率等等。然后还有就是验证工程师添加的覆盖点。一般验证工作完成以后要使用这些东西完成报告的。 　　4．主要的仿真线程常常用初始语句initial模仿，包含一系列阻塞表达式。 　　5．个人认为，写case本身并不是很重要，重要的是你的case里的测试点是否全面，相关的东西测的全不全。 　　6．case要尽量提供随机激励信号来增加验证的测试空间，这样能够使验证覆盖的功能空间最大化。这里的随机一般是约束随机，而不是一般意义上的随机一般的随机没有针对性。 　　7．case的编写可以分为以下三步：From specification to features, From features to testcase, From testcase to testbenches 　　（1）Case编写的第一步是辨别需要验证的特征（feature），不同的feature，适合的验证层次也不同，有些适合在component（unit/reusable/ASIC）级进行验证，有些则必须在system级验证。Component级的feature完全包含在待验证的component中，因此其验证与系统其他模块无关，可以独立进行。System-level features涉及系统多个单元之间的相互作用，System-level features不宜多，能够在Component-level验证的features，不要定义为System-level features。 　　（2）形成testcase之前，首先要对Features进行分类： 　　Must-have（必须的）：设计为了能正常工作或满足市场需要而必须具有的功能，这是first-time success的主要内容，应在各种条件下做彻底的验证。 　　Should-have（应该有的）：主要用于扩展设计的性能或与竞争对手相区别，只需对