建模技术最大化虚拟平台的价值

系统级环境提高了开发人员的工作效率并更早地将产品推向市场，为架构分析、硬件/软件协同开发和系统验证提供了一个开发平台。模型为任何系统级平台提供了支柱；然而，开发这些模型所涉及的困难和费用限制了虚拟平台的采用。Andy 描述了有效建模策略对虚拟平台开发的重要性。

在过去的几年里，开发团队和方法论小组更加重视平台驱动的设计技术。更短的产品生命周期和更高的上市时间压力迫使公司投资于设计周期早期可用的系统级平台。此外，向利用传统和第三方 IP 的片上系统 （SoC） 设计技术的过渡为系统级建模提供了更好的结构和方法。同时，越来越多的嵌入式软件和固件内容已将生产产品所需的大部分资源重新定位到软件领域。在传统的设计流程中，这意味着大部分开发过程在设计流程的后期转移，从而增加了进度风险。

虚拟平台有助于解决这些日益复杂的问题、市场压力和内容变化。尽管一些工程师已经详细描述了这些平台的好处，但确定合适的建模方法通常留给读者作为练习。为了阐明虚拟平台的这一方面，以下讨论将分析适当建模技术的不同方面。

具有讽刺意味的是，虽然模型为任何系统级平台提供了支柱，但与开发这些模型相关的困难和费用限制了虚拟平台的采用。此外，建模和支持工作消耗了开发和支持这些平台的大部分成本。

模型抽象级别

对于本次讨论，模型可以分为四个不同的部分：时序、功能、可寻址状态和接口。模型的四个部分中的每一个都可以在不同的抽象级别上有所不同，从高级行为描述到实际设计实现。直接从反映真实设计行为的设计描述创建的模型称为实现精确模型。表 1 中的建模堆栈显示了最高和最低极端之间的连续抽象。

表格1

与大多数与计算相关的应用程序一样，提高准确性对降低执行速度有直接影响。这与建模没有什么不同。提高模型的准确性需要更多的处理并降低执行速度。

此外，提高模型准确性与创建和支持模型所需的工作量和时间直接相关。找到适当的速度与准确性权衡对于实现满足虚拟平台用户需求并限制开发和维护平台所需工作量的建模范例至关重要。

一方面，硬件工程师需要实现精确的模型来验证他们的设计。另一方面，应用软件开发人员可以使用高级行为模型。在这两个极端之间存在较低级别的软件，包括操作系统 （OS）、驱动程序、固件以及架构和性能分析。

应用软件工程师最关心的是开发他们的应用程序并拥有一个高效的调试环境。他们不需要详细模型的准确性；他们的代码很少接触到实际的硬件，因为它分层在其他软件之上。但是，在某些情况下，应用软件工程师可能需要了解需要更高准确性的简单性能指标。

与应用程序代码不同，操作系统和驱动程序开发涉及硬件；因此，开发这些组件的人员需要更高的准确度来了解他们的软件和底层硬件如何交互。他们可以用速度换取更高的准确性，因为他们的代码库比应用软件工程师的代码库要小。不定时行为模型可能对早期开发有用，但最终，操作系统和驱动程序开发人员必须了解他们的软件如何使用更准确的模型工作，以确保整个系统（硬件和软件）能够协同工作。

固件工程师开发与硬件交互的代码——引导代码、自检、诊断和控制台。鉴于与硬件的这种高度交互和对硬件的依赖，这些工程师很少使用不准确的模型。他们可以交换模型速度以获得更高的准确性，因为他们的软件处于最低级别，并且与更高级别的软件相比通常很小。调整低级固件和驱动程序软件性能还需要周期精确的模型来了解对硬件的时序依赖性以及资源瓶颈。

架构师需要了解他们的硬件/软件分区、IP 选择、总线架构、内存架构和整体架构决策如何影响与性能、面积和功耗相关的系统。他们还必须了解管道效应、延迟、吞吐量、带宽和活动。不按建筑师计划执行的最终设计可能会极大地影响产品的成本、性能和进度。因此，架构师必须使用高度准确的模型来验证他们的设计，以建立对其决策的信心。硬件工程师必须有实现精确的模型；任何其他级别的精度都不适合验证设计。

