一、验证概述：什么是仿真验证、验证在芯片开发流程中的位置、验证的挑战与目标

仿真验证，说白了就是给芯片设计“跑个软件”。

你写好了RTL代码，但能不能正常工作？不知道。那就搭一个测试环境，给设计输入各种激励信号，然后看输出对不对。这就是仿真验证。

我个人习惯把仿真验证分成三个层次：

举个例子，你写了一个UART模块。仿真验证就是：给它一串数据，看它能不能正确发送出去，再收回来。如果波形对得上，那基本就稳了。

核心要点：仿真验证不是“跑一次就完事”，而是反复迭代、不断覆盖各种场景的过程。

芯片开发流程，我一般画成下面这张图。你想想看，验证几乎贯穿了所有环节。

从这张图你能看到，验证不是最后才做的事。需求阶段就要想“怎么测”，架构阶段就要搭验证方案。我记得有一次项目，架构师拍脑袋定了个接口协议，结果验证时发现根本没法覆盖所有场景。最后只能回头改架构，白白浪费了两周。

我的建议：验证工程师最好从项目第一天就介入。越早参与，越能避免后期的大坑。

做验证这么多年，我总结了几大挑战。嗯，每一个都是血泪教训。

挑战	具体表现	我曾经踩过的坑
覆盖率难保证	功能点太多，总有测不到的角落	有一次漏测了FIFO满标志的边界情况，流片回来直接挂
仿真速度慢	跑一次系统级仿真可能要几天	等仿真结果等到怀疑人生，后来学会了用随机测试加速
调试困难	出问题不知道是RTL错还是验证环境错	花了三天查一个bug，最后发现是验证环境的时钟没对齐
需求变更	设计改了，验证环境也得跟着改	最夸张的一次，一周内改了三次接口协议

为什么会这样？说白了，芯片设计越来越复杂。一个SoC可能有几十个IP，上亿个门。你不可能手动测完所有情况。所以验证方法学才这么重要——SystemVerilog、UVM、形式化验证，都是为了解决这些问题。

注意：不要以为仿真通过就万事大吉。仿真只能证明“有bug”，不能证明“没bug”。覆盖率不到90%的项目，我建议不要轻易流片。

验证的目标其实就一句话：在流片前，尽可能多地发现并修复bug。

具体来说，我把它拆成四个层次：

你想想看，流一次片少说几十万，多则上千万。如果回来发现不能用，那损失就大了。所以验证的目标不是“完美”，而是“足够好”——在时间和成本允许的范围内，把风险降到最低。

记住：验证不是证明设计是对的，而是证明设计没有错。这两句话，意义完全不同。

我个人习惯在项目开始时先列一个“验证清单”，把所有的功能点、边界条件、异常场景都写下来。然后每测完一项就打勾。这样心里有数，也知道还差什么。

好了，这一章就聊这么多。验证是个大话题，后面我们会一步步深入。你先把这些基础概念消化掉，后面讲UVM、覆盖率、随机测试时，你就能理解为什么需要这些东西了。

一个小练习：找一个你熟悉的模块（比如计数器、FIFO），试着列出它的验证清单。看看你能想到多少个测试点。这比光看书有用得多。

可可精品资料库