验证漫谈

dizhixiong · 发表于 2011-10-6 19:52:19

XIA老师的那本verilog书真是毁人不倦啊，根本没有说明硬件描述语言的特点，多少初学者被误导！！

post_design · 发表于 2011-10-8 11:09:42

验证的方式有很多种，所谓少量的test case依靠大量的随机就能完成验证只是针对一般情况。本人目前做的一个通信项目，验证的覆盖率全部由软件工程师来保证，芯片验证仅能拿到vector，看似这种方法太原始了，但是针对这个项目却是最有效的，因为只有软件工程师对这个系统理解最深刻。有的时候验证更是一个系统工作，往往需要算法，软件，系统，甚至做模拟的人都参与进来。

对于debug，验证工程师只能做到最简单的工作，debug永远都是designer的工作。白盒的debug最简单，难点是fix bug。发现bug的数量从来不是验证工程师的绩效考核范围，验证工程师唯一考虑的就是验证的覆盖范围。

至于有人提到仿真速度的问题，我认为首先要确保在顶层只跑最必要的case，如果把不必要的case也放在顶层跑，那绝对是浪费时间。在集成的时候，其实可以做很多script来自动完成。比如IO mux，如果人工完成，不仅工作量巨大，而且极容易出错，如果用脚本完成既省力省时还可靠性高。
eda工具都能提供分析各某块消耗系统资源的功能，如果发现testbench消耗的资源比较大，这就需要优化了。至于RTL，最有效的手段就是硬件加速器，代价也最昂贵。多核并行仿真也能在一定程度上提高仿真速度。另外，FPGA也可以协同仿真。

相比于芯片结构，testbench的复杂度很低，这也就导致各种方法学并不具备压倒性的优势。很多复杂的项目，用最传统的verilog一样能够很好的完成。这种情况在软件工程上是不可能的。就算是芯片，复杂度也远远无法和软件相比，其设计方法学20年也没有多大变化，还不如验证。对于新的项目，采用先进的方法学的优势还是比较大，但是对于一个已有的项目，是否采用新的方法学就需要反复权衡。