如何利用嵌入式仪器调试SoC？

　　随着系统级芯片（SoC）的复杂度不断提高，软、硬件开发融合所带来的挑战已经不可小觑。这些功能强大的系统现在由复杂的软件、固件、嵌入式处理器、GPU、存储控制器和其它高速外设混合而成。更高的功能集成度与更快的内部时钟速度以及复杂的高速I/O相结合，意味着提供正常运行、并经过全面验证的系统比以前变得更难。

　　传统上，软件验证和调试及硬件验证和调试一直是两个不同的世界。通常情况下，软件团队和硬件团队各自为政，前者专注于编程模型内部的软件执行，后者则在硬件开发框架内进行调试，其中时钟周期精度、并行运行及调试数据回溯原始设计的关系是关键。理论上，经过全面调试后，软件和硬件应无差错地协同运行。但在实际环境中，无差错协同运行的情况不多，正因如此，经常会导致关键成本上升及产品开发周期延误。

　　为在合理的成本和时间范围内实现更高的集成度，业界必须转向新的方法：设计的洞察。换句话说，如果我们想能够高效地持续验证和调试这些系统，工程师们必须提前设计成能够提供全面的系统视图。其中的关键是能够了解涵盖硬件领域和软件领域的各种行为之间的临时关系。本文介绍了使用嵌入式仪器调试SoC的一种方法，说明了通过整合硬件调试视图和软件调试视图，可以更快、更高效地调试整个系统。

　　构建测试台

　　图1所示的SoC 由一块32位RISC指令集处理器及一条AMBA APB外设总线组成，处理器连接到AMBA AHB系统总线上。SoC还包含一个DDR2存储控制器、一个千兆位以太网网络适配器、一个Compact Flash控制器、VGA控制器及多个低速外设接口。SoC运行Debian GNU Linux操作系统第4版，这一操作系统运行v2.6.21内核。处理器核心工作频率为60MHz，DDR存储控制器工作频率为100MHz，其它I/O 外设在33MHz~12MHz之间的基本频率上运行。整个SoC在Virtex-5开发板卡上实现。

　　图1. SoC基线测试台

　　总体上看，这一系统是一台全功能计算机，能够提供基于终端的用户接入，能够连接互联网，运行应用程序，安装文件系统等等。SoC的这些特点产生了复杂的调试场景，给硬件调试设施和软件调试设施的功能带来了压力。在大多数情况下，关键操作都同时涵盖硬件和软件。

　　调试基础设施

　　处理器核心开发人员一般会提供调试基础设施，要么是某个核心的一套固定特性，要么是一群核心的可配置插件。不管是哪种形式，调试基础设施都变成了被制造的核心的一部分。然后调试软件使用这个基础设施，为软件开发人员提供调试特性。

　　与大多数现代处理器类似，如英特尔处理器、AMD处理器、IBM处理器、Oracle处理器和ARM处理器，这里突出显示的处理器核心支持一套基本调试功能。在本例中，可以通过JTAG访问的“后门”，允许软件调试程序（如GDB）读取和写入系统中的存储器，检测处理器的运行状态。通过这些机制及访问原始软件源代码，GDB和其它软件调试程序可以提供软件断点、单步操作、变量值检查、堆栈跟踪、初始条件配置、交替存储器值及恢复功能。

　　在大多数情况下，硬件调试设施并不是与构成SoC的硬件IP核心一起提供的。相反，硬件调试设施通常叠加到现有的SoC设计上。造成这种差异的原因有很多。首先，与软件调试不同，硬件要求的底层功能具有多样化特点，通常只有在SoC组装时才能得到全面了解。此外，每种新的SoC通常要求不同的调试基础设施。最后，作为新兴领域，硬件调试的标准化程度不高，生态系统建设不够。因此，硬件调试设施通常被留给各个设计人员，这些设计人员会创建针对不同功能领域的特定调试特性。在大型机构中，通常会开发拥有内部支持的工具和结构。但是，随着SoC的复杂程度不断提高，创建高效硬件调试设施的复杂程度也在不断提高，内部开发工作难以为继。

　　作为替代方案，测试和测量厂商可以提供完整的设计工具、IP库和工作流程，创建硬件调试设施。图2所示的设置称为Tektronix Clarus Post-Silicon Validation Suite，这一验证套件由多种可以重复配置的嵌入式仪器组成，这些仪器可以连接起来，分布在整个SoC中，创建满足特定功能要求的调试基础设施。 Implementer工具可以在RTL级（Vreilog、System Verilog和VHDL）把硬件设计中任何层级的任何信号仪器化。Analyzer通过JTAG或以太网连接，配置和控制嵌入式仪器。最后，Investigator把嵌入式仪器收集的数据向回映射到原始RTL（在仿真环境中），实现更复杂的调试。

　　图2： Clarus Post-Silicon Vlidtion Suite套件的结构。

