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