如何用硬件仿真使嵌入式系统更加的可靠实用

（文章来源：中国电工仪器仪表信息网）

在当今竞争激烈的形势下，使富含嵌入式软件的复杂电子设备更快面市，但是同时确保其更便宜更可靠，是一种相当冒险的做法。未经彻底测试的硬件设计不可避免地导致返工，增加设计成本并延长布局流程的网表交付时间，并最终延迟上市时间目标，对收益源造成破坏性影响。推迟嵌入式软件的测试也潜藏有错过上市机遇的可能，会带来更严重的后果。

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

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

SoC 的软件内容使协同验证成为验证策略中一个非常重要的部分，因为它可以在投片前确认一个嵌入式 SoC 的硬件和软件部分同时得到验证且正确交互。过去，如果设计流片后发生硬件问题，软件开发者必须尽其所能设法围绕问题进行编码。在 SoC 完成之前验证软件，设计团队可以在进入硅片阶段之前解决硬件问题。如前所述，硬件仿真检查用于确保嵌入式软件根据规范在硬件上运行。

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

这些传统技术在调试 SoC 时无效，因为没有实际硬件，无法以真实系统速度执行代码。一般来说，只要执行代码且软件模拟器提供所有硬件可视性，即可仿真硬件。但问题是速度 - 调试代码是很慢的一种方法。例如，如果 SoC 设计为在 Linux 上运行程序，软件开发者必须以数十亿时钟周期完成 Linux 启动，软件才能开始执行。粗略估计这会以约 10 赫兹 （Hz） 的典型软件仿真速度花费 28 年以上完成 Linux 启动。

不管调试硬件还是软件，传统硬件和软件调试工具都无法得知彼此的任何情况。如果采用复杂的大型 SoC 设计，尝试找到问题时独立完成两种调试是效率低下的。两者结合是最为理想的方法，这样硬件仿真就可以节约时间。SoC 硬件通常在 FPGA 或其他可编程器件中实施，速度更快。在此设置中，根据运行速度，最快可以 15 分钟的速度完成 Linux 启动。硬件仿真可提供与硬件调试器相似的断点和波形控制及可视性。

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

引入事务级建模 （TLM） 和事务处理器可用性可将硬件仿真转为一系列垂直市场的虚拟平台测试环境。事务处理器作为验证知识产权 （IP） 组合的一部分，是外设功能或协议的一种高级抽象模型。事务处理器通常作为现成 IP 提供，可用于各种不同的协议。典型的事务处理器通常包括 PCIe、USB、FireWire、Ethernet、Digital Video、RGB、HDMI、I2C、UART 和 JTAG 器件。

先前，硬件设计独立于要在芯片上执行的软件的开发。但今非昔比，由于 SoC 处理器数量翻倍且每代产品包含两倍的软件内容，软件问题成为开发团队和项目经理优先考虑的对象。现在，开发团队证实预期软件在硬件平台正常工作后，SoC 才算完整。

SoC 是一个全面的嵌入式系统，需要进行硬件仿真来验证其能否正常工作。通过硬件仿真，开发团队可以更策略性地进行计划，并根据多个抽象层面实施调试方法。他们可以同时在硬件和嵌入式软件之间追踪错误，确定问题所在。通过具有更高性价比且有效的方式，他们在这个过程中节约了时间，大幅降低错过上市机遇的风险。

（责任编辑：fqj）