芯片验证漫游指南5验证的管理

1 验证周期的检查清单

如果能很清晰地知道一份验证周期的检查清单，那么对每一个项目节点需要做什么、上一个节点跟下一个节点有什么联系、不同节点在整个项目周期有什么作用，就有一个全面的认识。这样，作为验证新手，相信会更好地扮演验证角色。

如果每位验证人员都能充分了解各个验证环节，那么就可以更好地贯彻各项验证任务、保持信息通畅，项目整体的风险毫无疑问降低了。执行验证任务的动力来源于整个团队，验证经理背负的压力也由所有验证人员共同分担了。

所以，无论你担任什么样的验证角色，在执行日常事务时，如果心中已经有一幅通往流片大门的地图，那么整个团队的目标会更加清晰，验证人员同验证经理之间的沟通会更顺畅。接下来，我们一起看一看，验证周期各个关键节点的划分和每个节点需要完成的事情有哪些（见图5.1）。

从项目的启动阶段开始，历经RTL验证、门级验证（GLS,Gate Level Simulation）到最终的流片（TO,TapeOut），我们将各个环节分为如下几个环节，各环节的验证任务清单见表5.1～表5.6。

• RTL0：芯片框架和模块功能定义完成，制定验证的策略。
• RTL1：模块和子系统的功能信号定义完成，定制需要的存储模型。
• RTL2：完成所有模块的设计，以及80%以上的模块和子系统的验证，核心功能全部完成验证。
• RTL3：完成芯片系统的连线集成和验证，覆盖所有的功能验证点。
• GLS：完成门级网表的验证。
• TO：回顾验证的各项检查清单，最终流片。

在这里，我们指出几个需要注意的前提：

• 实际的芯片项目周期跨度要超过上面提到的验证周期，因为它往往会包含RTL0之前的产品可行性调查、项目立项和启动的过程。同时在TO后，仍然需要对硅后测试阶段提供支持，也需要对客户的集成使用提供支持，可能也要准备功能改进后的下一次流片（新的周期）。
• 不同公司的芯片项目对验证周期的划分和定义可能存在差别，但就芯片验证的一般流程来看，我们上面提到的各个环节是有普适性的。所以，通过进一步详细列举出上面各个环节需要完成的事项，我们对验证的生命周期会有一个全局的认识。
• 在上面列出的各个环节中，我们主要将注意力放在验证方面，系统定义、设计和后端的事项并没有在这里列出。

RTL0的验证任务清单:

RTL1的验证任务清单:

RTL2的验证任务清单:

RTL3的验证任务清单:

GLS的验证任务清单:

TO的验证任务清单:

也许表5.1到表5.6的这一列验证任务清单对你而言还不是那么迫切，但要相信，随着经验和责任的增加，你会越来越意识到一幅验证周期的全视野地图多么重要。如果你需要管理一个验证项目，那么将这些任务清单放在枕边，可以让你在新的挑战面前睡得安稳一些。正所谓不打无准备之仗，“凡事预则立，不预则废”，多一些未雨绸缪，懂得一点“套路”，对一个新人来说不是什么坏事。

2 验证管理的三要素

3 验证的收敛

随机验证的方式使回归（regression）测试更加有意义。一般地，我们基于两种目的提交回归测试表：

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

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

• 回归流程；
• 回归质量；
• 回归效率。

3.1 回归流程

在芯片的开发周期中，通常是从模块级到子系统级再到芯片级，设计、集成和验证都按照这样的步骤。那么采取瀑布集成的方式是否可以完成快速的SoC芯片周期呢？恐怕很难。虽然我们之前列举了不同项目节点的内容，方便项目过程中参考，但实际的窘境是，由于紧张的节点安排，往往是“一波未平，一波又起”。例如，本应该在RTL2之前完成模块级验证工作、在RTL3完成芯片级验证，但实际情况往往是，在RTL2节点上可能只完成80%左右的模块验证工作，其余模块验证工作需和芯片验证工作一同完成。一方面，作为验证经理，需要顶着压力，在RTL2结束后开展芯片验证工作；另一方面需要同时追踪各个模块的验证进度。所以，回归流程没有一致的标准，更多的是要符合实际的项目需求，同时又要在节节落后的情况下保证最终流片能够按时完成。这看起来是一种与项目进度的妥协，但更多地需要验证经理清楚哪些任务是必须在节点前完成、哪些任务可以适当延迟，总体控制风险，如同走钢丝一样，平衡一词始终需要牢记心间。

如图5.2所示，接下来让我们看看如何在快速的项目周期中做出合理的回归流程。

