新闻中心 NEWS CENTER
如何保证验证的质量-修订稿
如何保证验证的质量-修订稿
验证是设计质量的保证方式，没有一个设计不经过验证就可以准确运行的。所以验证本身该如何保证质量就显得非常重要了。
整个验证工作在形式上主要表现为两方面：1，验证点；2，验证环境（包括测例）
验证环境是验证点的载体，是验证点的具体实现。
对项目而言，还包括验证的组织工作，验证的组织者是否合格将决定真个项目的验证工作是否能够顺利开展。
对验证点而言，它的重点是完备性；
对验证环境而言，它的重点是效率与准确性。
对验证组织而言，它的重点是验证计划的掌控，包括验证重点，盲点，瓶颈以及验证进度的掌控。同时也包括人员上的组织与验证成员心理的掌控。
1 保证验证点的完备性
我们的芯片出现的问题往往是遗漏了某些验证点的缘故。我们验证中覆盖到的地方极少有出问题的。可以说验证点是否完备是验证质量保证的基础。那我们该如何确保验证点的完备呢？
2 首先从Spec出发，提取测试点
这种方式往往是从外部功能角度出发，比较少考虑内部结构：比如什么总线类型，支持什么协议等等。
这种方式的优点是容易把最重要的验证点找出来，特别是对于系统功能很容易检测。如果是纯黒盒验证的话，往往容易遗漏一些设计本身的验证点，从而会使芯片遗漏bug。因为Spec的功能组合是非常多的，我们无法穷举所有的功能组合。
例如：
为此我们还需要考虑：
从协议出发：
2 协议的理解容易偏差：
我们的芯片项目基本上都跟一些通用协议相关，像非接卡的14443协议，RFID的18000-6协议，一些接口协议像SD协议，USB协议等等。这些协议不是我们自己制定的，而且协议文档也写得参差不齐，这让我们的理解容易跟实际有所偏差
1 多人讨论：
协议的理解需要多人讨论，一个协议至少需要两人精通（设计者和验证者）；
1 协议部分的设计和验证需要从人员上分开：
协议本身的分析：
1 首先保证基本流程与基本功能：基本流程与基本功能一般已经包含协议的80%的功能了，这部分功能是容易把握的；但不容忽视，否则会差之毫厘，失之千里；
1 协议的边界：这部分是验证者需要严格把握的，绝不可疏漏。（这是我们2201之前没做好的地方）；
哪些协议边界需要注意的？
1 协议规定的最大值和最小值：需要跟设计者沟通，搞清楚实际的边界；
1 特殊情况与特殊条件：比如RFID 18000-6中的Truncate功能就有很多特别的要求。
1 需要了解协议的应用场景：
协议的应用场景不仅是系统验证的要求，对我们深刻理解协议也有帮助。如果我们不知道具体的应用场景，我们就没有把握我们做的东西是否是符合协议的，是否是符合实际需要的。
2 设计自身的特点：
设计自身往往有很多小的结构组成的，如果这些基本结构正确，结构跟结构之间的连接又没有错的话，那他们所组成的无数的功能也就可以满足。这部分是自验证和交叉验证的重点。
这部分的测试点首先需要由设计者本人详细给出，然后由交叉验证者单独给出；最后经过交叉验证者和设计者以及相关人员综合讨论后合并成一个总的测试点CheckList。
即最后设计者和交叉验证者需要共同维护一个验证点的CheckList；
从覆盖率报告增加相关测试点：
2 覆盖率包括需要在所有已知验证点都跑完的情况下再看覆盖率报告，即在整个验证工作即将结束时再看，而不是验证的中间；
1 验证组织者一定要强调这一点：覆盖率不是验证的目的，而是防止验证遗漏的一种手段；所以绝不可以为了让覆盖率通过而验证，即绝不以说覆盖率100%，验证就没有问题了。
2 覆盖率报告可以让我们想到一些遗漏的验证点：所以对覆盖率报告要重视，绝不可以放过任何的遗漏；
2 在所有验证点列全后，我们还需要根据主要的功能，即主要的feature来对一些测试点加以组合；这种组合应该是定向的组合加受限随机的组合；
1 对于保证测试点的完备性，有针对的小范围讨论是一种很好的补充方式，特别是设计者和交叉验证者的讨论。
1 对于交叉验证者：需要了解主要的设计实现，最好在设计开始时就切入，从而对模块的需求与实现由更深入的了解。
1 对验证点列全后，我们需要对验证点进行分析：搞清楚验证点直接的关联性，耦合性；相同的可以合并，以提高效率；
1 对于验证有bug修改的地方的处理：需要考虑新的修改是否带来新的验证点；如果修改会影响其它功能，而现有验证点又没有覆盖的，需要增加相应的验证点和相关的验证。
1 设计者需要考虑设计的可验证性：设计者要为验证者着想（设计者需要有验证经验），设计者需要降低组合的种类；要保证设计组合比较少，各部分的耦合性要低。
2 确保验证环境的有效性
验证环境是验证点的实际载体，好的验证环境能有效的保证验证的质量，而差的验证环境则会给人一种错觉，表面上所有的测试点都验证过了，但实际上由于验证环境有错误或验证环境不完善，而导致错误的设计也能通过这个验证环境。
这点在我们之前的2201芯片中有过类似的情况：由于我们的验证环境不完善，没有有效的错误检测机制，从而导致一些bug遗漏过去。
那我们如何保证验证环境的完备与有效呢？
3 要有完善的差错检测机制。
3 要有合适的debug机制
3 验证环境输出给DUT的接口信号需要有兼容性机制，即需要能够根据协议要求调整信号质量，使得信号能在一定的范围波动，甚至增加信号的毛刺等。
特别是对于芯片接口信号和数模接口信号，这些不靠性因素在实际中是真实存在的，所以一定要在功能仿真的时候尽量模仿真实环境。
1 要有合理的分层：
合理的随机机制：
3 对待随机测试的态度：
验证者要清楚不是每种首先随机都是有效的，所以，随机测例要有很好的目的性。
3 随机测例的目的是：
没有想到的条件组合是否有问题，所以重点是没有想到的，而不是想到，但为了偷懒而使用随机测试。
如果想到的有效条件组合，就不能使用随机测试。不管随机性如何的好，都有可能没有覆盖到这种有效条件。（我们之前就碰到过这个问题）
3 在时间有限的情况下，要提高受限随机的效率，没有效果的随机测试需要避免；
2 要有时间打印机制：
比如毫秒打印等。功能要可关闭（使用define即可）
2 要有准确报错机制：
跑出错误需要指明错误case号；
需要合理的时间控制机制：
3 需要有最长时间的finish机制；（单独起initial，#Time；$finish)；
3 出错的时候不要立即finish，最后延时一段时间，这样可以方便debug；
2 尽量少的拉probe：
对后方，混纺有好处。如果一定要有，需要可关闭；
1 要有异常检测机制：
比如毛刺检测等机制，特别是时钟输入信号；
Dump波形机制需要可灵活控制：
3 可以根据实际情况关闭；
3 可以做到在出错的地方左右dump需要的波形，以减少仿真时间；
使用自动检测机制取代看波形的方式：
3 尽快要使用合理的check机制来取代看波形来check是否正确。
要有合理的差错处理机制：
3 错误则仿真停止机制要可关闭（可以使用自定义的Finish task来处理）；
3 异常打印的时候需要打印具体的仿真时间；
验证环境的维护性：
3 验证环境命名需要有统一的规范，包括信号，参数，
3 需要有说明文档，说明共用的task使用方式，说明环境结构，参数说明等内容；
3 合理的parameter和define：把数据使用合理的字母定义数字；
1 要考虑验证环境易用性；
1 SVA使用；
验证组织：
3 验证计划：区分重点，掌控进度
3 验证心理：不放过任何异常；验证者需要具备严谨的工作作风
3 验证组织者需要掌控重点，瓶颈，与盲点；
1 在验证和设计分开的情况下，验证者最好跟设计者同时准备，而不要等到设计完成后才开始准备验证；这样可以让验证者加深对设计的理解。
2 验证者的思路需要独立于设计者。
2 分子系统，同步进行，落实责任，各自保证，要有统筹规划，统一Check；
2 要搞清楚那部分是重点，要把重点交给责任心强，能力强的人验证；一个功能两个子系统都覆盖的情况下，则最好由责任心强的那个来负责。
1 站在产品应用的角度考虑问题；
2 尽早开始考虑软件的验证，固件人员需要在验证阶段参与。
1 让验证者按照自己的思路去验证；
1 验证组织者要清楚交叉的地方，要制定明确的责任人。
1 需要详细记录bug，包括自验证和系统验证；
2 验证何时结束
验证者需要清楚一个事实：
我们的验证还没有做完；我们现在觉得做完了，是因为有好多点我们还没有想到。
我们之前做的任何验证，现在来看都有许多疏漏的地方；只是有些疏漏没有质量问题，因为设计做对了，不用验证也是对的。有些疏漏由于设计没做对，就形成了最后的bug；
那我们的验证是不是没完没了了呢？
不是的，验证者需要清楚，你想到的所有基本功能是否可靠的验证了；所有主要的功能组合是否都没问题了。
如果以上两点能保证，那验证阶段可以基本结束，因为这时99%以上的功能已经能够保证了，特别是所有重要功能都得到了保证；后续根据实际情况再补充。
