rockeric.com

芯片到底验到什么时候才能流片呢？这是芯片开发团队面对的最棘手问题之一，无数验证经理和验证工程师可能都考虑过tape out标准。

自20世纪80年代以来，为了量化解决这一问题，已经定义了一些指标和方法来降低流片风险，如功能覆盖率和代码覆盖率。如今利用这两个并不完美的指标，已经给我们流片提供了充分的信心。但是SoC设计愈加复杂的今天，这些指标对于系统级的验证看起来这有点鸡肋了。

在芯片设计中IP化极普遍的今天，组成SoC的众多模块都早已被验证过了，因此SoC级别的验证就显得尤为重要了。但问题是，能体现系统级验证质量的可靠指标是什么？

业内也在研究如何将现有概念和想法进行改进和实践，PSWG（Portable Simulus Working Groups）针对这一问题也将开启新一轮的讨论。

验证焦点的转换

自SystemVerilog和UVM创立以来，验证工作中，验证机制和覆盖空间已经发生了许多变化。Cadence研究员Mike Stellfox讲到：“对于IP和子系统验证，设计功能很好地映射到功能覆盖组以及交叉的功能覆盖组。使用随机约束可以尽可能详尽地验证模块所有设计功能。但是简单沿用之前的功能覆盖率不太适用于大规模SoC，如今的SoC级的验证常常是跨平台的验证，如simulation、emulation、FPGA等”

Mentor产品营销经理Mark Olen强调说：“系统级的覆盖率模型不仅仅是所有模块功能覆盖率的汇总模型，如果在SoC中只针对模块功能覆盖率展开验证，这只是在重复之前的工作，而且是在仿真运行更慢的验证环境中做无用功。”

Breker Verification Systems的首席执行官Adnan Hamid说:“系统级覆盖率和大数据有一些重叠，为验证一个相当简单的Arm系统，便携激励工具可以产生10^93个可能的路径。所有路径都可能映射着真实的行为。因此，尽管便携激励工具会定义覆盖率空间，我们依然需要知道的是哪些覆盖空间是有效的，在SoC级别，不会有人会尝试验证SoC中每个设计功能的交互组合，规模太大了，没有可操作性”

定义覆盖空间

便携激励图谱定义了一系列设计的预期执行功能，也可被称为测试场景或测试用例，便携激励工具可以基于便携激励图谱产生测试用例，这些测试用例都是完整的，并带有自我检查功能，而且可以在多个执行环境（simulation、emulation、FPGA等）中执行。

覆盖空间模型

除了每条可能的路径之外，我们还必须在图中包含并发活动的不同组合。假设所有路径都是独立的（当然真实场景一般不会这样），如果只有两个操作可能同时发生，所有路径都是独立的，那么总覆盖空间现在就是N x（N-1），其中N 是路径总数。

便携激励只是想要模拟硬件的行为。但是，很多时候工具事先并不能够知道真实场景会遇到怎样的复杂情况。设想有这样的一个测试，两个线程需要对同一资源进行访问，但这一资源只能同时被一个主设备访问，这样的话便携激励工具就需要考虑每个线程应该访问的时间，但便携激励生成器生成的测试不知道前面的任务可能需要多长时间，因此来自两个线程的请求可能重叠的顺序或方式也无法确定。所以激励的执行还需要返回其执行状况，以便更好的收集和提高覆盖率。

所以定义全面的覆盖空间需要考虑的因素也很多。

便携激励的完整性

而且便携激励图谱的完整性很难评估，因为它可能涉及到用自然语言编写的需求文档，你需要确定整个SoC系统能够做什么，然后才能分解它们，你要考虑设计所有可以执行的行为模型，并与功能列表进行交叉比对。

过去，通过比较不同类型的覆盖率来验证完整性。例如，通过查看代码覆盖率和功能覆盖率结果来确定缺失哪些测试激励。这当然是可行的，功能概率和代码覆盖率都是反映我们验证进度的重要指标。但Hamid继续说:“但是implementation coverage和intent coverage是两个不同的事情，implementation coverage是我们设计所完成的功能，intent coverage是芯片本身应该要完成的功能。而在系统层面，intent coverage很重要，过去20年，我们都把implementation coverage当作intent coverage。100％的implementation coverage并不能保证所有的设计意图都达标了。”

OneSpin Solutions产品管理总监Ashish Darbari说：“不能简单的用之前代码覆盖率、FSM等覆盖率的方式来看待这种根据行为定义的覆盖率。代码覆盖率、FSM等覆盖率等不能宏观的反映覆盖空间。”

那么我们如何确保覆盖空间的完整性呢？我们知道，实际的覆盖目标永远无法接近所有的意图覆盖空间。由于实际SoC验证中能覆盖的范围很窄，因此不能期望设计的所有功能都会被系统级测试覆盖。这仍然是模块级验证的任务。业界需要的是一种为总体覆盖空间提取有效子集的方法，这一子集可以在系统级展开验证。

定义覆盖率目标

业界如今也正是在这里挣扎，因为系统级覆盖率不仅仅是关注功能。性能和功耗也在验证考量范围之内。

Stellfox说：“在SoC验证中，功耗和性能的重要性与功能相当，考虑一款具有图像识别处理功能的汽车芯片，并且你有一个用例，测得在相机接口和加速器之间无法获得足够的带宽。这虽然是性能的问题，但可能是一场灾难性的失败。我们需要的是构建能够强调性能和功耗的测试场景，并跟测试用例的测试结果。”

有人建议，在不同验证方向上找到最坏情况组合，这一方案看起来似乎也是合理的。 Sonics首席技术官Drew Wingard表示：“如果验证场景将所有最坏情况都组合起来，芯片设计可能就很难做了，至少会由于开发周期过长而使市场表现不如预期。将所有的最坏情况组合在一起太过于保守了，验证工程师的艺术是找出哪些最坏情况不会同时发生，并证明这是安全的，这一工作，可能也会让验证工程师的工作更有趣一些吧。

业界目前正试图寻找一个最佳实践方案。 Stellfox表示：“类似于UVM在IP和子系统的随机激励应用实践，SoC级和大型系统的验证也终将找到一个可行的优化验证方案，而PS工具可能在这以方案中扮演重要角色。“