日志

验证的管理篇之三：验证的收敛

已有 1958 次阅读| 2016-10-16 22:41 |个人分类:验证系统思想|系统分类:芯片设计

伴随着随机验证的方式，递归（regression）验证的方式变得更加有意义。一般来讲，我们基于两种目的来提交递归测试表：

由于随机验证环境每次仿真产生的激励序列不同，这就使得每次仿真均会对覆盖率产生贡献，变得有意义。
当设计缺陷被发现以后，递归测试序列需要再次提交，用来确保之前的功能点测试无误，同时设计缺陷也被修复。

通常而言的递归测试指的是每次将所有测试用例提交到服务器上，检查测试结果。对于模块级的递归测试，这种方法在时间和计算资源上也许是可行的，然而对于芯片级，这种方式每次要消耗的时间和资源恐怕需要重新考虑。在实际项目中，采取何种方式使用递归测试，需要考虑的是下面几个因素：

递归流程
递归质量
递归效率

递归流程

我们在验证周期中，通常都是从模块级到子系统级再到芯片级，对于设计、集成和验证都是这样的步骤。那么，采取瀑布集成的方式是否可以满足目前快速的SoC芯片周期呢？恐怕会很难。虽然我们之前将不同项目节点的内容列举出来，但是实际的窘境是，由于紧张的节点安排，往往是“一波未平，一波又起”。例如我们本应该在RTL2之前完成模块级验证工作，在RTL3完成芯片级验证，但实际情况却往往是在RTL2节点上，我们可能只完成了80%以上的验证工作，而剩下的模块验证工作需要和芯片验证工作一同完成。一方面，作为验证经理，需要顶着压力，在RTL2结束以后，开展芯片验证工作，另外一方面，他也需要同时追踪各个模块的验证进度。

所以，递归流程没有一致的标准，更多的是去符合实际的项目情况，但同时又需要在节节落后的情况下要保证最终流片的按时完成。这看起来可能是一种同项目进度的妥协，但更多地需要验证经理详细清楚哪些任务是必要在节点前完成，哪些任务可以适当延迟，总体控制风险，这同走钢丝一样，平衡一词始终需要牢记心间。

那么，单独拿出递归流程举例，让我们看看如何在快速的项目周期下，做出合理的递归流程吧。
首先在模块设计阶段，除了需要需要准备验证环境之外，需要在验证的基本功能完备之时就创建一些基本测试用例，并形成一份基本功能递归列表。该列表在RTL2（模块周期）前必须全部通过。
同时，在保证基本功能递归列表时，一些高级、附加功能仍然需要尽可能多地在RTL2前完成验证，但这些功能可能有部分需要在RTL2和RTL3之间完成验证，所以按照优先级划分的高级功能递归列表也需要作为最终模块验证完成的检查项。
由于在RTL2节点时可以保证基本功能的正常工作，这一份递归测试表单也使得在RTL3开始时进行的芯片集成工作可以得到保证，在完成集成之后，各个模块之间的互动也能初步得到测试。此时，各个模块同其它模块的通话就依赖于这些基本功能的测试表单。
同时，在RTL2与RTL3之间，我们需要在完成模块级的高级功能验证之后，进行反复提交递归测试列表，通过大规模的随机测试用来测试设计的稳定性，并且完成覆盖率收集。
模块功能验证必须在RTL3之前完成，而芯片级验证则需要在门级仿真之前完成，并且尽可能减小落后于节点的差距，只有这样才会留给后端小组稳定的设计（出现更少新的缺陷）来做物理实现，为门级仿真提供合理的物理实现时间。

那么当以上流程中一旦出现了缺陷该怎么办呢？我们应该遵循的原则是：
选择更小的验证环境、给出更少的变量，实现更容易调试的环境。具体而言，就是在芯片级遇到缺陷，如果可以在模块级验证，那么首先在模块级验证；通过，如果可以固定其它变量，例如配置设计的功能为一些基本功能，减少负责功能配置，来重现错误场景，那么这种方式也会更有利于错误定位、设计分析和缺陷修正。在缺陷完成修复以后，也可以在更小的验证环境中，重复之前的测试，来确保出错的场景通过。
在对缺陷完成修复之后，我们仍然需要先后进行模块级验证和芯片级验证的递归测试表，确保除了缺陷修复之后，还不会引入新的缺陷，所有之前测试通过的功能仍然可以保证正常工作。



递归质量
在软件的迭代开发中，除了保证测试质量之外，也需要通过单元测试来保证设计在每次提交之后（版本更新或者缺陷修复）保证设计的自检，使得在提交给测试人员之前可以保证基本功能通过，减少由于明显设计错误带来的设计与测试人员之间的沟通和时间消耗。而这种有效的方式，也被越来越广泛地运用到芯片验证过程中。
尽管芯片设计在每次完成后，无法通过集成开发环境简单地通过一个敲键就完成设计模块的单元测试，但是，我们仍然可以通过有效的递归测试工具将设计、验证环境的编译、仿真、结果检查集成为一体，使得设计在完成以后，也可以通过一些简单的命令由设计者首先查看是否设计的基本功能是否正常工作，只有在保证这项基本功能递归列表完成以后，我们的版本管理工具才会允许设计文本的签入，同时通知验证人员设计的更新，由验证人员直接展开其它高级功能或者更高层次的验证工作。

