芯华章发布数字验证调试系统—昭晓Fusion Debug™

近期，芯华章正式发布了基于创新架构的数字验证调试系统——昭晓Fusion Debug™。在研讨会暨新产品发布会上，中兴微电子有线系统部部长贺志强、平头哥上海半导体技术IP验证及软硬协同验证负责人张天放、燧原科技资深架构师鲍敏祺，与芯华章科技产品和市场战略总监黄武，通过圆桌对话的方式，围绕当前集成电路验证挑战及未来EDA发展趋势，展开了一场精彩交流。

对话中，三位嘉宾均从不同角度指出：

伴随集成度的增加，芯片设计日益复杂，系统级、场景级验证需求不断增加，系统级芯片验证，对提升流片成功率，赋能芯片设计创新意义重大，也在其中扮演愈发重要的角色。但是，工具兼容性差、数据碎片化、工具缺乏创新等痛点，也在限制着EDA的进一步发展。

良好的调试工具，对于提升复杂验证效率有重要作用，是非常关键的验证手段。业界认为一款优秀的调试工具，需要具备高效的性能、可开放的接口、支持图形化呈现等特质。

展望未来，国产EDA优势在于没有历史包袱、创新以及贴近用户。下一代EDA设计以及验证工具，需要加强流程的自动化及智能化，建立统一标准，提供更好的兼容性，从而全面提升验证效率及精度。

以下为嘉宾对话实录，经编辑整理，我们将分为“挑战篇”、“调试篇”、“展望篇”三期，以飨读者，本篇为挑战篇。

挑战篇：验完了没有？

黄武：目前前端验证发展了20~30年，大家认为在做 SoC设计验证的时候，最大的难点和挑战在什么地方？

鲍敏祺：

首先，芯片的设计现在逐渐从10、12纳米走到了7纳米，特别是在AI芯片领域，它会变得越来越大，我们可能已经超过50亿门，甚至更多比如说像M1最新一代ultra的话，它已经超过了1100亿个晶体管。

伴随着激烈的市场竞争，还会压缩开发周期。以往，这样一个大芯片通常需要一年半的时间完成，而现在我们可能需要压缩到一个更短的时间。因此，如何完成更多功能验证的工作，成为一个非常大的挑战。

另外一个挑战是：随着芯片的增大，它不仅是在功能上的验证，就像之前在做的一些功耗相关的验证；现在验证的问题更多的是要伴随场景，去看整体power analysis、信号完整性等这样一个验证的工作。这对于整个验证来说，就从一个单纯的功能需求，转变为整个系统级、场景级的验证的需求。

贺志强：

我想在座的鲍总、张总、包括黄武，相信作为验证团队的负责人，可能会经常被问到两个问题，第一个就是“你验完了没有”，第二个问题就是“芯片还存不存在bug”。这两个问题虽然字数不多，但我觉得都是直击灵魂的一个拷问。其实如何回答这两个问题，我觉得应该是验证工作最大的难点和挑战。

我们都知道验证是一个证伪非证明的过程，我们能够证明是有bug的，但是却很难证明没有bug，但是项目组可不接受这样的回答。

随着芯片规模的越来越大，复杂度也不断提升，芯片的一版成功其实也成为了我们的最低要求。验证不仅在质量上，还要在挑战的时间窗内去完成这个工作，应该说肉体和灵魂都在双重的折磨下。但是，我们还是要给予正面的回答，因此对验证效率、验证质量的度量就非常的有必要，也很重要。

那么我们，对于质量的度量，对于效率的度量，其实又是一个问号。

这些度量里面，我相信有一些是主观的数据，有些是客观的数据，在各种数据之间如何佐证不同的流程、不同的方法，以及不同的工具之间又如何关联，这个是留给验证的问题，那也是给我们EDA厂家的问题。

希望我们未来的EDA厂家，像芯华章一样能够聚焦在验证的痛点，跟着客户一起，不仅在工具上提供更高性能更好用的工具，同时也把我们的痛点的解决方案能够固化到流程里，沉淀到我们的经验里，最后集成到我们的工具里。

黄武：EDA工具很多时候都是一个集成的过程，有很多工具也是EDA公司不断收购来的，这导致的一个问题就是这些工具之间数据的交互很多时候存在兼容性的问题。大家对工具导致的数据不统一的问题，有没有什么看法？

鲍敏祺：

工具不统一，这个问题的确存在于很多领域。

比如举个最简单例子，关于覆盖率。如果说有一个仿真验证、有一个形式验证的情况下，按照以前的流程，它是两个完全独立的体系。因为对于原型验证来说，我可能看的是一个logic code，就是逻辑锥，但对于功能级的话，它看的code coverage或者是一个功能，是由他们自己去标定的。

这样的话其实我们很多的功能验证，已经在形式验证这头覆盖了，但是这两个如果没有融合的话，你会发现一边覆盖率很低，但是另外一边也不知道。只是说因为形式验证一般都是做的相对小的模块，所以如果两边不能融合，就会带来一个相对比较大的困难。

另外，其实我们现在整个芯片里面，其实不光是simulation，后面还有emulation，prototype，两者的覆盖率范围怎么能够合理地反标到前级，其实是对于前面的整个SoC sign-off会起到一个非常积极的作用。再则，对于Low power，它其实就是对UPF的理解，包括simulation工具也好，synthesis工具也好，它们的解析可能都会有一些不一致。一致性check，其实是一个非常重要的东西。

贺志强：

我觉得我们在验证过程中经常会遇到这些问题，因为数据的兼容性其实可以分成两方面：第一方面就是我们不同的EDA厂家的工具的一个兼容性问题；第二个其实是我们自家工具的不同的验证手段的兼容性。

