验证漫谈

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年也没有多大变化，还不如验证。对于新的项目，采用先进的方法学的优势还是比较大，但是对于一个已有的项目，是否采用新的方法学就需要反复权衡。

alyssa · 发表于 2011-10-9 11:18:20

真正的牛人哪有闲情雅致在这里吵？
大家自己的路自己走吧

feiying_cq · 发表于 2011-10-11 03:06:53

精彩！！！
没看完
明天继续

taoleite · 发表于 2011-10-11 11:21:21

讨论的太深入了。。。受教了，准备看看原版书了。。。

feiying_cq · 发表于 2011-10-12 02:47:57

个人感觉
代码上 testbench 比 RTL复杂繁琐

post_design · 发表于 2011-10-12 20:34:17

个人感觉
代码上 testbench 比 RTL复杂繁琐
feiying_cq 发表于 2011-10-12 02:47

登录/注册后可看大图

testbench的复杂，应该是指语法的复杂。verilog几乎就是语法最简单的语言了，sv复杂多了，导致各种eda工具对sv有不同的理解。通常来讲，tb是不会比设计更复杂的，tb出bug比rtl出bug要严重得多。另外，不要忘了，tb是可以调用c程序的，结果就是tb的复杂度转嫁给了软件。

xiao19821022 · 发表于 2011-10-13 15:45:41

终于找到这样的文章了
我的目标就是验证及架构
谢谢楼主

xxlist · 发表于 2011-10-15 21:14:23

讲的很经典哟，就是国人很浮躁惹的祸，不能静下心来做事。

g280045620 · 发表于 2011-10-16 17:22:54

mark！

[原创] 验证漫谈

站长推荐 /2