基于嵌入式的SoC验证效率测试方案

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

构建测试台

整个SoC在Virtex-5开发板卡上实现。图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之间的基本频率上运行。

图1. SoC基线测试台。

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

事件管理

重建软件调试视图和硬件调试视图之间临时关系的能力，涉及两种调试设施中调试状态和事件处理的整合，或综合硬件管理，如图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设计。