第二章 开发环境搭建：Linux服务器配置，EDA工具安装与License管理，版本控制与项目管理

说实话，搭建开发环境这件事，看着不起眼，但往往是整个芯片设计流程里最容易踩坑的地方。我见过不少团队，工具装了两周还没跑通一个仿真，最后发现是License配置出了问题。所以这一章，咱们就把这事彻底理清楚。

2.1 Linux服务器配置——打好地基

做MCU芯片设计，服务器就是你的战场。我个人习惯用CentOS 7或RHEL 8，SMIC 40nm的PDK对这些系统支持最好。Ubuntu也能用，但有些EDA工具的安装脚本对Debian系的支持没那么完善，你可能会遇到一些奇怪的依赖问题。

嗯，这里要注意一个细节。很多新手装完系统就直接用，结果跑DC综合时发现内存不够。SMIC 40nm的库文件本身就很大，再加上综合、仿真时的中间文件，一个项目下来轻松吃掉几百G。所以存储空间一定要留足。

2.2 EDA工具安装——三大家族的部署

芯片设计离不开Synopsys、Cadence、Mentor这三家。每家工具都有自己的脾气，安装顺序也有讲究。我建议先装Synopsys，再装Cadence，最后装Mentor。为什么？因为License管理工具通常用Synopsys的SCL，先装它方便统一管理。

2.2.1 Synopsys工具链

Synopsys的工具包括DC (Design Compiler)、VCS (仿真)、Formality (形式验证)、PrimeTime (STA) 等。安装其实不复杂，关键是环境变量要配对。

# 设置Synopsys安装目录
export SYNOPSYS_HOME=/tools/synopsys
export PATH=$SYNOPSYS_HOME/bin:$PATH

# 设置License
export SNPSLMD_LICENSE_FILE=27000@license-server-ip

# 设置临时目录（很重要！）
export TMPDIR=/tmp/synopsys_$USER
mkdir -p $TMPDIR

2.2.2 Cadence工具链

Cadence这边主要是Virtuoso（版图设计）、Innovus（布局布线）、Xcelium（仿真）。安装方式和Synopsys类似，但环境变量名不同。

# Cadence环境变量
export CADENCE_HOME=/tools/cadence
export PATH=$CADENCE_HOME/bin:$PATH

# License设置
export CDS_LIC_FILE=5280@license-server-ip

# 设置OA（OpenAccess）路径
export OA_HOME=$CADENCE_HOME/oa_v22.60.xxx

说白了，Cadence的OA库版本经常变，不同工具可能依赖不同版本。我建议把所有OA版本都装好，然后在环境变量里指定最常用的那个。遇到版本不兼容时再临时切换。

2.2.3 Mentor工具链

Mentor这边主要是Calibre（DRC/LVS验证）。它的安装相对独立，License管理用的是自己的mgcld。

# Mentor环境变量
export MGC_HOME=/tools/mentor/calibre_2023
export PATH=$MGC_HOME/bin:$PATH
export CALIBRE_HOME=$MGC_HOME

# License设置
export MGLS_LICENSE_FILE=1717@license-server-ip

2.3 License管理——最容易出问题的环节

License配置，说白了就是让工具能认到你的授权。我见过最坑的情况是：工具装好了，环境变量也配了，但就是启动不了。最后发现是防火墙把端口给封了。

启动License服务的命令也很关键：

# 启动Synopsys License Server
lmgrd -c /tools/licenses/synopsys.dat -l /var/log/synopsys_license.log

# 检查License状态
lmstat -a -c 27000@localhost

你想想看，如果lmstat输出里能看到你的工具和feature，那基本就稳了。如果看不到，先检查日志文件，错误信息通常写得很清楚。

2.4 版本控制与项目管理——Git的正确用法

芯片设计和软件开发不一样，代码库动不动就几十G。Git管理大文件是个难题，我推荐用Git LFS (Large File Storage)。

2.4.1 Git仓库结构

我个人习惯按模块分仓库，而不是一个大仓库装所有东西。比如：

mcu_project/
├── rtl/              # RTL代码仓库
├── verification/     # 验证环境仓库
├── pdk/              # PDK文件（用Git LFS管理）
├── scripts/          # 脚本仓库
└── docs/             # 文档仓库

为什么要这么分？因为不同模块的更新频率不同，RTL可能每天改，PDK可能几个月才更新一次。分开管理，git clone的时候也快很多。

2.4.2 Git LFS配置

# 安装Git LFS
git lfs install

# 在仓库中跟踪大文件
git lfs track "*.gds"
git lfs track "*.lib"
git lfs track "*.db"
git lfs track "*.lef"
git lfs track "*.def"

# 提交.trackattributes文件
git add .gitattributes
git commit -m "add LFS tracking for large files"

2.4.3 分支管理策略

芯片设计的分支策略和软件开发不太一样。我推荐用这个模型：

分支名称	用途	说明
master	稳定版本	只有经过完整验证的版本才能合并到这里
develop	开发主线	日常开发都在这个分支上
feature/*	功能分支	每个新功能或模块单独开一个分支
release/*	发布分支	流片前做最终验证的分支
hotfix/*	紧急修复	流片后发现bug，紧急修复用

举个例子，我在做某个MCU项目时，有个同事直接在master上改代码，结果把别人已经验证好的模块搞坏了。从那以后，我严格要求所有人必须从develop拉feature分支，合并前必须做code review。

2.5 项目管理——别让流程拖后腿

工具装好了，代码也管起来了，接下来就是怎么组织项目。我推荐用Makefile来管理整个流程，而不是靠人肉记忆命令。

# 项目根目录的Makefile示例
.PHONY: all clean sim synth pnr

all: sim synth

# 仿真
sim:
	cd verification && make run

# 综合
synth:
	cd synthesis && make dc

# 布局布线
pnr:
	cd apr && make innovus

# 清理中间文件
clean:
	find . -name "*.log" -delete
	find . -name "*.vcd" -delete
	find . -name "work" -type d -exec rm -rf {} +

你想想看，有了Makefile，新人来了也能直接make sim跑仿真，不用去记那些复杂的命令。而且Makefile本身也放在Git里管理，版本变化一目了然。

嗯，这一章的内容就到这里。环境搭建虽然繁琐，但一次配好，后面能省很多事。下一章咱们开始讲RTL设计，那才是真正有意思的部分。