在之前提到的如果验证人员发现缺陷之后，设计人员首先完成缺陷修复并且通过基本功能测试之后再次递交给验证人员。那么验证人员需要做的是，检查之前错误的场景是否可以通过，同时创建专门针对该缺陷的基本测试来更有目的地完成测试。在这些激励确定性较明显的测试完成之后，我们也会给出更宽松的激励，产生更复杂的可能场景来对设计产生更丰富的测试场景。

通过随机递归测试，我们可以在每次递归测试完成之后收集覆盖率，分析一些功能点覆盖漏洞，在下一次递归测试开始之前，有意地调整随机约束，使得产生的激励更有可能填补那些功能点漏洞。

除了随机测试以外，我们也会通过形式验证的方式来完成验证。对此，我们提供的多种属性检查也可以分为基本功能属性和高级功能属性，这种简单的分类也可以保证设计每次提交以后保证基本功能属性，而高级功能属性的验证可以由验证人员完成。同时，覆盖率的收集，也可以从形式验证中得到，并且和其它动态仿真的覆盖率数据实现合并和分析。

随机测试的递归序列如果要实现更高的覆盖率，就需要运行多次，这种方式使得覆盖率收敛曲线随着递归往复的次数而提高，同时该方式也非常消耗运算资源和时间。所以关于通过递归方式来完善功能覆盖率和检查设计功能，我们建议将它们区别开来，比较合理的方式应该是：
前期设计不稳定的情况下，主要定向提交一些测试用例来快速检查功能是否通过。
在设计较稳定以后，可以规划用时较短，测试场景较简单的用例，来较快检查核心功能点是否通过。
在设计后期，应该一方面设计复杂场景，另外一方面大量提交递归测试表来完善功能覆盖率。

递归效率
递归测试虽然是一种确保设计功能通过的稳妥手段，而且由于它方便管理操作，也可以用来提升覆盖率，但同时，追求验证完备性的同时，递归测试的效率问题也变得越来越引起重视。递归效率的重要性基于以下几个方面：
在模块验证阶段，随机测试的方式使得倾向于反复提交测试表用来产生各种可能场景，而到了后期，覆盖率难以得到更多提升，那么如何精细控制随机约束，使得每次递归测试总有新增覆盖率的收获，这是要深入的问题。
在设计缺陷得到修复以后，如何快速检查设计基本功能，保证设计版本提交的质量，进而转移到验证人员一侧，提升沟通效率，这也需要设计合适的递归表。
在芯片级验证阶段，由于测试用例时间明显加长，那么每次递归整个测试表（ 数以千计）耗时极长，且由于芯片级测试更多基于C的验证，在项目后期集成改动较少的情况下，反复递归的收益就明显降低，但同时验证管理又需要这样的数据，这种矛盾也需要化解。

通过上面的考虑，我们在日常工作中，建议采取以下的办法来提升递归效率：
在可实现的情况下，可以考虑切分测试场景，将一个长的测试序列切分为多个序列并为之创建多个测试用例。这么做的好处是避免过于冗长复杂的测试，划分为多个用例可以实现并行提交测试，用计算空间来换取时间。
对于一些较难切分测试向量的场景，例如芯片级仿真需要首先完成上电、复位、时钟使能的流程，同时芯片处理器需要完成初始化、搬运执行代码的过程，我们可以考虑通过快速跳转到该状态来实现缩短测试时间的要求。
对于一些需要通过长时间运行来跳转到某一状态的测试，我们建议可以分为两个阶段。第一阶段来检查，跳转到该状态的条件是否满足，进而检查状态跳转。一旦第一阶段被验证过，我们可以在第二阶段后的用例，通过直接初始化到该特定状态来节省时间，例如强行置位硬件寄存器、状态位等方式，来使得设计可以快速条状到某一状态，进而缩短验证时间。
尽可能给予充分的计算资源，目前用于仿真的普遍方式是，中心集群化的服务器来提供计算和数据存储资源，通过资源分配管理办法来实现尽可能足够的并行运算资源，使得递归测试表可以尽快执行完毕。

至此，关于通过递归测试来合理收敛验证进程的讨论已完毕，智慧合理的递归测试方式有利于设计的发布质量和快速稳定。下一节课，我们将带大家一起看看，如果发现了漏洞，我们应该做哪些事情。

谢谢你对路科验证的关注，也欢迎你分享和转发真正的技术价值，你的支持是我们保持前行的动力。