日志

验证的管理篇之一：验证周期的检查清单

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

从这一篇开始我们进入到了《验证的管理篇》，也许不少读者会有疑问，验证管理不是验证经理关心的事情吗？和验证人员有什么关系呢？在我们进入本篇的正题之前，我想讲讲自己刚进入第一家公司作为一个验证菜鸟，在头一个月的经历。

刚进公司的时候，我只知道自己要验证的模块是什么，花时间了解它的功能，跟设计人员交流，进行模块验证，可以说是完全专注在一个点，那一个模块上面。验证经理给我安排的验证时间也很紧张，我脑海里只知道一件事情，就是尽可能又快又多地发现漏洞，在截止时间前完成验证，而对模块验证完成之后我要做什么，我知道的几乎很少，所以我感觉挺被动的。那个时候，我就在想，如果我能很清晰地知道一份验证周期的检查清单，那么对于每一个项目节点我需要做什么，跟下一个节点的联系以及在整个周期的作用，我会首先有一个全面的认识。在这样的条件下，作为验证的新手，会更好地扮演他的角色。

到了后来，随着经验的增长，项目赋予了我更多的责任，从负责一个模块、到一个子系统、再到整个芯片的验证。每当接到更有挑战性的任务，或者芯片的功能更复杂的时候，肩负的压力自然会更大，这种压力来源不单单是面对更多的技术问题、更大的验证团队，也来源于对于未知部分的焦虑。在这里，未知的部分包括验证流程的执行和每天出现的新的风险。风险虽然是不可避免的，但是也是可以尽可能降低的。如果，不单单是验证经理，包括每一位验证人员都能够充分了解各个验证环节，那么就可以在已知的范围内将各项验证任务贯彻下来，从项目的整体风险来看毫无疑问降低了，而且其中的动力来源于整个团队，验证经理背负的压力也由所有验证人员共同分担了。

所以，无论你担任着什么样的验证角色，在执行日常事务的时候如果心中已经有一副通往流片大门的地图，那么整个团队的目标会更加清晰、验证人员同验证经理之间的沟通也会更顺畅。

接下来，我们一起看一看，验证周期各个关键节点的划分和每个节点需要完成的事情有哪些。

从项目的启动阶段开始，历经RTL验证、门级验证到最终的流片，我们将各个环节可以分为：
RTL0：芯片框架和模块功能定义完成，制定验证的策略。
RTL1：模块和子系统的功能信号定义完成，定制完成需要的存储模型。
RTL2：完成所有模块的设计，以及80%以上的模块和子系统的验证，核心功能全部完成验证。
RTL3：完成芯片系统的连线集成和验证，覆盖所有的功能验证点。
GLS：完成门级网表的验证。
TO：回顾验证的各项检查清单，最终流片。

在这里，我们需要指出几个需要注意的前提：
实际的芯片项目周期跨度要超过上面提到的验证周期长度，因为它往往会包含RTL0之前的产品可行性调查、项目立项、项目启动的过程，同时在TO之后，我们仍然需要对硅后测试阶段提供支持、也需要对客户的集成使用提供支持，并且也需要准备可能的下一次功能改进之后的流片（新的周期）。
尽管不同公司的芯片项目对于验证周期的划分和定义会存在差别，但是就芯片验证的一般意义来看，我们上面提到的各个环节是有普适性的。所有通过进一步详细列举出上面各个环节需要完成的事项，我们会对于验证的生命周期有一个全局的认识。
在上面列出的各个环节中，我们主要将注意力放在验证方面，对于设计、系统定义和后端的事项我们并没有详细列出。
RTL0
RTL1
RTL2
RTL3
GLS
TO
也许上面的这一列验证清单对你而言，还不是那么迫切，但你要相信伴随着你的经验和责任的增加，你会越来越意识到一幅验证周期的全视野地图对你而言有多么重要，如果你需要管理一个验证项目，那么这些任务清单放在枕边，那么就可以让你在新的挑战开始可以睡得好一点。正所谓不打无准备之仗，懂得一点点套路，对于一个新人而言，不是什么坏事。

我们至此将这份验证清单梳理完毕，下一节我们将进入管理的三个核心要素：时间、人力和任务。

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