请选择 进入手机版 | 继续访问电脑版
搜索
查看: 961|回复: 1

除了多核并行,Xcelium还有哪些特性值得期待

[复制链接]
发表于 2017-5-22 16:52 | 显示全部楼层 |阅读模式
一种定义功能覆盖率的新方法的可能性

不管是CDV(Coverage Driven Verification,覆盖率驱动的验证),还是MDV(Metric Driven Verification,度量驱动的验证),都离不开Function Coverage(功能覆盖率)。而将用户需求(Specification)转换为功能覆盖率模型(Function Coverage Model),则需要花费大量的人工。

我经常在想一件事情:有没有一种方法,自动化的生成功能覆盖率的信息,就像生成RTL的代码覆盖率信息那样。如果存在这样一种方法,一定可以大量的节省验证的人力投入,以及加快项目的进度。

这次研讨会,Xcelium的一个新功能,着实让我眼前一亮:Testbench Coverage

宣传材料如此介绍Testbench Coverage:Code Coverage for SystemVerilog/UVM improves testbench quality by validating that all testbench code is executed in regression。

明显,Cadence 将其作为一种提升验证平台质量的工具了。当然,这样的提法是没有问题的。将Testbench 类比做RTL,那么明显对Testbench 的Code Coverage自然会像对RTL的Code Coverage 那样,提升Testbench的质量。

但我认为,仅仅这样使用这个功能,还远远不够。

1.jpg

传统的验证平台,基本结构如上图所示,其中,Reference Model(参考模型)使用高级语言完成了与DUV相同的功能。而验证平台就是让DUV输出的RTL处理结果,与Reference Model 输出的预期进行比对。

既然Reference Model 实现了DUV 相同的功能,那么所有DUV 在功能层面做的分支选择,在Reference Model 中一定做了相同的分支选择。

不过,Cadence的专家也想到了这一点,估计是限于从Testbench的代码覆盖率,获取功能覆盖率这条路径的方法学,还不成熟,没有获得广泛认可,所以介绍的很隐晦。在宣传材料中,是这样介绍的:“Code that is not executed may indicate holes in the functional coverage(未执行的Testbench代码,可能意味着功能覆盖率的)”。

从我多年验证的角度来看,利用Testbench的Code Coverage,实现相当一部分的Functional Coverage,其实已经相当成熟,只差工具支持这临门一脚,现在工具总算出现了。等待这一天,我已经等了很多年。

更聪明的Elaboration过程

首先,解释一下Compile 和Elaboration的差异:
Compile对代码进行语法检查,并生成基于代码的中间文件,在Cadence仿真器中对应ncvlog操作;
Elaboration自顶向下查看需要的设计(此时为中间文件)是否完备,然后将中间文件连接在一起,形成统一的可执行的快照,在Cadence仿真器中对应ncelab操作。

加快细化速度,一直是验证工程师追求的目标之一,尤其对于规模较大的设计,能显著提升整体的工作效率。为此,EDA厂商引入了增量细化(Incremental Elaboration)功能。增量细化,就是之前细化过的信息,不重新细化,仅细化新的内容。例如,我们运行一个新的用例时,验证平台(Testbench),以及DUV(RTL Code)是不变的,新的内容仅有用例文件,那么,最优的情况是我们仅细化新的用例。当然,这个例子仅仅是增量细化中最简单的一种场景。

对于SOC 设计而言,一个设计包含很多IP,如CPU、DSP、DDR Controller、USB 等等,在不同的验证层次时,会使用到其中的一个或者几个IP。在之前仿真器的增量细化过程中,只能定义一个快照(仿真可执行文件库),然后在这个快照的基础上增量细化。

假设你有如下的场景:
  • CPU+DSP+USB
  • CPU+USB
  • DSP+USB+DDR Controller
  • ……

你就需要认真管理好几个快照信息。

Cadence开发的MSIE(Multi-Snapshot Incremental Elaboration)技术,正是为了应对这样的场景。我们可以将CPU、DSP、USB、DDR Controller等分别定义为快照,即多快照(Multi-Snapshot)。在细化时,不需要调用之前细化完的(CPU+DSP+USB)快照,而是同时引入CPU、DSP、USB这三个快照,像玩乐高积木一样,把我们需要的快照拼到一起。

这么做的好处,包括两点:
  • 使用灵活,例如,DSP的代码更新了,但是CPU、USB的代码没有更新,那么我们可以仅编译+细化DSP的快照,而直接使用CPU、USB的快照;而非MSIE模式,则需要重新细化CPU+DSP+USB整体;
  • 管理清晰,通过MSIE,我们可以基于IP(CPU、DSP、USB、DDR Controller等)管理快照,我们可以简单的给快照命名,只要IP不增加,快照就不需要增加;而非MSIE的模式,每增加一个场景,就需要增加一个快照,管理起来非常困难。


当然,Cadence不是首次推出MSIE 技术,但在Xcelium中,MSIE又做了新的增强,主要在智能化方面。