　　嵌入式仪器被应用到SOC中，提供调试基础设施，如图3所示。其中一个重要方面是能够在调试过程中重新配置仪器，针对SoC不同领域中的各种信号和场景。基本仪器称为捕获站，其独立管理观测数据的选择、压缩、处理和存储。多台捕获站通常一起使用，为某个SoC创建特定设计基础设施。在插入过程中，捕获站配置一系列关心的潜在信号、最高同时观测数量以及最大RAM容量。捕获站一般被分配给特定时钟域，同时捕获观测数据。Analyzer从每个捕获站中收集数据，颠倒压缩算法，把每个站中捕获的数据对准，在所有捕获站中生成时间相关的视图。

　　图3： 硬件调试基础设施。

　　本例中使用的SoC有四个捕获站：一个位于处理器时钟域，标为1号捕获站（60MHz），针对362个信号；一个位于RX以太网域，标为2号捕获站 （25MHz），针对17个信号；一个位于TX以太网域，标为3号捕获站（25MHz），针对17个信号；最后一个位于闪存时钟域，标为4号捕获站 （33MHz），针对178个信号。每个捕获站都并行运行，能够选择性地观测任意信号组合。Analyzer工具的最终输出是一个表示实际硅片器件中时钟周期准确信号事务的波形，如图4所示。

　　图4： SoC波形实例。

　　尽管软件调试设施和硬件调试设施在目标平台上观测只限于软件问题或硬件问题时效果很好，但在了解涉及软件和硬件交互的行为时，则面临着明显挑战。表1列出了我们的测试台开发过程中遇到的部分问题，以及我们在业界看到的代表性问题。

　　主要挑战在于，尽管使用软件调试设施或硬件调试设施能够“看到”非预期行为的影响，但通常很难确定观测到的不正确行为到底是因还是果。这个问题经常变成软件中非预计的行为是硬件行为不正确的结果，还是其它方式。关键在于确定多个事件之间的临时关系，这要求软件调试视图和硬件调试视图之间有一个公共参照物。

　　事件管理

　　重建软件调试视图和硬件调试视图之间临时关系的能力，涉及两种调试设施中调试状态和事件处理的整合，或综合硬件管理，如图5所示。

　　图5： 综合事件管理。

　　在本例中，Clarus Suite提供的分布式异步仪器使得每个捕获站可以视作自治设备。为支持仪器之间的“交叉触发”，有一条共享事件总线及一个集中式事件处理器。集中式事件处理器在图5中标为接入控制（Access Control），把调试事件和状态传送给Analyzer软件，Analyzer软件管理着整个调试基础设施。这可以对多个功能单元和时钟域同时进行高效硬件调试。为创建综合事件管理，这些信息传播到软件调试设施中，并从软件基础设施中收集数据。通过采用综合事件管理，基础设施可以检测软件断点事件，调试处理器的状态。同样，软件调试设施能够检测硬件触发，调试硬件调试设施的状态。

　　综合事件管理的两大优势是软件调试发起的事件能够控制硬件触发，硬件调试发起的事件能够控制软件调试。更具体地说，软件断点可以映射到特定硬件行为，硬件触发可以在某个点中断软件。图6和图7分别说明了这两种场景的实例。

　　图6：由软件发起的事件。

　　图7：由硬件发起的事件。

　　为演示综合调试系统中软件发起的断点功能，我们修改了Linux内核，在磁盘扇区0x00041d90上发生读取时打印消息“BLOCK”。然后，把目标对准调试设施中来自“sysace”Compact Flash控制器的轨迹。我们使用GDB，在xsysace.c文件第714行上设置了一个硬件断点（printk发生的行）。然后配置测试设施，使用综合事件管理监测软件调试设施。最后，“find/”命令强制内核读取整个磁盘。如图6所示，软件断点在希望的行上暂停了内核执行，另外还触发了硬件调试设施。结果，可以在软件断点时间上看到详细的硬件行为。

　　我们使用硬件适配器，演示综合调试系统中硬件发起的触发功能。我们设置成在Linux内核清除以太网适配器中的“RX Packet Ready Interrupt Bit”时发生硬件触发。我们把综合事件管理界面配置成把硬件事件映射到软件调试设施。到系统中路由器IP地址的ping从SoC到路由器应答位置发起一个发送包。在应答发生时，这个包到达以太网物理层，由以太网适配器处理。然后处理器被中断，Linux内核服务中断。在中断服务结束时，中断被清除。这导致硬件触发和软件被暂停，如图7所示。得到的视图显示了从物理层直到操作系统的整个复杂系统中硬件和软件的同步行为或时间相关行为。

　　小结：通过在软件调试设施和硬件调试设施之间创建综合事件管理界面，可以围绕软件调试事件和硬件调试事件实现单事件同步。这种同步可以有意义地表示同时来自这两种基础设施的调试数据。这样一个完整的系统视图为观察涵盖软件和硬件的各种SoC功能之间的临时关系打开了一扇窗户，可以更快、更高效地调试日益复杂的 SoC设计。