• 在模块设计阶段，除了准备验证环境，在验证的基本功能完备之时就应创建一些基本测试用例，并形成一份基本功能回归列表。该列表在RTL2（模块周期）前必须全部通过。
• 同时，在保证基本功能回归列表时，一些高级、附加功能仍要尽可能多地在RTL2前完成验证。但这些功能可能有部分需要在RTL2和RTL3之间完成验证，所以按照优先级划分的高级功能回归列表也要作为模块验证完成的检查项。
• 由于在 RTL2节点时可以保证基本功能的正常工作，这一份回归测试表单也使得在RTL3开始时进行的芯片集成工作得到保证。完成集成后，各个模块之间的互动也可以初步完成测试。此时，各个模块同其他模块的通话依赖于这些基本功能的测试表单。
• 在RTL2与RTL3之间，完成模块级的高级功能验证后要反复提交回归测试列表，通过大规模的随机测试来检验设计的稳定性，并完成覆盖率收集。
• 模块功能验证必须在RTL3之前完成，芯片级验证则要在门级仿真之前完成，并尽可能减小落后于节点的差距。这样才会留给后端部门稳定的设计（出现更少新的缺陷）来做物理实现，为门级仿真尽早提供网表和时序反标文件（timing back-annotation）以便开展门级仿真。

那么在以上流程中出现了缺陷该怎么办呢？应该遵循的原则是：

• 选择更小的验证环境、给出更少的变量，实现更容易调试的环境。具体而言，在芯片级遇到缺陷，可以在模块级验证则优先在模块级验证，同时尽量缩小配置的变量数目，以此重现错误场景。这种方式更有利于错误定位和缺陷修正。缺陷修复后，可以在更小的验证环境中重复之前的测试，确保之前出错的场景通过。
• 缺陷完成修复后，仍要分别进行模块级验证和芯片级验证的回归测试表。确保除了缺陷修复之外不引入新的缺陷，所有之前测试通过的功能仍然可以正常工作。

3.2 回归质量

在软件的迭代开发中，除了保证测试质量还要通过单元测试保证设计在每次提交之后（版本更新或缺陷修复）完成设计的自我检查，以便在提交给验证人员之前保证基本功能通过，减少明显设计错误带来的设计与验证人员之间的额外沟通和时间消耗。这种有效的方式越来越广泛地运用到芯片验证过程中。提高回归质量的策略在图5.3中给出。

每次完成芯片设计后，可以通过回归测试工具将设计、验证环境的编译、仿真、结果检查集成为一体，也可以通过一些简单的命令由设计者先查看基本功能是否正常工作。只有在保证基本功能回归列表测试完成以后，我们的版本管理工具才会允许设计文本的签入（check-in），同时通知验证人员设计的更新，由验证人员展开其他高级功能或者更高层次的验证工作。之前提到，如果验证人员发现了缺陷，在缺陷修复后，设计人员应先通过基本功能测试再递交给验证人员。验证人员需要做的是，检查之前错误的场景是否可以通过，同时创建专门针对该缺陷的基本测试来更有目的地完成验证。在这些激励确定性（determinacy）较明显的测试完成之后，我们也会给出更宽松的激励，对设计产生更丰富的测试场景。通过随机回归测试，我们可以在每次回归测试完成之后收集覆盖率，分析一些功能点覆盖漏洞，在下一次回归测试开始之前，有意地偏置（biasing）调整随机约束，使产生的激励更有可能填补那些功能点漏洞。

除了随机测试以外，我们也会通过形式验证的方式来完成验证。我们提供的多种属性检查分为基本功能属性和高级功能属性，这种简单的分类可以保证设计每次提交以后首先保证基本功能属性，而高级功能属性的验证由验证人员完成。同时，覆盖率也可以在形式验证中收集，并且和其他动态仿真的覆盖率数据实现合并和分析。随机测试的回归序列若要实现更高的覆盖率，就要运行多次。这种方式使得覆盖率收敛曲线随着回归往复的次数而提高，但是该方式非常消耗运算资源和时间。在通过回归方式完善功能覆盖率和检查设计功能时，建议将它们区别开来。比较合理的方式如下：

• 在前期设计不稳定的情况下，主要定向提交一些测试用例来快速检查功能是否通过。
• 在设计比较稳定后，可以规划用时较短、测试场景较简单的用例，检查核心功能点是否通过。
• 在设计后期，应一方面实现复杂场景，另一方面大量提交回归测试表来完善功能覆盖率。

3.3 回归效率

回归测试是一种确保设计功能通过的稳妥手段，方便操作管理，也可以提升覆盖率。在追求验证完备性的同时，回归测试的效率问题越来越受到重视。回归效率的现状考量基于以下几个方面：

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

基于以上考虑，在日常工作中，建议采取以下办法提升回归效率：

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

从对回归测试的流程、质量和效率的论述可以发现，智慧合理的回归测试方式有利于设计的发布质量和快速稳定。

4 让漏洞无处可逃