目前我们可能用的比较多的simulation、formal这一块，那么我们同一家的手段是不是能够把我们的数据、把我们的覆盖率信息能够合并到一起，而不是孤立地去看我们的验证工作的输出，包括像emulation和prototyping的一些验证手段的一些信息能不能集成进来。其实我觉得对于同一家工具，这个应该是能够去解决，没有太多的技术壁垒，但是对于不同厂家的工具，它的解析、格式，实际上我觉得在过去30年，我们EDA工具被国外垄断的这样情况下，是很难做到统一的。数据的一些不兼容，其实给用户带来的体验感也不是很好。

就像我们举个例子，我们现在用的这种手机充电线也一样，我们现在有Type-C的、还有苹果的一些接口，那么目前看到的一些趋势可能像安卓，它有趋向Type-C的统一，但是要和苹果去统一，我觉得还是挺难的。那么像现在比较火的一个行业就是电动汽车，汽车从充电口来看的话，其实它一开始从规划我觉得不管是哪一家的电动汽车，它的充电口慢充快充都是一样的，其实这样带来的好处我觉得是不言而喻的。

回到EDA工具，其实从用户的角度，是希望我们不同的工具之间，它的数据能够兼容，能够去解析，能够提供一些API的接口，包括我们的覆盖率信息能够合并，这样对我们的验证效率的提升就存在更多的可能性。

我相信这是未来的趋势，当然也需要一些国产EDA的崛起，驱动业界的改变。

黄武：验证在芯片设计中时间消耗越来越大，那怎么样通过一种方式高效量化判断芯片验证是处于收敛的趋势？

贺志强：

这个问题其实我觉得还是挺难回答的，关于如何判断我们验证的效率和质量，如何判断我的验证已经收敛了，这个确实是验证工程师一直在持续去做的一件事情。

那么首先我们说验证效率，效率其实它直接影响到我们一个研发周期的长短，对于咱们芯片的流片以及芯片的商用，其实是起到了一个很关键的作用。

那么效率的提升或者说我们代码的收敛，它不能单单的只看效率，我们所有的效率是在质量的前提下去谈效率才有意义。

那么效率的影响的因素有很多，从整个芯片的研发流程来看，包括我们方案的一些继承性、前端代码的一些IP化，包括我们验证平台的通用以及验证用例的复用程度，其实都是效率提升的一些关键因素，但是验证效率或者说我们代码收敛，我觉得应该是没有一个直接的或者说单一的度量指标。

那么刚才提到的像一些覆盖率，像assertion，包括formal，包括其他的验证手段，我所有的这些指标它应该是综合的来去判断我验证是不是收敛的过程。

单纯从效率来看的话，我觉得可以从几点去看，第一个就是我们平台的一个搭建周期，我是不是能够快速地去复用我的平台、用例的调试周期；其次，当然我们最经常会关注到的就是用例的一些图、增长曲线以及回归周期，这是从过程来看的一些数据。

那么从验证结果来看，我觉得还有一些bug的趋势、覆盖率的一些覆盖情况，包括我们的验证周期的综合指标，来度量验证效率和收敛情况。

所以这个问题我觉得还是挺难回答，当然不是说不能回答，比如我们现在业界有很多的方法，我觉得哪一种方法其实对于我们做验证的质量和效率来看的话都是有意义的，是要统筹或者说要去从整体上去考虑，而不是单单的一个指标。

张天放：

对于验证，一般我们都会根据架构和设计的规格制定验证的策略，就是说在我们现有的资源下，这个资源既包括人力的资源，当然也包括EDA的资源，还包括时间的资源，用什么样的验证方法和方案，能够在我们可以接受的风险度下达成质量目标，让芯片回来一版成功。

我觉得这是非常值得探讨的一个课题，里面有非常多值得深挖的一些地方，无论是数据，还是经验，还是决策点等等。实际上我觉得在业界里面都很值得探讨——我们有了这么多方法学，我们有了这么多数据，我们跑了这么多测试，最后我们的情况到底是怎么样？

当然我们有很多的方法学可以使用，从DDV（Direct-test Driven Verification）到CDV（Coverage Driven Verification）再到MDV （Metric Driven Verification） ，那么我们到底应该把它们用在什么地方？

实际上，我们知道现在有这么多的芯片的业务形态，这么多的产品特征，那么实际上每一类DUT的验证策略都不尽相同。一般的做法可能是说对于unit level或者是某些比较小规模的，我们可能会考虑引入一些形式验证的方法去把它做到充分的覆盖。

那么对于block level的验证，我们可能倾向于业界现在比较通用的，基于UVM的MDV的这种方法学。通过功能覆盖率以及代码覆盖率这两个重要指标，然后以及各家公司都可能定义的非常完备的质量流程和check list，去保障研发质量，降低风险。

那么对于sub system、IP level等规模比较大、较为复杂的DUT的验证，从UVM角度一般会采用自底向上集成的方式，关注点一般会集中在各个block之间的interaction。此外，对于sub-system level和IP level的代码覆盖率策略，如果block level代码覆盖率已在checklist中，SS和IP level会重点关注各个sub-block以及自身的boundary toggle coverage。

而对于SoC level，断言覆盖率或者是必要的功能覆盖率一般都会纳入考量。

总之验证策略（包括覆盖率策略）、验证测试计划（包括功能覆盖率计划）都是验证工作中非常重要的部分。我们如何用适配的方法学在现有的人力、EDA资源和时间资源的条件下，能够达到什么样的质量标准并能承受怎样的风险，然后做到一次流片成功，我觉得是个很值得探讨的问题。

审核编辑：彭静