在硬件/软件接口调试

在硬件/软件接口调试

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

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

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

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

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

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

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

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

跨执行引擎进行调试

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

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

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

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

全面了解硬件/软件

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

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

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

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

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。