未来多核SoC设计的决定性因数——软件设计

        回顾过去10年左右的时间，半导体工艺技术在一定程度上满足了人们对大规模处理器IC功能的需求。当下一代机顶盒IC需要更强大功能的时候，从180nm工艺过渡到130nm工艺能够进一步提高芯片的集成度，加快时钟频率，从而提供应用所需的功能增强。但是，下一代芯片不再是只包含一个处理器。

        在过去几年内情况已经发生了很大的变化。简单的看，硅尺寸缩放已经无法满足应用对芯片功能的需求。因此，芯片设计者开始转向多处理器架构，这种架构面临着处理功耗增大的风险。每个芯片内集成的处理器个数正在迅速增加，多年前Cisco公司为其CRS-1网络路由器研制的192处理器引擎（如图1所示）就是这样一个例子。

        随着处理器功耗和复杂性的增大，带来了很多问题，其中大都归结于系统方程的软件方面。编写用于单处理器系统的软件是一件相对简单的工作，纯顺序的编程方式就能够解决问题。但是对于多处理器引擎，如果无法让它们并行执行指令，那么它们就没有什么优势了。如何发掘并行性是问题的关键所在。错误的编程方法会导致可怕的后果，带来复杂的调试问题。

       对于希望在自己的SoC（片上系统）设计中采用多处理器架构的设计师而言，幸运的是，相关的设计工具和方法学已经开始显现。设计师们可以按照一定的步骤确保他们的并行应用代码不会产生访存死锁、竞争条件或者其他一些会导致一个或多个处理器甚至整个系统失效的故障。

      多核处理器的现状

      通过一个普通的多核SoC实例就可以说明这类器件的复杂性和编程难度（如图2所示）。假设将一个采用130nm工艺设计的单处理器SoC转换成由65nm工艺实现的多核架构，设计师将需要处理4倍的晶体管数目。

        多核架构复杂性的增大远非集成多个处理器那样简单。更多可用的逻辑门可以实现更大容量的存储器，这需要处理更大量的数据、高分辨率的视频流和其他一些内容。增大带宽意味着需要更多的I/O处理全部的数据。各种各样的网络栈和更精细的用户界面要求采用更复杂的控制过程。“设计师们正采用越来越多的CPU，” Tensilica公司的CEO，Chris Rowen说，“但是这种方式的潜力是有限的，因为需要编写芯片的控制通路。”

       对于多核SoC，重要的区别在控制通路和数据通路的处理上。“在数据通路中，人们更注重于集成更多的功能，”Rowen说，“芯片不再仅仅用于处理音频、视频或无线基带，而是要能够处理所有的功能。同时，每种功能的应用复杂性也在不断增大。这需要可编程性更强的解决方案。”

        大部分多处理器的设计努力常常因为访存冲突问题而中途失败。“较早的多核设计采用共享存储结构是基于多个任务并行发生的假设，设计者原本希望各个任务访问不同地址空间的存储器，”第45届设计自动化大会主席、匹兹堡Intel研究中心副主任Limor Fix说。

      “设计思想是，并行线程不相互干扰，尽可能地减少访问共享存储器的时钟周期数，”Fix认为，“如果每个并行计算程序处理的是存储器内不同的数据，那么冲突就减少了，访问共享存储的锁定时间也减少了。”

       问题在于设计的可见性是极其有限的。“一般而言，当使用处理器的RTL级仿真模型时，软件调试主要靠查看处理器的通用寄存器，” Mentor Graphic的产品营销经理Jim Kenney说，“这些寄存器通常显示在顶层，在逻辑模拟器的波形窗口中用于追踪处理器的执行过程。”

      更糟糕的是，多个处理器可能只有一个调试端口。当所有处理器同时执行指令时，很难控制某个处理器的速度。

       在缺乏判断的情况下调试工作将变得更加困难。“对于多个处理器，你无法控制其执行的内容，” Virtutech公司负责营销的副总裁Michel Genard认为。重新执行代码常常是没有意义的，因为每次执行的结果可能都是不一样的，很难定位程序中的问题。从而就出现了所谓的“Heisenbug”，即由于介入式探针影响系统行为而导致的变化。

       虚拟技术

       幸运的是，针对这些问题还是有解决办法的，其中最常见的是“虚拟化”即“虚拟平台”技术。虚拟平台为多核设计带来了很多好处。

        当采用硬件模型构建出虚拟平台之后，涉及软件调试的很多问题就迎刃而解了。设计者能够在更大的范围内控制系统，从而获得确定性更强的结果。对于处理器核的数量和速度以及每个核的软件负载，都很容易改变系统的配置。

       虚拟硬件技术对存储器、处理器寄存器和器件状态都提供了良好的可见性。此外，当对各个处理器进行同步时，你可以一次性同步所有的处理器。它还对系统执行提供了更强大的控制功能。

       当调试工作需要全局性的系统停顿时，所有的处理器同时停止，没有“刹车”效应。当通过指令对某个处理器进行单步调试时，可以令其他处理器进入等待状态。可以减慢或者完全停止处理器核的运行；通信延迟增大；断点造成的时序干扰问题消失了。

       抛开上述所有问题，装配虚拟平台的关键仍然在于模型本身。这些模型来自于哪里？它们应该体现哪一级的抽象？

       如果你的多核设计采用了大量原来积累的RTL模型，就像大多数设计那样，那么可以采用Carbon Design Systems提供的设计工具进行建模，这种工具能够将RTL编译成可执行的软件镜像。编译可以逐个模块进行，或者在子系统一级进行，甚至可以对整个系统进行。

       Carbon公司的CTO，Bill Neifert认为，通过模型可以看出系统内部的情况。“我们在某些RTL模型上实现了类似模拟器的功能，”Neifert说，“你可以查看波形，看到处理器之间竞争资源出现的冲突。”

       硬件和软件开发部门也可以利用虚拟平台选择适用于系统的用例。例如，飞思卡尔半导体公司认为，广泛研究用例对于公司的多核SoC设计是至关重要的。

      “我们花了大量的精力，动员包括销售、验证、检验、软件设计、硬件设计和开发工具在内的各个部门共同决定各个用例的应用优先级，”飞思卡尔公司的验证部主管J.T. Yen说，“然后我们就会选用那些用例并推荐给我们的团队，确保硬件架构与用例的一致性。”

       Virtutech公司推出的Simics 4.0就是一个支持这种用例探索的虚拟环境。本月发布的4.0版新增了支持更多用例的API，以及包含大量模型的模型库，这些模型是从Simics最初版本以来不断产生积累的。

      而且，Simics 4.0本身就是一个多线程工具，能够帮助多核SoC的设计者利用其计算资源（包括笔记本电脑或多路服务器）内的所有IP核增强仿真速度和可扩展性。Virtutech的Simics加速器具有这一功能，能够利用一个Simics会话并行仿真多个机器。

      CoWare公司推出的ESL 2.0工具套件也能够用于创建平台。利用CoWare的工具，多核SoC设计者能够以周期精确的抽象级别调试和评测他们的IP核与子系统RTL的平台级性能。

      克服障碍

       如前所述，采用虚拟平台的方式有其自身的优势，但是还存在一些障碍需要克服。构建虚拟平台是一项艰巨的任务，必须与设计过程本身同时进行。其次，不通商用设计流程之间还存在硬件模型互通性的问题。

      Imperas公司是虚拟平台领域一个相对较新的组织，他采用了一种有些独特的方式进入了这一领域。与众不同的是，该公司主要的技术贡献是开创了虚拟平台的开源基础架构。

     “在我们创办公司之初，我们的目标是多核SoC的编程，” Imperas公司的总裁兼CEO，Simon Davidmann说，“但是我们发现真正的困难在于调试。没有明确的仿真基础架构支持多核的调试。关键是建模技术要支持各个模型协同工作，而不论模型来源于何处。”

       最终，Imperas公司通过其“开放虚拟平台”（Open Virtual Platform）网站（www.ovpworld.org）以及SourceForge免费提供了三种技术要素。第一个是用于处理器、外设和平台建模的C语言API（应用编程接口）。

        第二个是为API编写的开源模型库。用户可以获得这些模型的预编译目标代码或者源码文件。目前，该模型库包含ARM、MIPS和OpenRISC OR1K的处理器模型，其他处理器模型也在不断补充之中。模型库中还包含大量组件和外设模型。另外，还有几个用C、C++和SystemC编写的嵌入式平台实例。

       第三个是一个免费的OVP参考仿真器，OVPSim，它运行处理器模型的速度可达500MIPS。该仿真器具有GNU调试器（GDB）接口。

        通过C/C++/SystemC辅助代码可以从其他仿真器中调用OVPSim。它还可以集成现有的ISS（指令级模拟器）处理器模型（如图4所示）。
 

       复杂性问题

        对于编写多核SoC嵌入式代码所用的语言，某些设计者认为现有的方式需要彻底突破。换句话说，用C或C++语言以顺序的方式编写软件不再是一种实用的方法。现在，我们需要最新的真正并行的语言和设计方法学。

       “寻找全新的能够解决并行性的设计入口语言是一个长期的目标，实现这一目标至少需要5到10年的时间，”Synopsys公司系统级解决方案产品营销主管Frank Schirrmeister认为。他还谈到，最好为当前用户提供具有多核分析与调试功能的虚拟平台。

       这种语言和方法学或许最终会出现。但是目前，人们正将大量传统的顺序软件转换成并行代码，只是这一转换过程非常艰苦。不过，已经有设计工具能够帮助设计者判断顺序代码中是否存在并行性。

      Critical Blue公司的Cascade就是这样的一种工具。它集成了可重编程的协处理器，能够加速本地二进制代码或C/汇编程序源码的执行。最近，该公司将Cascade扩展成一个具有同样功能的多核版本，增加了多核间软件划分、任务相关性分析和验证功能（如图5所示）。

      “多核架构本身并不是新概念，但是之前人们通常针对特定的用途设计多核架构，” Critical Blue公司的创始人兼CEO，David Stewart说，“我们现在看到的大部分多核架构的形式是可用于多核SoC的硬件架构。这意味着重新编程，进而归结为软件问题。”

       Stewart认为，Multicore Cascade是一种实用的方法，有助于构建当前适用于多核架构的编程语言和技术。“当我们只设计一个协处理器时，我们开发出了指令级并行性，”他说，“现在，我们正在开发任务级并行性。除此之外，我们还要分析代码相关性存在的位置，以及打破这些相关性所带来的好处。”

       调试方法的改进

        多核SoC的功能验证在很大程度上是采用基于处理器测试的方法来实现的。验证工程师采用由RTL级设计衍生而成的全功能、精确结束（signoff-accurate）的处理器模型驱动挂接在总线上的其余IP模块的周期。该方法可以用于模块级的验证，或者作为最终仿真，用于确保硬件能够产生复位并执行代码。

       但是基于处理器测试的不利之处也在于软件调试的可见性是有限的。一般的调试流程只能看到处理器的通用寄存器。

      “判断一个C测试没有在硬件上正确运行的唯一交互式视图是波形视图，” Mentor Graphics的Kenney说，“在测试过程中将波形视图的异常点与源码中发生异常的位置关联起来是非常困难的。”

      Mentor Graphics推出的Questa Codelink工具就是针对这一问题的一种解决方案，它是对Questa功能验证环境的扩展。“我们已经在ModelSim Questa环境中集成了一个标准的源码级软件调试器，并将它们与验证中使用的RTL处理器模型连接起来，”Kenney说。

        利用Questa Codelink，用户能够实现交互式图形化调试。在源码视图下，用户可以看到的断点数量是没有处理器个数限制的。该工具能够显示寄存器的状态，追踪变量的值。源码视图中的一个光标与调试器波形窗口中的一个光标是锁步的。移动任意一个窗口中的光标都会将另一个窗口中的光标移到相应的位置。

        Mentor公司Questa Codelink的项目经理Russ Klein认为，多核SoC设计工具重要的一点是不侵入处理器。“你可以看到每个处理器上发生的动作而不会引入任何同步误差，”Klein说。“你可以完全同步的看到这种信息，同时看到每个处理器的详细状态。你还可以对代码进行向后的单步调试，直到出现同步错误的位置，这种功能也是非常强大的。”