fpga验证及其在soc验证中的作用有哪些

前 言

芯片的功能安全曾是非常小众的领域，只有少数汽车、工业、航空航天和其他类似市场的芯片与系统开发商关注。然而，随着汽车行业过去几年各类应用的兴起，情况已经发生巨大变化。同时，除了汽车外，还有很多其他行业也能从电子器件的增加受益，当然保障功能安全是大的前提。本文讨论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板上的芯片顶层验证。

04

功能验证

//

功能验证的目标是确认SoC设计在功能场景及其应用场景中的预期功能。一个用例场景可以映射到一个或多个功能测试场景。例如，为了验证模块的加法功能，可能有三种测试情况:第一种是验证输入操作数，第二种是验证与输入相对应的输出结果，第三种是检查加法器的进位操作。基本上，SoC设计包含不同功能的多个块，这些块彼此互连和/或共享总线，多个块在该总线上交互，或者一个块按照标准协议运行。在这种情况下，SoC的功能验证包括模拟(a)块到块接口验证，(b)总线争用验证，以及(c)协议和符合性验证。

05

验证方法

//

有三种类型的设计验证。它们是黑盒、白盒和灰盒验证。通过采用这些方法的不同组合来验证SoC设计。

黑盒验证

这是一种验证方法，其中设计实现的内部细节不会暴露给验证。通过仅访问暴露的接口信号而不访问内部状态或信号来完成验证，从而使其实现独立。显然，验证对于设计的内部实现细节或系统状态是不可见的。这种方法最适合发现解释级别的问题，如字节序检查、协议误解和互操作性测试。

白盒验证

在这种验证方法中，测试平台模块可以访问设计的内部状态、信号和接口。在这种情况下，调试任何设计问题都非常容易，因为测试平台可以根据预期跟踪信号驱动器。这种方法最适合于检查低层次的特定于实现的场景和设计角落，在那里他们可以针对具有潜在问题的场景进行设计并调试它们。这种情况的一个例子是FIFO指针翻转、计数器溢出等。在这种方法中，断言最适合检查内部设计行为。这种方法完全是对黑盒验证方法的补充。

灰盒验证

这种方法介于黑盒和白盒验证技术之间。在这种方法中，测试环境在接口层验证系统，在顶层验证IOs，并根据需要基本(如设计角)访问测试和调试的设计内部。通常，第一级测试使用黑盒方法作为目标，并评估功能覆盖率。为了提高覆盖率，如果需要，通过白盒方法，测试场景被测试。

06

验证设计

随着SoC设计方法向系统级或架构级发展，在跨子系统的事务级验证系统功能至关重要。然而，SoC设计主要是集成预先设计或预先验证的IP核，这更像是内部IP的黑盒验证。此外，复杂的SoC设计正趋向于验证友好，其中内部状态和关键信号被锁存，并可供软件通过主接口读取，从而预测问题的根本原因。这在“黑盒”或“灰盒”验证中很有用。功能验证在不同的环境中以不同的方式进行。在RTL级别，开发了测试平台和一组测试用例，并使用模拟器进行模拟，以查看SoC是否按预期运行。通过观察接口或模块/块级输入和输出的波形来检查功能正确性。

在基于FPGA的硬件验证中，将RTL形式的待测设计移植到板上的FPGA，运行有限的软件，将实际激励馈入SoC输入，并在开发环境中观察输出。

在开发环境上，基于子模块的开发平台设计开发了与最终SoC接近的接口，并用一些更复杂的软件进行了验证。

RTL级别的测试环境或测试台代表SoC最有可能使用的环境。所有的环境都被开发来接受尽可能接近真实世界输入的刺激。典型的RTL试验环境(也称为试验台)是一个封闭的系统，因为它代表了一个完整的环境，包括通过行为总线功能模型(BFM)的输入刺激和输出控制。

外围模块

这些模块是在应用环境中完成SoC验证所需的支持模块。它们是外围功能的验证IP或IP，如外部存储器、数据转换器和实时传感器模型。

输入激励和公共功能模型(BFM)

输入激励代表在实际应用场景中被验证的SoC从外部世界馈入的输入信号。它可以是系统设计信号，如来自参考晶振的时钟、复位信号、传感器输入或来自SoC外部模块或验证IP的数据输入。SoC所需的来自不同源的激励的产生是自动的(当参考时钟被馈送到PLL模块时，它自动产生SoC所需频率的系统时钟，如所配置的)或半自动的，具有手动触发或有条件的。它们通过接口馈入SoC设计，通过总线功能模型(BFM)遵循设计的时序要求。

输出BFM

该输出BFM通过其输出接口捕捉特定激励输入时SoC的响应。将响应进行比较并写入文件，以便与预期输出进行比较，或者实时检查预期。该模块或者是具有文件比较功能的检查器，或者是波形数据库发生器，而SoC设计通过测试输入条件受到特定场景的影响，设计人员在图形查看器上查看这些输入条件并判断其正确性。

连续监视器

这些是环境中的附加检查点，它们是SoC正常运行的指示器。例如，在产生1-s时钟的定时器SoC中，很容易连续监控1-ms信号，该信号预计会连续滴答以产生1-s时钟。在测试环境中，测试块是非常模块化的，结果被自动检查，并作出通过/失败的决定，因此它们是自动化友好的。测试环境能够分析功能、代码和FSM覆盖率的设计。

测试环境模块的简要描述如下。

SoC DUT

SoC DUT是待验证的测试中的SoC设计。

设计和验证断言