3节提到如何快速有效地进行验证收敛，即利用回归测试表产生更多复杂场景和提高验证的覆盖率。在验证收敛的过程中，无论你是验证人员、设计人员还是系统人员，都不可避免地会遇到一个问题，那就是——检测出了漏洞，应该怎么办？ 设计漏洞较易理解，因为一旦验证环境的参考模型与硬件设计的结果产出不一致，且最终分析得出设计并未完全遵循硬件功能描述时，那么设计漏洞便被发现了；而在验证的过程中，如果发现了硬件的问题，且最终回溯到硬件设计有遗漏并不完善的时候，硬件设计描述便产生了一个漏洞；容易被人忽视的是，发现验证环境的漏洞以后，经常是由发现者提交问题邮件、由环境构建者检查并最终确认和修改漏洞，这种局部的方式可能造成更多不知情的验证人员被该问题阻碍，或者新的项目仍然会重复之前的陷阱。所以，验证环境的漏洞（一般属于芯片级验证环境）也需要被记录；后期门级仿真中因综合时序不满足采样条件导致的门级验证失败，也需要将时序问题予以追踪，这种方式会提醒后期项目着重关注一些较长的或较难处理的时序路径，进行有针对性的优化。验证过程中还会遇到别的问题，如仿真工具问题、标准单元设计库问题、第三方IP问题，等等。

我们可以总结出，发现问题后进行跟踪的基本依据是：如果该问题明显影响项目进度，或者影响大范围的群体，或者对后续项目造成影响，就要记录这些问题并跟踪它们的解决情况。如果在项目实施中（这里专注在硅前验证阶段）发现了满足上述情况的问题，也要记录下来。在这里，我们将问题追踪分为下面的几种类型：

• 系统功能定义问题；
• 硬件设计问题；
• 芯片验证环境问题；
• 综合时序问题；
• 硅前工具问题；
• 引用库和IP问题。

对硅前问题进行分类后，接下来要将它们记录到合适的数据库中。该数据库不但要记录问题，还要起到分类、派发、查找、追溯、报告的作用。芯片设计项目除了在执行过程中参考软件项目的构建、分块、依赖路径、决策的方法，也在问题追踪上借鉴软件开发的方式。软件开发更早地使用标准化的问题追踪工具来执行项目，随着芯片开发的进度逐渐加快，一些商业的或免费的问题跟踪工具进入了芯 片开发的视野，例如以下这些问题追踪工具：：

• 商业工具: Team Foundation Server（Microsoft）,JIRA,Rational ClearQuest（IBM）,HP Quality Center（Hewlett-Packard）。
• 开源工具： Bugzilla（Mozilla）,Redmine,Trac（Edgewall）,Mantis。

这些问题追踪工具一般具备下面的功能：

• 记录：需要记录的内容有问题标题、内容、出错场景、背景描述、发布版本、测试用例和相关文件等。
• 分类：归属于哪个项目、哪个环节（系统、设计、验证还是其他）、哪个模块以及问题严重性（致命、重要、中级、改进）。
• 派发：在跟踪系统中，问题一旦提交，它的生命周期即开始。接下来由管理层指定问题回顾和修复的人员，再转由下一位问题持有者完成所需做的环节，继续指定问题的下一位持有者。在后面的问题跟踪流程中将详细介绍这一问题。
• 查找：遇到漏洞时，除了与漏洞相关人员沟通之外，在提交问题之前还要利用问题追踪工具数据库提供的查询功能判断，该问题以前是否发生过、有无解决方法；我们可以很方便地利用问题独一无二的ID编码在工具搜索栏中快速调出该问题的背景和进度。
• 追溯：问题从被提出到被派发、解决、验证和最终关闭，在一个项目中走完它的生命周期，但不排除它可能在下一个项目中“复活”。造成问题复活的可能因素有很多，比如问题重新发现、原解决方案不再满足、新项目继承上一个项目时一些问题修复没有被集成进来仍然需要再次修复，等等。所以，问题追溯的好处在于，可以看到同一个“顽固”的问题是如何在不同的项目之间（尤其是多个并行项目中）产生的。
• 报告：谁最喜欢看报告？当然是管理层！他们时间有限，若不能深入前线听到枪响、嗅到火药味，那么对他们而言，看到一份数据健全、有内容的报告必不可少。问题追踪工具从项目周期开始统计出多个维度的数据，如常见的设计问题提交、修复、验证和关闭趋势图，从这张图可以看出项目执行的健康状况；又如硬件设计缺陷提交曲线图，若曲率到项目后期仍居高不下，可能意味着结构性的严重错误，由此进一步导致项目延期乃至调整硬件结构。

了解问题追踪工具基本的功能之后，还要清楚如果在项目工作中发现问题，如何使用工具来提交、跟踪、修改和验证这个问题，状态之间的跳转通常在什么情况下发生。图5.4是针对硅前芯片开发流程的，实际上，问题跟踪周期要比这个状态更长，还包括了硅后测试周期。在这里我们集中在硅前芯片开发阶段，来依次解释各个状态的表征以及状态之间的跳转条件。

