为什么设计后必须验证
第六章
数字逻辑系统与 testbench
建立“设计 + 验证”闭环思维，从会写模块走向会做验证
一、本章导航
二、本章定位
本章强调验证不是附加步骤，而是数字系统开发主流程。通过 testbench 与仿真，才能证明设计真正满足需求。
- testbench 是什么？
- 为什么 FPGA/Verilog 设计必须先仿真？
- 激励、观测、比较如何形成验证闭环？
- 为什么能综合不等于设计正确？
三、知识点讲解
1. 数字逻辑系统设计与验证关系
1.1 为什么设计后必须验证
代码写完不代表功能正确。验证的职责是证明设计在关键场景下符合需求，包括边界条件和异常路径。
仿真越前置，问题发现越早，修复成本越低。把验证放到上板之后，通常会带来高成本低效率的调试。
1.2 疑难点：能综合为什么仍会出错
综合通过只说明设计可映射到硬件资源，不说明行为一定正确。需求理解偏差、时序假设错误、边界覆盖不足都可能导致功能错误。
验证关注“需求符合性”，综合关注“实现可行性”。两者目标不同，缺一不可。
2. testbench 的基本结构
2.1 DUT 与 testbench 的角色分工
DUT 是被测设计模块，负责业务功能实现；testbench 是外部验证环境，负责激励、观测、比较和仿真控制。
角色清晰后，验证代码与设计代码职责不混杂，调试与回归效率会更高。
- - DUT 实例
- - 输入激励
- - 时钟/复位生成
- - 输出观测
- - 结果比较
- - 结束控制
2.2 疑难点：为什么只给输入不够
只给输入但不判断输出，本质上只是“看波形”，不是“做验证”。验证必须有预期结果和判断标准。
建议每个测试场景都明确：场景目标、输入序列、预期输出、判定条件。这样每次仿真都有可复用结论。
3. 仿真验证的基本思想与习惯
3.1 激励-观测-比较的验证闭环
高质量验证强调闭环：激励用于驱动场景，观测用于采集行为，比较用于判定正确性。缺少任何一环，验证结论都会不完整。
除了主流程，还应覆盖边界场景和异常场景。很多真实问题恰恰出现在非常规路径。
3.2 疑难点：如何从“会写模块”走向“会做验证”
转变关键在于提问方式改变：从“代码能跑吗”转为“我如何证明它在关键场景都正确”。
建议每次完成模块后立即补最小 testbench，并逐步扩展覆盖。把验证作为常规开发动作，而不是项目后期补救动作。