之前的MSIE,验证工程师需要手动管理每个快照,采用多步手动的模式,生成/使用快照;在Xcelium中,多了Automated模式,采用单步的方式,由工具自动判断哪些快照需要重新生成,哪些快照可以使用之前的信息。采用单步自动模式,由Xcelium判断快照的方式,节省了验证工作中,更为珍贵的资源:人力。

当然,如果你习惯了采用多步手动模式,在Xcelium更是可以达到20X的细化速度提升。对于单步自动模式,在Xcelium中提速为10X。

更灵活的动态加载

2.jpg

上图的原图,来源于宣传材料,这张图已经基本可以说明其特点了。

为了加快仿真,我们可以使用Save/Restore组合。当验证达到一个仿真点后,我们使用Save命令,产生一个Snapshot(快照),如图中,可以在Boot/Reset后Save一个Snapshot;下次用例执行时,我们不用从仿真0时刻开始执行用例,而是直接加载Boot/Reset的Snapshot,即仿真从Boot/Reset完成后,继续执行。

在之前的仿真器中,我们能够方便实现的是:Boot/Reset->DUT init 1,或DUT init 1->Test 1 这样的操作。

而在Xcelium中,Snapshot可以更灵活的加载:Boot/Reset 以后,可以方便的选择是加载DUT init 1,还是DUT init 2,在DUT init 完成后,可以选择是继续执行Test 1,还是Test 2。

动态加载用例,使我们验证更为灵活,或称为敏捷:)

更智能的覆盖率

Xcelium 能够更加智能的剔除无效和重复的信息。例如:
功能覆盖率模型的Covergroup中,很多Covergroup会使用相同的Coverpoint;一个Coverpoint在A Covergroup收集和显示一遍,又在B Covergroup收集和显示一遍,重复且没有收益。Xcelium会剔除掉这样重复的Coverpoint信息
代码覆盖率的Toggle中,直连信号其实是不用考虑的,因为Toggle覆盖率,主要是检查信号的连接关系,而直连信号(应该是信号名、位宽一致)的连接关系是不验自明的,收集和显示这样的覆盖率信息,也没有意义,Xcelium将这些无效的信息剔除了。
以上这是Xcelium在剔除无效和重复信息的例子。

对于SOC系统设计而言,覆盖率还有一个特别重要的工作,即合并覆盖率信息。当RTL代码更新时,覆盖率信息的合并往往令人很头疼,仅有不关心的模块有少量代码不一致,导致两个或多个覆盖率信息合并失败,是工作中很常见的问题。Xcelium对RTL代码更新时的覆盖率信息合并,也做了相应的增强。算法会更精确,更容易使用。

其它优化的特性列表

以下功能在之前的仿真器,如Incisive中已经支持,而Xcelium对其进行了优化。可能是限于篇幅的原因,宣传材料并未详细介绍以下特性优化的内容,感兴趣的,可以咨询Cadence 的技术工程师,以获取更详细的信息。
  • X-Propagation Verification,X态传播仿真;
  • IEEE 1801(UPF) low power simulation,低功耗仿真;
  • Multi-engine MDV(JasperGold+PXP),将多个仿真引擎,如形式验证的Jasper Gold,以及硬件仿真器PXP 的用例通过情况、覆盖率等信息合并在一起观察;
  • Improved randomized distribution and quality,增加随机的分布和质量,即优化了随机的算法;
  • Improved SV migration constructs + VHDL interoperability,增加了SV 结构与VHDL的互操作性;
  • Expanded VHDL 2008 support,支持VHDL 2008,可以欧洲公司会更感兴趣;
  • Indago RTL debug and new LP(Low Power)debug,Indago RTL代码调试,以及新的低功耗调试;
  • ……


总结

抛开Xcelium 的多核提速不谈,单就Xcelium 的易用性、灵活性、智能化而言,具备了相当多的有意义的新特性,并且对老特性做了性能提升;
基于Xcelium,我们可以期待:
新的基于Testbench Coverage的Functional Coverage,指日可待;
更聪明的Elaboration 过程,让本来还需要搭积木的特性MSIE,还可以支持自动化MSIE的过程;
更灵活的动态加载,用例,仿真片段,都可以使用加载仿真Snapshot(快照)的方式实现;
更智能的覆盖率,自动剔除无效和重复的覆盖率信息;
以及一大波原有特性的功能提升。

总之,Xcelium 的确让我期待。

本文转载自公众号“IC验证工程师”

回复

使用道具 举报

发表于 2017-5-31 08:29 | 显示全部楼层
用户的优异使用体验,依托复杂后台技术,优秀人算法和解决方案则可以大大节省资源。
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

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

facebook google plus twitter linkedin youku weibo rss
©2019 Microchip Corporation

小黑屋|手机版|Archiver|Tensilica技术社区

GMT+8, 2019-9-19 21:39 , Processed in 0.090216 second(s), 9 queries , MemCache On.

快速回复 返回顶部 返回列表