开发一个复杂的多内核无线系统无疑是个艰巨的挑战，特别是当内核包含有高性能处理器和先进的数字信号处理器(DSP)时更是如此。等待硬件原型实现是不能令人接受的：关键的软硬件折衷应该在芯片制造之前尽早地完成。在内核芯片制造前传统的验证与调试方法依赖于指令集仿真器(ISS)模型。不幸的是，ISS模型速度太慢，并且时序精度无法达到与系统硬件部分的RTL模型交互所需的要求。

在多内核环境中问题更加严重，因为单个独立的模拟器工具在调试模式下通常都缺少同步机制。结果是有些软件开发和软硬件集成工作必须等到无线硬件原型实现后才能开始。在昂贵、数量又少的硬件原型基础上进行开发和调试常常导致项目进度的延迟，并会增加芯片返工的风险。

本文将提供一种采用虚拟系统原型实现系统级的多内核系统调试方法，该方法允许在PC机上实时执行一个完整系统的周期精确仿真，而且执行速度比基于ISS的仿真要快得多。该方法支持完整的系统级单步调试操作，其调试模式下的时序精度水平完全可以匹配实际设备指标。另外，由于虚拟系统原型能让开发人员在多系统环境下快速精确地调试，因此给开发工作带来了极大的便利。下文讨论的包含二个ARM处理器和一个StarCore DSP的多内核无线系统实例证明了该方法的有效性。

无线SoC实例

适合无线应用的一个实际多内核芯片整体架构采用了通用CPU和专用DSP内核来达到并行和专用处理的目的。另外该芯片还包含了用于片外通信的多层存储器系统和多个外围器件。

这个特殊芯片包含2个ARM926E CPU内核，每个内核拥有独立的指令和数据缓存。其中一个ARM处理器运行Linux操作系统，并提供虚拟机、图形化环境和消息等多个普通服务。另外一个ARM926E与DSP内核联系紧密，主要用于处理整个系统的通信和控制，需要时也能用于执行特殊任务和应用进程。拥有2个CPU可以完全实时地处理各种业务，从而满足无线设备的各项关键要求。

作为2个ARM内核的重要补充，StarCore SC1200处理器可以加速多媒体数据处理，执行无线调制解调器的处理任务以及其它DSP任务。这块内核内置有2个独立的执行单元，每个单元都可以执行乘法累加(MAC)以及其它信号处理算法中常用的算术操作。DSP设计用于提供大部分的语音数据处理以及MP3、MPEG-4和H.264等多媒体数据解码服务。

作为无线芯片中的典型部件，层次化总线网络可以提供专用的数据通道，减少业务流量，并提供通信所需的公共存储模块访问。在顶层，六条系统总线通过各自专用的存储器子系统和外围器件与处理器建立互连。所有这些总线都使用AHB协议，该协议是ARM公司定义的用于ARM处理器内核的先进高速总线。

专用AHB总线允许全部三个处理器同时对存储器进行数据和指令存取，因而能够消除多内核设备常见的瓶颈问题。AHB系统级总线到更低层的总线通过桥进行链接。三条专用存储器总线提供对存储器模块的访问，二条低速外围器件总线连接片外通信用的定时器、中断控制器和串行接口。

当然，处理器之间也必须交换数据或控制信息。所有这类通信都是通过系统内任何地方都能访问的共享存储器完成的。利用旗语(semaphore)和邮箱(mailbox)等现成技术即可提供处理器和外围器件之间信息的安全传送。

传统的软件建模

在SoC生产出来以后才进行验证势必会使最终产品存在大量缺陷。即使设计中嵌入了专门用于调试的访问路径，可观察性也相当有限。而在实际应用中，为了满足紧迫的产品上市时间要求，有用的调试功能往往会被删除掉。因此协调与同步内含多处理器的硬件验证测试非常困难，为了调试故障测试在处理器之间设置交叉触发也有一定的难度。

