1. 场景验证概述
大家好，我是老李，在芯片验证这行摸爬滚打了十几年。今天咱们开始聊《仿真验证场景搭建方法实战课程》的第一章——场景验证概述。
说实话，我刚入行那会儿，对「场景验证」这个概念也是一头雾水。那时候大家管验证叫「跑仿真」，觉得只要把波形跑出来、覆盖率凑够就完事了。后来踩了不少坑，才慢慢明白——验证的核心，其实是场景。
什么是仿真验证场景
先问大家一个问题：你写一个 testbench，给 DUT 灌激励、收响应，这算不算验证？
算，但不够。
仿真验证场景，说白了就是一组有意义的输入条件、配置状态和时序关系的组合。它不只是「给个时钟、拉高复位、发几个包」这么简单。
我个人的理解是：场景 = 激励 + 配置 + 时序 + 预期行为。
举个例子。你验证一个 SPI 控制器，只测「主机发 0xAA，从机回 0x55」——这叫功能点，不叫场景。真正的场景是什么？是「当 SPI 时钟极性 CPOL=1、相位 CPHA=0 时，主机连续发送 8 个字节，中间被更高优先级的中断打断，然后恢复传输」——这才叫场景。
验证在芯片开发流程中的位置
芯片开发流程，大家应该都熟悉：
- 需求定义 → 架构设计 → RTL 编码 → 验证 → 后端实现 → 流片 → 测试
验证在哪个位置？
嗯，它其实贯穿了整个流程。从架构阶段开始，验证就要介入。我见过太多项目，RTL 写完了才找验证团队，结果发现架构本身就有缺陷——那叫一个痛苦。
下面这张图是我自己整理的验证在芯片开发中的位置关系：
看到了吗？验证不是最后才做的事。从需求阶段就要开始规划验证场景。我习惯把验证分成三个层次：
| 验证层次 | 对应阶段 | 典型场景 |
|---|---|---|
| 架构验证 | 需求/架构设计 | 带宽计算、协议一致性、死锁检测 |
| 模块验证 | RTL编码阶段 | 寄存器读写、中断处理、数据通路 |
| 系统验证 | 后端实现前 | 多模块交互、低功耗切换、复位序列 |
场景验证的核心目标
场景验证到底要解决什么问题？说白了就三个字：找 bug。但怎么找、找什么样的 bug，这里面门道很深。
我个人把场景验证的核心目标归纳为四点：
- 功能正确性——DUT 该做的事做了没有？比如加法器算对了没有。
- 协议合规性——接口时序、握手信号是否符合规范？我曾经遇到一个 AXI 从机，在 WLAST 拉高后还继续收数据——协议上这是不允许的。
- 边界鲁棒性——在极端条件下会不会崩溃？比如 FIFO 满的时候继续写、空的时候继续读。
- 异常处理能力——遇到非法输入、错误状态时，DUT 能不能优雅地处理？
1. 这个场景覆盖了哪个功能点？
2. 这个场景的边界条件是什么？
3. 如果 DUT 在这个场景下出错了，后果有多严重？
优先级排序，先测后果严重的。
你想想看，如果验证场景只覆盖了「正常操作」，那芯片流片回来大概率会出问题。因为芯片在实际系统中，永远会遇到各种意想不到的情况——电源抖动、外部干扰、软件配置错误……
所以场景验证的核心目标，不是证明 DUT 在理想条件下能工作，而是证明 DUT 在真实世界中能可靠运行。
嗯，这一章就聊这么多。记住一句话：场景是验证的灵魂，没有场景的验证只是跑波形。
可可精品资料库