版本管理工具：Git、SVN在PD调试环境中的搭建与使用

做PD调试，版本管理跑不掉。

你想想看，一个复杂的SoC项目，几十号人同时改设计、调脚本、修时序。没有版本管理，改乱了谁负责？回退到哪个版本？我记得有个项目，因为某位同事误删了一个关键脚本，大家硬是找了三天才找到备份——从那以后，全组强制上版本管理。

今天咱们就聊SVN和Git。这两个工具，我估摸着你在PD领域迟早都得碰。

SVN vs Git：先搞清选哪个

简单说，SVN是集中式，Git是分布式。这个区别决定了你整个工作流的组织方式。

特性 SVN Git
模型 集中式 分布式
仓库位置 只有中心仓库 每个开发者有完整仓库
本地操作速度 慢（依赖网络） 快（全本地）
分支创建成本 高（拷贝目录） 极低（指针）
权限控制 细粒度（路径级别） 仓库级别
锁定机制 支持文件锁定 不原生支持锁定
适用场景 大型二进制文件、EDA工具体系成熟 源码、脚本、配置项
上手难度 较低 中等

我个人习惯：脚本和源码走Git，二进制库和PD输出走SVN。为什么不全用Git？因为PD工具生成的那么多Log、Def、GDS，动辄几百兆到几G，Git仓库很快就爆掉了。SVN在这种场景下反而更稳。

SVN搭建：稳扎稳打的集中式路线

1. 安装与初始化

# Ubuntu/Debian
sudo apt-get install subversion

# CentOS/RHEL
sudo yum install subversion

# 创建仓库目录
mkdir -p /home/svn_repo/my_pd_project
svnadmin create /home/svn_repo/my_pd_project

服务器端搞定后，别急着往里塞文件。先搭好主干、分支、标签的标准目录结构——这个结构我吃过亏。现在但凡新项目，第一步一定是这个。

svn mkdir svn://server/my_pd_project/trunk \
          svn://server/my_pd_project/branches \
          svn://server/my_pd_project/tags \
          -m "初始化标准目录结构"

标准目录结构说明：

  • trunk：主线开发，始终是最新稳定版本
  • branches：分支开发，比如IP单独调试、时序优化分支
  • tags：里程碑快照，比如RC1、RC2、Tape-Out版

2. 工作流配置

把整个工作目录检出来。注意，PD项目文件一般很大，所以先别checkout全部，只checkout你需要的部分。

svn co svn://server/my_pd_project/trunk my_pd_work
cd my_pd_work

# 设置忽略文件（避免把中间文件提交上去）
svn propedit svn:ignore . --editor-cmd vim
# 在打开的文件里添加：
# *.log
# *.rpt
# work/
# .synopsys_dc.setup

我通常会同时建一个.svnignore文件放项目里，谁都能直接引用。怎么保证每个工程师的忽略规则统一？用svn:global-ignores属性。

3. 多人协作时的避坑指南

三不原则：

  • 不直接提交大文件（>50MB）到trunk——改用专用存储或LFS
  • 不同时签出同一个文件做长时间编辑——容易冲突，提前跟队友打个招呼
  • 不反复删除又添加文件——SVN的历史树会很臃肿，尽量用svn move

我曾经踩过的一个坑：两年前一个项目，组里有人把整个work/目录提交上去了，仓库瞬间膨胀了30多GB。从那以后我强制每台机器装svn:ignore，并在pre-commit钩子里加了文件大小检查。

# pre-commit 钩子示例：禁止超过512MB的文件提交
#!/bin/bash
REPOS="$1"
TXN="$2"
MAX_SIZE=536870912  # 512MB
svnlook changed -t "$TXN" "$REPOS" | while read line; do
    file=$(echo $line | awk '{print $2}')
    size=$(svnlook filesize -t "$TXN" "$REPOS" "$file")
    if [ "$size" -gt "$MAX_SIZE" ]; then
        echo "错误：文件 $file 超过512MB，请检查是否误提交了中间文件" >&2
        exit 1
    fi
done
exit 0

Git搭建：灵活高效的分布式工作流

1. 初始化与配置

# 安装
sudo apt-get install git

# 全局配置（项目级优先于全局级）
git config --global user.name "Zhang San"
git config --global user.email "zhangsan@chipdesign.com"

# 创建裸仓库（作为中心仓库）
mkdir -p /home/git_repo/pd_scripts.git
cd /home/git_repo/pd_scripts.git
git init --bare

