嵌入式系统验证的自动化 C 测试用例

随着片上系统 (SoC) 设计向更高的复杂性迈进，包含数千行用于系统级验证的代码的测试套件继续由手工编写，这是一种古怪的老派和无效的实践，违背了“自动化”的格言。只要有可能。”对于在 SoC 的嵌入式处理器上运行以在制造前验证整个设备的 C 测试尤其如此。

在可能的情况下自动化验证测试组合已被证明可以提高 SoC 开发的许多阶段的生产力。例如，在通用验证方法 (UVM) 测试平台中，约束随机技术利用针对特定场景的随机测试向量来增加覆盖率。虽然这些提高了硬件模块级别的验证效率，但该设计仍被视为一个黑匣子，激励、检查和覆盖代码分别编写，对于大型模块来说仍然是一项繁重且容易出错的任务。

鉴于需要将处理器测试代码与 I/O 事务（通常在仿真器或原型系统上执行）相结合，很难将此方法扩展到系统级别。要正确验证 SoC，必须使用处理器本身。 UVM 和其他受约束的随机方法不考虑在处理器上运行的代码。事实上，要在 SoC 上使用 UVM，处理器通常会被移除并替换为 SoC 总线上的虚拟输入和输出，从而可以验证子系统减去处理器。

SoC 验证工程师认识到约束随机测试平台的局限性，促使他们手写 C 测试以在处理器上运行以进行仿真和硬件仿真，即使他们在充分运用 SoC 设计方面受到限制。这些验证平台的性能不足以运行完整的操作系统 (OS)，因此这些测试执行“裸机”，这为组合工作增加了大量开销。手写测试，尤其是在没有操作系统服务帮助的情况下，在利用多个线程的多核处理器之间以协调的方式运行是不寻常的。结果是对 SoC 行为的各个方面（例如并发操作和一致性）进行了最低限度的验证。

自动生成 C 测试

当然，自动生成的 C 测试将更有效地利用工程资源。它们还增加了覆盖范围。与手写测试相比，生成的 C 测试用例可以使用更多的 SoC 功能，并将寻找难以想象的复杂极端案例。多线程、多处理器测试用例可以使用设计中的所有并行路径来验证并发性。它们可以在内存段之间移动数据以强调一致性算法，并在数据应该发送到芯片的输入或从其输出读取时与 I/O 事务协调。这样做的总体效果是增加了系统功能覆盖率，通常比特征性低得多的数字覆盖率超过 90%。

测试生成软件称为 Test Suite Synthesis，它使用易于理解的基于图形的场景模型来捕获预期的设计行为。这些模型可以使用本地 C++ 使用 Accellera 便携式激励标准编写或进行可视化描述。场景模型由设计或验证工程师创建，作为 SoC 开发的自然组成部分，因为它们类似于传统的芯片数据流图，可能会绘制在白板上以解释部分设计规范。

这些模型本质上包括激励、检查、覆盖细节和调试信息，为生成器提供了生成高质量、自检 C 测试用例所需的一切，这些测试用例强调设计的各个方面。因为它们是分层和模块化的，所以在块级别开发的任何测试都可以作为完整 SoC 模型的一部分完全重用，并且可以轻松地与不同团队和跨项目共享。最后，可以通过综合工具分解单个意图模型，以提供跨线程和 I/O 端口的并发测试，所有这些都同步在一起。

优势测试套件合成

测试套件合成的一个显着优势是能够在意图模型上预先定义覆盖目标。一旦指定了意图，该工具就可以对其进行分析，以了解可以生成的测试数量以及可以实现的功能意图的覆盖范围。

对于 SoC，这可能需要进行数千次测试。然后可以通过限制要测试的意图并将工具集中在关键领域来设定覆盖目标。此功能避免了传统方法中出现的痛苦的迭代循环，即设置测试、运行验证工具、了解实现的覆盖率，然后一遍又一遍地重置测试。

在某知名半导体公司开发的大型 SoC 上的一个典型项目中，验证工程师将测试组合时间减少到以前需要手写测试的 20%。自动化技术产生了更严格的测试用例，覆盖率从 84% 增加到 97%。此外，模型是便携式的。

单个模型可以为虚拟平台、寄存器传输级 (RTL) 仿真、仿真、现场可编程门阵列 (FPGA) 原型或实验室中正在进行硅后验证的实际芯片生成测试用例。

调试是工程师的另一个时间节点，尤其是在 SoC 级别。如果测试用例发现了潜伏的设计错误，验证工程师必须了解哪个测试触发了错误以追踪其来源。测试用例失败可能是由于场景模型中的错误造成的，因此必须能够将测试用例关联回捕获设计意图的图形。这个过程创建了高度模块化和自包含的测试，很容易分解，这样对发现的错误执行的测试很容易看到。

应用场景

综合测试用例可以为设计练习真实的用例，称为应用程序场景。例如，考虑图 1 所示的数码相机 SoC。

点击查看大图

图 1：图像处理 SoC 示例。 （来源：Breker Verification Systems）

SoC 块级组件包括两个处理器、外围设备和内存。 SoC 的简单图形显示在框图下方。该图包括可能在 SoC 验证过程中使用的高级路径。例如，一种可能的场景，用图表的顶部路径表示，从 SD 卡读取 JPEG 图像，并通过内存中的分配区域将其传递给照片处理器。图像被处理成可以显示的形式并加载到内存中的第二个块中。从那里，它被传递到显示控制器。当然，这些高级块中的每一个本质上都是分层的，许多动作和决策作为流程的一部分被执行。

综合工具将进行随机测试并适当安排它们。在最简单的形式中，如图所示，测试可能是调度到单个线程中，然后是下一个测试，依此类推。然而，测试用例对 SoC 施加压力的能力来自于跨多个线程和多个处理器的交错应用程序。该工具将在设计的固有并发性支持下并行运行尽可能多的应用程序，并尽可能以曲折的方式分配内存。这也显示为图中的替代方案，其中测试分布在三个线程上，利用跨 SoC 存储器分配的各个区域。

当然，这个例子是在高层次上呈现的，以使过程清晰。在现实中，层次图会被合成工具扁平化，创建大量的动作和连接。这些还将包括需要通过求解器算法运行的随机决策。在遍历图形时，会使用 AI 规划算法来检查所需的输出并优化输入测试以与其匹配。综合工具包括类似操作系统的服务，这些服务分配内存、提供地址映射访问、处理中断和完成测试结构所需的其他任务。然后随机安排测试并适当分配存储和其他资源。

结论

就像约束随机测试平台消除了块验证的手动工作一样，基于嵌入式处理器的 SoC 的综合测试内容已被证明可以减少系统级验证工作。此外，该解决方案现在正应用于块级和硅后验证。在这个例子中，自动化 C 测试用例应用了“尽可能自动化”的格言，显着提高了覆盖率，同时缩短了验证时间表。