测试中的设计和验证测试环境可以有断言来提高验证的有效性。断言是用于检查设计中同步信号的时间关系以确保模块正确运行的语句。设计断言，如果被支持，由测试工作台检查器模块跟踪，以查看它是否已经被触发，并且被评估正确性。例如，考虑逻辑设计的一部分，其中功能是检查接收的分组是否正确，并且接收的分组由packet_valid信号验证。显而易见，每当产生packet_correct或packet_error信号时，packet_valid信号应被设置为高电平。在这种情况下，写一个检查packet_error和packet_valid或packet_correct和packet valid信号同时出现的设计断言是有意义的，如果触发了该断言，则可以验证设计意图。在所示的例子中，设计断言被写入以查看packet_valid和packet_correct或packet_valid和packet_error信号是否不同时出现。如果这个断言被触发，那么这个设计就是有缺陷的。

可以在DUT事务的事务级别编写类似的断言，并对设计的正确性进行跟踪。

时钟/复位模块

时钟复位模块根据SoC设计的要求产生所需的时钟和复位信号。

配置

该模块将DUT和测试台设置为需要测试DUT的配置。

激励发生器

该模块在测试台中产生输入激励。通常，该模块根据SoC功能以所需的顺序和次序产生信号。这可能是一个复杂的IP验证。

总线功能模块(BFM)

总线功能模块遵循接口规范向SoC DUT提供激励。总线接口有多少，BFM就有多少。如果SoC设计支持UART、USB和PCI Express接口，则应该有一个对应于这些接口的BFMs来管理符合这些协议的事务。

邮筒

这些是系统Verilog测试平台中的通信机制，允许在进程之间交换消息。希望与另一个进程对话的进程将消息发送到mailbox，mailbox将消息临时存储在系统定义的内存对象中，然后将消息传递给所需的进程。创建的邮箱具有绑定或未绑定的队列大小。当绑定邮箱包含的邮件达到定义的最大数量时，该邮箱就会变满。试图将邮件放入已满邮箱的进程应被挂起，直到邮箱队列中有足够的可用空间。基本上，邮箱是一种同步不同进程技术。该过程可以是checker，如本例所示。一旦邮箱有了一组预定义的消息，它们就可以启动一个检查器来检查内容并判断其正确性。

棋子

Checker检查所有过程，如将DUT响应与预期、断言和监视器进行比较，以决定测试场景的通过/失败标准。

测试程序接口(TPI)

这是用户界面，它接受用户输入作为参数，并编译选项来触发测试场景和执行模拟。TPI支持许多带有可选参数的命令，以在测试场景中逐个执行模拟，并生成合并的结果。这被称为回归测试。

07

验证示例

在本节中，我们将介绍一个简单的十进制计数器设计的仿真，以便更好地理解验证过程。

十进制计数器的设计功能:十进制计数器在时钟的每个有效边沿计数数字0、1、2、3、4、5、6、7、8、9、0。设计要求每当计数器计数到5时就产生一个输出信号。

设计文件保存为decade-counter.v，测试台文件保存为tb_dcounter.v(。v代表Verilog文件)。为了模拟设计文件，使用了模拟器。大多数使用的模拟器是基于循环的模拟器。基于周期的仿真器对信号进行采样，并在每个时钟周期计算设计响应。模拟器首先分析RTL代码，并在模拟设计之前进行阐述。

执行模拟时，观察终端上显示的错误和警告日志消息。如果有任何错误/警告，需要在设计文件中纠正它们。对于设计示例中的模块，不应该有任何警告或错误，模拟会成功终止。如果您在当前的工作目录中观察，会发现模拟运行生成了许多输出文件。它们是命令日志文件、名为decade_counter.vcd的波形转储文件。decade_counter.vcd文件可以用波形查看器工具打开。当在波形查看器工具中打开该文件时，可以观察到输入输出信号和内部网络的逻辑状态变化。有关运行仿真和使用波形查看器工具的更多信息，可以参考相应的用户手册。通过观察设计信号clock，reset_n和out_5，count_out来验证设计行为。

验证流程可以扩展到任何复杂程度的设计。本节中解释的下一个设计示例演示了这一点。阐述了利用扰码器设计作为验证IP的自同步解扰器在测试平台上的验证。考虑多项式g(x) = 1 + x13 + x33的自同步扰频器的设计。如果输入数据是具有零DC偏移的0或1的长序列，则在通信中使用自同步加扰器模块来加扰输入数据。在发送器使用相同的多项式对数据进行加扰，并在接收器端使用相同的多项式对数据进行解扰以恢复发送的原始数据。自同步解扰器中解扰器的功能属性，因为它不需要由初始化向量初始化来实现同步。

加扰器-解扰器的同步被定义为加扰器和解扰器的LFSRs保持相同的模式，因此，当数据被馈送到解扰器时，它可以生成加扰器数据的输入。

被测模块是解扰器。为了测试解扰器是否与加扰器同步，需要将解扰器LFSR重置为任何初始值。随机模式通过加扰器输入，加扰后的数据作为输入激励输入解扰器。将验证解扰器在某个时间点将能够解码输入的数据。您可能会注意到，测试平台没有任何端口，因为这将是一个独立的测试模块环境。

试验台由以下部分组成:

1

测试平台的第一部分是激励产生，包括时钟、复位、使能和数据产生。

2

第二部分是加扰器模块，用作标准验证IP。

3

第三部分是模块实例化。

4

第四部分是输出读取器和波形转储，用于调试和用户验证。

一个典型的SoC测试平台将具有多个时钟(OCC)生成模块和标准PLL、多个所需的VIP，以及控制状态机，这些状态机将使这些模块中的每一个能够用于多种测试场景。输出读取器和波形转储部分可以是复杂的模块，可以根据SoC验证要求自动验证功能的正确性。

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就可以被修复，不会反复出现。

责任编辑：彭菁