以前芯片架构师和设计师在芯片制造之前是利用基于软件的模型进行完整的芯片验证和调试的。最常见的方法是使用为每个处理器设计的指令集仿真器模型。这些模型执行的二进制代码与芯片中的实际处理器代码完全相同，因此这些模型可以用来在SoC制造之前开发和调试软件。

然而，典型的ISS模型在仿真运行大型软件(比如实时操作系统(RTOS))时速度太慢。那些具有较高性能的ISS模型在牺牲精度的条件下才能达到较快的速度。ISS模型的主要特点仅在于精确的指令，也就是说它们能够如实地产生与制造芯片中处理器相同的结果运行代码。然而，处理器接口的逐个周期行为可能无法匹配实际处理器内核的行为。

在开发多内核无线设备时ISS模型的缺点是一个大问题。由于对缓存和存储器的访问不具有周期精确性，因此无法精确测量存储器性能，也无法进行详细的架构折衷。此外，针对SoC的剩余部分将ISS和硬件设计连接起来需要周期精确性，单凭指令精确性将极大地限制可以执行的软硬件协同仿真的数量。而且不准确的时序将意味着处理器内核之间的交互操作有可能不匹配实际运行情况，从而导致芯片和硬件原型制造出来以后还要做进一步的软件开发和反复调试。

使用独立的ISS模型会给调试带来很大的限制。由于单个模型之间缺少同步机制，在试图调试故障测试案例时很难理解处理器之间是如何交互信息的。另外，由于内核周边环境中而不是内核本身内的时序问题会导致许多错误发生(如竞态条件和死锁)，因此使用单步执行调试根本无法捕获这些错误。

从传统角度看唯一的替代方案是针对处理器内核使用周期精确性仿真模型。这种模型牺牲速度换取精度，由于运行速度太慢，仿真中只能执行关键代码中的一小部分。然而在单内核芯片中，周期精确模型允许详尽的测量，与硬件设计有更多的交互，可提供精确调试所需的深度可观察性。只有这些模型被链接进一个公共验证环境、而且速度不重要的条件下多内核调试才可能获得相同的好处。

多内核无线设计师真正需要的解决方案需要具有很高的仿真速度、完全的周期精确以及支持不同处理器之间精确控制和交互调试的集成环境。而能够满足所有这些要求的唯一已知解决方案就是虚拟系统原型技术。

虚拟系统原型

虚拟系统原型是一个基于软件仿真、时序精确的电子系统级(ESL)模型，首先使用于架构级，然后在整个设计周期内作为可执行的黄金参考模型。虚拟系统原型可以包含周期精确、所执行的编译链接目标代码与实际硬件相同的虚拟处理器模型，因此可以准确地预测系统的实际行为。还可以增加总线、外围器件和其它硬件设计部分的周期精确模型，以便虚拟系统原型能够为多内核无线SoC的完整行为建模。

虚拟系统原型通过混合和匹配硬件和软件部分实施架构开发。针对实际行为建模的精确测量可以帮助系统架构师在开发过程早期进行精确的软硬件折衷。当建立最初的系统架构模型后，虚拟系统原型就能成为可执行的系统规范来进一步推进具体软硬件实现的并行开发。

图1给出了与其它基于软件方法相比之下的虚拟系统原型中处理器模型的性能。由于可以同时提供高速和周期精确性，虚拟系统原型在SoC开发中扮演着非常重要的角色。而且虚拟系统原型可以运行在标准PC平台之上，因此它们能够很容易地发布给系统架构师、软件工程师和硬件设计师，甚至在地理上分散的团队成员。

在本例中，为了实现虚拟系统原型的高效仿真，VaST系统技术公司同时提供了模型和基础架构。VaST仿真内核能够在包括处理器内核、总线和外围器件在内的各个模块间实现精确的同步式交互，同时还能促进与第三方调试器的透明通信。由于能够执行完整的系统级单步调试，因此能为调试提供时序精确性以匹配实际的配置。

