作者：郑威
前言
芯片的功能安全曾是非常小众的领域，只有少数汽车、工业、航空航天和其他类似市场的芯片与系统开发商关注。然而，随着汽车行业过去几年各类应用的兴起，情况已经发生巨大变化。同时，除了汽车外，还有很多其他行业也能从电子器件的增加受益，当然保障功能安全是大的前提。本文讨论SOC芯片设计验证、验证计划和策略以及验证方法。它定义了功能模拟、功能覆盖、代码覆盖以及设计验证中使用的重要术语。本文还涉及FPGA验证及其在SOC验证中的作用。
01、验证的重要性
由于开发和制造成本过高，一次成功是SoC设计的首要要求。几十年来，人们一直致力于提高SoC验证的有效性和效率。评估验证有效性的最有效指标是SoC设计通过现场测试的次数。除此之外，SoC设计越来越复杂，需要有效的验证方法来改善这些统计数据。这种对ASIC/SoC设计的有效验证的需求在2000年出现，开始设计许多创新的方法来验证SoC设计，但仍有更多的空间。
SoC验证是用于确认SoC设计的功能正确性的过程。典型的SoC设计周期(从规格开始到设计流片)从六个月到三年不等，具体取决于技术、系统的复杂性以及SoC设计构建模块的可用性。制造过程、封装、ATE测试和获取工程样品进行现场验证(芯片交付给客户进行产品试验)通常需要6个月的时间。因此，所有的SOC只有在工程样品在确定的产品用例场景中被验证之后才可用于生产。如果这是成功的，SoC设计被考虑用于批量生产。这是设计的一次成功。开发周期中任何一个步骤的失败都会成倍地影响设计时间，有时需要新的金属流片和设计修正。使设计一次成功的另一个驱动因素是纳米技术的制造成本。采用40纳米CMOS FinFET技术的36平方毫米芯片设计的典型制造成本约为80万至100万美元。SoC工程样品开发期间产生的高额非经常性工程(NRE)和制造成本将在大量生产中摊销。因此，如果NRE要求对工程样品进行多次流片，那么它可能会对业务产生很大影响，在商业上根本不可行。因此，在片上系统开发中，一次成功是绝对必要的。
SoC设计验证的可行性取决于在预硅阶段确定系统的一组“最常见的用例场景”。这是一个非常复杂和具有挑战性的现象，因为可能有无数的用例场景。例如，人们可以很容易地想象智能手机移动SoC的无数用例场景，其主要功能是通话电话。但是智能手机被用于许多应用，例如发送信息、购物、跟踪人体健康、银行和信息娱乐。将会有大量的应用场景来测试和验证移动SoC对这些应用场景的设想来识别和验证它们。在开发周期中，随着设计从一个阶段进入下一个阶段，调试SoC问题的成本会增加10倍。也就是说，设计阶段的验证成本比在晶片阶段验证相同功能的成本低10倍，比在芯片阶段验证的成本低10倍。这比在客户现场进行验证要便宜十分之一。这是因为与开发的高级阶段相比，设计人员在设计阶段获得了更高的调试权限和工具支持。因此，在预芯片阶段，一组接近实际应用用例的关键场景将被识别和瞄准，以获得SoC首次成功的良好信心。SoC设计是通过集成不同类型的设计模块或IP核(软、硬核)来完成的，这进一步挑战了设计验证。SoC设计过程还包括从RTL到网表再到布局结构的一系列设计转换，然后转换为掩模数据。当设计经历这些转换时，需要验证设计意图在所有层次上都得到了保留，直到完成为止。
总而言之，验证对SoC设计如此重要的原因如下:
1. 过高的制造成本要求首次成功，因为多次重复可能使其在商业上不可行。
2. 随着开发周期中设计的进展，验证成本增加10倍。因此，早期验证将增强首次获得正确SoC设计的信心。
3. 由于SoC设计涉及到使用EDA工具对数据库进行一系列转换，因此有必要验证这些转换是否正确实现，这需要通过验证来完成。
02、验证计划和策略
为了SoC设计的一次成功（当它第一次被制造时，SoC按预期工作），在设计阶段采用许多验证方法是重要的。所使用的不同类型的验证技术是基于仿真的验证、形式验证、时序验证、FPGA验证以及硬件仿真和验证。仿真验证是过去唯一采用的技术。但是随着系统的日益复杂，有必要使用一切可能的方法来验证SoC设计。
很难定义完成设计验证的条件，因为几乎不可能模拟SoC设计的所有设计场景。考虑具有两种状态的单个触发器的设计示例：测试触发器所需的测试模式的数量是4，ARM Cortex M4内核采用65纳米技术，具有65 K个门，这些门可以有多个输入输出。为了简化讨论，假设所有的门只有两种状态，想象一下测试ARM cortex M4内核所需的模式数量，将是65 × 1000 × 4 = 0.26万个图案。仅仅模拟所有这些（不考虑从主要输入-输出访问它们的问题，为它们中的每一个寻找测试模式，等等）在不同的设计阶段实际上是不可能的。
在系统层面，识别所有场景也是非常具有挑战性的。这可能是因为无法预测和可视化用例场景本身，或者可能是因为环境中需要更多的模型或模块来实现它。它可以是完整的软件堆栈，也可以是移植整个设计数据库的硬件平台，或者是用于仿真的计算系统基础设施。因此，需要将可实现的场景定义为验证测试环境和一组测试用例，作为预芯片验证的范围。这可以通过多种方式实现：
- 自上而下的方法
- 自下而上的方法
- 平台级验证
- 系统级或交易级验证(TLV)
自上而下的方法
在这种方法中，SoC从接口层级的最高层开始验证，然后继续到层级的下一个较低层，直到最小的叶级设计元素被验证。传统上，当SoC设计有一个或两个层次时，这种方法被用作验证计划。
自底向上的方法
这是设计验证中最常用的方法。它从验证较小的设计块开始；验证小块是简单而实用的。此外，在块级模拟中，查找错误并修复它们更容易。这是因为在较小的设计中更容易来回跟踪信号，以便在发现问题时进行调试。当多个模块被验证时，它们被集成以形成芯片的顶层模块，这由单独的顶层测试设置来验证。例如，由UART内核、USB内核和协议总线接口内核组成的SoC中的内核首先逐个内核进行验证，然后在芯片顶层进行验证。
平台级验证
如果设计是基于标准的，如USB设备内核，最好在安装了标准对等设备(如USB主机设备)的标准平台上进行验证。同样，SPI从内核可以在带有SPI主器件的平台上进行验证。这也将确认互操作性问题。
基于系统接口级验证
如果SoC基于协议，则需要通过监控对事务的响应，使用标准验证IP(知识产权)内核构建验证设置。例如，在具有WLAN接入点的环境中，通过观察两者之间的事务来验证Wi-Fi设备核心。WLAN接入点核心是经过预先验证和确认的标准参考验证IP。这也证明了制造时内核的互操作性。
03、验证计划
验证计划是描述SoC设计验证计划和流片标准的文档。它解释了如何计划验证SoC设计的每个功能。它列出了模块级和层次结构顶层的验证目标。它确定了必要的工具，如模拟器、波形查看器和用于验证的脚本。它明确提到了成功完成验证的覆盖标准，作为设计流片的完成标准。
与SoC设计相关的不同验证覆盖有：
- 功能覆盖
- 代码覆盖
- 有限状态机(FSM)覆盖
功能覆盖通过编写测试用例并设置模拟要实现的正确设计响应来量化要验证的功能数量。有一些工具可以通过测试用例以及功能(特性)列表来测量功能覆盖率。由于识别功能并输入到这些工具中是手动完成的，所以为了获得高覆盖率，功能的数量可能会不足。
还有一个通常使用的参数叫做“代码覆盖率”,它决定了在RTL级别的设计数据库上模拟的测试用例所覆盖的RTL语句的数量。这有助于识别设计数据库中的冗余代码，并有助于代码清理。
用于代码覆盖的工具也能够给出测试用例所覆盖的有限状态机状态。这是一个非常重要的措施，通过添加适当的测试用例来覆盖所有的状态转换。设计验证范围不仅用于评估一些公司的设计验证状态，还用于评估验证工程师的表现。
验证计划文件根据设计范围列出了设计验证完整性的标准。验证覆盖率的剩余差距由其他验证技术填补，如基于FPGA的验证、仿真技术以及在开发板上测试SoC设计。例如，如果通过仿真实现的功能覆盖率是98%，那么剩余的2%是通过将设计移植到FPGA上并在FPGA板上测试相关功能或任何其他适当的测试技术来实现的。这些方法可能需要板上和FPGA上的额外电路，以使其成为适合SoC设计功能验证的测试设置。它可能还需要在运行的软件或与之接口的系统。
验证计划中包含的主要设计细节如下:
1. SoC设计首次成功的定义
2. SoC的关键应用场景。SoC测试对测试环境开发的要求
3. 功能验证环境和所需资源的开发计划
4. 将在模块级和设计层级的顶层验证的功能特性列表
5. 区块和顶层设计的主要验证策略
6. 设计RTL级别的测试平台模块：
- 总线功能模块(BFM)和总线监视器
- 信号监视器
- 验证参考模型
7. FPGA级验证详情：
- SoC验证对FPGA板的要求
- FPGA验证平台需要附加模块
- 将根据这一要求开发所需的软件模块、软件开发和调试平台
8. 所需的验证工具和流程
9. 对块级仿真环境的要求
10. 回归测试环境和回归测试计划
11. 确定验证完成的明确标准，如目标覆盖率、回归测试向量的数量，以及门级模拟策略和期望
设计资源包括验证工程师及其技能、硬件开发板、FPGA板、软件要求、EDA工具环境、(工作站和服务器)模拟器(许可证数量)以及用于验证的设计基础设施。验证VLSI SoC的策略因SoC的设计复杂性和使用场景而异。
理想情况下，其目标是使用RTL级测试平台或FPGA验证计划，或使用开发板设置，或任意或全部组合，来仿真/模拟用例场景。使用这些资源，验证SoC设计，以获得预测其成功的高度信心。验证策略包括子模块级验证的设计划分和FPGA板上的芯片顶层验证。
未完待续……
本文转自：TUV北德工业服务，转载此文目的在于传递更多信息，版权归原作者所有。如不支持转载，请联系小编demi@eetrend.com删除。
