处女项目后关于IC验证经验的总结.docxVIP

完整的、详细的设计规范是验证工作的重要起点。　　验证工作根据设计规范（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（应该有的）：主要用于扩展设计的性能或与竞争对手相区别，只需对基本功能进行验证，若有时间与资源，可做进一步详细验证；　　Nice-to-have（最好有的）：做为设计实现的可选项