Accellera便携式测试和刺激标准

到目前为止，在本博客系列中，我们已经讨论了 Accellera 便携式测试和刺激标准 （PSS） 的一些基础知识，以及它如何增强通用验证方法 （UVM） 流程。这是一种非常有效的块级验证策略，允许重复使用现有的验证 IP （VIP） 模型。然而，一旦几个设计 IP 模块集成在一起，几乎可以肯定一个或多个处理器将成为子系统的一部分。一旦发生这种情况，就需要一种新的验证策略。

软件通常代表系统功能的一个重要方面，它的一部分可能需要包含在验证过程中。能够按照 UVM 流程的要求直接操作总线，意味着可以进行更彻底的测试，而不是在将多个模块集成在一起之后的验证重点。您不会尝试重复在每个块上单独进行的验证。相反，您正在尝试确保模块之间正确通信并且可以执行产品的更高级别功能。事实上，一旦处理器和总线协议在设计中固定下来，就不可能访问连接到总线的每个 IP 块的所有功能。

在模拟环境中，每个处理器都可能由指令集模拟器 （ISS） 或某种其他形式的行为模型来表示。这些可从所有处理器供应商和第三方处轻松获得。这些模型提供了功能准确性，虽然它们在时间意义上并不完美，但它们通常足以满足大多数目的。最重要的是，它们的运行速度比寄存器传输级 （RTL） 模型快几个数量级，并且已集成到您最喜欢的 RTL 仿真环境中。

您应该在这些处理器上运行什么软件？过去，会编写专用测试代码来以一小套定向测试的形式来测试子系统。经验丰富的验证工程师知道开发这些测试并在硬件发生变化时对其进行维护需要多长时间。使用 PSS 和测试综合，这个问题几乎变得微不足道。

让我们不要太快得意忘形了。仅仅因为我们有一条路径可以自动生成在这些处理器上运行的软件，问题并没有完全解决，也没有回答有关要使用的软件级别的所有问题。

嵌入式处理器可以以实际运行的软件可以访问的确切方式访问设计中的所有内容。我们为什么不直接运行它？这有几个原因。首先，生产软件可能还没有准备好。虽然左移运动试图推动软件开发，但并不总是可以同时开发它们。其次，您不希望您的测试仅限于当前版本的软件对硬件所做的事情。如果预计稍后会通过软件更新发布附加功能怎么办？如果产品最初发布时尚未验证硬件，则可能会影响您将来添加更新的能力。

这并不意味着您永远不应该使用任何生产软件。当您接近完成设计并且验证接近覆盖目标时，您可能希望使用生产驱动程序、协议栈的其他一些层，甚至操作系统的元素。例如，Breker 提供了一个可在测试综合期间使用的函数库。这些功能，例如内存管理，构成了我们将在以后的博客中讨论的多层硬件/软件接口抽象层的基础。

在软件运行时让测试台运行是另一个问题。您如何协调子系统或芯片的外部输入的活动？必须有一种方法在处理器和 VIP 之间进行通信，以便协调活动。我们在 Breker 使用 TrekBox 完成了这项工作（参见图 1）。

图 1 标题：在此示例中，工具协调软件和外部 VIP 之间的活动。

TrekBox 使用模拟器的后门内存 API 监控模拟器中的内存。当处理器写入某个地址时，它表示要发送给特定 VIP 的命令。在该消息中可能包含有关所需确切操作的更多信息。因此，处理器可以协调外部活动。如果您想测试，例如，当软件进入中断服务程序时，将数据洪流到所有外部端口，这很有用。

在上一篇博客中，我们为图 2 所示的示例设计开发了一个测试平台。VIP 为两个 UART 提供数据。处理器已被移除，取而代之的是由测试平台驱动的总线接口模型。一切都由测试台控制。

图 2 说明：示例设计说明了 VIP 如何为测试平台驱动的 UARTS 和总线接口模型提供数据。

图 3 标题：类图突出显示了如何通过图形输入工具输入测试。它也可以使用便携式刺激标准 （PSS） 语言编写。

在图 3 中，显示了测试平台的三种配置tb_cfg_uart、tb_cfg_ss和tb_cfg_fc。第一个配置以前与一个处理器一起使用，运行四个线程并通过事务级建模 （TLM） 进行通信。TLM 名称表明它们在设计中不是真正的 CPU，而是为 TLM 接口生成流量。与此相关的代码如下所示。

8 组件 tb_cfg_uart {

9

10 // 用户代码的开始 Component_tb_cfg_uart

11 处理器 cpu0 {“cpu0”， 4， Processor：：TLM};

12 // 用户代码结束

我们可以修改配置，改为为两个处理器生成测试，每个处理器运行四个线程。这需要更改配置代码，如下所示。

8 组件 tb_cfg_ss {

9

10 // 用户代码的开始 Component_tb_cfg_ss

11 处理器 cpu0 {“cpu0”， 4， Processor：：TLM};

12 处理器 cpu1 {“cpu1”， 4， Processor：：TLM};

13

14 memory_resource ddr0 {“ddr0”， 0x1000};

虽然没有将处理器实例化到设计中，但仍为数据读取和写入以及行为检查定义了一个内存区域。为了切换到使生成的测试软件驱动而不是使用 UVM，我们再次更改配置代码，如下所示。

8 组件 tb_cfg_fc {

9

10 // 用户代码的开始 Component_tb_cfg_fc

11 处理器 cpu0 {“cpu0”， 4， Processor：：SDV};

12 处理器 cpu1 {“cpu1”， 4， Processor：：SDV};

13

14 memory_resource ddr0 {“ddr0”， 0x1000};

这是唯一需要做出的改变。现在测试合成将输出处理器代码、加载到 TrekBox 的代码以及执行外部 VIP 协调的所有内容，如图 1 所示。

在下一篇博客中，我们将把这个例子转移到模拟器上，产生一些新问题。正是这种模拟和仿真之间测试的可移植性是创建该标准的主要动机。

审核编辑：郭婷