FPGA 验证的主要工作流程和验证工具是什么？

验证本质上也是一个“证伪”的过程。

从流程到工具，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 项目不像一次性流片那样不可逆，但调试成本同样真实存在。
每一次细节打磨，都是工程能力的积累。

验证，从来是一个细节为王的岗位。