日志

验证的方法篇之八：趋势展望

已有 1989 次阅读| 2016-9-11 16:22 |个人分类:验证系统思想

目前主要的验证方式包括动态仿真、形式验证和硬件加速，那么如何选择它们，已经是否可以构建一个可复用的验证平台实现这些不同验证方法的跨越是接下来我们需要关心的。随着设计的尺寸和复杂度在不断提高，即便有IP复用的方式来缩短设计时间，更多模块之间的互动可能性也要求更充分地去验证这些状态空间。目前仿真技术的瓶颈在于速度，随着这几年实际项目中的切身感受，仿真技术除了需要EDA厂商提供加速方式以外，项目自身也需要结合实际情况使得仿真可以实现相对轻量化来保证可接受的速度。

形式验证可以穷尽检验一些设计属性。对于一个合适尺寸的IP，它只需要通过一些时钟周期就可以穷尽检验出设计属性是否满足。例如一个32位的乘法器，如果通过动态验证可能需要几年的时间来穷举出所有可能的情况来完全验证，然而对于形式验证而言，往往几分钟到数小时的时间就可以了。同时，形式验证伴随着设计的复杂度提高状态空间指数增长的情况下，运行速度也急剧下降，IP是合适的形式验证尺寸。

尽管在学术和工业领域，对于形式验证的算法研究非常活跃，它还需要解决的问题是，使用者对于形式验证语言的不精通。因为使用者还需要保证设计属性描述是精确反映实际设计的，同时属性描述的总和可以对等一个设计的所有功能，只有这两点满足了，才有足够信心确信形式验证的完备性。目前我们可以通过EDA厂商提供的可复用的断言库来实现高层次的属性描述，弥补我们对断言描述本身的知识缺乏。此外，形式验证让我们“不那么放心”的一点是，它无法像仿真一样为我们提供一个动态的行为，而验证人员又需要“眼见为实”来亲自判断设计的实际行为是否正确。所以，如果采取形式验证，建议的一种方式为以动态仿真为辅助手段，来完成基本的功能激励和检查。

硬件加速的历史要更悠久，这可以回溯到1980中期到1990中后期，在RTL仿真还未推出被广泛使用之前，占据验证市场的还是门级硬件模拟技术，随着Verilog和VHDL的语言推出和自动逻辑综合技术的应用，RTL仿真就逐渐取代了硬件加速技术。这一技术更迭的背后，关键因素还是速度，因为那一时期的设计还不足以复杂到仿真器性能无法满足的情况。20年后的今天，硬件加速技术显然又有着收复失地的趋势，三大主流工具商都提供各自的硬件加速解决方案。

硬件加速技术的速度优势还是相当明显的。动态仿真的性能平均保持在1KHz，硬件模拟技术大致在1MHz左右，而FPGA在10MHz左右。无论是硬件模拟还是FPGA，都要比动态仿真技术的速度显著提高不少，通过更快速的验证技术，我们也才能够抵消日益复杂的设计，和体量不断增大的嵌入式软件代码测试。

那么是不是硬件加速技术就是未来的主流呢？仍然不是绝对的。目前硬件加速技术也有自己的不足，比如：

编译时间较长。这是因为硬件加速加速需要额外的逻辑综合和硬件映射的时间，而综合、布局、布线和映射在动态仿真中是不需要的环节。
调试手段少且慢。尽管最新的硬件加速技术可以实现记录任何信号、修改信号或者等待信号事件等常用的仿真调试手段，然而由于技术限制，如果要添加或者修改新的信号，仍然需要再次编译消耗大量事件。此外，由于存储的限制，我们也无法记录所有层次的信号，而只能有选择性的记录某些信号在某一段时间内的行为。从调试流程上来看，硬件加速技术仍然无法达到动态仿真的易调试程度。

这么看来，尽管在速度上硬件加速有显著的优势，但是从调试层面，动态仿真和形式验证也有其优点。那么，实际中我们是怎么结合这些技术的呢？一般我们倾向于以下方式：

在模块级或者IP级验证中，更多使用动态仿真和形式验证，尽量将缺陷率曲线更快更多地收敛在这一层次。
到了芯片系统级验证中，我们倾向于使用动态仿真测试模块之间综合的系统任务和集成关系。
对于耗时的测试用例，例如固件启动测试、性能测试、大规模数据存储测试等我们会在系统测试阶段使用硬件加速加速来更快得到结果。

从验证平台搭建和复用的角度出发，我们也需要考虑，如何实现一个可以横跨这三种技术的可复用平台呢？通过一个统一平台，如果可以自如地在这三种技术之间实现横向跨越，以及完成从模块级到子系统级再到芯片级验证的复用实现纵向复用，这将是接下来实现技术融合和验证层次复用的方向。为讨论这一方向，我们分别以下列问题展开叙述：

不同技术之间的验证平台横向跨越
不同层次之间的验证平台纵向复用

技术之间的横向跨越

在解决横向跨越的问题之前，我们先需要理解为什么有这样的需求？从下面这张图可以看到这三种技术之前有着共通的技术桥接，和一些核心的基础技术：

我们的核心基础技术有验证IP、覆盖率、调试和软件驱动测试，而三种技术构建于这些基础之上。例如它们都需要提供调试方式、也需要提供各自的覆盖率来完成验证。
形式验证和动态仿真之间，它们可以通过断言和X-prop技术来桥接，因为这两种验证方法都可以通过两种技术完成验证。
间于动态仿真和硬件加速之间，我们也可以通过软硬件协同验证的方式，实现这两种技术的桥接。
而对于断言VIP，我们已经知道的是，可以利用它完成形式验证，或者植入到动态仿真环境中。而一些可以综合的断言VIP，也可以被移植到硬件加速平台中继续完成验证的任务。

那么基于这些项目实际中的桥接，如何设计出可以合并的数据库和通用的验证平台就成为了关键。但对于这两点，目前三大工具商还缺乏一种完整的解决方案。例如，验证的覆盖率数据库如何在三种技术中实现互通和合并？如何定义出合理的结构完成形式验证平台到动态仿真平台的复用？以及什么样的动态仿真平台才可以顺利移植到硬件加速平台上呢？这些都是还有待思考解决的问题。

层次之间的纵向复用
在不同验证层次之间的复用，我们也会遭遇到实际的痛点。例如，随机约束的仿真方法（SystemVerilog，UVM/OVM或者Specman/e）适合于模块级和子系统级验证，而直接测试方法（C/C++）则适用于子系统级和芯片系统级的验证过程。在这里，我们看到了子系统级验证有着两种可能的验证方法，我们需要考虑是否选择其中一种，还是两折兼具？如何实现模块级随机测试到子系统级随机测试的复用？如何实现子系统级直接测试到芯片系统级的直接测试复用？又譬如通过何种方式实现从随机约束测试到直接测试的复用？因为只有完成了层次之间的纵向复用，我们验证的是时间成本和人力成本才会降低，验证效率才会进一步地提高。

面临这目前这三种主流验证技术，我们需要从验证效率出发，只有通过合理地选择使用这几种技术，并且实现技术之间的横向跨越和层次之间的纵向复用以后，我们才有可能在不断提速的SoC集成设计过程中也保持加速，与设计实现共同飞跃。

至此，我们关于《验证的方法篇》就结束了，到了下一个新篇章，我们将为你带来《验证的计划篇》，欢迎你们的订阅和传播！