4 验证环境的可重用架构设计

芯片验证团队普遍面临三座山：回归耗时长、覆盖率收敛慢、环境复用难。其中“环境复用难”最容易被低估——一旦设计规格升级或项目切换，验证环境中几百个文件无法迁移，团队被迫从零搭建。可重用架构设计要解决的，正是“让验证资产持续增值”这一核心工程命题。

4.1 问题背景：为什么可重用架构决定验证效率

在 IP 验证、SoC 集成验证和硅后验证之间，验证对象不断变化，但协议接口、时序行为和总线事务往往高度相似。若验证环境从第一版就遵循可重用架构，后续每个项目都能沿用：

• 验证周期压缩：已有 UVC、Env、Sequence 库可直接装配，新平台上只写差异部分。
• 多项目/IP 复用：同一个 APB、AXI、UART 协议组件，可以服务于不同 DUT。
• 团队协作与回归成本：统一架构让新人更快接手，回归用例可跨项目持续积累。

4.2 核心概念：可重用性不是“复制代码”

一个具有可重用架构的验证环境，是“由分层 UVC、可组装 Env、可复用 Sequence 和统一配置接口构成的验证软件系统”。在 UVM 语境中，最重要的可重用载体有三类：

• UVC（Universal Verification Component）：针对一种协议的总线功能模型，包含 Driver、Monitor、Sequencer、Sequence 库和协议检查。
• Env：面向 DUT 或子系统的组件容器，把多个 UVC、Scoreboard、Coverage 装配成完整验证上下文。
• Test 层：将不同场景组织成可执行用例，通过 Factory Override 和 Configuration 实现用例差异。

下图给出典型可重用 UVM 验证环境的逻辑分层架构：

4.3 可重用性的三个层次与组件职责

可重用性不是非黑即白，而是分层次的。从组件级别到项目级别，每一层的复用收益和设计重心不同：

4.4 原理机制：分层架构如何支撑重用

可重用架构的底层机制可以概括为四个“隔离”：

• 分层隔离：Driver 不知道具体 Test 内容，Monitor 不知道 Scoreboard 如何消费数据，层次之间只通过标准事务类交互。
• 接口标准化：Sequence 通过 Sequencer 发布 Transaction，Driver 通过 seq_item_port 获取；所有协议信号被封装在 Interface 中。
• 配置外部化：Virtual Interface、配置对象、地址范围等统一通过 config_db 传入，组件内部不写死环境信息。
• 扩展开放：通过 Factory Override、Analysis Port、Callback 三类机制，在不修改原组件的前提下增加新功能或替换子组件。

这种机制保证：上层变化不会冲击下层，下层升级不会破坏上层；每个组件都可以成为独立的重用资产。

4.5 流程步骤：从零建设可重用验证环境

1. 定义协议事务模型：明确 Transaction 字段、约束、打印与比较函数。
2. 封装接口层：定义 Virtual Interface、同步时序和管脚映射，避免信号级代码渗入组件。
3. 开发 Driver 与 Monitor：均面向 Transaction，不直接依赖测试用例。
4. 构建 Sequence Library：沉淀基础读写、突发、异常序列，作为可复用激励原子。
5. 封装 Agent / UVC：内部组合 Sequencer、Driver、Monitor，对外暴露可配置参数。
6. 搭建 Env：装配多个 Agent、Scoreboard、Coverage，并建立分析通路。
7. 加入 Virtual Sequencer：支撑跨接口场景调度，避免在 Test 中直接操作多个 Sequencer。
8. 配置 Test Cases：通过 config_db 和 Factory Override 表达用例差异，不修改环境代码。
9. 沉淀最小示例与回归用例：每个重用资产必须配有可运行示例，作为后续项目接手的入口。

4.6 案例说明：APB UVC 从 IP 到 SoC 重用的最小落地

假设 Block 级验证环境中已有 APB UVC，包含 apb_agent、apb_sequence_lib 和 apb_scoreboard。现在 SoC 集成验证需要把 APB 验证组件挂到不同基地址的 APB IP 口。重用策略如下：

• 通过 config_db 为不同 apb_agent 实例传入不同的 Virtual Interface。
• 通过 Factory Override
  ← 上一章 📖 返回目录 下一章 →