3. 开发环境搭建：Linux环境配置、EDA工具安装、版本管理(Git)与项目结构
说实话，做交换芯片验证，环境搭建是第一步，也是最容易踩坑的一步。我见过太多新人，一上来就急着写代码，结果环境没配好，后面三天两头出问题。今天咱们就把这块彻底讲透。
3.1 Linux环境配置——你的工作台
我个人习惯用CentOS 7或Ubuntu 20.04 LTS。为什么？因为EDA工具对这两个发行版支持最好。你想想看，如果选了个冷门系统，装个VCS都要折腾半天，何必呢？
核心配置清单：
- 操作系统：CentOS 7.9 / Ubuntu 20.04 LTS（64位）
- 内核版本：3.10.0+（CentOS）或5.4.0+（Ubuntu）
- 磁盘分区：/home 单独分区，建议200GB+
- 交换空间：至少32GB（大型仿真时内存不够会卡死）
- 网络配置：静态IP，方便远程访问
嗯，这里要注意一个细节：关闭SELinux。我在项目中遇到过，SELinux开着，VCS死活跑不起来，查了两天才发现是权限问题。直接 setenforce 0 搞定。
# 关闭SELinux（临时）
sudo setenforce 0
# 永久关闭
sudo sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config
# 安装基础依赖
sudo yum install -y gcc gcc-c++ make flex bison perl \
tcsh tk tcl-devel libX11-devel libXext-devel \
libXft-devel libXt-devel libXmu-devel \
ncurses-devel redhat-lsb-core
小技巧：装完系统后，先跑一遍 lscpu 和 free -h，确认CPU和内存信息。我习惯把系统日志打开，方便后面排查问题。
3.2 EDA工具安装——别被版本坑了
EDA工具安装，说白了就是解压、配置license、设置环境变量。但这里有个坑：版本兼容性。
我曾经在项目里用过VCS 2018和Verdi 2019，结果两个工具对同一个波形文件的解析不一致，debug时差点崩溃。后来统一成VCS 2020 + Verdi 2020，问题就没了。
| 工具 | 推荐版本 | 用途 | 安装路径 |
|---|---|---|---|
| VCS | 2020.12 | 仿真编译 | /tools/synopsys/vcs |
| Verdi | 2020.12 | 波形调试 | /tools/synopsys/verdi |
| Design Compiler | 2020.09 | 综合（可选） | /tools/synopsys/dc |
| QuestaSim | 2021.1 | 替代仿真器 | /tools/mentor/questa |
安装步骤其实很简单，我总结成三步：
- 解压安装包：tar -xvf vcs_2020.12.tar -C /tools/synopsys/
- 配置license：设置
SNPSLMD_LICENSE_FILE环境变量 - 设置环境变量：在
.bashrc里加路径
# .bashrc 中的EDA环境配置
export VCS_HOME=/tools/synopsys/vcs/O-2018.09-SP2
export VERDI_HOME=/tools/synopsys/verdi/Verdi_O-2018.09-SP2
export PATH=$VCS_HOME/bin:$VERDI_HOME/bin:$PATH
export SNPSLMD_LICENSE_FILE=27000@license-server
export LM_LICENSE_FILE=27000@license-server
注意：license server的端口不要用默认的27000，容易冲突。我习惯用27001或27002。另外，lmstat -a 可以查看license状态，这个命令要记牢。
3.3 版本管理(Git)——你的后悔药
做验证，代码版本管理是必须的。我见过有人用U盘拷代码，结果版本搞混，仿真结果对不上，那叫一个惨。
Git的基本流程，我建议这样：
- 主分支(main)：只放稳定版本，每次合入前必须经过review
- 开发分支(dev)：日常开发在这里，可以频繁提交
- 功能分支(feature-xxx)：每个新功能单独开分支，互不干扰
为什么会这样？因为交换芯片验证涉及多个模块，比如MAC层、交换核心、管理接口。如果大家都在main上改，冲突会多到你怀疑人生。
# 初始化仓库
git init
git remote add origin git@github.com:your-team/switch_chip_verif.git
# 创建分支结构
git checkout -b dev
git checkout -b feature/mac_layer
git checkout -b feature/switch_core
# 日常提交
git add .
git commit -m "[MAC] 添加CRC校验测试用例"
git push origin feature/mac_layer
个人习惯：我每次提交前都会跑一遍 git diff，看看改了哪些东西。有时候改多了，自己都忘了改了啥。另外，commit message要写清楚，别写"fix bug"这种，要写"修复MAC层CRC校验溢出问题"。
3.4 项目结构——别让代码乱成一锅粥
项目结构，说白了就是给代码找个家。我见过最乱的项目，所有文件都在一个目录下，找testbench得翻半天。
我推荐的结构是这样的：
switch_chip_verif/
├── docs/ # 文档
│ ├── spec/ # 规格文档
│ └── notes/ # 个人笔记
├── rtl/ # 设计代码（来自设计团队）
│ ├── mac/
│ ├── switch_core/
│ └── top/
├── tb/ # 测试平台
│ ├── tests/ # 测试用例
│ ├── models/ # 参考模型
│ └── drivers/ # 驱动
├── scripts/ # 脚本
│ ├── run/ # 仿真脚本
│ └── debug/ # 调试脚本
├── logs/ # 仿真日志
├── waves/ # 波形文件
└── Makefile # 顶层Makefile
嗯，这里要注意：日志和波形文件不要提交到Git。我在项目中遇到过，有人把几个G的波形文件push上去了，结果仓库直接炸了。记得加 .gitignore：
# .gitignore
logs/
waves/
*.vcd
*.fsdb
*.log
*.dump
核心原则：
- 每个模块一个目录，互不干扰
- 测试用例按功能分类，命名规范
- 脚本统一放在scripts下，不要散落各处
- Makefile作为入口，一键运行所有
3.5 知识体系总览
下面这张图，是我画的环境搭建整体流程。你看一眼，心里就有数了。
这张图把整个环境搭建的脉络理清了。从Linux系统开始，到EDA工具，再到Git和项目结构，最后落地到实战。每一步都环环相扣，缺一不可。
最后说一句：环境搭建别急，慢慢来。我刚开始做验证时，光配环境就花了一周。但后面仿真、debug的时候，一次都没因为环境问题卡过。前期投入，后面省心。
公众号:蓝海资料掘金营，微信deep3321