分层验证架构：层次划分与环境复用
更新时间：2026-10-01。前面的篇章分别讲了 driver、monitor、scoreboard，这篇解决一个工程问题：怎么组织它们，让同一套平台能从单模块一路复用到子系统和整机。
本文要回答的问题
- 一个可复用平台分几层，每层只允许做什么？
- block 级验证环境如何平滑长成 system 级而不是重写？
- 多个接口的 agent 怎样做到“即插即用”？
一、为什么必须分层
如果 driver 直接调用 generator、scoreboard 直接读引脚，平台会耦合死：换一个接口、加一个模块、从 block 升到 system，就要改一大片。分层把“物理时序”“事务语义”“功能预期”“场景编排”隔离，各层通过明确定义的事务接口通信。
二、五层结构
- 信号级：interface + clocking block，负责引脚、时序与竞争消除（见 interface/clocking）。
- 事务级：driver 把事务转成引脚时序，monitor 把引脚时序还原成事务，sequencer 调度事务。
- 模块功能级（agent）：封装 sequencer/driver/monitor + 配置，自成一个可复用接口单元（如 PCIe agent、I2C agent）。
- 子系统/系统级（env）：组合多个 agent，加入 reference model、scoreboard、coverage，定义功能预期。
- 测试级（test/sequence）：只做配置和场景编排，不含具体驱动。
层间只能向下依赖、靠事务/TLM 通信；test 不应直接碰引脚。
三、垂直与水平复用
- 水平复用：interface agent（含完整协议检查与覆盖率）在不同项目间直接复用。
- 垂直复用：block 级的 agent 在更高级别切换为 passive（只监听不驱动，内部由真实模块驱动），env 通过配置拼装，而不是另起炉灶。
四、可配置 env 与复用契约
用统一配置对象描述“这个 agent 是否存在、active/passive、几个端口、是否启用检查器”，test 只改配置。复用契约包括：事务类型、TLM 连接点、配置字段、时钟复位约定——这些要稳定并文档化，平台才能长期复用。
五、常见坑
- 层间越界（test 直接驱动引脚、scoreboard 直接读信号），升级即重写。
- 低层 active agent 到高层忘了切 passive，和真实驱动打架。
- 配置散落硬编码，无法派生新场景。
- 复用契约不文档化，换人后接不上。
- reference model 与 agent 事务类型不统一，每次集成都写转换。
小结
分层让物理、事务、功能、场景各归其位；水平靠 agent、垂直靠 active/passive 切换与可配置 env。下一篇 UVM 配置对象与资源数据库。
总结
现代验证平台分五层以支持复用：信号级（interface/clocking 管引脚与时序）→ 事务级（driver 转引脚时序、monitor 还原事务、sequencer 调度）→ 模块功能级 agent（封装三者成可复用接口单元）→ 子系统/系统级 env（组合多 agent + reference model/scoreboard/coverage）→ 测试级 test/sequence（只做配置和场景编排）；层间只向下依赖、只靠事务/TLM 通信，test 不直接碰引脚。复用有两个方向：水平复用让带完整协议检查和覆盖率的 agent 跨项目复用，垂直复用让同一 env 从 block→subsystem→system 生长——低层 active 的内部 agent 到高层切成 passive 仅监控、由真实模块驱动，并用统一配置对象和稳定文档化的复用契约（事务类型/TLM 连接点/配置字段/时钟约定）拼装，而非另起炉灶。