使用事务级模型确保硬件和软件同步

消费者和无线通信市场比以往任何时候都更具竞争力。公司聚合与分解之间的持续战斗如火如荼。聚合的一个例子是决定通过将芯片设计引入内部来拥有更多的垂直设计链。这有助于像 Apple 这样的公司通过控制更多的整体产品设计来实现差异化，从而不受其他人可用的现成芯片的限制。

虽然苹果已经证明了垂直差异化的潜在回报，但这种方法确实带来了巨大的风险，无论一家公司是否有设计芯片的经验。具体来说，软件团队如何开发与交付的硬件一起使用的软件？

在等式的另一边，完全分解是由软件抽象层（如谷歌的 Android 操作系统）实现的。它在某种程度上使设计空间民主化，允许所有系统公司参与并使用软件实现差异化。Android 允许半导体供应商通过提供支持硬件平等参与。同样，软件与硬件一起工作的方式决定了产品的成功。

这个问题的传统解决方案在今天的市场上是行不通的。公司过去可以根据规范开始软件开发，并等待芯片原型可供测试。如果软件非常简单，独立于硬件，并且有一个简单的规范，那么它就可以工作，但对于今天需要所有东西都连接起来的消费电子产品来说就不行了。

此外，等待很长时间才能开始测试会使调试周期在计划中太晚。近年来，许多公司通过转向标准的现成芯片来解决这个问题，但这种方法限制了差异化的能力。如果你想添加一个省电的睡眠模式但是没有办法关闭芯片怎么办？

在综合场景中，公司不仅在软件和工业设计方面寻求差异化，而且在电子硬件方面也有所不同。进行芯片设计项目会带来风险；再加上嵌入式软件开发，整体项目风险呈指数级上升。大多数公司都非常小心，会花大量时间预先构建系统、对其进行测试、将其划分为软件和硬件，并指定两者的行为。但是一旦每个团队开始设计，就会做出某些实现假设，引入错误，并且可以添加功能。

在一个分散的世界中，情况甚至更糟，因为责任现在跨越了公司边界。来自系统和半导体领域的公司可能会决定合作优化硬件/软件交互并创建针对系统需求进行优化的芯片。即使有持续的同步会议，设计更改也会在软件团队不知情的情况下潜入，并且可能直到软件第一次在实际硬件上运行时才会被看到。这又回到了硬件不够快可用的问题。工程师如何解决这个难题？

原型设计的黄金模型

以软件模型形式出现的硬件虚拟原型（或虚拟平台）在流程的早期为软件团队提供了系统硬件模型。这使开发人员能够开始对硬件规范模型进行测试。但是，它只是规范的模型。今天的大多数硬件设计都是从工程师阅读和解释规范开始的，然后用 Verilog 等硬件设计语言编写低级寄存器传输语言 （RTL） 模型，以开始验证和实施过程。由于前面提到的因素，硬件行为可能会偏离规范。

解决方案是使用一个通用的“黄金模型”，软件团队可以在该模型上进行开发，硬件团队可以使用该模型开始实施。现在，随着开放系统 C 倡议 （OSCI） 事务级建模 （TLM） 2.0 标准的可用性，这成为可能。

简而言之，SystemC 是一个类库，通过对硬件数据类型和并发性进行建模，可以使用 C/C++ 进行硬件设计。因为硬件现在可以用 C 语言建模，所以软件团队可以运行相同的模型。TLM 扩展很重要，因为它们抽象出硬件所需的所有信号级协议细节，以确保它与系统总线正确通信。过多的这些细节会使模型运行软件太慢。TLM 将这些细节抽象为更高级的模型，这些模型可以在高级综合期间映射到详细的硬件。

解决高级综合限制

高级综合提供了 C 模型和构建的实际硬件之间的自动链接。这消除了硬件设计人员解释规范并手动编写自己的模型以开始构建硬件的人为因素。直到最近，由于现在已经解决了一些关键限制，这在实践中很少使用：

结果质量：前两代高级综合从未能够生产出满足手动编写 RTL 所能达到的相同性能、功耗和尺寸的硬件。现代高级合成技术已经解决了这个问题。

细化方法：用于软件开发的高级虚拟原型使用 SystemC TLM 描述，但仍需要硬件团队通过添加硬件架构细节来对其进行细化，以便高级综合可以产生最佳的硬件微架构。这些细节对于软件测试来说太低级了，会减慢它的速度，但它们对于构建高效的硬件很重要。这种方法现在已经存在，并已被早期采用者客户证明。

验证：直到最近，工程师还缺乏一种成熟的方法来验证 SystemC TLM 中硬件架构和其余硬件实现流程的正确性。这主要是因为不存在实现实现的自动化路径，因此大多数验证都是在较低级别完成的。因此验证成为硬件开发进度的瓶颈。既然存在自动化路径，验证方法就已经开发出来了。

硬件设计团队熟悉使用 SystemC TLM 设计和验证硬件的这些传统障碍。然而，大多数人并不知道这些障碍已得到解决。那些意识到这一点的人现在享有显着的竞争优势。他们可以更有效地描述他们的硬件，更快速地验证它，并更容易地在衍生芯片中重用它。

实践中的虚拟平台

硬件的通用模型现在可以更早地作为虚拟平台的一部分使用，因此可以更快地解决硬件/软件交互问题。这种通用模型可以作为虚拟平台中更大系统的一部分在公司内部的聚合开发场景中交付，也可以在分散的世界中跨公司交付。

系统概念首先被描述为 SystemC TLM 虚拟原型。在 Cadence 流程中，虚拟系统平台使用此虚拟原型在此硬件模型上运行软件。同时，硬件设计团队将完善 TLM，为 C-to-Silicon Compiler 高级综合添加硬件架构细节，这是实现硅片的开始。

如果在测试过程中发现错误，虚拟系统平台将与 Incisive Verification Platform 集成，以便可以在软件和硬件上进行调试。这意味着无需繁琐的固件补丁即可从源头解决问题。随着硬件实施过程的进展，更详细的 RTL 模型可用于在验证计算平台中创建硬件仿真模型或在快速原型开发平台中创建 FPGA 原型。

整个过程是一系列连续的改进，从快速 TLM 模型开始，在可用时添加更多硬件细节，同时保持足够快的运行时以进行软件开发。这最终使软件和硬件团队——甚至跨越公司边界——拥有一个通用模型，可以实现更早的通信和持续的同步。这是与当今消费市场所需的创新和交付计划保持同步所需的协作类型。只有硬件团队发展其设计和验证方法以包含 SystemC TLM，才能实现这一目标。

审核编辑：郭婷