哪一种验证方法最好？形式验证、硬件加速还是动态仿真？

时间：2016-10-30 07:30:19 阅读：660 评论：0 收藏：0 [点我收藏+]

关于最佳的验证方法，最近总能在各种文章中看到。这里希望以一些新的视角来看待这些问题。所以根据一些EDA公司代表对相关问题的回答，总结出本文。

受邀回答问题的代表有：Steve Bailey，Mentor Graphics公司新兴技术总监；Dave Kelf，OneSpin解决方案营销副总裁；Frank Schirrmeister ，Cadence高级产品管理总监；Seena Shankar，Silvaco的技术营销经理；Vigyan Singhal，Oski技术总裁兼首席执行官；Lauro Rizzatti，验证顾问。

最好用的验证技术

对于验证技术讨论，大都集中在模拟（硬件加速）和仿真之间，但是同时，形式验证也不应该被忽略。但是以下内容并不包括基于FPGA的验证，因为除了价格因素，它跟仿真实际是一样的。那么，到底哪种验证技术是最好的呢？各种验证技术都在广泛应用，各种验证技术都有其优势，显然武断地回答这个问题并不合适。

正如Lauro Rizzatti所说的那样，这得取决于要进行验证的设计的特点。他说：“虽然我是偏爱仿真的，但是当设计并不太复杂时，模拟和形式验证还是应该优先考虑。对设计debug时，模拟要优于仿真太多了。因为模拟交互性强、灵活多变，支持时序分析。然而，在现在的IC设计中，设计复杂性的增长是大势所趋，这个复杂性不光是说有更多的晶体管和门电路，还意指会有更多更复杂的嵌入式软件的代码。面对这种趋势，模拟和形式验证都显得有些无能为力，然后仿真就成为了首选。”

Vigyan Singhal写道：“形式验证和仿真都越来越流行。模块级的bug（其实大多数bug都是模块级的）使用形式验证debug效益最高，系统级的bug最好还是通过仿真来debug吧。许多时候，我们在设计流程中常出现的问题是，形式验证的使用还是不够早啊！”

Seena Shankar的观点是：“模拟中，RTL和测试平台都是完全可视的，在开发周期的早期阶段，更容易修复错误并重新模拟验证。但是我们也会被可运行周期限制住，对于1亿门的设计，进行只有几个功能操作的基本测试可能需要长达12小时才能完成。虽然仿真花费更长的初始设置时间，但是数以百万计的操作可以在几分钟内运行完成，这是极其有利的一面。不过，对于与仿真，debug是非常困难、很费时间的。形式化验证需要不同方面的专业知识，虽然只对验证小的模块有用，但是通过假设和约束，形式验证可以发现一些角落处的bug。”

Steve Bailey得出的结论是：“似乎现在模拟的使用越来越少了，但是这都是相对的。验证周期也在大幅增长。即使硬件加速和形式验证是整个验证流程中主要的部分，但是模拟验证的周期相比自身也还是在增长。形式验证已经成为验证中非常重要的一环，基于形式验证的全面性，形式验证更偏向于应用于一些验证花费可能比较高的验证任务（一般都是比较难比较有挑战性的任务）。”

所以呢，就我看来，如果我可以决定的话，我会在设计周期尽可能早的时候使用形式验证工具制定一个可执行的规范，确保预期产品的所有功能特性都能被覆盖到。我同意模拟和仿真之间的选择取决于被验证模块的大小，而且我也觉得软硬件协同仿真常需要使用仿真加速设备。

不同技术的联合使用

每一种技术都在特定的条件下，都有其独特的价值。那么不同的技术之间可以很容易联合使用吗？

Frank Schirrmeister提供了一个很详尽的回答，并附了一张图显示一些不同验证方法的联合使用。

部分示例：

