作者：郑威
08、验证工具
有许多验证工具可用于SoC设计的功能验证。
它们是 :
1、模拟器
2、覆盖工具。
在上面列出的工具中，模拟器对于RTL功能验证是必不可少的。模拟器是一种工具，通过在测试平台中使用测试向量来理解大多数预期用例场景中的设计行为。它是一个软件，能够在用户提供刺激的情况下，在要求的持续时间内研究SoC设计状态及其输出，称为测试向量。有不同类型的模拟器。它们是基于周期的模拟器、基于事件的模拟器和电路模拟器。要模拟的SoC设计称为被测器件。模拟器使用测试平台中的某些命令，可以在模拟期间监控和写出内部逻辑电平、设计模块中的信号状态和输入输出。然后，在与图形调试环境交互的波形查看器工具中打开该波形输出文件。基于SoC设计的类型，使用不同的仿真器进行验证。基于周期和基于事件的模拟器是数字模拟器。大多数用于数字模拟的模拟器是基于循环的模拟器。基于周期的仿真器在每个周期评估设计的逻辑状态。模拟器周期为皮秒或纳秒量级，以便为用户虚拟仿真硬件的并发行为。上述模拟器都是基于循环的模拟器。它们被称为周期精确仿真器，因为它们在时钟信号的输入边沿对SoC设计进行采样。基于周期的模拟器比基于事件的模拟器快10-100倍，用于大多数SoC设计验证。使用基于周期的模拟器的设计验证需要STA分析，因为设计是以时钟间隔验证的。
每当电路中的任何网络上发生逻辑变化时，基于事件的仿真器评估设计。这些模拟器也称为定时精确模拟器，适用于小电路级验证。它们提供了良好的调试环境，并且也不需要时序分析，因为在设计中的所有节点上的所有事件中，设计都被功能性地验证。基于事件的模拟器需要运行模拟的大型计算机器。这是因为当今SoC设计中的网络数量激增，在仿真过程中会有大量的逻辑转换。监控网络上的大量逻辑转换并评估它们的所有组合实际上是不可能的。在这样的设计中调试故障是非常困难的。
当今的SoC设计包括模拟模块，也需要对其进行验证。使用模拟仿真器单独验证模拟模块。模拟仿真器使用数学模型来表示设计的模拟功能。它们通过检测并产生对设计的适当响应来模拟模拟功能。很少有模拟和混合信号模拟器可用。
模拟器通常非常慢，并且不是自动化的。它们要求设计师很好地理解设计，并使用工具作为分析设计的辅助。因此，模拟模块的详细验证是单独进行的，然后进行模拟-数字混合信号仿真，只是为了在实践中验证集成。另一个用于验证模拟过程或模块的重要工具是提取覆盖率分析器。覆盖矩阵提供了对设计数据库验证的质量或完整性的洞察。有三种类型的覆盖:功能覆盖、代码覆盖和状态机覆盖。通过比较和分析在SoC设计数据库上运行的测试用例以及SoC设计的功能特征清单来获得功能覆盖。代码覆盖率是在SoC设计上运行仿真以跟踪设计中被激发的代码行时提取的指标。由于模拟运行中的测试情况，状态机覆盖范围给出了设计FSM中状态转换的信息。所有这些矩阵都有助于验证工程师最大化覆盖度量，从而达到设计验证目标。
除了HDL语言的基本语法和语义之外，Lint工具还根据为不同目标设置的规则，在RTL级别检查SoC设计。这是一个静态的RTL代码检查器。它通过编译设计并为仿真、综合和DFT仿真对其进行预处理来进行检查。运行lint的不同设计目标是针对仿真、可综合性和可测试性的RTL设计的基本编译。工具为每个目标定义了标准规则。这些规则集中的每一个都可以针对SoC特定的设计目标进行定制或增强。当在设计文件上执行时，这些工具会写出日志文件，根据定义的规则对设计进行详细分析，并根据违规的严重程度对违规发出警告和错误警报。nLint和HAL是设计中心使用的少数几种已知验证工具中的两种。
09、验证语言
与设计语言相比，用于建模测试平台或测试用例的语言更加宽松和灵活。这种灵活性的主要原因是需要在测试用例中创建更多的随机性，并且这不需要是可合成的。Verilog是最古老的HDL之一，也是验证语言。由于设计描述方法在体系结构级别上升到更高的抽象级别，一些验证语言，如SystemVerilog、Vera和System C，正在成为更高抽象层的主要硬件验证语言(hvl)。这些语言支持类、面向对象、类扩展和时态属性，这有助于轻松定义系统级或事务级测试功能。在提到的语言中，SystemVerilog作为一种强大的断言语言也越来越受欢迎，这是验证中的一个主要特性。但它也提供了一些构造，旨在确保合成和模拟之间的结果一致。此外，还有支持这些语言结构的模拟工具，可以解释结果，并根据测试覆盖率进行分析。它们支持诸如直接编程接口(DPI)之类的接口到诸如C++和Java之类的高级软件语言，这使得能够构建图形用户界面(GUI ),该图形用户界面可以使得验证环境在更高的抽象级别上更通用和有效，直到层级的系统级别。这些的更多细节可以在参考文献中提到的语言书籍中找到。模拟器工具现在足够智能，可以忽略设计人员犯下的常见错误，并可以通过通知用户警告来自行纠正错误。
10、自动化脚本
为SoC创建用例场景是通过一组具有随机刺激的复杂测试用例来实现的，因为实时场景是随机的。当刺激是随机的，对这种刺激的反应变得难以预测。因此，测试通常在这种情况下通过预测最终结果或状态或分析系统的统计数据和稳定性来进行，并且也在可预测的系统中间状态进行。这需要输入随机性和系统状态的某种一致性，它们或多或少都在变化。为了映射出这种对应关系，测试用例是自动化的。自动化意味着测试期望，比如数据完整性、状态，以及将控制移交给下一个随机场景，被自动控制和评估。这是通过脚本语言实现的。最常用的脚本语言有Perl、Tcl、PHP等。因此，脚本语言是为特殊的运行时环境编写的编程语言，这些运行时环境自动执行原本可以由用户一个接一个执行的任务。EDA工具也理解这些结构，因此可以集成到测试设置中。自动化也用于分析大数据的完整性检查、统计分析，并批量运行测试用例以获得期望的功能覆盖。测试脚本是被解释的，而不是编译的。
11、设计验证
设计验证通过发现系统设计和架构中的潜在错误来保证设计质量。只有尽可能详尽地模拟系统的所有功能，同时仔细研究任何可能的错误行为，才有可能做到这一点。这值得花费最多的时间、注意力和完整的设计用例知识。在大多数情况下，如果设计很复杂，这可能会变得非常具有挑战性。这要求设计是可验证的。设计师对功能的设计实现有完整的理解。如果设计者确定了设计的关键设计角和关键状态，则验证可以有针对性地监控和检查它们。有时在设计中，某些场景可能需要长时间的模拟运行来达到设计的极限，而验证工程师可能不知道这一点。一个简单的例子是32位计数器的溢出生成，它运行在一秒钟的时钟上。这需要很长时间来模拟，但在实际硬件中可能会很快发生。在这种情况下，如果设计人员提供预加载计数器的功能，32位计数器溢出是可行的。这样的设计调整使得设计可以在更多的场景中得到验证。设计师必须确定可以验证的关键设计角。此外，系统的非功能特性，如可伸缩性、可扩展性和灵活性，需要额外的设计支持来验证。这样的例子是存储器地址扩展、以非默认模式通过软件写入寄存器或存储器的访问、作为可能的错误解释问题(例如小端或大端)的替代提供的额外配置等。
12、验证中的断言
在设计中实现断言需要有意识地决定以不同的方式来看待设计过程。这是一个附加的设计和验证声明，用于监控这部分设计的正确性。断言肯定会减少调试时间和工作量。断言本质上充当模拟期间的早期警告，可以查明可能直接导致测试失败或者未被通过的测试检测到的故障。模块接口上的断言可以快速识别可能由行为模型或设计的不当使用(无效寄存器设置、无效操作模式等)引起的无效行为。).这种断言失败表明测试平台可能存在问题，这有助于验证工程师修复测试平台中的问题。它有助于解决设计中的问题。设计断言通过查看失败所显示的不正确的功能来帮助定位失败的根本原因。例如，约束随机模拟检测FIFO操作的溢出和下溢处的设计角处的设计问题，这些问题通常不是定向测试的目标。FIFO接口信号上的简单断言检测同时的读和写操作、读的数量超过写的数量等。将有助于在测试场景中找到实际失败的根本原因，而无需冗长的调试会话。断言更大的优势在于，它通过保留设计和验证所有者之外的设计意图，使设计和验证测试平台可重用。
13、验证重用和验证IP
就像可重复使用的设计模块一样，验证模块也可以在各代SoC设计中重复使用。由于多个接口协议模块是SoC的一部分，如一些具有多个USB内核、多个SPI内核和多个UART内核的SoC，相应的测试模块可以在测试台中重用。测试平台中的总线接口模块(BFM)和接口内核甚至可以用来验证具有相同功能的SOC的数量。这也将解决上市时间缩短和设计生产率差距的问题。随着SoC功能变得越来越复杂，许多集成内核符合许多标准并需要具有互操作性，在过去几十年中，这些模块被开发为参考模型，以确保符合标准规范。这些被称为验证IP。这些都经过预先验证或认证，符合标准或协议规范。这些可以被许可，或者从知识产权开发者那里购买。这些VIP作为标准IP集成到测试环境中，SoC根据验证IP进行测试，以证明合规性和互操作性。验证IP的重用是SoC验证中的常见做法。
14、通用验证方法(UVM)
通用验证方法(UVM)是一种行业标准验证方法，用于定义、重用和改进验证环境，并降低验证成本。它为验证环境中的基本类库(BSL)组件的使用提供了某些应用编程接口(API ),使它们可重用且独立于工具。基于UVM的验证环境对于各种类型的测试创建、覆盖分析和重用是足够灵活的。UVM标准化提高了互操作性，降低了重新购买的成本，并且采用了为每个新的SoC设计或验证工具重写知识产权(IP ),以便更容易地重用验证组件。总体而言，UVM标准化将降低整个行业的验证成本并提高设计质量。更重要的是，它可以使用复杂SoC设计验证中最常用的SystemVerilog来实现。
15、缺陷和调试
bug是系统中的缺陷。SoC设计的质量直接取决于其中隐藏的缺陷或错误。如前所述，较高设计或开发阶段(RTL、物理设计、布局、芯片、电路板、系统、现场系统)的测试成本至少比较低设计或开发阶段的测试成本高十倍。在早期设计/开发阶段发现缺陷或错误是明智的。Bug是特定场景中不需要的状态或条件。它可以是暂时的，也可以是永久的。这可能是由多种原因造成的。最主要的原因是设计者没有能力按照预期来解释需求(参考图中关于需求解释问题的著名的tree swing例子),以及大量隐含的、未声明的需求。由于验证人员对系统需求的解释以及他为整个用例场景创建测试用例的能力，设计缺陷也可能渗透进来。也可能是因为在设计阶段用于进行设计转换的人为错误和工具错误。在设计和开发阶段或在现场，正式记录和管理bug是很重要的，这样bug就可以被修复，不会反复出现。
作者介绍：
郑威，TÜV北德，功能安全（SIL/ASIL)证书评估授权人，功能安全工程师资质课程授权讲师&功能安全专家，ASPICE Provisional Assessor，国家注册审核员，中国工业过程测量控制和自动化标准化技术委员会，系统及功能安全分技术委员会委员，国家功能安全标准GB/T20438起草工作组专家成员，“TÜV功能安全工程师”课程组织推广领军者
本文转自：TUV北德工业服务，转载此文目的在于传递更多信息，版权归原作者所有。如不支持转载，请联系小编demi@eetrend.com删除。
