硬件调试领域的各项挑战

介绍

日常生活中，我们不会注意到最常用设备核心的复杂芯片 — 它们通常隐藏在设备内部。另一方面，芯片的功能却非常引人注目：它们能让我们使用手机拍摄高质量的照片，驾驶时提醒我们注意行人，以及检测和识别我们向虚拟助手发出的命令。在本系列文章中，我将重点讨论验证芯片功能所面临的挑战。

正如广告宣传的那样，在设备光鲜亮丽的外表下，隐藏着一支杰出的人才队伍 — 研究人员、硬件架构师、硬件设计师、软件开发人员、集成商和质量保证工程师 — 他们确保了每一块芯片在任何可能的情况下都能平稳运行。这些人员即使处于不同时区空域，也必须努力协作。他们的任务就是确保拼图的各个部分完美地组合在一起，并通过大量的软件代码行和硬件逻辑块来确保所需要的功能顺利实现，以满足消费者的预期要求。实现这些芯片功能的最大挑战之一在于软件和硬件之间的边界。

硬件调试

我假定垂阅这篇文章的您已对嵌入式设计领域有所了解，但我仍需快速扼要地复述一些主要的挑战，特别是当开放嵌入式 DSP软件时的挑战。

首先，为什么您想使用 DSP？CEVA DSP 专门用于多个应用领域，如人工智能、计算机视觉、语音识别和移动通信。相比通用 CPU，使用 DSP 可以实现更高的性能和更低的功耗，同时仍能保持软件编程的灵活性。CEVA DSP 可在必要时运行实时操作系统，以保证 DSP 应用程序通常所需要的实时性能。应用程序既可以在多核系统上同时运行多个线程，又可以在单核系统上分时运行。然后，线程可以异步处理多个并行进程，从而控制系统的不同硬件元素以及处理数据。

举个 DSP 操作的例子，它可以通过增强颜色或对比度、采用高动态范围 (HDR)算法将多个图像融合为一个图像、自动检测场景内容、或稳定快速行驶期间手持电话拍摄的抖动视频来处理相机的图像。或者，它还可以对来自两个传感器的两个每秒 120 帧/12 位采样率/超高清 8K分辨率视频流来执行上面所有这些功能，。在这种复杂运算时，数据传输率可超过每秒 33GB，因此，确保该过程每一步都能按预期运行具有非常大的复杂性和挑战性。

DSP 架构可能相当复杂，相应的汇编操作可能跨越多条线路。为了满足预期吞吐量，需要通过专用编译器或由程序员手动对代码进行性能优化。这包括展开循环、重新排序指令并将其组合在一起以便在单个循环内并行执行等等。调试此类代码可能非常困难，且需要非常先进的调试工具。

通常，新功能的开发都从高级开发语言环境开始，例如Matlab、Visual Studio 或在PC 上运行的GNU 开发/调试工具。这些环境在软件开发人员中很受欢迎，文档完善，拥有很多针对各种算法的现成方法，并且通常以开源方式分发。这样可以快速提升软件、重用代码、利用高级编程环境并采用快速服务器基础设施。工程师可以很便捷地进行通信，共享代码并在多个开发人员甚至团队之间分工协作。这些开发环境可提供一种简单而舒适的调试体验：程序员可在运行时在应用程序内部进行步进操作，以检查内存和变量值、设置断点、手动操纵资源并检查结果，有时，甚至可以在不停止调试应用程序的情况下重新编译代码，从而相对容易地跟踪漏洞和实施过程中发生的故障。

但最终，该软件需要能够运行起来，并且在嵌入式目标上有效运行。那时，开发人员必须有能够在实际芯片上进行调试和优化软件的工具。这就需要主流的开发和调试工具有更高的能力的。

硬件调试领域的各项挑战

由于目标芯片或设备在我们的桌面工作环境中属于“外来”元素，因此在目标硬件上调试软件会面临一系列不同的挑战。桌面工作环境及其操作系统对自身的计算引擎（在一定程度上）有所了解，但通常没有访问外部硬件内部状态的通用方法。这就是为什么最终您必须采用硬件供应商提供的嵌入式开发环境的原因。这些嵌入式开发工具可以与目标设备进行通信，并观测或操纵内部状态。当您在不同的调试环境中进行这种详细调试和优化时，会希望这些工具能提供易于使用的调试体验，并且能够完全支持您在这个阶段的所有需求。

对于目标硬件的调试可能具有挑战性，因为很多情况在您的早期开发中都无法预见。您只要与 DUT（被测设备）建立调试连接，就可能会遇到一些匪夷所思的通信问题。更为普遍的是，硬件调试问题可能发生在各个阶段：在初始连接、设备重置、应用程序加载、分步调试程序或查看内存和变量值时；这些问题的原因可能并不明显。基于主机或通用的开发和调试工具对目标平台并不了解，因此，在分析此类问题方面几乎没有帮助。您只能寄希望于一个充分了解你所构建系统的开发/调试平台。