OVP使系统级虚拟原型成为现实

随着软件内容的重要性和复杂性不断增长，该行业正面临由多个异构处理器带来的挑战，这些处理器的通信比过去更加紧密。为了确保高质量软件的快速上市，开发人员需要一个高性能、系统级的硬件虚拟原型，可以在其上设计、实施和测试软件。虽然以前的原型在开发周期中太慢或到达太晚，但最近宣布的开放虚拟平台 （OVP） 计划可实现早期和快速的虚拟原型可用性。

电子设计自动化 （EDA） 流程建立在模型可互操作且供应商之间可自由互换的基本前提之上，这意味着模型可以从任何地方编写或获取，并且可以被任何供应商的工具所接受。这些特性对于支持高性能原型所需的抽象模型来说是难以捉摸的。正因为如此，EDA 未能提供能够提供适当级别的功能和执行速度的系统级虚拟原型。

硬件和软件领域发生的重大变化很快就会使没有抽象模型的系统无法构建。通过采用重用，设计人员现在基本上是在组装复杂的嵌入式系统，如乐高系统。处理器的复杂性已经碰壁了，这是由于以巨大的功率增加为代价而降低性能增益所造成的，因此今天的大多数系统都使用多个异构处理器而不是一个中央处理器。随着系统功能的不断增长，它必须应对向多处理器世界的过渡。由于所有这些变化，如果没有可行的系统级模型，设计人员就无法继续构建系统，在该模型上可以设计和验证此功能和架构。

历史的角度

硬件/软件覆盖

一些公司试图通过提供可用于软件开发的虚拟硬件模型将硬件和软件社区结合在一起。例如，Mentor Graphics 的无缝替代每个处理器的指令集模拟器 （ISS） 模型，并将它们集成到传统的寄存器传输级 （RTL） 仿真环境中。该模型有助于驱动程序调试，但对于其他任何事情都缺乏足够的性能。无缝产品还包括几个虚拟化主机内存系统的性能增强器，从而将其使用扩展到一些低级操作系统领域。

在后来的几年中，更快的模型取代了 RTL 模型，例如 C 或 SystemC 模型。尽管这些模型提供了更好的性能，但复杂的系统仍然运行得太慢，不适合主流软件使用。

SystemC 原型

业界花费了大量时间和精力来构建基于 SystemC 的虚拟平台。示例包括由 CoWare创建和扩展的平台以及 Eclipse 虚拟原型平台 （VPP）下的拟议工作项目。这些原型提供了一个灵活且适应性强的平台，可以在该平台上分析总线流量、功率、性能和许多其他实现属性。虽然比讨论的 RTL 原型快得多，但这些原型的性能水平使其保持在硬件验证和固件开发领域。

此外，SystemC 未能解决模型互操作性问题，这是 Open SystemC Initiative （OSCI） Transaction-Level Modeling （TLM） 小组正试图纠正的问题。该集团的最新尝试并没有给业内许多人留下深刻印象，因为有些人称这项努力“太少太晚了”。此外，这个提议的标准只涉及内存映射接口，限制了它定义完整系统级原型的能力。

其他公司，如 Virtutech 和 VaST Systems已经放弃了标准领域，并使用定制语言和工具来创建更快的处理器模型、内存系统和硬件的某些方面。虽然这些公司已经成功地创建了具有更高性能的原型，但它们仍受到模型可用性和专有格式问题的困扰。

不断变化的需求和日益增加的复杂性

今天的大多数原型都包含时序，这对于硬件和架构验证以及低级驱动程序测试至关重要。但是时间信息会减慢原型的速度。对于处理应用程序开发的软件团队，时间信息是不必要的。时间随着每个处理器的计时而前进，并且每个线程的事件以正确的顺序前进。

为了可靠地工作，多处理器应用程序必须执行不依赖于时间的同步。因此，软件社区的系统级模型可以完全放弃计时，而是依赖于执行的顺序和线程之间的适当同步。使用信号量、握手或其他机制执行同步，以确保需要通信的两个软件线程都处于交换数据的必要状态。

