第7章 庭审交锋：测试台与验证

第 7 章 · 庭审交锋：测试台与验证

章节摘要：本章跟着「一场验证诉讼如何打赢」的主线走：测试台是法庭的建筑结构，显示与监控是记录仪，自检查是自动判决，覆盖率是「审够了没有」的量化答案。不会验证的设计者只能听信自己代码的一面之词。

一条主线

主线是一场完整的诉讼流程。开庭前要搭法庭——测试台给被测模块接上激励源、时钟、复位与观测点；开庭中要记录证词——display、monitor、波形文件把设计的每一步言行固定下来；判决要自动作出——自检查测试台把「对不对」变成机器可判的比对，人只看异常；结案要出量化报告——覆盖率回答「测过的空间占多大、还有哪些角落没人去过」。四节按这个流程排列：先建筑，后记录，再判决，最后统计。

验证在工程里的地位可以这样概括：设计代码写的是「我认为电路会怎么做」，验证代码证明的是「电路真的这么做了」。两者角色对立、利益相反——这正是「控辩对抗」比喻的本义：好的测试台必须站在「挑毛病」的立场，而不是「走一遍正常路径就收工」的立场。

验证还是一项「投资回报率极不对称」的工作：测试台的建设成本在项目早期一次性付出，回报却贯穿整个生命周期——每次设计改动后的回归、每个现场问题的复现、每轮协议升级的适配，都在消耗这笔投资的利息。反过来看，跳过验证省下的时间，会在项目后期以数量级放大的方式偿还出去。理解了这笔账，就知道为什么成熟团队里验证的人力投入往往超过设计。

沿途站点

第一站 7.1「测试台架构」：激励、时钟、复位、被测实例、观测五要素的标准布局；激励的编写风格从「逐拍堆语句」升级到「事务级 task」；并行块构造多路并发激励的用法；测试台自身的工程纪律。

第二站 7.2「显示监控与自检」：display 家族与 monitor 的分工、波形文件的记录开关、以及把期望值比对写进测试台的自检查手法——错误在仿真结束的那一刻自动浮出水面，结案判卷协议让回归脚本能机器汇总。

第三站 7.3「功能覆盖与回归」：覆盖率的三种口径（代码覆盖、功能覆盖、断言覆盖）、手写功能覆盖点的实现、回归流程与随机种子的管理思路。回答那个终极问题：测够了没有——以及覆盖率停滞时该怎么诊断。

拐点与结论

本章的拐点是「验证代码与设计代码同等对待」。初级阶段的测试台是一次性脚本——能跑就行；工程化的测试台是长期资产——它要跟着设计走完整生命周期，每次设计改动都要重跑。因此测试台同样需要架构：激励与检查分离、事务封装成 task、公共部分抽成可复用模块。一个没有架构的测试台，在项目的第无数次回归时就会变成没人敢动的黑盒。

结论落在一句职业信条上：没被测试台逼问过的代码，没有资格交付。 仿真通过只说明「你想到的场景没问题」，验证的价值在于「逼你想到没想到的场景」——这需要测试台的作者以对抗的心态工作。综合之后还有门级仿真、形式验证层层关卡，但第一道也是最便宜的一道关卡，永远是 RTL 仿真。

读完你应该

• 能独立搭建含时钟复位激励观测五要素的完整测试台，并说明各要素的编写惯例；
• 能把重复激励封装成事务级 task，用并行块构造多路并发激励；
• 能正确选用 display 与 monitor，配置波形记录，理解打印语句与调度区的关系；
• 能写出带自动比对的测试台：期望值生成、实时校验、结束时报错统计与判卷协议；
• 能解释代码覆盖与功能覆盖的区别，手写覆盖计数器并解读覆盖报告；
• 能组织一次回归：用例清单、种子管理、结果判定、失败复现。

下一章的接力

验证通过只是「行为上正确」。下一章「判决执行」进入综合与实现：代码如何变成门电路、FPGA 与 ASIC 各自要走哪些流程、面积功耗速度的三角怎么权衡。验证给了你功能自信，下一章给的是物理自信——测试台里抽象掉的时间与面积，在那一刻全部回来算账。