利用硬件仿真工具进行验证和确认-电子发烧友网

任何学科的设计——电子、机械、航空航天等——都始于一个规范，该规范捕捉最终产品应该做什么，并从根本上推动整个开发周期。在开发的早期阶段，第一个任务使用规范来验证正在开发的设计是否正常工作并且没有错误。然后，当设计的所有部分都组装成一个完整的系统时，第二个任务使用规范来确定系统是否也按照预期的方式运行。

这两个任务称为设计验证（任务 1）和设计验证（任务 2）。有时，错误地，这两个术语可以互换使用。虽然相似，但这两项任务的目标却截然不同。

验证：我们构建的系统正确吗？

验证：我们是否在构建正确的系统？

在片上系统（SoC）设计过程中，使用基于软件的硬件描述语言（HDL）仿真方法进行设计验证。相反，设计验证是在实际使用环境中测试的整个系统的原型上进行的。

不幸的是，HDL 仿真执行速度并没有跟上设备的复杂性，尽管它具有所有优点：易用性、灵活性和快速的设计迭代时间。当今的许多设计，例如具有 1，024 个端口的互联网路由器或高清视频处理器，都需要大量的验证序列，即使在最快的 PC 上模拟也需要很多年。这些序列源于运行长的、连续的串行协议流或处理复杂的嵌入式软件以全面验证 SoC 或系统设计的需要。

此外，近年来，在硅可用之前开始软件验证已变得很重要。为了实现这一目标，引入了一种称为虚拟原型的新型方法。虽然其中一些工具已经实现了启动软件开发的目标，但它们只处理不需要准确表示底层硬件的应用程序。在测试嵌入式软件（例如固件、设备驱动程序、操作系统和诊断程序）的交互时，它们会出现不足。对于此测试，嵌入式软件开发人员依靠准确的硬件模型来验证他们的代码。

相比之下，硬件设计人员需要一套相当完整的软件来在系统验证期间全面测试他们的 SoC。古老的基于 FPGA 电路板的系统原型设计方法提供了设计的准确表示，但不太适合硬件调试。因此，只要设计适合少数 FPGA，FPGA 原型对软件开发团队的吸引力就更大。

最终，软件和硬件组需要在一个通用模型上走到一起，以验证完整的硬件和嵌入式软件。对于大多数使用传统开发周期的人来说，第一个完整的模型是实际的硅片（图 1）。

【图1 | 在传统的开发周期中，第一个完整的模型是硅。］

等待实际硅片的问题在于它在设计周期中为时已晚。由于嵌入式软件在硅片之前无法在完整、准确的系统模型的上下文中得到充分验证，因此在硅片中发现问题的可能性增加。它们可以在软件或软件和硬件中找到，通常会迫使额外的芯片重新设计和代码修订。重新设计和代码修订都具有成本和上市时间的影响。避免这些影响所需要的是一种提供统一解决方案的方法，以在第一块芯片之前实现硬件/软件验证和确认。

最新一代的硬件仿真器实现了这一点。它们提供几乎无限的容量，多达数十亿个门，并以 1 兆赫或更多兆赫的速度验证被测设计（DUT），提供比 FPGA 原型系统更好的硬件调试。它们易于使用，可以更快地编译 DUT，并允许从世界任何地方进行 24/7 远程访问。在仿真器上运行的新软件应用程序使其能够支持多种类型的验证，从低功耗分析和验证到测试设计（DFT）逻辑验证。仿真器还为从网络到处理器/图形、存储等各种细分市场带来了独特的技术。

在设计周期的早期，仿真器用于与仿真器和 SystemVerilog 进行协同仿真，以在组装完整的 SoC 设计之前验证知识产权（IP）模块和子系统。在设计周期的后期，仿真器用于验证整个系统并执行嵌入式软件验证。

它们在相同的设计表示上为硬件和软件工程师提供完整的硬件和软件调试功能。这让硬件和软件开发团队能够以前所未有的方式协作并修复集成问题（图 2）。