技术干货 | SoC芯片设计验证详解

前  言

为了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。这也证明了制造时内核的互操作性。

验证计划是描述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板上的芯片顶层验证。

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

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

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

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

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

随着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支持许多带有可选参数的命令，以在测试场景中逐个执行模拟，并生成合并的结果。这被称为回归测试。

有许多验证工具可用于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是设计中心使用的少数几种已知验证工具中的两种。

与设计语言相比，用于建模测试平台或测试用例的语言更加宽松和灵活。这种灵活性的主要原因是需要在测试用例中创建更多的随机性，并且这不需要是可合成的。Verilog是最古老的HDL之一，也是验证语言。由于设计描述方法在体系结构级别上升到更高的抽象级别，一些验证语言，如SystemVerilog、Vera和System C，正在成为更高抽象层的主要硬件验证语言(hvl)。这些语言支持类、面向对象、类扩展和时态属性，这有助于轻松定义系统级或事务级测试功能。在提到的语言中，SystemVerilog作为一种强大的断言语言也越来越受欢迎，这是验证中的一个主要特性。但它也提供了一些构造，旨在确保合成和模拟之间的结果一致。此外，还有支持这些语言结构的模拟工具，可以解释结果，并根据测试覆盖率进行分析。它们支持诸如直接编程接口(DPI)之类的接口到诸如C++和Java之类的高级软件语言，这使得能够构建图形用户界面(GUI ),该图形用户界面可以使得验证环境在更高的抽象级别上更通用和有效，直到层级的系统级别。这些的更多细节可以在参考文献中提到的语言书籍中找到。模拟器工具现在足够智能，可以忽略设计人员犯下的常见错误，并可以通过通知用户警告来自行纠正错误。

设计验证通过发现系统设计和架构中的潜在错误来保证设计质量。只有尽可能详尽地模拟系统的所有功能，同时仔细研究任何可能的错误行为，才有可能做到这一点。这值得花费最多的时间、注意力和完整的设计用例知识。在大多数情况下，如果设计很复杂，这可能会变得非常具有挑战性。这要求设计是可验证的。设计师对功能的设计实现有完整的理解。如果设计者确定了设计的关键设计角和关键状态，则验证可以有针对性地监控和检查它们。有时在设计中，某些场景可能需要长时间的模拟运行来达到设计的极限，而验证工程师可能不知道这一点。一个简单的例子是32位计数器的溢出生成，它运行在一秒钟的时钟上。这需要很长时间来模拟，但在实际硬件中可能会很快发生。在这种情况下，如果设计人员提供预加载计数器的功能，32位计数器溢出是可行的。这样的设计调整使得设计可以在更多的场景中得到验证。设计师必须确定可以验证的关键设计角。此外，系统的非功能特性，如可伸缩性、可扩展性和灵活性，需要额外的设计支持来验证。这样的例子是存储器地址扩展、以非默认模式通过软件写入寄存器或存储器的访问、作为可能的错误解释问题(例如小端或大端)的替代提供的额外配置等。

通用验证方法(UVM)是一种行业标准验证方法，用于定义、重用和改进验证环境，并降低验证成本。它为验证环境中的基本类库(BSL)组件的使用提供了某些应用编程接口(API ),使它们可重用且独立于工具。基于UVM的验证环境对于各种类型的测试创建、覆盖分析和重用是足够灵活的。UVM标准化提高了互操作性，降低了重新购买的成本，并且采用了为每个新的SoC设计或验证工具重写知识产权(IP ),以便更容易地重用验证组件。总体而言，UVM标准化将降低整个行业的验证成本并提高设计质量。更重要的是，它可以使用复杂SoC设计验证中最常用的SystemVerilog来实现。

bug是系统中的缺陷。SoC设计的质量直接取决于其中隐藏的缺陷或错误。如前所述，较高设计或开发阶段(RTL、物理设计、布局、芯片、电路板、系统、现场系统)的测试成本至少比较低设计或开发阶段的测试成本高十倍。在早期设计/开发阶段发现缺陷或错误是明智的。Bug是特定场景中不需要的状态或条件。它可以是暂时的，也可以是永久的。这可能是由多种原因造成的。最主要的原因是设计者没有能力按照预期来解释需求(参考图中关于需求解释问题的著名的tree swing例子),以及大量隐含的、未声明的需求。由于验证人员对系统需求的解释以及他为整个用例场景创建测试用例的能力，设计缺陷也可能渗透进来。也可能是因为在设计阶段用于进行设计转换的人为错误和工具错误。在设计和开发阶段或在现场，正式记录和管理bug是很重要的，这样bug就可以被修复，不会反复出现。

— END —

免责声明

本文来源于网络，文中观点仅供分享交流，不代表本公众号立场。如涉及版权等问题，请您告知，我们将及时处理。

展会详情咨询

关注公众号，实时关注智能汽车电子最新资讯