应对百万门级系统级芯片验证挑战的可扩展解决方案

块层次上，设计人员的关注重点是功能和时序的细节情况，这样他们就能够保证这些模块符合技术规范，不存在明显 问题。其目标是尽可能多地查找错误，因为这在设计流程中是查找这些错误的最廉价和最快速阶段。模拟和数字交互作用在模块层次上进行验证。功能和代码得到全 面演练，验证移交应考虑在这一阶段进行。由于HDL仿真技术易于使用且具纠错能力，因而成为理想的工具。

模拟/混合信号模 块：系统级芯片设计的能力在不断提升，模拟和混合信号元器件不断加入其中，因此要求模拟环境能够具备与数字逻辑相同的、必需的验证功能。与模拟HDL行为 模拟以及模拟原始模块的Spice模拟顺利实现接口，允许数字和模拟元器件的模拟工作实现同步，并能够在相同的纠错环境中查看。

子系统层次：所有模块均已验证后，随后进行模块集成，涉及对各模块组或整个芯片进行集成。在子系统阶段，模块间通信、控 制、时序和协议对功能而言具有重要意义；因此，检查协议或应用断言以验证总线处理程序的工具就能发挥作用。硬件断言或仿真可以运用HDL、C或 SystemC 以及Verisity等其它高层次测试平台语言布署在这一阶段。

系统级芯片层次：系统级芯片层次验证涉及各模块与后端流程的其余部分进一步集成，其中包括设计的物理实现。在设计人员将较小模块集成进入越来越大模块的过程中，需要模拟的内容日益增多，测试时间日益延长，并且需要开展更多模拟来验证设计。

这对多种验证方法提出了要求，比如芯片和系统功能测试。它还要求验证布图、时钟树或DFT插入会否引入意外更改。等效性检查工具可以验证整个大规模设计，并在每次修改设计后迅速纠错，无需再运行众多漫长的模拟。

除了等效性检查之外，我们还可能在这一流程中使用硬件加速仿真器和多CPU并行仿真，以确保更改设计期间没有造成任何破坏。 多CPU并行仿真将会缩短测试时间，获得非常高的吞吐能力。就较长时间测试而言，出于验证大规模芯片设计的能力考虑，硬件仿真是我们的首选方法。硬件加速 仿真器和多CPU并行仿真是互为补充的解决方案，可以在不同的环境中得到有效使用。

绝大多数系统级芯片器件都包含必须验证的嵌入式软件，其中包括应用代码、实时操作系统(RTOS)、器件驱动程序、硬件诊断以及启动ROM代码。功能仍然重要，但吞吐能力以及其它系统级事宜可能也需要获得验证。运行大量软件通常意味着长时间模拟作业。

硬件/软件协同仿真解决方案提供降低总体负担的途径，同时也提供高效能纠错和分析环境。即便就较长运行时间而言，该设计可能也需要部分或全部移入硬件解决方案之中，但应该保留相同或相当的纠错环境，这样就可以最大限度减少上述执行环境中的迁移。

改进的纠错解决方案

为支持可扩展验证解决方案，纠错工具必须实现集成，在各个抽象层次上保持前后一致，在各个可扩展性工具之间保持一致。其目标 是加快速度发现错误、跟踪捕获故障原因、修复故障，并最大限度缩短反馈时间，将反复回路减少到最低限度。目前，无论是设计团队还是验证团队，都将超过 50%的时间用在纠错上，因此这一领域的改进可能对缩短产品上市时间产生重大影响。

在系统层次上，由于抽象层次混杂，系统内部存在的不同语义，因此纠错工作变得更加复杂。在异类环境，比如硬件和软件或数字 和模拟环境中，挑战就会更为严峻。因此，信息不仅必须可用，而且必须在正确的语义背景下可用。同样，利用多层次抽象，信息也必须在必需的抽象层次上可用。

例如，对软件纠错时，有关软件程序执行的所有信息都包含在硬件记忆体中，但没有任何东西是随时可用的。了解变量放置在何处 正是解决方案的发端。它还必须确定信息保存在哪个芯片之中以及芯片中的相对位置，假定它并非缓存或寄存器。在许多情况下，即使在这种时候，数据还可能因为 数据或地址交叉原因而未按逻辑排序。因此，获得变量值就可能非常复杂。

为了化解这些挑战，新的纠错方法正在不断推广。例如断言或检查器，尽管其用途并未得到完全理解。另一个容易引起混淆的问题 则涉及覆盖率问题。许多工程师并未认识到，满足代码覆盖率标准并不意味着系统已经得到适当验证。同样，我们还必须使用功能覆盖率或断言覆盖率等其它标准来 确认该设计已经得到完全验证。

今天，绝大多数工程师都在创建激励源，并将其馈送进入执行引擎之中，这样他们就可以对产生的响应进行分析(图4)。在许多 情况下，他们对照参照模型对该设计的某项实施的波