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要尽量提供随机激励信号来增加验证的测试空间,这样能够使验证覆盖的功能空间最大化。这里的随机一般是约束随机,而不是一般意义上的随机一般的随机没有针对性。