利用便携式激励为软件驱动的验证铺平道路

设计正变得日益复杂，越来越多的设计包含了处理器 - 甚至包含多个处理器。由于处理器是设计不可分割的一部分，因此我们必须验证在处理器上运行的软件与设计的其它部分之间的交互，这一点非常重要。软件对当今系统的运作至关重要，因而在实验室中原型芯片完成之前，对硬件/软件边界的验证和确认不容出现任何延迟。至少，验证团队必须完成这项任务，并且自行承担风险。相信我们都听说过一些严重错误的场景，例如，团队在实验室中发现，处理器的总线与设计的连接顺序接反了，或者处理器从低功耗模式下再无法上电启动。

硬件/软件逐步细化

一个显而易见的解决方案就是在传统的验证流程中，围绕硬件/软件边界进行更多验证。但是，我们无法直接从以硬件为中心的验证，转变为尝试运行整个应用程序堆栈。运行大量的软件而存在的复杂性及生成的大量调试日志，让追踪简单错误也会变得非常复杂。

一种高效的方法是在最简单的验证环境中进行所有可行的验证，该环境让我们能够执行目标功能，并且具有最高的可见性，最大程度减少与测试意图不相关的工作。

在本文中，我们将讨论涉及到寄存器访问验证的简单示例。验证处理器是否能够正确写入和读取 IP 寄存器，是非常关键的集成验证任务。即便是简单的 SoC，也包含数以百计的寄存器，因而创建测试来验证处理器是否能够读取和写入所有寄存器将会是非常耗时的工作。

图 1 - 简单的 SoC

图 1 显示了简单的 SoC，它搭载了闪存、DDR 存储器、紧耦合存储器以及 UART 和 DMA 引擎，它们的寄存器通过低速外设总线来访问。

虽然最终目标是验证在处理器上运行的代码是否能够访问 IP 寄存器，但我们可以首先从基于 UVM 的验证开始，更加集中验证某一部分。在UVM 中率先验证存储器子系统后，我们在嵌入式处理器上调通软件时将更有信心。使用 Mentor 的 Questa inFact 便携式激励工具，可让我们将同一测试的目标重定向到 UVM 和嵌入式软件环境，从而节省测试开发时间。

使用图形描述寄存器

Questa inFact 使用了基于图形的声明输入描述，可提供约束编程的功能，增强以迭代方式指定决策的能力。当需要对访问寄存器的规定约束时，以迭代方式进行决策的能力非常有帮助。

首先，我们要捕获存储器测试操作的核心属性：地址、访问范围大小、写入数据、写入掩码。写入掩码指定了在进行检查时应该读取/写入哪些位，而必须忽略哪些位。

图 2 - 核心寄存器访问结构体

action 是指要在目标验证环境中执行的操作的单位。在下文中，我们将了解更改 body 操作的实施如何让我们轻松地将寄存器访问测试的目标重定向到 UVM 和嵌入式软件环境。

图 2 显示的寄存器访问描述符不包括系统中的 IP 的任何详细信息。接下来，我们需要添加这些限制。我们的 DMA 引擎(来自 opencores.org 的 Wishbone DMA Core)包括一系列的核心寄存器，还有通道描述符寄存器阵列。使用基于图形的描述，我们能够以迭代方式描述寄存器地址。

图 3 - DMA 寄存器地址选择

图3的图形描述显示了选择 DMA 寄存器地址的过程：

· 选择核心寄存器或通道控制寄存器阵列 (dma_reg)

· 如果选择通道控制寄存器

o 选择哪个通道 (dma_ch)

o 选择哪个通道寄存器被作为目标 (dma_ch_reg)

图 4 - DMA 寄存器地址选择规则

图 4 显示了此过程的文字描述。

图 5 - DMA 寄存器地址选择约束

用于指定在约束中编码的寄存器地址和写入掩码的更详细约束显示在图 5 中。请注意，此约束标记为“dynamic”(动态)，这意味着在图形范围内，它只有在激活之后才会应用 – 在这种情况下，我们已经决定访问 DMA 寄存器。虽然这些约束是手动创建的，但它们也可从机器可读取的寄存器描述生成，例如 IP-XACT、SystemRDL 等。

图 6 - 简单 SoC 寄存器访问图形

整合寄存器访问图形的 DMA、UART 和 TCM 部分之后，可获得图 6 中显示的图形。我们可以将它视为流程图：首先，我们决定要访问哪个 IP，然后基于选定的 IP 来决定图形分支，并且做出特定的选择。例如，最左侧的图形分支包含 DMA 特定的决策。

定向测试

即便是小型 SoC，也有超过 250 个寄存器，而常规的 SoC 的寄存器数量甚至还会超出很多倍。我们必须确保能够访问所有这些寄存器，并通过某种随机顺序进行访问。我们还可能希望集中测试某一部分 – 例如，仅测试 UART 寄存器。

Questa inFact 允许结合使用约束和图形覆盖率目标，将测试重点放在要实现的目标上。约束指定允许生成哪些测试，而覆盖率目标则侧重于系统性生成某些测试。例如，我们可以使用约束来指定 UART 当前尚不能进行测试。使用覆盖率目标可指定某个特定测试的重点是 DMA 引擎，但在实现该目标之后，可将目标定向到其他可用 IP。

