IC验证经验总结

1.验证工作

根据设计规范（specification）进行，详细的spec是RTL代码编写工作的依据，也是验证工作的依据。当验证过程发现DUT的响应与testbench预计的不符时，需要根据spec判断是DUT出现错误还是testbench出现错误

2.参数化的全局定义

在编写testbench过程中，如果激励中有一些重复的事件，可以考虑将这些语句编写成一个task

• 1.Register相关位及其数值可以全局宏定义在reg_define.v中。
• 2.相关路径可以全局宏定义在define_board.v中。
• 3.系统重要变量的显示信息可以定义在display.v中。
• 4.与Register相关的比较任务和报错任务可以编写成task定义在reg_cmp.v中。
• 5.时钟周期参数的定义，一般局部定义，用parameter定义。

3.测试案例

• 1．case本身尽可能模块化。
• 2．case最好是自动的、自检的case，可以自动报错，以节省测试时间。
• 3．覆盖率问题：覆盖率分为功能覆盖率，代码覆盖率，还有人为添加的一些覆盖点的覆盖率。它提供关于仿真的统计信息，包括所经历的结构和转移，以及如何经历。可以决定设计的哪些部分没有被仿真，以知道验证中的薄弱处。最容易实现100%的是代码覆盖率，但是如果verilog代码中使用了case的default，那就很难实现100%覆盖了。功能覆盖率就是一些函数的功能，还有状态机的状态覆盖率等等。然后还有就是验证工程师添加的覆盖点。一般验证工作完成以后要使用这些东西完成报告的。
• 4．主要的仿真线程常常用初始语句initial模仿，包含一系列阻塞表达式。
• 5．个人认为，写case本身并不是很重要，重要的是你的case里的测试点是否全面，相关的东西测的全不全。
• 6．case要尽量提供随机激励信号来增加验证的测试空间，这样能够使验证覆盖的功能空间最大化。这里的随机一般是约束随机，而不是一般意义上的随机一般的随机没有针对性。