新的问题：在项目执行中发现一个新的问题，当它带来的影响满足提交的基本依据时，就要在问题追踪工具中提交这个问题，填写相应的内容，这对应步骤1。接下来，提交者将问题派发给需要解决问题的所有者。如果所有者发现该问题不属于他的模块，那么他应将该问题派发给真正的问题所有者，即步骤2。问题所有者进行研究，确定属于系统结构、设计或者验证问题，然后他可能进入开始状态，修复问题，即步骤3；如果问题所有者分析发现他的模块并不会导致该问题，问题是由其他模块引起的，那么他可以将状态重新修改为新的问题，即步骤4。该问题之前已经被发现过，则将状态修改为重复状态，即步骤5，同时需要备注已经提交相同问题的 ID 号，用来追溯该问题。该问题如果不严重影响项目进度且不是致命问题时，要同管理层商讨。假如最终确定有软件方法或其他修补方法时，可考虑修改为延后状态，即步骤6，待后续项目进行时，可以重启该问题。如果问题所有者发现该问题实际上已经在新的发布版本中修正，他可以将状态修改为解决状态，即步骤7。

开始：当问题开始进入修复过程时，问题所有者经过研究并做出修正，同时将问题修改为解决状态，即步骤8。在这一状态中，问题所有者仍然有可能将状态修改为重复或者延后，即步骤9和步骤10。

解决：问题修复后，问题所有者将该问题派发给验证人员。例如，设计人员派发给验证人员要求测试漏洞是否修复成功，系统人员派发给设计人员要求检查功能描述是否与设计相符等，这一过程即是图5.4的步骤11。

验证：问题得到修复和验证后，问题再次派发给当初的问题提交者或管理人员，由他们将状态修改为关闭状态，即步骤12。

关闭：问题关闭之后，问题的提交者如果在回顾问题时发现问题没有完全解决或者再次遇到此问题时，他可以重启问题，即步骤13。

重启：问题得到重启后，问题所有者需再次进入问题，检查新的问题场景，经过研究后

• 如果问题仍然需要再次修复，则进入开始状态，即步骤14。
• 如果问题的场景需要另外的软件配置，或者已经修复，则可转入解决状态，即步骤15。
• 如果问题受限于实际，暂时无法修复需要延迟，则需要步骤16。

以上各个状态以及状态之间的跳转，符合一般芯片开发中的问题追踪流程。从流程的细节中可以发现，问题追踪管理的特点是：

• 符合实际工程应用，状态之间的跳转合理。
• 问题一旦提交即有两方——提交者和所有者，且这种状态一直持续到问题的生命周期结束，即关闭状态。
• 追踪工具可以满足工程师和管理者的需求，让双方共同参与，深入记录第一线的资料（问题描述、解决方法、验证方案），同时提供整个项目的执行状态。
• 管理者并不需要在问题的生命周期内全程参与，他可以随时介入，但更多的状态跳转只需要由工程师执行。这样减轻了管理者的负担，为他们留出时间统揽全局。

至此，我们将问题追踪的需求、分类、工具和流程介绍完毕。有了团队间的协作，接下来我们将进入“人”的环节，看一看如何在长、中、短期建设验证团队，使验证团队成为公司的宝贵财富。

5 团队建设

6 验证师的培养

7 验证的专业化

8 作者结束语

我们所处的时代对中国的IC行业而言可谓是黄金时代。在国家战略和市场需求的双重引导下，中国集成电路的产业规模持续扩大，发展质量不断提高，基础更加坚实。与快速发展的行业形势相比，国内的集成电路人才培养不容乐观。据估计，如果2020年芯片设计业达到4000亿元人民币产业规模，那么设计业的从业人数要从2017年的13万增长到2020年的28万，这中间存在着巨大的技术人才需求缺口。同时我们还要考虑到，“十年树木，百年树人”，人才培养并非朝夕之功。目前高校的集成电路类教育，面临着象牙塔教育与企业需求脱节的问题，给企业带来额外的时间和金钱上的培训成本。

笔者认为，结合目前国内的高等教育现状，较为可行的方式是将IC验证教育从研究生教育扩展到本科生教育。以本书的内容为例，它将验证的核心内容与虚拟的项目案例相结合，既有基础知识也有高阶知识，以培养人才的动手能力为目标，最终满足企业的用人需求。将芯片验证教育拓展到本科生教育，也可以减少本科生毕业后因就业不顺利而不得不放弃专业的尴尬现状。笔者相信，只要我们不断提升高校的IC教育质量，芯片验证的本科化教育一定能够为企业输送更多合格的IC人才，这也是本书希望推动的一件事情。