3. 验证环境搭建基础：目录结构规范、文件命名规范、版本管理工具（Git）的使用

好，咱们直接进入正题。验证环境搭建，说白了就是给你的验证项目搭个「家」。这个家要是乱糟糟的，后面找文件、定位问题、团队协作，全得抓瞎。我见过太多项目，光是在目录里翻一个testbench文件就要花五分钟，效率低得吓人。

今天我就把我在几个大型芯片项目里沉淀下来的经验，掰开揉碎了讲给你听。记住，规范不是束缚，是解放。

3.1 目录结构规范：让项目「一眼清」

一个标准的验证环境，目录结构应该像一本字典——你想查什么，翻到对应章节就能找到。我个人习惯用这种分层结构：

project_root/
├── rtl/                # 待测设计（DUT）的RTL代码
├── sim/                # 仿真相关
│   ├── run/            # 仿真脚本、Makefile
│   ├── waves/          # 波形文件（.vcd, .fsdb）
│   └── logs/           # 仿真日志
├── tb/                 # 测试平台
│   ├── tests/          # 测试用例
│   ├── sequences/      # 激励序列
│   ├── agents/         # 代理模块
│   ├── monitors/       # 监视器
│   ├── scoreboards/    # 计分板
│   └── env/            # 验证环境顶层
├── vip/                # 验证IP（第三方或自研）
├── scripts/            # 辅助脚本（Python, Perl等）
├── docs/               # 文档
└── tools/              # 工具配置

嗯，这里要注意：rtl和tb一定要分开。我在一个项目里遇到过，有人把DUT代码直接塞进了tb目录，结果版本管理混乱，最后回退版本时把设计代码也搞丢了。血的教训。

你想想看，如果团队里每个人都按自己的喜好建目录，那项目后期光「找文件」就能消耗掉20%的时间。规范目录结构，就是给团队省时间。

3.2 文件命名规范：名字里就藏着信息

文件命名，说白了就是「见名知意」。我建议用这种格式：

<模块名>_<类型>_<描述>.<扩展名>

举个例子：

文件名	含义
uart_tb_top.sv	UART模块的测试平台顶层
uart_agent.sv	UART模块的代理
uart_test_smoke.sv	UART模块的冒烟测试
uart_test_regression.sv	UART模块的回归测试

我曾经接手过一个项目，里面全是 test1.sv、test2.sv 这种名字。你猜怎么着？没人知道每个测试测的是什么。最后只能一个个打开看代码，浪费了整整两天。所以，命名规范就是文档的一部分。

3.3 版本管理工具（Git）的使用：给项目上「保险」

Git这东西，说实话，刚开始用的时候我也觉得麻烦。但后来我意识到，没有Git的验证项目，就像没有安全带的赛车——随时可能翻车。

3.3.1 基本工作流

我个人习惯用这种分支策略：

main          # 稳定版本，只合入经过评审的代码
├── dev       # 开发分支，日常开发在这里
├── feature/* # 功能分支，每个新功能一个分支
└── fix/*     # 修复分支，修bug用

举个例子，你要加一个UART的测试用例：

git checkout -b feature/uart_add_smoke_test
# 写代码...
git add uart_test_smoke.sv
git commit -m "add: UART冒烟测试用例"
git push origin feature/uart_add_smoke_test
# 然后发起Pull Request，等评审

3.3.2 提交信息怎么写

提交信息不是随便写两句就完事的。我建议用这种格式：

<类型>: <简短描述>

<详细说明（可选）>

类型我用这几个：

• add：新增功能或测试
• fix：修复bug
• refactor：重构代码
• docs：文档更新
• chore：杂项（比如改配置文件）

举个例子：

add: UART模块冒烟测试用例

- 覆盖了发送、接收、中断三种场景
- 验证了波特率配置的正确性
- 修复了之前测试中遗漏的奇偶校验检查

你想想看，如果每个提交信息都这么写，三个月后回来看，一眼就知道当时改了啥。要是只写个「update」或者「fix bug」，那跟没写有啥区别？

3.3.3 避坑指南

3.4 知识体系总览

下面这张图，是我对本章知识体系的总结。你看一眼，心里就有数了：

说白了，目录结构、文件命名、Git使用，这三件事做好了，你的验证环境就成功了一半。剩下的，就是往里面填测试用例了。