路科验证(Rocker IC)专注于验证系统思想和前沿工程资讯,拥有一支活跃的技术原创团队,著有《芯片验证漫游指南》一书,致力为高校微电子相关专业学生与IC从业人员提供技术食粮。 您可以在手机移动端同步关注微信订阅号“路科验证”或是登录网页www.rockeric.com了解更多资讯。如果您需要联系我们,请发送邮件至 bin.rocker.liu@intel.com 。

解决系统验证复杂性难题恐怕只有它了

上一篇 / 下一篇  2018-06-29 19:23:12 / 个人分类:验证前沿资讯

 rockeric.com

芯片到底验到什么时候才能流片呢?这是芯片开发团队面对的最棘手问题之一,无数验证经理和验证工程师可能都考虑过tape out标准。


自20世纪80年代以来,为了量化解决这一问题,已经定义了一些指标和方法来降低流片风险,如功能覆盖率和代码覆盖率。如今利用这两个并不完美的指标,已经给我们流片提供了充分的信心。但是SoC设计愈加复杂的今天,这些指标对于系统级的验证看起来这有点鸡肋了。


在芯片设计中IP化极普遍的今天,组成SoC的众多模块都早已被验证过了,因此SoC级别的验证就显得尤为重要了。但问题是,能体现系统级验证质量的可靠指标是什么?


业内也在研究如何将现有概念和想法进行改进和实践,PSWG(Portable Simulus Working Groups)针对这一问题也将开启新一轮的讨论。


验证焦点的转换

自SystemVerilog和UVM创立以来,验证工作中,验证机制和覆盖空间已经发生了许多变化。Cadence研究员Mike Stellfox讲到:“对于IP和子系统验证,设计功能很好地映射到功能覆盖组以及交叉的功能覆盖组。使用随机约束可以尽可能详尽地验证模块所有设计功能。但是简单沿用之前的功能覆盖率不太适用于大规模SoC,如今的SoC级的验证常常是跨平台的验证,如simulation、emulation、FPGA等”


Mentor产品营销经理Mark Olen强调说:“系统级的覆盖率模型不仅仅是所有模块功能覆盖率的汇总模型,如果在SoC中只针对模块功能覆盖率展开验证,这只是在重复之前的工作,而且是在仿真运行更慢的验证环境中做无用功。”


Breker Verification Systems的首席执行官Adnan Hamid说:“系统级覆盖率和大数据有一些重叠,为验证一个相当简单的Arm系统,便携激励工具可以产生10^93个可能的路径。所有路径都可能映射着真实的行为。因此,尽管便携激励工具会定义覆盖率空间,我们依然需要知道的是哪些覆盖空间是有效的在SoC级别,不会有人会尝试验证SoC中每个设计功能的交互组合,规模太大了,没有可操作性


定义覆盖空间

便携激励图谱定义了一系列设计的预期执行功能,也可被称为测试场景或测试用例,便携激励工具可以基于便携激励图谱产生测试用例,这些测试用例都是完整的,并带有自我检查功能,而且可以在多个执行环境(simulation、emulation、FPGA等)中执行。




覆盖空间模型

除了每条可能的路径之外,我们还必须在图中包含并发活动的不同组合。假设所有路径都是独立的(当然真实场景一般不会这样),如果只有两个操作可能同时发生,所有路径都是独立的,那么总覆盖空间现在就是N x(N-1),其中N 是路径总数。


便携激励只是想要模拟硬件的行为。但是,很多时候工具事先并不能够知道真实场景会遇到怎样的复杂情况。设想有这样的一个测试,两个线程需要对同一资源进行访问,但这一资源只能同时被一个主设备访问,这样的话便携激励工具就需要考虑每个线程应该访问的时间,但便携激励生成器生成的测试不知道前面的任务可能需要多长时间,因此来自两个线程的请求可能重叠的顺序或方式也无法确定。所以激励的执行还需要返回其执行状况,以便更好的收集和提高覆盖率。

所以定义全面的覆盖空间需要考虑的因素也很多。


便携激励的完整性

而且便携激励图谱的完整性很难评估,因为它可能涉及到用自然语言编写的需求文档,你需要确定整个SoC系统能够做什么,然后才能分解它们,你要考虑设计所有可以执行的行为模型,并与功能列表进行交叉比对。


过去,通过比较不同类型的覆盖率来验证完整性。例如,通过查看代码覆盖率和功能覆盖率结果来确定缺失哪些测试激励。这当然是可行的,功能概率和代码覆盖率都是反映我们验证进度的重要指标。但Hamid继续说:“但是implementation coverage和intent coverage是两个不同的事情,implementation coverage是我们设计所完成的功能,intent coverage是芯片本身应该要完成的功能。而在系统层面,intent coverage很重要,过去20年,我们都把implementation coverage当作intent coverage。100%的implementation coverage并不能保证所有的设计意图都达标了。”


OneSpin Solutions产品管理总监Ashish Darbari说:“不能简单的用之前代码覆盖率、FSM等覆盖率的方式来看待这种根据行为定义的覆盖率。代码覆盖率、FSM等覆盖率等不能宏观的反映覆盖空间。”


那么我们如何确保覆盖空间的完整性呢?我们知道,实际的覆盖目标永远无法接近所有的意图覆盖空间。由于实际SoC验证中能覆盖的范围很窄,因此不能期望设计的所有功能都会被系统级测试覆盖。这仍然是模块级验证的任务。业界需要的是一种为总体覆盖空间提取有效子集的方法,这一子集可以在系统级展开验证。


定义覆盖率目标

业界如今也正是在这里挣扎,因为系统级覆盖率不仅仅是关注功能。性能和功耗也在验证考量范围之内。


Stellfox说:“在SoC验证中,功耗和性能的重要性与功能相当,考虑一款具有图像识别处理功能的汽车芯片,并且你有一个用例,测得在相机接口和加速器之间无法获得足够的带宽。这虽然是性能的问题,但可能是一场灾难性的失败。我们需要的是构建能够强调性能和功耗的测试场景,并跟测试用例的测试结果。”


有人建议,在不同验证方向上找到最坏情况组合,这一方案看起来似乎也是合理的。 Sonics首席技术官Drew Wingard表示:“如果验证场景将所有最坏情况都组合起来,芯片设计可能就很难做了,至少会由于开发周期过长而使市场表现不如预期。将所有的最坏情况组合在一起太过于保守了,验证工程师的艺术是找出哪些最坏情况不会同时发生,并证明这是安全的,这一工作,可能也会让验证工程师的工作更有趣一些吧。


业界目前正试图寻找一个最佳实践方案。 Stellfox表示:“类似于UVM在IP和子系统的随机激励应用实践,SoC级和大型系统的验证也终将找到一个可行的优化验证方案,而PS工具可能在这以方案中扮演重要角色。“





TAG:

 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

路科验证

路科验证

路科验证(Rocker IC)专注于验证系统思想和前沿工程资讯,拥有一支活跃的技术原创团队,为高校微电子相关专业学生与IC从业人员提供技术食粮。 您可以在手机移动端同步关注微信订阅号“路科验证”。如果您需要联系我们,请发送邮件至 rocker.ic@vip.163.com 或者 bin.rocker.liu@intel.com 。

日历

« 2018-07-22  
1234567
891011121314
15161718192021
22232425262728
293031    

数据统计

  • 访问量: 132117
  • 日志数: 238
  • 建立时间: 2016-06-25
  • 更新时间: 2018-06-29

RSS订阅

Open Toolbar