电动汽车的换电模式

在当今竞争激烈的形势下，使富含嵌入式软件的复杂电子设备更快面市，但是同时确保其更便宜更可靠，是一种相当冒险的做法。

未经彻底测试的硬件设计不可避免地导致返工，增加设计成本并延长布局流程的网表交付时间，并最终延迟上市时间目标，对收益源造成破坏性影响。推迟嵌入式软件的测试也潜藏有错过上市机遇的可能，会带来更严重的后果。

正因为如此，项目周期的验证部分极大地占用计划时间变成了很常见的事情。其中的根本原因，在于跟踪和消除错误极为不易，尤其是在片上系统 (SoC) 的软件内容以每年约 200% 的速度增长的情况下。与此相反，设计的硬件部分仅增长约 50%。

硬件仿真作为系统验证的基础

虽然虚拟原型和现场可编程门阵列 (FPGA) 原型在早期嵌入式软件测试上已受到关注，但对于软件和硬件的集成并无助益。前者缺乏追踪硬件错误所需的硬件精确性，而对于尽快消除错误所需的硬件调试，后者能力有限。

因此，开发团队和项目经理已转而采用硬件仿真作为其验证策略的基础。硬件仿真是一种多功能验证工具，有许多相关优势，包括软硬件协同验证或测试硬件和软件集成的功能。它已受到软件开发者的注意，因为这是能够确保嵌入式系统软件通过底层硬件正常工作的唯一验证工具。对于致力于调试复杂 SoC 设计的硬件工程师来说，这也是值得注意的，因为工程师可以凭借该方法追踪硬件内的软件错误或软件行为中的硬件错误。硬件仿真的其他优势包括快速汇编功能、软件验证、全面的设计调试和可扩展性，可满足包括数十亿应用程序特定集成电路 (ASIC) 门的设计。此外，它能够以验证嵌入式软件和执行系统验证必需的高速率来处理数十亿验证周期（图 1）。

过去，硬件调试和测试是项目周期验证部分的唯一工作，此作业由硬件描述语言 (HDL) 测试平台驱动的逻辑软件仿真进行管理。传统的大箱式硬件仿真只用于最大型的设计。很多开发团队已采用正式验证对软件仿真进行补充，以增加基础覆盖范围并确保不遗漏特殊用例。但是，只有硬件仿真可以在比较可行的时间内完成 SoC 设计的全部验证任务，并缓解与基于事件的软件仿真相关的运行问题。

都是软件内容的问题

SoC 的软件内容使协同验证成为验证策略中一个非常重要的部分，因为它可以在投片前确认一个嵌入式 SoC 的硬件和软件部分同时得到验证且正确交互。

过去，如果设计流片后发生硬件问题，软件开发者必须尽其所能设法围绕问题进行编码。在 SoC 完成之前验证软件，设计团队可以在进入硅片阶段之前解决硬件问题。如前所述，硬件仿真检查用于确保嵌入式软件根据规范在硬件上运行。

过去使用各种调试引擎进行软件调试。每种引擎有一个核心，充分利用硬件对处理器内部工作的可视性和控制功能。虽然提供了部分调试功能，但由于处理器提供的接入方式，诊断问题的能力受限。此外，由于传统软件调试通常发生在实际系统中，软件开发者以目标系统速度在实际硬件上执行实际代码。这样他们可以通过大量代码迅速找到错误的程序。

这些传统技术在调试 SoC 时无效，因为没有实际硬件，无法以真实系统速度执行代码。一般来说，只要执行代码且软件模拟器提供所有硬件可视性，即可仿真硬件。但问题是速度 - 调试代码是很慢的一种方法。

例如，如果 SoC 设计为在 Linux 上运行程序，软件开发者必须以数十亿时钟周期完成 Linux 启动，软件才能开始执行。粗略估计这会以约 10 赫兹 (Hz) 的典型软件仿真速度花费 28 年以上完成 Linux 启动。

不管调试硬件还是软件，传统硬件和软件调试工具都无法得知彼此的任何情况。如果采用复杂的大型 SoC 设计，尝试找到问题时独立完成两种调试是效率低下的。

两者结合是最为理想的方法，这样硬件仿真就可以节约时间。SoC 硬件通常在 FPGA 或其他可编程器件中实施，速度更快。在此设置中，根据运行速度，最快可以 15 分钟的速度完成 Linux 启动。硬件仿真可提供与硬件调试器相似的断点和波形控制及可视性。

确认 SoC 设计按预期工作

硬件仿真以其高性能（这是软件需求推动的越来越重要的需求）在一众验证工具中脱颖而出。它能够确认 SoC 设计按计划工作，并适于处理大到十亿 ASIC 等效门的复杂设计，且每月可完成超过一万亿验证周期。即使是这样，现阶段使用硬件仿真进行彻底详尽的功能验证仍然是可用的最具成本效益且有效的调试方法（图 2）。

引入事务级建模 (TLM) 和事务处理器可用性可将硬件仿真转为一系列垂直市场的虚拟平台测试环境。事务处理器作为验证知识产权 (IP) 组合的一部分，是外设功能或协