在硬件/软件接口调试

虽然硬件/软件接口的设计问题已经讨论了 10 年的大部分时间，但当今应用程序驱动设计中软件内容的增加已经给这些问题带来了新的紧迫性——特别是软件对硬件和高效分区的依赖。过去，软件开发人员使用连接到原型板的嵌入式软件调试器以独立于硬件的“外围盲区”方式执行调试任务。这提供了对处理器的深入了解，但几乎没有关于周围外围设备和片上互连结构的信息。相比之下，硬件开发人员专注于寄存器和片上系统 （SoC） 互连中的低级效应，这些效应每年都变得越来越复杂。

在考虑调试挑战时，必须评估片上和系统内效应。在开发阶段需要进行片上调试，以确保芯片本身正常工作。系统内效应与芯片在其环境中的行为方式有关。如果要在芯片开发期间考虑影响，则调试系统内影响需要对环境进行复杂建模，或者在芯片可用后控制实际环境。

图 1 显示了一个典型的基于ARM内核的 SoC，其处理器子系统包含各种处理器，这些处理器通过连贯的结构连接到芯片的其余部分。SoC 还包含用于 3D 图形、数字信号处理、专用专用硬件加速器、低速外设和高速接口的定制应用特定组件。调试挑战包括同步调试多个内核、确保 IP 块集成正常工作、调试 AMBA 4 AXI 一致性扩展 （ACE） 协议等协议，以及调试整个芯片互连。

图 1：典型的基于 ARM 内核的 SoC 存在调试挑战，例如同步调试多个内核。

相比之下，图 2 在其系统环境中显示了相同的 SoC。SoC 和实际系统外围设备之间的连接建立在PCB上，并且通常基于 DigRF、MIPI和USB等标准。现在，调试挑战从片上区域转移到芯片在其环境中的行为方式。例如，图形引擎生成的帧是否被外部显示器正确显示？各种片外和系统内效应需要与片上效应一起考虑，因为它们通常会驱动图形内容和控制。

图 2：系统环境中的 SoC 对芯片在其环境中的行为方式提出了调试挑战。

硬件/软件集成和调试方法

在开发流程中，设计团队使用多种技术来实现软件调试和硬件/软件集成。

一旦所有芯片都可用并集成后，硬件团队通常会构建有限数量的原型板，以便软件开发人员可以开始在设备上构建他们的代码。在产品发布并激增后，这些原型板通常被称为开发套件。它们以实时速度运行并且完全准确。调试器通过 JTAG（边界扫描）接口连接到这些板。这种类型的软件调试非常普遍且易于理解，但也有其挑战，因为对硬件深度的访问受限于实现的片上仪器的级别。

将集成到板上的基于FPGA的芯片原型可以在硅片之前几个月提供。这些原型在数十 MHz 范围内运行，硬件精确，并且通常只有在稳定的寄存器传输语言 （RTL） 代码可用后才能使用。它们允许有限的调试功能。与软件调试器的连接通常通过 JTAG 建立，但设计人员可以使用调试信息增强 RTL，以启用硬件/软件调试和分析。根据原型，可以将芯片连接到环境；经常需要使用速度适配器，或者需要降低环境速度以匹配原型速度。

硬件仿真器甚至可以在设计流程的早期使用，它们在 MHz 速度范围内执行正在开发的芯片或其子集。它们提供快速启动（与基于 FPGA 的原型设计相比，后者需要对实现硬件的代码进行更多修改）和更好的硬件/软件调试，因为硬件仿真器的很大一部分专用于调试和控制设计。然而，当今仿真器的大小和价格限制了它们被大量软件开发人员复制的能力。

RTL 仿真是第一个可以满足精确硬件和软件的执行环境。它提供了出色的硬件调试能力，但由于它运行在 KHz 范围内，它在软件开发和软硬件集成方面的适用性非常有限。RTL 专注于硬件验证，传统上仅用于非常低级的裸机软件开发。鉴于现代片上和片外接口的复杂性，商业验证 IP（提供预定义的测试模式以检查接口正确性）可以在片上和系统内使用。

使用不太准确的抽象硬件模型，正在开发的虚拟芯片平台可以高速运行，有时在硅片之前 9-12 个月就可以使用。它们使用 GNU 调试器 （GDB） 和周期精确调试接口 （CADI） 等标准接口提供出色的软件调试功能，以将软件调试器连接到虚拟化硬件。以后可以在板级使用相同的软件调试器。根据建模工作，整个芯片及其环境可用于片上和系统内的高级硬件/软件调试。

最后，软件开发工具包 （SDK） 通常是最早可用的开发平台。像 AppleiPhoneSDK 或AndroidSDK 这样的 SDK 使许多软件开发人员能够为非常抽象的硬件编写代码，因此无法调试。在 SDK 上开发的代码通常需要重新编译才能在实际设备上运行，这与前面提到的虚拟原型和其他引擎不同，后者加载 .elf 文件并运行相同的二进制代码，然后在硬件目标上执行。

跨执行引擎进行调试

电子制造商越来越多地跨多个内核分发软件，以保持在复杂设计的功率范围内。因此，多核调试已成为更大的挑战。多核设计的完全同步的异构软件调试非常适合在所有软件组件和硬件本身中设置断点，然后允许检查状态、堆栈、软件中的变量和硬件中的寄存器。

使用原型板，即使不是不可能，也很困难。如果断点触发了一个处理器的软件并导致其停止，则所有其他处理器继续执行，从而改变断点发生的环境状态。相比之下，使用虚拟原型，所有参与元素（即所有处理器和硬件模块）都可以在断点发生时准确停止，从而实现高效的硬件/软件调试。

此外，当开发人员在实际硬件或老一代虚拟原型上工作时，他们会看到各种不同步的调试器窗口。现代虚拟原型允许用户通过抽象层有效地集成来自不同供应商的处理器模型，从而在单一、统一的环境中实现完全同步的调试和分析。

另一个在实际开发板上难以分析的影响是根据硬件所处的状态而必须停止软件。在仿真器、RTLvwin 器和虚拟原型的世界中，硬件调试是先进的，两者硬件和软件可以根据表示硬件内状态或状态转换的断点有效地停止 - 例如达到特定的计数器值或通过总线发送的特定事务。

每当涉及基于软件的硬件执行时，软件调试也可以与不同硬件抽象级别的混合有效地同步。这在衍生项目开始时很有价值，因为新的硬件组件在事务级别作为高度抽象的模型可用，而不是在 RTL 上实现的硬件。

全面了解硬件/软件

现代软件的复杂性及其对执行它的硬件的依赖性使得延迟调试和硬件/软件集成，直到所有芯片都可用并集成到 PCB 上是不可行的。芯片和系统开发团队可以使用多个执行引擎，但这些引擎的开发和调试软件能力差异很大。图 3 显示了之前介绍的芯片和电路板与引擎相结合以执行正在开发的芯片以及与硬件/软件调试的连接。

图 3：结合 SoC 和电路板的硬件/软件执行引擎在芯片开发过程中执行芯片。

Debug 有几个层次，通常构建在 Eclipse 等集成开发环境 （IDE） 上。用户需要调试实际硬件、操作系统之外的裸机软件执行、硬件和软件的结合以及整个系统的性能。

随着不同引擎和新一代软件调试器的混合组合，该行业正在接近一个时代，在这个时代，软件开发人员可以比以往任何时候都更早地在设计周期中获得软件和硬件的完整程序员视图。

作者：Frank Schirrmeister，Michael （Mac） McNamara，Larry Melling，Neeti Bhatnagar

审核编辑：郭婷