日志

完成功能验证就足够了吗？

已有 1791 次阅读| 2016-9-11 16:48 |个人分类:验证前沿资讯

基于验证的复杂性和验证的目的意义，验证的完成结束有许多层意义。对于一个新的设计，验证工作的完成有两种基本的节点，功能性验证完成和RTL验证完成，二者的不同在于一个完全着眼于功能属性，而另一个为确保设计的正确性加入了一些主观的RTL测试。

对于前者，功能性验证中，虽然工程师们使用了强大的验证语言和方法，但功能性验证的阶段还是花费了工程师们大量的力气。而后者，RTL验证更为自动一些，主要由工具来完成。把RTL代码读进工具，工具就会根据输入自动判断它是否通过检查。比如，跨时钟域的检查、综合检查、配置方式检查等。

功能性验证完成这个概念实际上有一些不准确性，特别是对于复杂的SOC而言。对于一个给定的IP验证项目，即使你能得到地球上最好的验证工程师们，对于设计要求的最精确严格的功能，他们验证代码都能覆盖到，并且他们遵循了最复杂全面的验证计划，你还是没法说对于设计要求100%精确验证到位了，也就是你没法严格的说你真的完成了功能验证。总会总一些其他的因素诸如一些难以到达的角落、验证角度的完整性、验证的深度、不精确的用例场景、设计的模糊等，这样的例子数不胜数，单独看其中一个方面，问题并不大，但是把他们结合在一块就是验证工作巨大的挑战了。就像一个有安全隐患的机械设计，功能验证也会有安全因素的考量。
技术发展到现在，极限测试以及使用独立的和可选择性的测试方法成为确保设计质量的途径。就像你会要求一名独立的验证工程师确保设计完整性一样，你最好采用一些独立的验证技术去验证一些关键性的设计。
基于上面描述的功能验证的属性，所以功能验证这一阶段花费了大量额验证时间。验证工作中我们也更倾向于着重考虑这一阶段，至少一个IP设计的功能验证要包含一些几个方面。
RTL代码覆盖 。检查以确保设计的各个方面都进行了测试，确保代码都被使用到了。
Functional覆盖 。使用functional covergroups和断言进行检查，以确保设计的各个方面功能性的正确。
用例测试。 根据设计的用途对设计进行测试。
Bug率。 没有新的bug生成，bug率不再上升。
当然，如果添加更多的压力测试、需求覆盖、计划覆盖、功能覆盖、稳定性测试等等就更好了。这时，为了便于管理项目，有一个工具可能对你很有帮助。Incisive vManager工具可以很容易地在一个统一的列表显示所有的功能验证结束的度量标准。这个列表把所有的其它覆盖率度量标准融合在一起形成一个统一的整体最终标准。为确保数据一致性，你也可以从多个其它地方把度量标准结合到一起。
功能验证的结束后，我们会进行RTL结构测试，并且附加另外的sequence、power-up和基于时序的检查。这些测试包括了 Power up、Shut down、 Configuration modes、 Reset、Low power等的测试。RTL结构验证需要额外地对时钟、综合、时序、状态机等方面进行附加的测试。另外，独立于质量目标，你的设计可能或多或少会有一些RTL-specific 完成目标。
验证工作中，两个阶段都很重要，并且他们作为验证工作进度的独立节点，要方便显示和管理。功能性验证中，度量标准决定了验证的结束，在不同的层次包含了不同标准。对于IP设计，度量标准多是基于覆盖率的，对于SOC设计，度量标准更多是基于测试用例验证进度。在项目中，读者可以尝试使用Cadence的Incisive vManager工具。Incisive vManager主要注重于功能验证的完成，并且提供能够自动收集、管理、分析功能验证结束的基础设施和接口，为工程师和项目管理者提供了很好的专用视角。通过数据导入或者API，Incisive vManager可以添加收集整合到的RTL验证完成数据，也为RTL验证工作完成提供了一定的分析依据。