通过场景模型验证管理SoC复杂性

开发片上系统 （SoC） 需要管理设计的许多复杂方面。晶体管的绝对数量是压倒性的，但复杂性不仅仅是数量。SoC 包含具有精确功能规范和一系列要求的高度复杂的特性。除了设计的复杂性之外，验证每个功能和整个 SoC 是否满足其规范和要求也是一个巨大的挑战。

除了设计和验证的复杂性之外，整个过程的项目管理也令人生畏。没有一种解决方案可以解决 SoC 复杂性的所有方面，甚至大部分方面。然而，一些技术可以解决问题的特定部分，例如基于图形的场景模型，这种形式可以直接降低验证复杂性，同时为管理 SoC 设计和项目复杂性提供附带好处。

SoC验证

可以在示例数码相机 SoC 设计的上下文中说明基于图形的场景模型的作用（图 1）。原始图像由相机模块从电荷耦合器件 （CCD） 阵列（正面或背面）捕获。它可以显示给用户，由照片处理器操作，通过 USB 端口传输，或保存到 SD 卡。一系列此类图像可被视为视频流，并由视频处理器和 SoC 中的其他知识产权 （IP） 块进行类似处理。

图 1：具有数码相机功能的 SoC 的复杂设计。

SoC 具有相互交织的数据流并支持一些并行性。使用两个嵌入式 CPU，可以同时对多个 IP 块进行编程。此外，如果结构具有交叉开关功能，则多个数据流可以在不同的 IP 块和内存之间并行运行，如果不需要内存缓冲区，则可以直接在 IP 块之间运行。验证要求在架构支持时并行执行所有这些可能的流程，以模仿相机中的实际最终用途。

如果要开发测试平台环境，验证团队必须了解所有数据流和所有可能的交互。将 SoC 纯粹视为黑匣子并不能提供足够的验证；在大型设计中，严格地通过操纵输入来激发深层行为是很困难的。因此，SoC 验证团队几乎总是开发在嵌入式处理器上运行的 C 语言测试，作为他们方法的一部分。当然，手写测试也很困难，要对相互协调的多个处理器和测试台进行手写测试以充分发挥 SoC 的作用，几乎是不可能的。

基于图的场景模型

验证团队在理解芯片内所有可能的行为和数据流方面面临挑战。纸质规范很难消化，并且受制于自然语言的所有不精确性。由于描述的复杂性以及并非所有设计类型都适合声明性语言这一事实，尝试使用纯形式化方法描述完整的 SoC 的尝试没有成功。

一种获得认可的方法是基于图形的场景模型。这样的模型是一种形式主义——有向图——但不需要形式语言。它可以使用标准 C/C++ 语言加上一些来自标准巴科斯-瑙尔形式 （BNF） 表示法的结构来描述。该图显示了 SoC 中 IP 块之间的互连和合法数据流。场景模型类似于 SoC 架构师可能在板上绘制的数据流图，不同之处在于它的左侧是输出和结果，右侧是输入。

如图 2所示，可能的最终用户场景包括：

从其中一个 CCD 阵列读取并显示在屏幕上、写入 SD 卡或发送到 USB 端口的原始图像

从其中一个 CCD 阵列读取的原始图像，由照片处理器编码为 JPEG，然后写入 SD 卡或发送到 USB 端口

从其中一个 CCD 阵列读取的一系列原始图像，由视频处理器编码为 MPEG，然后写入 SD 卡或发送到 USB 端口

从 SD 卡或 USB 端口读取并显示在屏幕上的原始图像，写入 SD 卡或发送到 USB 端口

从 SD 卡或 USB 端口读取的 JPEG 图像，由照片处理器解码并显示在屏幕上，写入 SD 卡或从 USB 端口发送

从 SD 卡或 USB 端口读取的 MPEG 流，由视频处理器解码并显示在屏幕上，写入 SD 卡或从 USB 端口发送

图 2：数码相机 SoC 的高级场景模型。

因为场景模型是分层的，所以图 2中的每个图形节点（目标）都可以展开以显示相应 IP 块设计的详细信息。该模型可以由 SoC 团队自上而下开发，也可由 IP 开发人员自下而上开发。自上而下的开发更为常见，因为项目通常开始使用场景模型来解决全芯片 SoC 验证问题。这可能需要 IP 开发人员的一些参与来填写较低级别的详细信息。如果一个项目完全采用该方法，那么场景模型也用于验证单个 IP 块，然后组合成一个全芯片模型。

场景模型提供了对 SoC 设计和芯片制造前必须覆盖的验证空间的洞察。这通过帮助定义测试计划来解决验证的复杂性。场景模型还有助于解决设计复杂性，因为它很像芯片架构师可能绘制的数据流图的扩展版本来解释设计的工作原理。因此，该图成为架构师、设计师、验证工程师、嵌入式程序员和启动团队之间可以使用的通用模型。这也降低了项目管理的复杂性，无论是在单个项目中，还是在共享设计部分的多个项目中。

场景模型自动化

图形场景模型的最大价值可能在于它可用于生成 C 测试用例，以在仿真、在线仿真 （ICE）、现场可编程门阵列 （FPGA） 原型或 SoC 芯片中的嵌入式处理器上运行在培养实验室。生成器从左到右遍历图表，从期望的结果到输入，组装一系列步骤，这些步骤返回到产生特定结果所需的输入值集。图形决策点和数据值是随机的，因此每个演练都会产生一个独特的测试用例。这种自动化消除了在 SoC 项目的任何阶段（从模拟一直到实验室）手写测试的需要。用户报告说，他们可以使用以前用于手写测试的 20% 的团队来获得更好的自动化结果，

可以将约束添加到图形中以阻止根据规范非法的路径，隔离尚未准备好验证的设计部分，或将测试用例生成偏向某些方向。例如，图 2所示的图表允许从 SD 卡读取原始图像，由照片处理器处理，然后显示在屏幕上的场景。这是一个不必要的步骤，因为可以直接显示原始图像；用户可以很容易地添加一个约束，即只有 JPEG 编码的图像被发送到照片处理器，以消除不必要的测试。

生成的测试用例是多线程和多处理器的，具有跨线程、处理器和内置测试台的所有通信。目标是在允许的最大流量和并行度下对 SoC 进行压力测试。在相机 SoC 中，可能会在从 SD 卡读取前一个图像并显示在屏幕上的同时将相机图像写入 USB端口。这种级别的活动不太可能发生在手写 C 测试或传统的仿真测试平台中，因此可以提供更完整的设计验证。

把它们放在一起

与任何自动测试生成方法一样，SoC 团队需要一种方法来评估验证的彻底性并确定何时流片。除了捕获设计和验证空间外，场景模型还用作系统级覆盖模型。由于遍历图表的确定性，验证工程师在测试用例生成时准确地知道图表中的最终用户场景（路径）和目标已被覆盖。他们不需要收集和整合运行时覆盖来评估验证进度。更重要的是，他们可以避免花费数周时间运行额外的模拟测试，这些测试对覆盖结果几乎没有任何影响。

场景模型和自动测试用例生成形成闭环覆盖系统。验证工程师可以指向任何未发现的路径或目标，生成器将生成一个覆盖它的测试用例。这同样适用于跨覆盖路径或目标。Breker 的 TrekSoC 系列产品提供闭环覆盖和场景模型的其他优势。

基于图的场景模型捕获关键的设计和验证知识，通过通用模型实现 SoC 项目团队成员之间更好的沟通，减少流程中多个点的人工工作，加快进度，更完整地验证设计以增加获得第一名的机会- 硅成功。

审核编辑：郭婷