日志

验证的管理篇之四：让漏洞无处可逃

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

在上一节我们提到如何快速有效地进行验证收敛，即利用递归测试表来产生更多复杂场景和提高验证的覆盖率。在验证收敛的过程中，每一个人，无论你是验证人员、设计人员还是系统人员，都不可避免地会遇到一个问题，那就是检测出了漏洞，应该怎么办？

对于设计漏洞而言，较容易理解，因为一旦验证环境的参考模型与硬件设计的结构产出不一致，且最终得出设计并未完全遵循硬件功能描述时，那么设计漏洞便被发现了；而在验证的过程中，如果发现了硬件的问题，且最终回溯到系统设计有遗漏并不全面的时候，那么系统设计描述便产生了一个漏洞；容易被人忽视的是，验证环境的漏洞往往在被发现以后，经常是由发现者提交问题邮件、由环境构建者予以检查并最终确认和修改，这种局部的方式可能造成了更多不知情的验证人员被该问题阻碍，或者新的项目仍然需要重复之前的陷阱，所以验证环境的漏洞（一般是芯片级验证环境的），也需要被记录；而在后期门级仿真，因为综合时序不满足采样条件导致的门级验证失败，也需要将时序问题予以追踪，这带来的方式会提醒后期项目着重关注一些较长的时序路径，进行有针对性的优化；在验证过程中，我们还会遇到别的问题，例如仿真工具问题、标准单元设计库问题、第三方IP问题等等。

由以上的例子我们可以总结出，发现了问题以后，进行跟踪的基本依据是：

如果该问题会明显影响项目进度、或者影响大范围的群体、或者对后续项目造成影响的话，我们需要将这些问题记录并且跟踪它们的解决情况。
在项目中实施的各个环节中（我们这里专注在硅前验证阶段），如果符合上述情况的话，我们需要记录下各种环节的问题。

所以，我们可以将问题追踪的类型分为以下几类：

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

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

商业工具：Team Foundation Server (Microsoft)，JIRA，Rational ClearQuest (IBM)，HP Quality Center (Hewlett-Packard)
开源工具：Bugzilla (Mozilla)，Redmine，Trac (Edgewall)，Mantis

这些问题追踪工具一般也都会具备如下的功能：

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

问题追踪流程

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

新的问题：当在项目执行中，发现了一个新的问题，而且这个问题的影响满足之前问题提交的基本依据时，我们就需要在问题追踪工具中提交这个问题，填写相应的内容，这对应着步骤1。接下来，提交者会将问题派发给需要解决问题的所有者。如果所有者发现该问题不属于他的模块，那么他应该再次将该问题派发给真正的问题所有者，即步骤2。问题所有者会进行研究，确定是否属于系统结构、设计或者验证问题，然后他可能会进行
进入开始状态，修复问题，即步骤3。
如果问题所有者进过分析，发现他的模块并不会导致该问题，而是由其它模块引起的，那么他可以将状态重新修改为新的问题，即步骤4。
该问题之前已经被发现过，则将状态修改为重复状态，即步骤5，同时需要备注已经提交相同问题的ID号，用来追溯该问题。
该问题的修复如果会严重影响项目进度而且不使致命问题的情况下，需要同管理层商讨。假如最终确定有软件方法或者其它补正方法时，可修改为延后状态，即步骤6，待后期项目可以重启该问题。
如果问题所有者发现该问题实际上已经在新的发布版本中修正以后，他可以将状态修改为解决状态，即步骤7。
开始：当问题开始进入修复过程时，问题所有者在经过研究之后，做出了修正，则他会将问题修改了解决状态，即步骤8。在这一状态中，问题所有者仍然有可能会将状态修改为重复或者延后的状态，即步骤9和步骤10。
解决：当问题修复以后，问题所有者会将该问题再派发给验证人员，例如设计人员会派发给验证人员要求测试漏洞修复是否完成，系统人员派发给设计人员要求检查功能描述是否与设计相符且漏洞得到修复等，这一过程即是上图的步骤11。
验证：当问题得到修复和验证之后，问题会再次派发给当初的问题提交者或者管理人员，由他们将状态修改为关闭状态，即步骤12。
关闭：在问题关闭之后，问题的提交者如果在回顾问题、或者再次遇到此问题发现没有得到完全解决时，他可以重启问题，即步骤13。
重启：问题得到重启后，问题所有者又需要再次进入问题，检查新的问题场景，经过研究后
如果问题仍然需要再次修复，则进入开始状态，即步骤14。
如果问题的场景需要另外配置设置，或者已经修复，则可转入解决状态，即步骤15。
如果问题受限于实际，暂时无法修复需要延迟，则需要步骤16。

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

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

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