​SOC验证的作用与含义及原因

SOC 验证有什么用？

这篇文章的标题听起来像是上世纪90年代电视剧里的玩笑，但它实际上是一个严肃的问题。很多人不明白，是什么让一个系统级芯片（SoC）与其他半导体器件不同。许多公司，尤其是在电子设计自动化（EDA）行业中，围绕术语“SOC”进行了众多讨论，但却没有定义它，或者解释它为什么是这样一个重要的概念。

Soc验证的含义

从“SoC”的定义开始讨论，应该是最合适的地方。正如其名称所暗示的那样，“系统级芯片”，是存在于单个封装的完整系统，通常都处于单个die，尽管3-D集成电路建立在多个die上的情况也正变得越来越普遍。

本质上，SoC就是将分布在多个芯片甚至是离散设备上的功能集成到一个芯片中。现在已经很难找到不含某种处理器的系统了，所以在实际的定义中，在SoC必须包括至少一个处理器。

最常见的SoC架构包括一个或多个嵌入式处理器，部分片上存储器，附加的功能单元，标准总线接口以及可能的片外存储器。某种类型的片上总线，总线结构，或网络芯片将所有的单元连接在一起。

与其他芯片验证不同的原因是什么？

由于需要在嵌入式处理器上运行的软件，完整的SoC实际是芯片加上在这些在处理器上运行的代码。有些系统级芯片具有在多个不同的处理器，CPU，DSP，图像处理器等，——所有的运行代码都是针对单独功能定制的。

处理器的存在是使得SoC验证与其他芯片验证不同的关键。更小，没那么复杂的芯片，以及许多在SoC内部的模块，可以使用仿真测试平台有效的进行验证。提供数据到芯片的输入，检查芯片上的输出数据。

传统测试平台可简化为一个框架，允许用户提供一系列的二进制输入，并使用波形查看器查看输出结果。当然，如此的手动设置仅仅能够验证复杂设计很少的预期功能。

现代的基于测试平台的验证环境会为芯片输入自动生成随机的stimulus，这种随机同时处于用户指定的约束条件（规则）下，并会自动检查每个测试的结果。这比基于传统测试平台手工编写单独的测试更有效率。

有约束的随机测试平台

一些验证方法已经建立，流行的标准是有约束的随机测试平台，并允许有限复用测试平台的组件。这些验证方法中，最有名的是标准组织Accellera定义的通用验证方法学（UVM）。

带约束的随机测试平台在一定程度上工作正常，但不能就此扩展到full-SoC验证上。仅仅从芯片的输入来验证其所有功能，是一件太过困难的工程。

此外，虽然在SoC的嵌入式处理器通常有能力在仿真中运行代码，但对所有协调处理器与测试平台的活动，UVM都不提供任何指导。事实上，在SoC级运行的任何UVM-based仿真，通常用总线功能模型（BFMS）去替代嵌入式处理器。

以上的这些限制导致许多SoC团队在full-chip级仅仅做最少的验证。他们仅仅验证模块是否已正确连接，并可能运行一些简单的测试来验证各主要模块运行正常。

对SoC运行中，模块串接的真实情形，他们却很少运行测试。这种“stitch and ship”方法带来高风险，因为它从从未测试模块间复杂相互作用的情况，而其恰恰极可能暴露设计bug或证实性能的缺陷。

模块级验证

在模块级验证中，很难发现诸如存储器冲突，总线饱和，等在SoC多模块共享资源时才发生的问题。

考虑到SoC功能在很大程度上取决于其嵌入式处理器，意料之中，一个纯粹的测试平台是不足够的。有些验证团队认识到这一点，他们用人工设计测试在嵌入式处理器上运行。这些测试通常不连接到测试平台也未很好集成到整个验证工作中。

此外，要人工设计对SoC并行功能多任务（multi-threaded）测试简直比登天还难。当然，我们所需要的就是考虑这些corner-case bugs和性能问题。

充分有效的SoC验证

SoC验证要充分有效，就必须包括在嵌入式处理器上运行自动化测试。软件可以在仿真中生成在多处理器多线程情况下的测试case。

为了对SoC有足够的压力测试，测试case需要刺激和协调处理器和测试平台内的并发活动。测试case必须能够对随机生成的输入数据进行自动验证，计算输入的预期结果，并检查芯片的输出符合预期的结果。

通常来说，我们需要提供SoC的功能信息给测试case生成器，这些case才能恰当的验证其功能性并检验结果。描述SoC设计功能的最好方法就是一系列可视方案模型。

图像能够捕获芯片的数据流路径并记录如何配置模块来运行所有SoC设计功能。图像引导的生成器约束保证其不会对非预期行为生成test case。

来自Breker验证系统中的TrekSoC产品

这个软件工具能自动生成在SoC的嵌入式处理器上运行并能够自验证的C语言test case，而且该软件不需要操作系统或者其他产品软件的支持。

这些test case都是多线程的，因此能并行检验SoC的多个部位，在tapeout之前进行足够的压力测试。生成器中成熟的scheduler能够跟踪多个并行运行的现实情况，并从线程中移动它们以尽可能多的对SoC进行测试。

因为一些C-based测试会从芯片输入读取数据，或者发送数据到芯片输出，“TrekBox”组件连接现有的总线功能模型（BFMS）在测试平台中，并协调处理器和测试平台间的活动。

当每个C-based测试准备接收或生成数据时，会通知TrekBox处理实际的数据传输。源数据也可以被加载到存储器，并且存储器检查可以在不干扰的SoC的情况下进行。

这个基于图形的场景模型描述了能够在SoC中产生无限数量的多线程测试case的所有信息。

总结

总之，SoCs使得半导体产业能继续实现其，更好，体积更小，更快芯片的目标。它们与其它类型的芯片不同，所以SoC的验证也必然是不同的。

开发团队必须认识到，在SoC时代，存在严重bugs风险或者毫无竞争力的去生产芯片的情况，使得他们的世界已经不同。

自动生成多线程，自我验证C测试case是一个相当新，但是很好的验证方法。“SoC验证”团队采取这种方式会有着更快产生更好的，更小的芯片的优势。
编辑：lyn