EEPW论坛

没有人说过 FPGA 设计很容易。然而，与开发 ASIC 和定制芯片的同行相比，可编程设备的设计人员长期以来在验证方面具有主要优势。当然，这种优势在于可以修复在 FPGA 验证过程中遗漏的设计错误，而无需重新制造芯片。不久前，很多FPGA设计者根本没有进行验证；他们可以直接“吹气就走”到培养实验室。

在实验室中，FPGA 被直接插入到最终系统的原型中。该团队专注于产品验证，在产品最终应用的上下文中提出硬件和软件（如果需要）。在实验室中发现任何漏掉的设计错误都可能很乏味。一旦找到一个，重新编程 FPGA 并继续启动是一件简单的事情。只要错误的数量保持相当小，这个串行过程就可以很好地工作。

随着可编程芯片变得越来越大和越来越复杂，实验室中发现的错误数量和发现它们所需的时间都显着增加。为了保持合理的启动计划，FPGA 开发团队意识到他们必须在进入实验室之前更好地验证他们的设计。作为回应，FPGA 验证团队应运而生，并开始看起来很像他们的 ASIC 表亲。

寄存器传输级 （RTL） 仿真仍然是所有芯片验证的核心，FPGA 团队从简单的手写矢量文件转移到仿真中更加自动化的测试台。一些采用了通用验证方法 （UVM） 标准的约束随机功能。用于检查时钟域和低功耗结构的静态分析工具开始出现，一些高级 FPGA 团队甚至开始使用形式分析。

更复杂的验证方法变得越来越普遍，以减少在启动实验室中花费的时间并加快最终产品的上市时间。然而，FPGA 设计人员仍然拥有能够重新编程设备以修复通过验证并在实验室中发现的错误的后备位置。随着 FPGA 片上系统 （SoC） 设计的出现，即使这种转义机制也越来越不可用。

FPGA SoC 验证的挑战

图 1 显示了一个具有代表性的 FPGA SoC，基于多个供应商公开发布的框图。芯片的很大一部分仍然是可用于最终产品及其应用的传统可编程逻辑。但是，包含一个硬核处理器子系统以提供 SoC 级电源。该子系统通常包括至少两个嵌入式处理器、片上存储器以及各种内部和外部接口。

图 1：除了传统的用户可编程逻辑之外，当今的 FPGA SoC 还包含多个处理器和标准接口。

FPGA 团队在使用此类复杂芯片进入 SoC 时代时遇到验证障碍的原因有三个。首先是重新编译和重新编程巨大的 FPGA 的时间。一旦发现错误并更改源 RTL 代码，在高端个人计算机上创建新图像的过程可能需要一整天。然后必须将图像下载到 FPGA，这可能需要几个小时。

其次，实验室调试过程也是使 FPGA 设计功能正确所需时间的一个重要因素。一旦将芯片安装到真正的目标系统中，就很难操纵输入或读取输出。协议分析仪可用于标准总线，但几乎总是有带有自定义或 ad hoc 接口的 FPGA 端口。一个团队在实验室中花费数天甚至数周的时间试图追踪一个难以捉摸的错误的来源并不罕见。

根据 FPGA 架构，团队可能必须进行多次编译/程序传递，以带出内部信号以进行调试。一旦发现错误，在验证错误是否已得到解决之前，可能需要更多的编译/程序通过来尝试可能的修复。通常，团队会在重新编程之前验证错误并在模拟中测试修复。这是一个聪明的举动，但会增加调试周期的时间。

这样做的主要结果是，必须有某种形式的软件才能在启动实验室的 FPGA SoC 处理器上运行。在设计 FPGA 时，最终产品软件通常还没有准备好，因此开发团队经常不得不创建特殊的诊断软件来测试设备。这给项目增加了资源负担，因为该软件必须与硬件设计并行开发。

手写诊断代码的开发既耗时又昂贵，难以维护，并且功能有限。人类不擅长并行思考，因此诊断很少会在设计中强调并发性、跨多个线程或多个处理器进行协调，或者将块串在一起形成现实的最终用户应用程序。结果是设计错误可能潜伏在 FPGA 中，直到在最终系统集成时发现，甚至被客户发现。

来自非 FPGA SoC 领域的解决方案

为了解决诊断软件代码的困境，FPGA SoC 开发人员必须从 ASIC 和定制芯片验证这本书中翻开新的一页。他们可以从自动生成多线程、多处理器、自我验证 C 测试的方法中受益，这些测试强调 SoC 中的系统级行为。这些测试可以加载到嵌入式处理器中并在模拟或硬件加速中运行。图 2 显示了此方法的工作原理。

图 2：多线程、多处理器、自验证 C 测试用例可以从基于图形的 SoC 场景模型自动生成。

测试用例生成器的来源是一个基于图形的场景模型，它捕获了预期的芯片行为和验证计划。生成器分析图表以确定设计的功能，然后生成一组测试用例，使用嵌入式处理器验证这些功能。C 代码被编译并下载到处理器中，并在模拟或模拟加速中运行，就像任何其他软件一样。

这些测试用例旨在强调 FPGA 设计，在多个处理器上并行运行多个线程以测试并发功能。由于某些测试用例将从 FPGA 输入中提取数据或将数据发送到其输出，因此这种方法在测试台中包含一个运行时组件，用于协调处理器和 I/O 活动。验证团队可以轻松连接到标准 UVM 验证组件 （VC）。

创建场景模型很简单，因为它们反映了设计中的数据流并且类似于 SoC 框图。这种初始投资能够生成几乎无限的测试用例以在模拟中运行。如果有合适的 I/O 引脚连接可用，甚至可以在编程的 FPGA 上运行这些测试用例。

这种生成方法为 FPGA 开发人员提供了对传统“烧毁和搅动”重新编程周期的巨大改进，因为在实验室中一个一个地发现了错误。自动化测试用例可以节省开发时间、提供更彻底的验证并节省资源，因为嵌入式程序员不必开发一次性诊断。结果是更快、更可预测的 FPGA 开发计划，即使是最复杂的 SoC 设计也是如此。