随着时间的推移，开发人员不再关心单个块或孤立的算法如何发挥作用，而是关心控制和协调块和算法以形成一个完整的多功能系统。这种额外的能力会导致复杂性增加。总系统复杂度与通信的独立节点数量的平方成正比。这些节点可以相互通信并协作以执行全部功能。暗示，这些节点中的每一个都执行独立的任务或与其他节点协调以完成更复杂的任务。随着多处理器片上系统 （SoC） 的出现，软件现在已成为真正的多节点，因为线程可以以完全并发的方式执行并实时相互交互。

多处理器软件需求

过去，将代码交叉编译到主机上既快捷又简单。但是，这不适用于多处理器软件。尽管当前的台式机现在有两个或四个处理器，但它们提供的关于软件如何在实际嵌入式硬件上运行或执行的视图不太可靠，这些硬件可能在处理器之间进行特殊通信或需要异构处理器。多处理器软件需要更精确的原型来研究应用程序通信和同步。

在规模的另一端，许多公司利用物理原型进行软件验证。虽然这些原型以近乎实时的速度运行并具有准确的时序，但它们在开发周期中可用的太晚了，因为软件中发现的问题无法通过硬件的必要更改来反映。随着多处理器系统的引入，实时查看每个处理器在做什么变得更加困难，单步执行等操作几乎是不可能的。设计人员需要一个能够提供相同性能水平但在设计周期早期可用的平台。

过压保护概述

OSCI 维护 SystemC 语言并提供免费的模拟器。尽管这些产品看似有益，但实际上它们扼杀了商业进步。此外，SystemC 也未能解决前面讨论的模型互操作问题。

Imperas 最近推出了 OVP 计划，以推广开放虚拟平台的概念。OVP 鼓励开发人员采用新的嵌入式软件开发方式，尤其是针对 SoC 和多处理器 SoC 平台。该公司对 OVP 和 OVPsim 采取了不同的方法，首先向公众提供接口，从而解决模型互操作性问题。该公司提供了几个模型来演示接口的功能以及一个 Windows 平台模拟器，供开发人员构建和调试模型。

接口

OVP 包含四个 C 接口，如图 1 所示。

图1

ICM 将系统模块联系在一起，例如处理器、内存子系统、外围设备和其他硬件模块。ICM 是一个 C 接口，当编译并与每个模型和一些目标文件链接时，它会生成一个可执行模型。鉴于它是标准 C 代码，任何 C 编译器都可用于创建模型。ICM 接口还允许定义内存映像，以便可以将程序或数据预加载到系统模型中。

VMI 是允许处理器模型与内核和其他组件进行通信的虚拟机或处理器接口。VMI 本质上是 OVP 提供的高性能执行的核心。OVP 使用带有即时编译器的代码变形方法将处理器指令映射到主机提供的指令中。中间是一组优化的操作码，处理器操作映射到其中。OVPsim 提供对本机机器功能的解释或编译。这与解释每条指令的传统 ISS 方法不同。VMI 还为文件 I/O 等功能启用了一种虚拟化形式，允许使用提供的标准库在主机上直接执行。

PPM 是外围建模接口，类似于第四个接口 BHM，用于更通用的行为。这些模型在模拟器的第二部分运行，称为外围模拟引擎。OVPworld 声明“这是一个受保护的运行时环境，不会使模拟器崩溃”。它通过为每个模型创建单独的地址空间并将通信限制为 API 提供的机制来实现这一点。这两个接口之间的主要区别在于 PPM 接口理解总线和网络。因此，它在功能方面类似于 OSCI TLM 接口提案。BHM 更类似于具有流程激活和等待时间或特定事件的能力的传统行为建模语言。

性能基准

OVPworld 网站上提供了几种不同的处理器模型和预打包的演示。开发人员可以使用免费的模拟器来创建自己的平台。表 1 显示了运行各种基准测试的每个内核获得的性能结果。

硬件/软件虚拟原型的基石

OVP 有可能为硬件和软件开发提供真正的系统级虚拟原型。它有望成为第一个通用抽象建模系统，将形成完整流向硬件和软件社区的基石。虽然这在 DSP 设计等专业领域之前已经完成，但在更一般的情况下从未解决过。OVP 已经为这些原型打开了商业市场，这意味着它可以比 SystemC 获得更多的商业关注。如果成功，OVP 将解决模型互操作性问题，从而使整个行业受益。

审核编辑：郭婷