验证本质上也是一个“证伪”的过程。从流程到工具FPGA 验证工程师的终极目的只有一个发现所有问题或者证明在既定应用场景下没有问题确保设计在仿真和上板后功能、时序都符合预期。在实际项目中验证所占的精力远超很多人的想象· 从时间比例来说一个中大型 FPGA 项目中验证和调试往往占到整个开发周期的一半以上。· 从风险角度来说大多数延期都不是因为“写不出来”而是因为“调不干净”。下面就按工程实际流程说一说 FPGA 验证到底在做什么。理解 DUT验证的第一步永远是理解设计本身。包括但不限于模块架构、数据流向、接口协议、时钟域划分、复位策略、资源预算、约束目标等。Spec 可能是 Word 文档也可能是接口说明书或时序图。对设计理解得越深入后续验证越有针对性。制定验证计划对项目负责人来说验证计划不仅包含测试策略还包括进度安排、资源分配和风险评估。对工程师而言更核心的是功能测试点如何拆分仿真与上板验证如何分工时序验证目标是什么是否需要覆盖异常路径在搭建环境之前验证计划通常会进行一次 review。制定验证策略根据项目规模通常会划分验证层次module 级子系统级顶层系统级不同层次的验证目标不同。模块级关注功能闭环系统级关注接口联动和数据通路完整性。搭建验证平台根据验证方案搭建仿真环境。主流做法是基于 SystemVerilog 编写 testbench复杂项目会采用 UVM 框架。部分工程会用 Python 脚本生成激励或批量回归。常见仿真工具包括VCSXcelium波形查看与调试通常使用Verdi环境搭建完成后会先进行冒烟测试确认基本路径可跑通。提取测试点测试点是整个验证工作的核心。有的团队称为 Test Point有的称为验证目标列表。要求是完整无歧义低耦合测试点通常以表格形式列出并随着项目推进不断补充和修正。理想情况下拿到 DUT 和测试点列表后就可以开始编写 testcase。执行验证根据测试点编写 testcase在仿真平台上反复执行。这个阶段是一个持续迭代的过程编写激励观察波形定位问题修改 RTL 或约束回归测试除了功能仿真外还会进行时序仿真静态时序分析约束检查时序分析通常依赖综合和实现工具生成的报告例如在 Vivado 中查看 timing summary。收集覆盖率FPGA 项目同样需要关注覆盖率。包括代码覆盖率功能覆盖率通过覆盖率报告判断是否存在未触达的逻辑分支再补充用例。完成验证报告验证报告通常包含测试点完成情况覆盖率统计已知问题列表风险说明报告不仅是对当前版本的总结也是后续维护的重要依据。——需要强调的是FPGA 验证并不是某个阶段的工作而是贯穿整个开发周期。从 RTL 编写到上板调试只要发现问题就需要回到验证流程重新确认。很多新人以为验证只是“跑仿真”。但真正的验证是既能在系统层面理解数据流也能在信号级别定位一个错误翻转。两三年经验和十年经验的差距往往就体现在这些细节上。FPGA 项目不像一次性流片那样不可逆但调试成本同样真实存在。每一次细节打磨都是工程能力的积累。验证从来是一个细节为王的岗位。