2、验证计划制定：需求分析、验证目标定义、验证范围界定、资源与时间规划

验证计划，说白了就是整个验证工程的「作战地图」。

我见过太多团队，上来就写 testbench、跑仿真，结果跑到一半发现需求变了，或者某个功能压根没人测。嗯，这就是没做计划的下场。今天我们就聊聊，一份靠谱的验证计划该怎么写。

2.1 需求分析：搞清楚你要验证什么

需求分析是第一步，也是最容易被忽视的一步。我个人习惯，拿到芯片 spec 后，先不急着看细节，而是问三个问题：

• 这个芯片用在什么场景？—— 消费电子？车规？工业控制？场景不同，验证重点完全不同。
• 最关键的功能是什么？—— 比如 AI 芯片，算力、精度、功耗，哪个是核心卖点？
• 有没有历史遗留问题？—— 上一代芯片哪里出过 bug？这次必须重点覆盖。

我在项目中遇到过一件事：某次做 NPU 验证，需求文档里写「支持 INT8 量化推理」。我们按常规测了精度，结果客户反馈说实际跑模型时性能掉了一半。后来才发现，需求里没写「支持连续推理」—— 说白了，芯片散热跟不上，跑几分钟就降频了。从那以后，我每次做需求分析都会追问一句：「有没有隐含的性能约束？」

2.2 验证目标定义：到什么程度算「够了」

需求分析完了，接下来要定目标。你想想看，验证是永远做不完的 —— 你总能找到更多 corner case。所以必须明确：到什么程度，我们可以说「验证完成了」？

我一般把验证目标分成三个层次：

举个例子。有一次我们验证 AI 加速器，L1 目标定的是「所有算子功能正确」。结果跑完 L1 发现，卷积没问题，但池化层在特定尺寸下会算错。这就是 L1 的价值 —— 先把功能兜住。

2.3 验证范围界定：哪些测，哪些不测

这个环节最容易吵架。架构师说「这个必须测」，设计说「那个不用测」，项目经理说「时间不够了」。

我的做法是：把验证范围画成一个矩阵。

为什么要画这个矩阵？因为资源永远是有限的。你不可能什么都测，必须做取舍。我曾经在一个项目里，坚持要测「所有接口的电气特性」，结果验证周期拖了两个月。后来学乖了 —— 对于成熟 IP 的接口，只做抽测；对于新设计的核心模块，才做全覆盖。

2.4 资源与时间规划：人、机、时

最后一步，也是最现实的一步：算清楚你要多少人、多少机器、多少时间。

我一般用这个公式来估算验证工作量：

验证工作量 = 功能点数 × 复杂度系数 × 复用率

其中：

• 功能点数：从需求分析里数出来的，比如「支持 10 种算子」就是 10 个点
• 复杂度系数：简单模块 1.0，中等 1.5，复杂（比如 AI 核）2.0
• 复用率：如果之前有现成的验证环境，可以打 0.5~0.7 折

举个例子。一个 AI 加速器，有 20 个算子，复杂度系数 2.0，复用率 0.6（之前做过类似项目）。那么：

工作量 = 20 × 2.0 × 0.6 = 24 人月

如果团队有 4 个人，那就是 6 个月。嗯，这个数字和实际项目经验基本吻合。

时间规划上，我习惯用「里程碑倒推法」：

为什么要倒推？因为流片日期是死的。你从流片日往前推，就知道最晚什么时候必须完成验证。中间留出 buffer —— 我一般留 20% 的缓冲时间，专门处理那些「没想到的坑」。

好了，验证计划这部分就聊到这儿。下一章我们聊聊验证环境的搭建 —— 那是真正动手干活的地方。

公众号:蓝海资料掘金营，微信deep3321