日志

验证的结构篇之六：验证结构

已有 2830 次阅读| 2016-11-27 23:07 |个人分类:验证系统思想|系统分类:芯片设计

本节将是我们《验证的结构篇》最后一节，在这一节我们将模拟实际的工作来抛出一系列的问题，希望读者可以主动思考这些问题，我们给出的建议不是最完美的，至少是按照工程项目观点是合理的。如果你能够有更棒的主意，很欢迎你的留言，或者发送至我们的邮箱 rocker.ic@vip.163.com。

项目背景

读者你将是这个设计模块的负责人，需要考虑分配设计人员和验证人员。而Rocker作为有经验的工程师，对于下面这些模块的实现难度做出了评估：

MCDF设计

channel slave (slave interface + FIFO) 需要7个工作日
arbiter 需要10个工作日
formatter 需要5个工作日
registers 需要4个工作日
MCDF integration（模块集成）需要2个工作日

目前你一共有3位designer：肖、吕、高，需要你在最短的时间安排他们完成设计工作。你可以考虑的人力安排是什么？

由于MCDF模块之间有着独立性，我们可以同时安排3名设计者来展开设计工作，那么一种较为合理的建议是：

肖：channel slave 7天 + MCDF integration 2天 = 9天
吕：arbiter 10天 = 10天
高：formatter 5天 + registers 4天 = 9天

那么从设计完成的周期来看，一共需要10天（取最长的设计者所用时间）。那么针对这份设计的进度安排，你该怎么安排你的验证工作呢？

MCDF验证

在开展验证之前，首先恭喜你，运气还不错，你被分到了4位verifier：梅、尤、娄、董，比designer还要多呢。是啊，作为你的项目经理，我也知道验证的工作实际要更重一些呢。那么，如果按照一个简单的人力比例，验证人力：设计人力 = 1.5：1的话，那么上述各个模块的验证人力大致需要：

channel slave 11个工作日
arbiter 15个工作日
formatter 8个工作日
registers 6个工作日
MCDF integration的验证人力需要有待商榷，因为它不单单需要2*1.5个工作日，而是要求将所有模块的功能在MCDF集成以后做整体的验证，我们暂时按照30个工作日计算。

接下来如果要将verifier按照上述的人力估计进行分配，那就更加有趣了，我们来看一看吧。

由于只有三名designer，也意味者在formtter完成的前五天，我们只有3个模块在设计中。接下来，我们可以等待designer-高将registers模块完成，而分派给下一位verifier。这听起来都是按照天数来计算的，所以我们将这个时间进度表格绘制成下面的部分：

我们来分析一下这张项目人力安排表：
从设计者人力利用上来看，尽力做到了设计从各个模块设计开始到交付时用了最短的时间。
从验证一侧看，verifier梅、尤、娄的验证开展时间要略晚于设计部分。这是因为至少在设计的边界有雏形、即alpha版本准备好以后，验证可以考虑开始进入。
在verifier梅、尤、娄开始搭建验证环境的过程中，verifier董看似没有事情可以安排，因为designer高的另外一个设计registers还没有开始准备，那么verifier需要等待吗？相信我，verifier一旦闲置下来那么对于任何一个项目都是对项目经理的疑问。verifier董可以在其余三位verifier搭建模块验证环境一段时间以后着手准备顶层验证环境，即我们在上一节使用到的验证结构框图。
待完成初步验证环境集成以后，verifier董也可以在适当时间开始验证模块registers。在完成模块验证以后，verifier董可以进行最后阶段的验证环境持续集成。
在verfier董进行验证环境的持续集成前后，verifier梅、尤、娄可以在完成各自模块验证之后，进入顶层验证，检查各自的模块是否工作，而所用到的checker均来自于他们的模块验证环境。同时，verifier董也应该进行最后的顶层验证检查模块register的功能。
最后值得注意地方是，MCDF作为一个功能整体子系统，我们绝对不能忽视它的整体功能，即各个模块的协调功能。这项工作我们交给了verifier娄，因为他还有一定的人力来完成一项任务。而完成MCDF整体验证的任务包括有协调stimulator和checker来创建激励场景，完成数据检查。而数据检查用到的reference model、formatter FIFO和data checker需要由verifier娄来实现。
项目执行
在讨论项目执行的部分，我们将主要涵盖从下一篇的SystemVerilog基础和应用部分的安排。我们会主要围绕如何以四位verifier的角色从模块级验证环境开始搭建、到后续的验证环境集成、最后再到顶层环境的集成验证。

同时，我们也将省略关于MCDF模块设计和集成的代码实践部分，当然请读者放心，这些设计代码的源码也会一并公开给读者，作为整个SystemVerilog和UVM实践的核心示例代码。

从下一篇章开始我们将进入SystemVerilog语言基础的部分，我们采取的方式也将是简化语言的入门基础，同时结合实际应用，将SystemVerilog语言在验证环境中应用到的知识点展示出来。请读者在今后的语言和方法学介绍篇开始谨记本书的指导思想，知识点为辅助，项目实际应用和思想为我们贯穿全书的核心基调。




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