结合了RTL模拟和仿真的仿真加速。这种方法不仅具有模拟测试平台的表达力，而且跟仿真可综合DUT一样，有较高的验证效率。
仿真和基于FPGA原型的验证可以共用一个共同的前端，比如在在Cadence系统开发套件中，允许更快的采用多结构编译。
对于断言，X传播等，形式验证和模拟验证结合的很好，当断言可以被综合，并且映射到仿真上时，形式验证技术甚至与基于硬件的执行相关。

Vigyan Singhal指出：“对于不同技术联合使用，数据库的交互性和较差的testbenche是局限之所在，目前还没有统一的能够融合形式验证、模拟和仿真结果的覆盖率数据库标准。”

Dave Kelf总结说：“这里真正的问题是如何把需求和设计规范描述为机器可识别的内容模式，使用这些信息来生成验证计划，将它们转化测试结构，并提取可以与验证计划比对的覆盖率信息。这种自顶向下的封闭环境常被认为是理想的，但我们至今还没有在产业上将其实现，如何创建机器可识别的规范这个基本问题一直在限制我们。”

可移植的激励

Accellera 已经成立了一个学习小组，用于开发可移植的激励方法。这个小组十分活跃，并且已经在这一方向去的一定进展。但由于该小组并未发布其成果信息，所以就不太好提出任何具体问题，但是我认为提出在这一方向进行研究的决断是非常重要的。

Frank Schirrmeister 评论说：“在顶层，可移植激励的工程里，允许设计者创建测试案例来验证SoC，其中包括低功耗的方案和高速缓存一致性的项目。测试案例作为可以在任何设计的处理器上执行的软件例程，激励变得可以在不同的动态引擎、具体的模拟、仿真和FPGA原型间移植。这带来的一个优势是，回归测试可以在较快的引擎中使用，并产生较少的bug，并且遇到bug的时候能很快的检查传问题之所在。”

Dave Kelf也对这项工作持积极态度：“可移植的激励对于抽象UVM测试结构的关键部分是非常有帮助的，使得他们可以被用于模拟和仿真。这是个值得努力的方向，但目前也还是只停留在表层。还需要引入断言，并且考虑这些激励该如何从高级规范派生得到。”

SystemVerilog

SystemVerilog被认为是最好的SoC验证语言。然而，许多受访者表示SystemVerilog是有一些局限性的。

Seena Shankar回答说：“SystemVerilog是用于系统验证的最好语言吗？SystemVerilog封装了从软件和硬件范例等用于验证的最佳特征。它是一个非常容易遵循的标准，但是就性能来说，可能不是最佳的。”

Dave Kelf也说：“最名不副实的语言就是SystemVerilog了，这种语言并不是为系统验证设计的，它的名字中带了system只是当初为了和SystemC进行竞争，这显然很荒谬。现在，当然也可以在系统级验证使用SystemVerilog，但很显然，C衍生语言还是更为有效。”

Frank Schirrmeister评论指出：“SystemVerilog和UVM之类技术在IP和子系统级别上很好用，但似乎当扩展到完整的系统级芯片（SoC）的验证时，就显得有些乏力了。这就是可移植的激励项目的由来，它可以把UVM可用的部分延展到SoC级别，允许从IP到SoC级别的垂直复用。这种方法克服了UVM在SoC级验证比较乏力的问题。

结论

设计工程师和验证工程师仍然在等待来自EDA工具商的帮助。他们在应对越来越复杂的设计的时候，不得不面对不同的方法学以及不完善的验证语言。设计师必须谨慎，以确保他们写的东西是可验证的，同时验证工程师不仅需要理解设计的需求和架构，还要熟悉设计者使用的语言的特点，从而描述结构和产品的预期功能。我认为，要改善这种情况的一个方法是，对于一个新的设计，EDA公司和系统设计公司都要考虑到这将是一个集成了软件、硬件、机械和物理特性的产品，最终，能够使开发和验证能选择的最合适的、可共存的、提供一致结果的工具。