用于软件验证的硬件加速仿真之一：物理和虚拟探针

在验证领域，虚拟探针增强了硬件加速仿真作为数据中心资源对硬件设计人员和软件开发人员的吸引力。

硬件加速仿真不断证明它本身就是一种便利的工具，既可用于硬件/软件协同验证，也可用于测试硬件和软件的集成。

启动操作系统并执行软件应用程序需要经过数十亿个验证周期 - 传统的基于软件的分析工具无法胜任这项任务。只有基于硬件的验证引擎才可提供应对这一挑战所需的吞吐量。正因为如此，硬件加速仿真和 FPGA 原型设计才会成为当今设计和验证团队的验证工具箱中的必备引擎。

通过硬件加速仿真和 FPGA 原型设计，嵌入式软件开发人员能够验证嵌入式软件并执行系统验证，这是一项极具吸引力的功能。只有通过硬件加速仿真，他们才能确认嵌入式系统软件能够与底层硬件协同工作，因为 FPGA 原型设计没有提供可调试内部工作的硬件设计可见性。

另外，在设计周期中，项目组成员可以使用硬件加速仿真的时间通常远早于使用 FPGA 原型的时间。因此，使用硬件加速仿真技术，软件开发团队开始进行验证的时间要早于使用 FPGA 原型的情况。

硬件工程师也可以认识到在硬件加速仿真上运行软件的优势。当实际软件产品第一次在硬件上运行时，它几乎总会暴露出硬件错误，即使最全面的验证方法也会遗漏一些错误。及早运行软件可以暴露出这些错误，以便我们加以解决。这样不仅简单，而且成本较低。

物理探针
过去，软件开发人员使用物理 JTAG 探针来调试在硬件加速器上运行的代码（图 1）。JTAG 标准定义了一系列信号，以及通过四管脚接口读取和写入物理芯片中的寄存器的方法。这种做法的初衷是提供一种测试芯片的方法，让测试工程师窥探封装芯片的内部，确认它是否正常工作。

软件开发人员意识到他们可以使用相同的接口，读取和写入芯片中的处理器的通用寄存器。能够读取和写入处理器的主寄存器，意味着他们可以调试在处理器上运行的程序。

通过一些巧妙的接口，他们可以使用嵌入式调试器（例如 Lauterbach 的 Trace-32 或 ARM 的 DS-5），将命令发送到 JTAG 探针，以提取或设置连接到探针的板载处理器的状态。这是开发人员运行和调试嵌入式系统上的"裸机"程序和驱动程序的最常用方法。

使用当今的硬件加速仿真系统，可通过连接到外部器件的任何 I/O 卡，输出设计的任何信号。这种方法可用于输出 JTAG 接口的四个信号。通过将这些来自硬件加速器中的设计的信号连接到 JTAG 探针，软件开发人员能够在硬件加速仿真设计上，执行与在原型板上相同的调试工作。

由于 JTAG 探针将在设计后期用于原型板上，并且可能还在后续项目中使用，因此软件开发人员一般都了解该探针的使用方法和作用。在硬件加速仿真设计上调试软件时，软件开发人员自然会采用这种熟悉的工具。

虽然 JTAG 接口让调试器能够直接读取和写入寄存器，但要正确地调试程序，还需要能够读取和写入内存并且控制程序的执行。为了满足这种需求，处理器设计人员添加了调试器可访问的寄存器，以便将内存读取和写入指令插入到执行管道中。这样一来，调试器就能够完全访问设计中的所有内存和内存映射的器件。

另外，这些设计人员还采用了断点寄存器和其他调试支持电路，从而令 JTAG 调试器能够控制程序的执行。这意味着，通过连接至处理器的 JTAG，调试器能够显示程序源代码、处理器的寄存器、内存、变量以及程序的堆栈。因此，调试器能够设置断点，运行和单步调试程序，而这些正是软件开发人员期望现代化软件调试环境能够提供的功能。

处理 JTAG 探针问题
虽然 JTAG 探针实现了在硬件加速仿真设计上的软件调试，但它也有缺点。第一，JTAG 探针和在硬件加速器中运行的设计都有它们自己的自激时钟。为了保持同步，这些时钟必须维持一致的速度。如果做不到，调试器和设计之间的连接将会丢失。

很多情况下，需要重置探针；而有些时候，还将需要重置设计本身。有时减慢甚至停止硬件加速器中的设计时钟是非常有用的，因为这样可以采集和上载设计上的波形。这样一来，开发人员就能够查看设计的状态，或者对设计进行强制赋值，使其变换到新值。实质上，如果硬件加速器上的时钟不能减慢或停止，硬件开发人员将会丢失诸多硬件调试功能。

使用 JTAG 探针存在的第二个问题是性能。由于存在两个独立的时钟域，一个在硬件加速器上，另一个在探针上，数据将在两个域之间传递，就会产生跨时钟域问题。为了解决这个问题，探针上的时钟速度通常低于处理器的时钟速度。在原型板上，处理器的时针速度可达到几百兆赫甚至千兆赫，这不是问题。但在硬件加速仿真中，时钟运行速度为一兆赫或两兆赫，这可能让速度减慢很多。

例如，在 ARM Cortex-A57 中分步运行单个指令，需要超过 400 万个比特的 JTAG 扫描链活动。如果处理器的时钟在 2 MHz 的频率下运行，JTAG 时钟的频率是它的四分之一，也就是 500 kHz，则在分步运行之后，需要 8 秒才能更新调试器中的视图。

另一个性能问题是程序下载时间。软件开发人员使用扫描链，通过 JTAG 探针将程序下载到目标。如果程序很大，则将程序加载到存储器可能要花费一个小时甚至更长时间。大多数软件开发人员无法接受这种性能水平。