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

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

手机号码,快捷登录

手机号码,快捷登录

找回密码

  登录   注册  

快捷导航
搜帖子
查看: 20787|回复: 33

[求助] 请教CPU的验证方法

[复制链接]
发表于 2012-4-25 11:09:50 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?注册

x
通过手工写激励的方法去验证,速度慢而且比较难发现隐藏得比较深的BUG。FPGA原型验证速度上会好一些,但可能发现有BUG而不容易定位。
CPU验证有没有像VMM这样一种比较不错的验证平台呢?
发表于 2012-4-25 11:30:49 | 显示全部楼层
说起验证方法,我以前想到了一个比较前卫的方法。那就是把DUT(验证目标module)和软核处理器一起放在同一块FPGA内部。让软核处理器来控制DUT的输入和时钟,并收集DUT的输出来分析此次测试是否正确。那么每一次test case都是一段C程序;我们把n个test case连缀在一起,就是一套该DUT的测试流程。这种测试方法比任何服务器高速的仿真都要快,因为可综合的DUT是实时在运行。以后我们稍微修改一下DUT,只需要重新运行一次它的验证嵌入式软件,即可得到是否通过不通过。

举个例子,你在服务器上跑一个DUT验证,测试程序要跑一秒钟,那么服务器可能要跑十来个小时;但是DUT和软核处理器在FPGA里面,排除软核处理器的处理时间,那么可能只需要十来秒钟;这个差别不可以道里计。特别是后期,如果对DUT只是小小的改动,那么这套测试系统做回归测试,只要几分钟就确保OK。

这个思想理念是太前卫了。把做验证的人员由软件人员变成了嵌入式软件开发人员,所以只是说说而已。
 楼主| 发表于 2012-4-25 11:41:00 | 显示全部楼层
恩,这的确是一个不错的方法,有些Emulator的意思。
但是这样适合已经有硬体GOLDEN的情况,如果没有硬体的GOLDEN就需要另想办法。
很早之前有测试过6502,遇到一个非常难于发现的BUG,IRQn在某一条指令的特定时钟周期拉下去的时候就会导致错误,这种BUG隐藏得比较深,可能透过普通的验证或看看代码覆盖率都难于发现,有时候也难于把2^n种情况都验证完全。
发表于 2012-4-25 12:31:16 | 显示全部楼层
对于golden程序,软核处理器本来就吃C程序的,这个根本不是问题。如果生成golden吃力,完全可以生成ROM数据,软核处理器直接取来比对。
这种方法的最大好处在于迅速的暴露bug的隐藏点。我们知道,验证到最后,几乎都是穷举,如果使用仿真软件vcs\ncverilog搞穷举,那个时间开销太大了。使用FPGA来穷举,时间上绝对节省太多。
如果穷举不是问题,那么验证测试会让bug尽快暴露的。
发表于 2012-4-25 12:50:23 | 显示全部楼层
如果再加上一个嵌入式操作系统,那就更加绝了。所以说不定以后,FPGA+软核处理器+嵌入式系统 成为数字电路设计验证的一套解决方案了。
 楼主| 发表于 2012-4-25 14:59:21 | 显示全部楼层
才明白版主的意思,不需要为DUT单独写一个功能一模一样的GOLDEN模型,而是用两个不同的CPU(其中一个是软核处理器),来比对同一段C程序的执行结果,一般结果对了就说明DUT没有问题,是个非常不错的方法!
发表于 2012-4-25 15:23:22 | 显示全部楼层
回复 6# vongy

不是这个意思,我指的是 软核处理器+c程序 控制一切。这个一切包括:启动对DUT的输入,对DUT给出正确的时序和数据;收集DUT的输出数据;判断DUT的输出是否满足golden的要求,这个golden既可以是C程序产生的,也可以是bin数据,软核处理器只负责比对。

比如有一个FFT的IP核。我们把FFT的IP核和软核处理器一起放入FPGA内部,然后穷举生成数据,通过FFT IP核的输入灌入,在FFT计算好了以后,把FFT变换的结果暂存入某块RAM内。软核处理器就用输入数据,用C程序的函数计算一个结果,这个结果和FFT IP核的输出结果比较,如果正确,就表明这次验证OK。

就算FPGA只跑20 MHz,和一个2GMHz CPU的服务器跑vcs/ncverilog,两者比较起来,FPGA也会是飞速。
发表于 2012-4-26 00:05:39 | 显示全部楼层
这就是一个hardware emulation的过程,也是verification的一步,但还是无法代替simulation. simulation的好处是在coding阶段,就可以开始verification,而且还很容易发现bug和trace bug,虽然速度方面有些限制,而且和实际的状况比起来比较理想。在楼主设想的方法里面,如果发现DUT的结果和软核软件运算出来的不同,如果定位bug呢?
发表于 2012-4-26 09:51:00 | 显示全部楼层
回复 8# tbb2009

和一般的hardware emulation不同的是,你不需要信号发生器,不需要逻辑分析仪。和DUT一下进入FPGA的软核处理器,通过C程序搞定这一切了。传统的hardware emulation需要PC来控制专用的电路板,费用不菲,一旦定制,新增加功能很难改变。现在,如果让软核处理器+C程序,那么改变就非常灵活了,而且实现起来,也将节省大量的硬件费用。

它当然不能取代simulation。要注意到软核处理器只是操作DUT的顶层,DUT里面的大大小小的信号,软核处理器是无法采集和改变的——除非你把它引入顶层,留给软核处理器使用。因此,这种方法最大的优点是快捷迅速,改变灵活。我们只要编好了C程序,C程序对DUT进行密集式的轰击。DUT经过这番轰击,总会把bug暴露出来,那么我们找到了可能发生bug的地方,再通过simulation对相关内部信号的观察,就可以确定bug,来修正了。

所以如果DUT成熟了,或者小的改动要进行回归测试,那么这种方法会发挥它最大的效率。
发表于 2012-4-26 17:53:50 | 显示全部楼层
如果用SVA呢(systemverilog assertions),我们在写verilog代码的时候,就给每一条指令实现的功能,赋予一条属性,这样,在代码仿真的时候,就可以快速准确的定位出错的地点。
这种 设计即验证 的方法貌似也比较新吧~~~
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

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

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

GMT+8, 2024-11-5 16:32 , Processed in 0.027084 second(s), 8 queries , Gzip On, Redis On.

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