所有模型的单一抽象级别并不总是适用于所有情况。例如，考虑内存架构权衡的架构师可能会尝试分析每个预期内存子系统的内存延迟和吞吐量。在这种情况下，架构师可能需要高度精确的内存控制器和内存接口模型，以确保他们完全了解性能。系统的其余部分可以在更抽象的层次上建模，因为它对分析并不重要。使用支持混合抽象级别并为不同抽象级别的模型启用即插即用的模型方法有助于优化执行速度和分析准确性。

最后，在考虑所有可能的用例时，工程师应注意平台很少只针对一种类型的用户。更常见的是创建一个虚拟平台来满足多种类型用户的需求，从软件开发人员到架构师，在某些情况下，还包括硬件设计人员。因此，平台内必须支持不同的抽象级别。

互操作性和兼容性

在创建建模方法时，开发人员应确保模型彼此可互操作，跨抽象层分布，并与各种平台和第三方工具兼容。一致性对于保证不同模型开发人员创建的模型相互兼容也很重要。

虽然并不完美，但标准通过支持各种模型抽象并提供与不同平台和第三方工具的兼容性，有助于增加模型之间的一致性、兼容性和互操作性。

SystemC 等建模语言提供了连接和执行不同模型的基础平台。SystemC 提供了支持多个抽象级别和通信接口的灵活性。将 SystemC 与接口标准相结合，例如由 Open SystemC Initiative （OSCI） 开发的提议的事务级建模 （TLM） 2.0 规范，提供了一个环境，该环境保持与各种建模元素和抽象的兼容性，并使它们彼此可互操作，并且其他平台。

此外，当从不同的抽象级别细化模型时，开发人员应该尽可能多地重用从一个模型到另一个模型的信息，并从一个 IP 块的一个修订版本到另一个重用建模信息。一致的方法和标准提供了完成这些任务的机制。开发人员还可以重用接口、状态访问机制和从一个模型到另一个模型的时间。Spirit IP-XACT（来自 SPIRIT 联盟的 IP 元数据规范）等标准可以帮助开发人员导入和导出配置信息，并检查模型修订和抽象之间的差异。

不能保证不同模型和抽象之间的互操作性或提供与其他平台和第三方工具的兼容性的建模方法不适用于大多数项目。事实上，缺乏互操作性和兼容性已经减缓了嵌入式行业对虚拟平台的采用。

满足供应链需求

在整个供应链中提供模型的需求不断增长，这强化了互操作性、兼容性和标准的重要性。IP 提供商必须提供其 IP 的早期模型，因为客户需要能够为他们的产品选择合适的 IP。如果没有合适的模型，客户就无法知道哪种 IP 最适合他们的系统。客户还需要一个用于他们自己的开发（架构、硬件和软件）的平台，以便用正确的产品进入他们的市场窗口。

任何支持跨供应链交付 IP 的建模方法都必须考虑到这一点。IP 必须与最终客户的平台和模型兼容，同时提供安全性并且不受逆向工程的影响。

打破建模障碍

一个经过深思熟虑的建模方法可以克服虚拟平台采用的障碍，并确保用户获得虚拟平台可以提供的所有价值。虚拟平台建模应支持各种抽象级别的模型、模型即插即用以及互操作性、兼容性和重用标准。

行业需要提供工具，以跨各种抽象级别以一致的方式自动支持模型生成。这些工具必须包含标准并保留开发人员对其模型的投资。要求应：

提高模型开发人员的工作效率

重用来自遗留模型或不同抽象级别的模型的信息

支持标准以确保互操作性和模型到其他虚拟平台的迁移路径

提供一致性检查以验证跨抽象级别的模型

为模型支持和分发提供配置管理和修订控制帮助

审核编辑：郭婷