图 7 - 将 DMA 作为重点的覆盖目标

图 7 中显示的覆盖率目标(蓝色阴影区域)将当前测试活动的重点集中于 DMA 寄存器上。Questa inFact 将生成测试，按照伪随机顺序，系统地访问 DMA 寄存器，然后生成对 DMA、UART、TCM 的混合访问。

映射到 UVM 环境

截止目前，我们创建的寄存器访问测试的描述都是独立于任何验证环境的。我们现在必须提供一点胶接逻辑，将我们的测试图形连接到子系统级验证环境。

图 8 - 子系统级验证环境

在 UVM 子系统级环境中，我们使用总线功能模型 (BFM) 取代了处理器的 RTL 模型，以便通过互连访问寄存器。寄存器测试图形封装在将通过 BFM 访问寄存器的 UVM 虚拟序列 (virtual sequence) 中。

基本“CPU”虚拟序列提供通过类 API 对 BFM 的访问，它支持不同大小的读取和写入。我们添加了特定的“memcheck”序列，它在“do_memcheck”任务内部执行写入、回读和检查，如图 9 所示。

图 9 - UVM do_memcheck 任务

将寄存器测试图形连接到虚拟序列中的 do_memcheck 任务所需的映射信息收集在一个文件中 – 在本例中该文件为 target.rseg。映射信息显示在图 10 中。

图 10 - UVM 序列目标映射

映射信息指定：

· 图形应该封装在从 or1k_memcheck_vseq 扩展的类中

· 在 UVM 环境中，应该使用 or1k_memcheck_c 类来代表 or1k_soc_regacc 结构体。

· 当 or1k_soc_regacc 内部的“body”操作执行时，应调用 do_memcheck 任务。

只需这几行代码，我们就能在 UVM 环境中运行寄存器测试图形。这让我们能够使用标准的 UVM 和 SystemVerilog 调试工具，验证寄存器连接的基本信息，并对任何问题进行调试。

映射到嵌入式软件

当然，验证确认 BFM 能够访问寄存器存储器，并不一定确保处理器也能够访问。因此，在处理器上以与嵌入式软件相同的方式，来运行寄存器访问测试，仍然非常重要。这种最简单的完整 SoC 验证环境如图 11 中所示。

图 11 - 软件驱动的验证环境

在本例中，我们将创建以 C 语言编写的一系列测试，使用处理器写入和回读寄存器。我们的测试将使用 do_memcheck 函数来执行实际的写入、回读和检查。此函数如图 12 所示。

图 12 - 嵌入式软件 do_memcheck 函数

与在 UVM 环境中相同，我们需要指定图形如何映射到嵌入式软件环境。映射信息显示在图 13 中。

图 13 - 嵌入式软件映射

映射信息指定以下内容：

· 必须包括头文件 or1k_memcheck.h。此文件声明 do_memcheck 函数。

· 每次 body 操作执行时，必须调用函数 do_memcheck，传递 addr、size、wr_data 和 wr_mask 字段的值。

生成 C 测试

我们已经介绍了要执行的寄存器测试的基于图形的模型，我们在如何生成一系列特定测试方面具有很大灵活性。图 14 显示了生成的测试的一个示例。在本例中，我们允许 inFact 将目标定向到所有三个 IP，但限制该测试只能通过图形进行五次迭代。

图 14 - 示例寄存器测试

正如您看到的那样，生成的测试是定向测试，在生成过程中，inFact 填充了随机值。虽然特定测试在每次运行时始终执行相同的操作，但我们可以重新生成测试，每次在回归运行时使用不同的种子，从而在回归运行中实现更多随机性。

为了实现对上文所述的寄存器访问目标的覆盖率，我们需要生成更多针对性的测试。由于所有这些测试都是从单个描述模型生成的，因此我们可以简单地更改测试生成程序的选项，以便在以下两种方式之间切换：运行很多测试，每个测试都对 do_memcheck 进行少数几次调用;或者运行少数几次测试，每次测试都对 do_memcheck 进行很多次调用。我们还可以简单地调节覆盖率目标，例如，生成一系列测试，仅将重点放在 DMA 寄存器测试上。

总结

采用步进式方法来验证嵌入式处理器与设计其他部分的IP之间的交互，可在验证流程中及早发现错误，以便最简单地进行调试和纠正，从而节省时间。使用便携式激励，可从描述的测试意图着手，生成高质量的测试，并将目标重定向到多个环境。这样可以应对步进式方法的主要挑战，即它需要大量的重复工作，在多个位置执行测试意图，另外还需要使用低效率的定向测试，创建嵌入式软件测试。在本文中，我们看到对 SoC 寄存器的测试意图的单个描述如何能够轻松将目标定向到 UVM 和嵌入式软件环境，作为 SoC 集成测试的一部分。我们还看到了如何使用 Mentor 的 Questa inFact 便携式激励工具，对此测试意图进行描述，并将目标定向到特定环境。

下一次当您开始计划 SoC 集成测试时，应该考虑到便携式激励和步进式测试方法如何让您的验证流程受益!