随着片上系统(SoC)设计向更大的复杂性进军，包含数千行系统级验证代码的测试套件仍在继续手工编写，这是一种古老而低效的做法，违背了“尽可能自动化”的格言。在嵌入式开发中，对于在SoC的嵌入式处理器上运行以在制造之前验证整个器件的C测试来说尤其如此。

 

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

 

考虑到需要将处理器测试代码与I/O事务结合起来，通常在仿真器或原型系统上执行，很难将这种方法扩展到系统级。为了正确验证SoC，必须对处理器本身进行测试。UVM和其他约束随机方法不考虑处理器上运行的代码。事实上，为了在SoC上使用UVM，处理器通常被移除，并被SoC总线上的虚拟输入和输出所取代，从而允许子系统减去处理器进行验证。

 

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

自动生成C测试

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

 

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

 

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

 

优势测试套件综合

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

对于SoC来说，这可能需要数千次测试。然后，可以通过约束要测试的意图并将工具集中在关键领域来设置覆盖目标。这种能力避免了传统方法中出现的痛苦的迭代循环，传统方法是设置测试，运行验证工具，理解实现的覆盖范围，然后一次又一次地重置测试。

 

在一个由著名半导体公司开发的大型SoC的典型项目中，验证工程师将测试组合时间减少到以前需要手写测试的20%。自动化技术产生了更严格的测试用例，覆盖率从84%提高到97%。此外，这些型号便于携带。

 

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

 

调试是工程师的另一个时间陷阱，尤其是在SoC层面。如果一个测试用例发现了一个潜伏的设计错误，验证工程师必须了解是哪个测试触发了这个错误，从而追踪到它的来源。测试用例失败可能是由于场景模型中的一个错误，因此必须能够将测试用例与捕获设计意图的图相关联。这个过程创建了高度模块化和自包含的测试，这些测试很容易被分解，这样就很容易看到为发现bug而执行的测试。

 

结论

就像约束随机测试平台消除了块验证的人工工作一样，基于嵌入式处理器的SOC的综合测试内容已被证明可以减少系统级验证工作。此外，在嵌入式开发中，该解决方案目前正在块级应用，并用于芯片后验证。在这个例子中，自动化C测试用例应用了“尽可能自动化”的格言，显著地提高了覆盖率，同时缩短了验证计划。