一、验证场景设计概述
什么是验证场景
验证场景，说白了就是「你要测什么、怎么测、测到什么程度才算完」。
我刚开始做验证那会儿，总觉得验证就是写几个 testcase，跑一跑波形，看看对不对。后来被 mentor 骂了一顿才明白——验证场景才是整个验证工作的灵魂。没有好的场景设计，你写再多代码也是白搭。
举个例子。你要验证一个 UART 模块。最简单的场景就是发一个字节，收一个字节。但实际工作中呢？
- 波特率不匹配怎么办？
- 数据位、校验位配置错了会怎样？
- 连续发 1000 个字节，FIFO 会不会溢出？
- 接收端还没准备好，发送端就开始发数据了——这种情况你考虑过吗？
这些，都是验证场景要覆盖的内容。
验证场景的定义：验证场景是对芯片功能、性能、异常处理等行为的完整描述。它包含输入激励、期望输出、时序约束、配置参数等要素。一个完整的验证场景，应该能回答三个问题：
- 测什么功能点？
- 用什么方式测？
- 怎么判断结果对不对？
验证场景在芯片开发中的位置
芯片开发流程，我习惯把它分成三个阶段：
| 阶段 | 主要工作 | 验证场景的作用 |
|---|---|---|
| 设计阶段 | 架构设计、RTL 编码 | 验证场景指导设计人员理解功能需求 |
| 验证阶段 | 仿真、形式验证、FPGA 原型 | 验证场景是测试用例的蓝图 |
| 流片后阶段 | ATE 测试、系统测试 | 验证场景转化为 ATE 测试向量 |
嗯，这里要注意一点。很多团队把验证场景只当成验证工程师的事。我个人觉得不对。验证场景应该从设计阶段就开始构思。我在一个项目中遇到过这样的情况：设计人员写了一个很复杂的 DMA 控制器，但验证场景没覆盖到「多个通道同时请求」的情况。结果流片回来，一测就挂。你说这锅该谁背？
所以我的建议是：验证场景的设计，设计人员和验证人员要一起参与。你想想看，设计人员最清楚模块的边界在哪里，验证人员最清楚怎么测才能暴露问题。两者结合，才能写出高质量的验证场景。
验证场景的层次结构
验证场景不是一层不变的。它有不同的层次，对应不同的验证目标。
我一般把验证场景分成三个层次：
- 单元级验证场景：针对单个模块。比如验证一个加法器、一个 FIFO、一个状态机。这个层次的场景，重点在功能正确性和接口时序。
- 子系统级验证场景：针对多个模块的组合。比如验证 CPU 核和 Cache 之间的交互。这个层次的场景，重点在模块间的握手协议和数据一致性。
- 系统级验证场景：针对整个芯片。比如验证 SoC 启动流程、DDR 初始化、外设枚举。这个层次的场景，重点在系统行为和性能指标。
我的经验：很多新手喜欢一上来就写系统级场景。其实这是个大坑。系统级场景跑一次要几个小时，调试起来特别痛苦。我建议先从单元级场景入手，把每个模块测透了，再往上走。这叫「自底向上」的验证策略。
这三个层次的关系，我用一张图来说明：
从这张图你能看出来，越往上层，验证场景越复杂，覆盖的功能点也越多。但反过来，越往下层，调试起来越容易。所以我的建议是：
- 单元级场景要「全」——把每个模块的每个功能点都测到
- 子系统级场景要「准」——重点测模块间的交互
- 系统级场景要「稳」——保证芯片能正常工作就行
避坑指南：我曾经在一个项目中，系统级场景跑了两周才发现一个 bug。最后定位到是某个模块的复位时序有问题。如果当时单元级场景覆盖了复位时序，这个 bug 半天就能发现。所以千万别跳过单元级验证，直接去搞系统级。这个坑我替你踩过了。
好了，关于验证场景的概述就讲这么多。记住一句话：验证场景设计得好不好，直接决定了你的芯片能不能一次流片成功。这不是夸张，是我这些年用真金白银换来的教训。
可可精品资料库