多内核调试任何多内核SoC设计都会面临一些常见的调试挑战。由于多处理器和外围器件之间存在复杂交互，因此有许多通信链接需要深层次的观察和调试才能确保生成高质量的软件。

对于非常依赖于通过存储器进行同步的设计来说，常见的缺陷包括不正确的存储器访问仲裁和不希望的数据差错。一些其它系统通过专用主机端口进行直接通信，这是管理通信的一种方便有效的方式。采用这种方法的系统常会发生同步问题，如果没有仔细进行设计和验证，可能会造成系统中断甚至死锁，这对调试来说是也是一个艰巨的挑战。

目前的关键是要能精确地评估各项系统性能、调试所有缺陷以便通过修改架构或实现纠正这些缺陷。典型问题与总线宽度以及由于大业务量引起的时延有关，这二方面问题都是语音分析和综合类的实时应用所特有的，因为实时应用需要获得性能的保证。

总之，在无线SoC验证期间必须调试和解决的典型问题有：

* 共享存储器应用

。数据混乱

。竟态条件

* 直接通信链路

。死锁

。中断

。缺输入

* 处理器性能

。缓存

。管线中断

。缺输入

* 系统总线性能

。拥塞

* 外围器件性能

。时延

通过提供综合的验证环境以及能够快速执行实际代码的一致性处理器模型，虚拟系统原型能使所有这些问题的调试变得更加容易。与其它基于软件的方法相比，虚拟系统原型能够更加容易地设置复杂的测试方案，而且由于能够链接到第三方调试器，在单步执行中能够更加容易地全面观察设计内部细节。利用虚拟系统原型调试这些问题的最关键点如图2所示。

结论

设计、验证和调试一个复杂的多内核无线SoC不是一件简单的事情。调试器只能提供较差的硬件内部可见性，再加上成本和进度的压力都要求使用基于软件的方法。不幸的是，传统的软件技术存在速度和精度问题，极大地限制了其测试和调试与处理器间同步、共享资源竞争以及性能有关的常见问题的能力。

利用虚拟系统原型能够尽早实施软件开发和调试，并具有更好的可观察性能。从上述带2个ARM CPU内核和1个StarCore处理器内核的设计实例可以看出，控制、测量和调试复杂多内核交互操作的能力是项目成功的关键。实现这种解决方案的回报是巨大的：高效的架构开发，并行的软硬件开发，产品化芯片首次流片成功带来的巨大商业机会等等。

未来SoC测试面临的挑战

SOC内部晶体管集成度的增长远远高于芯片引脚的增长，有限的管脚资源使得外部数据带宽和内部数据带宽之间的差异越来越大。这种差异不仅降低了内部模块的可测性，还加大了间接复用方案中测试生成的难度。同时，具有一定故障覆盖率的测试数据会随着电路集成度和规模的增加而增加，大量的测试数据会对直接复用方案中的测试访问的频率和带宽提出要求。

SOC嵌入了类型丰富的IP模块，一些公司已将模拟电路、数字电路、嵌入式DRAM等不同形式的模块集成到芯片中。随着技术的发展，将有更多的电路类型被集成到SOC中，如嵌入式的FPGA、Flash、射频发生器等。混合信号测试在SOC测试中占有重要地位,现有的复用方案还未解决该问题。

迄今为止，还没有一个贯穿IP模块和SOC设计始终的完整的SOC测试解决方案，因为这不仅需要尽快订立相关的国际标准，还需要进行一些关于复用方法上的研究，例如，如何在进行IP模块的测试开发中引入可复用的因素，使得模块级的测试信息对被集成环境具有更好的适应性，能被更高层电路模块的测试开发高效率地复用；研究基于复用的测试集成和优化技术，利用已有模块测试信息，集成出更高层模块的测试并保证其可复用性等。