有点经验的PD工程师都会在配置文件里做三件事：设置core.autocrlf input、core.safecrlf true、以及diff.tool vimdiff。跨平台写脚本很容易在换行符上翻车，我为此debug过一个通宵。

2. 标准化提交日志

我建议：写清楚的commit message。别写“update”、“fix”、“改了一点”——这在PD项目里等于没写。

# 推荐的commit格式
[PD-SCRIPT] 添加时序报告自动解析模块
- 增加从PT报告中提取setup/hold slack的工具
- 支持多corner并行解析
- 输出格式统一为CSV
Issue: PD-1024
Signed-off-by: Zhang San <zhangsan@chipdesign.com>

3. 分支策略

PD调试不同于软件开发，不推荐用Git flow那种重分支策略。反而轻量级特性分支加Tag更适合。

分支类型 命名规则 用途
主线 master / main 始终可发布的版本
特性分支 feature/ir_drop_analysis 独立功能开发
调试分支 debug/clock_tree_synth 单点问题修复
Tag v1.0_rc1 里程碑快照 
# 实际工作流
git clone git@server:pd_scripts.git
git checkout -b feature/timing_script_refactor
# ... 写脚本，改代码 ...
git add ./tools/timing_analysis/
git commit -m "[TIMING] 重写时序分析主脚本，引入并行处理"
git push origin feature/timing_script_refactor

# 代码审核后进行合并请求（Merge Request / Pull Request）
# 我在团队里强制MR必须有一个Reviewer点过赞才能合入master
git checkout master
git merge --no-ff feature/timing_script_refactor
git tag -a v1.2 -m "时序分析脚本重构完成"
git push origin --tags

4. 与EDA工具的集成

很多PD工具都支持从Git仓库里直接拉脚本。比如我习惯在.synopsys_dc.setup文件里加入这样一段：

# 从Git仓库拉取的公共库
set pd_common_root "/home/project/pd_scripts"
if {[file exists "$pd_common_root"]} {
    source [file join $pd_common_root "common/pd_utils.tcl"]
} else {
    puts "Warning: PD公共库未检出，请执行: cd $pd_common_root && git pull"
}

好处是：团队所有人都引用同一个公共脚本库，改一处，跑验证的工程师第二天就能自动拿到更新，不用每个子模块单独提交。

版本管理在PD调试环境中的知识体系 版本管理在PD调试环境中的知识体系 版本管理核心 SVN 集中式 仓库搭建 主干/分支/标签 权限控制 pre-commit钩子 svn:ignore配置 锁定机制 Git 分布式 本地仓库 特性分支 Tag快照 Merge Request .gitignore Commit规范 与EDA工具集成（脚本调用、自动化CI） SVN适合大二进制文件/PD输出；Git适合脚本/源码配置；策略搭配使用 不同团队可根据项目规模灵活选用或同时接入两种工具

数据管理与导出

PD项目中，版本管理的最终目的是可追溯、可复现。跑了一版脚本，三天后结果不对——哪个版本出了问题？有了版本管理，git bisect或者svn log一比，全出来。

我个人有两个习惯：

  • 每轮正式Run前，打一个Tag或Label。注明运行时间、参数、期望结果。这个Tag就是你的“试验日志”。
  • 导出版本信息嵌入Log文件。跑脚本时自动记录git rev-parse HEAD或svn info的输出，事后对账少走弯路。
# 在Tcl脚本里自动记录版本信息，输出到log头部
proc write_version_info {log_fd} {
    if {[catch {exec git rev-parse HEAD} git_hash] == 0} {
        puts $log_fd "# Git Commit: $git_hash"
    }
    if {[catch {exec svn info --show-item revision} svn_rev] == 0} {
        puts $log_fd "# SVN Revision: $svn_rev"
    }
}

我曾经遇到一个问题：有次跑完整个后端流程后，发现结果无法复现。查了三天才发现，原来有人用git push --force覆盖了旧commit。从那以后我禁止在PD工作仓库中执行force push，并且所有push必须通过CI审核。

选型建议：怎么搭更顺

没有银弹。你得根据自己的团队结构来。

团队特征 推荐方案 原因
5人以内，脚本为主 纯Git（GitLab/Gitee） 分支灵活，本地操作快
10人+，大量二进制文件 SVN + Git LFS SVN管大文件，Git管脚本
跨团队协作，有外部IP交付 SVN（统一仓库）+ Git Mirror 权限可控，交付清晰

你想想看，工具只是手段。最终目标就一个：让调试过程可复现、可追溯、不乱。

← 上一章 📖 返回目录 下一章 →