当前位置:首页 > 公众号精选 > 芯片验证工程师
[导读]什么是功能覆盖率?验证中的覆盖率分功能覆盖率和代码覆盖率两种,断言覆盖率可归类为功能覆盖率。顾名思义,功能覆盖率用于衡量设计中有多少功能被覆盖到了,被验证了,而代码覆盖率则是衡量代码实现中有多少语句被执行到了。前者是基于设计的源头,而后者是基于设计的最终实现,源头是本,实现是末。...

么是功能覆盖率?验证中的覆盖率分功能覆盖率和代码覆盖率两种,断言覆盖率可归类为功能覆盖率。

顾名思义,功能覆盖率用于衡量设计中有多少功能被覆盖到了,被验证了,而代码覆盖率则是衡量代码实现中有多少语句被执行到了。前者是基于设计的源头,而后者是基于设计的最终实现,源头是本,实现是末。抓住了根本,目标指日可待;舍本逐末,事倍功半。
为什么是功能覆盖率?现在的主流的验证语言是systemverilog,其特点之一就是约束下的随机。相比较定向测试,它的验证效率更高,定向测试需要对每个功能点,每个测试维度去构造不同的用例测试,只能是想多少测多少,激励空间是已知的。而随机化的验证,其激励空间要大的多,远远大于定向测试的激励空间。定向测试好处是每个用例测试激励明确,只要测试通过了,用例的目标也就达成了,而随机化的验证问题是测试激励不明确,虽然它的激励空间更大,但是怎样知道用例执行完成后,覆盖到了哪些激励空间,没有覆盖到哪些激励空间呢?所以需要一个衡量标准,这就是功能覆盖率。
怎样做功能覆盖率?
需求!需求!需求!重要的事情说三遍,经过提取、整理和评审一致通过的验证需求,是做功能覆盖率的依据,要保证每个需求的充分验证,有哪些点必须验证到,这个是必须具体化、量化的,想不清楚这个问题就是没有真正理解需求,验证质量又如何保证呢。
Systemverilog语言对于功能覆盖率有很好的支持,其中覆盖点和交叉覆盖的概念非常重要。覆盖点对应的是上面提到的量化后的需求,这只是点,多个点就是一条线,是一个维度的覆盖;一个设计诸多功能并不是完全孤立的,所以单单验证一个点、一条线远远的不够的,交叉覆盖率就是来把这些点、线连接起来,织成了一张网。通过这张网把所有需求囊括其中。
基于功能覆盖率驱动的验证:有被动驱动和主动驱动两种。
所谓被动驱动,有点“马后炮”的嫌疑,在用例执行完成后,通过查看覆盖率报告来对未覆盖到的点补充定向用例覆盖;而主动驱动,是在用例执行过程中,以功能覆盖率100%或预期的百分比作为退出条件,否则会一直进行随机测试,“不达目的誓不罢休”。
所谓行百里者半九十,做随机化验证也存在着越临近终点,需要付出的更多,因为越到最后随机重复的概率越大,随机成千上万次可能才能有一个新覆盖点,命中率越来越低。针对这个问题,如果采用主动驱动方法,可以提前筛选掉重复的随机,只采用对覆盖率有贡献的随机值,将命中率提高到100%。
但被动驱动方法也有其优势,覆盖组是对所有用例的随机进行采样,而主动驱动是针对单一用例来实现的。通过诸多项目经验来看,首推主动驱动方法,效率更高。
结论
理解清楚验证需求,具体量化验证需求,用功能覆盖率编织的一张大网,把所有的覆盖点一网打尽,采用主动、被动驱动方法做到攻守兼备,让验证工作更加高质、高效。

本站声明: 本文章由作者或相关机构授权发布,目的在于传递更多信息,并不代表本站赞同其观点,本站亦不保证或承诺内容真实性等。需要转载请联系该专栏作者,如若文章内容侵犯您的权益,请及时联系本站删除。
关闭
关闭