在线咨询
eetop公众号 创芯大讲堂 创芯人才网
切换到宽版

EETOP 创芯网论坛 (原名:电子顶级开发网)

手机号码,快捷登录

手机号码,快捷登录

找回密码

  登录   注册  

快捷导航
搜帖子
楼主: rhythm1988

[原创] 验证漫谈

[复制链接]
发表于 2011-10-6 19:52:19 | 显示全部楼层
XIA老师的那本verilog书真是毁人不倦啊,根本没有说明硬件描述语言的特点,多少初学者被误导!!
发表于 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年也没有多大变化,还不如验证。对于新的项目,采用先进的方法学的优势还是比较大,但是对于一个已有的项目,是否采用新的方法学就需要反复权衡。
发表于 2011-10-9 11:18:20 | 显示全部楼层
真正的牛人哪有闲情雅致在这里吵?
大家自己的路自己走吧
发表于 2011-10-11 03:06:53 | 显示全部楼层
精彩!!!
没看完
明天继续
发表于 2011-10-11 11:21:21 | 显示全部楼层
讨论的太深入了。。。受教了,准备看看原版书了。。。
发表于 2011-10-12 02:47:57 | 显示全部楼层
个人感觉
代码上 testbench 比 RTL复杂繁琐
发表于 2011-10-12 20:34:17 | 显示全部楼层



testbench的复杂,应该是指语法的复杂。verilog几乎就是语法最简单的语言了,sv复杂多了,导致各种eda工具对sv有不同的理解。通常来讲,tb是不会比设计更复杂的,tb出bug比rtl出bug要严重得多。另外,不要忘了,tb是可以调用c程序的,结果就是tb的复杂度转嫁给了软件。
发表于 2011-10-13 15:45:41 | 显示全部楼层
终于找到这样的文章了
我的目标就是验证及架构
谢谢楼主
发表于 2011-10-15 21:14:23 | 显示全部楼层
讲的很经典哟,就是国人很浮躁惹的祸,不能静下心来做事。
发表于 2011-10-16 17:22:54 | 显示全部楼层
mark!
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

站长推荐 上一条 /1 下一条

×

小黑屋| 手机版| 关于我们| 联系我们| 在线咨询| 隐私声明| EETOP 创芯网
( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2024-11-5 22:04 , Processed in 0.027474 second(s), 5 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
快速回复 返回顶部 返回列表