EEPW论坛

简介

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

硬件／软件逐步细化

一个显而易见的解决方案就是在传统的验证流程中，围绕硬件／软件边界进行更多验证。但是，我们无法直接从以硬件为中心的验证，转变为尝试运行整个应用程序堆栈。尝试运行大量的软件而导致的复杂性及生成的大量调试日志，让追踪简单错误也会变得非常复杂。一种高效的方法是在最简单的验证环境中进行所有可行的验证，该环境让我们能够执行目标功能，并且具有最高的可见性，最大程度减少与测试意图不相关的工作。在本文中，我们将讨论涉及到寄存器访问验证的简单示例。验证处理器是否能够正确写入和读取 IP 寄存器，是非常关键的集成验证任务。即便是简单的 SoC，也包含数以百计的寄存器，因而创建测试来验证处理器是否能够读取和写入所有寄存器将会是非常耗时的工作。图 1 显示了一个简单的 SoC，它搭载了闪存、DDR 存储器、紧耦合存储器以及  UART  和  DMA  引擎，引擎的寄存器通过低速外设总线来访问。虽然最终目标是验证在处理器上运行的代码是否能够访问  IP  寄存器，但我们可以首先从基于  UVM  的验证开始，更加集中验证某一部分。在率先验证UVM 中的存储器子系统后，我们在嵌入式处理器上调通软件时将更有信心。使用 Mentor 的 Questa inFact 可移植性激励工具，可让我们将同一测试意图重定向到UVM 和嵌入式软件环境，从而节省测试开发时间。

图 1 - 简单的 SoC

使用图表描述寄存器

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

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

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

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

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

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

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

      –选择哪个通道 (dma_ch)

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

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

图 3 - DMA 寄存器地址选择

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

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

…未完待续…

点击免费下载完整白皮书>>