4、协同设计中的DRC流程：多人协作时如何统一DRC规则？版本管理中的DRC检查策略
做封装设计，一个人闷头干的时代早就过去了。现在哪个项目不是三五个人一起上？
人一多，问题就来了。你用的规则文件是V1.0，我用的V1.1，他用的V1.0改版。最后合到一起，DRC跑出来几百个错误，谁都不知道是谁的锅。
嗯，这章我就专门聊聊这个——多人协作时，怎么把DRC规则管好。
4.1 统一DRC规则：别让规则成为“罗生门”
我见过最离谱的一次，项目组五个人，手里有五份不同的规则文件。有人从服务器拉的，有人从邮件附件拿的，还有人自己手动改了几行参数。
结果呢？流片前对图，发现A模块和B模块的间距规则都不一样。你说这怎么合？
核心原则：一个项目，一个规则文件，一个版本。
具体怎么做？我建议分三步走：
- 规则文件统一托管——别放个人电脑，别发邮件附件。放到版本管理工具里，比如Git、SVN。谁要用，自己去拉。
- 指定规则管理员——团队里必须有一个人负责规则文件的维护和更新。其他人只有读取权限，没有修改权限。想改规则？走流程，找管理员。
- 规则文件命名规范——文件名里带上项目名、版本号、日期。比如：
ProjectX_DRC_Rule_v2.1_20250315.rul。别用“最终版”“打死不改版”这种名字，你懂的。
小技巧：我习惯在规则文件头部加一段注释，写明这个文件的适用范围、修改历史、责任人。这样谁打开文件，一眼就能看到关键信息。
4.2 版本管理中的DRC检查策略：什么时候跑？谁来跑？
规则统一了，接下来就是“什么时候跑DRC”的问题。
有些人喜欢画完一整块再跑，有些人画一根线就跑一次。这两种我都见过，也都有问题。
画完再跑，万一错了，回头改的工作量巨大。画一根线就跑一次，又太浪费时间，影响效率。
我个人推荐的做法是——分层、分阶段检查。
| 检查阶段 | 检查内容 | 检查频率 | 谁负责 |
|---|---|---|---|
| 个人工作区 | 基础规则（线宽、间距、孔尺寸） | 每次提交前 | 设计者本人 |
| 模块级 | 模块内部完整规则 | 模块完成时 | 模块负责人 |
| 集成级 | 跨模块规则、全局规则 | 每次集成时 | 项目负责人 |
| 最终签核 | 全部规则 + 特殊检查 | 流片前 | 质量工程师 |
你看，这样分工就很清楚。每个人只负责自己那一段，出了问题也能快速定位。
注意：千万不要等到最后一刻才跑集成级DRC。我曾经有个项目，大家各自画得挺好，一集成，发现两个模块的电源地网络命名不一样，导致短路。这种问题早发现早解决，拖到最后就是灾难。
4.3 自动化DRC检查：让机器替你盯着
人总会犯错，但机器不会（只要配置对）。
我建议在版本管理工具里配置自动化DRC检查钩子（hook）。每次有人提交代码，自动触发DRC检查。检查不通过，提交就失败。
举个例子，用Git的话，可以在pre-commit钩子里加一段脚本：
#!/bin/bash
# pre-commit hook: 自动运行DRC检查
echo "正在运行DRC检查..."
drc_check -rule ProjectX_DRC_Rule_v2.1.rul -input $1
if [ $? -ne 0 ]; then
echo "DRC检查未通过，提交已拒绝！"
exit 1
fi
echo "DRC检查通过，继续提交。"
exit 0这样，谁想绕过检查都不行。代码进不了仓库，DRC就必须过。
实战经验：刚开始推自动化检查时，团队里肯定有人抵触，觉得麻烦。我的做法是——先在小模块试点，跑通一个流程给大家看。等大家尝到甜头（少了很多返工），自然就接受了。
4.4 冲突处理：当DRC规则和设计需求打架时
规则是死的，设计是活的。有时候，DRC规则和设计需求就是会冲突。
比如，某个关键信号需要走宽线，但DRC规则里限制了最大线宽。怎么办？
我的建议是：不要硬改规则文件。正确的做法是：
- 提出规则豁免申请（waiver），写明原因、影响范围、责任人。
- 由规则管理员审核，确认是否真的需要豁免。
- 审核通过后，在规则文件中添加豁免条款，并注明有效期。
- 所有豁免记录存档，方便后续追溯。
记住：规则豁免不是“开后门”，而是“走流程”。每一次豁免都应该有记录、有理由、有责任人。
4.5 版本回滚：DRC检查的“后悔药”
版本管理的好处之一，就是可以回滚。
假设你更新了规则文件，结果跑出来一堆新错误。别慌，用版本管理工具回退到上一个版本就行。
我习惯的做法是：
- 每次更新规则文件前，先打一个标签（tag），比如
DRC_Rule_v2.0_stable。 - 更新后，跑一轮全量DRC检查，确认没问题再正式使用。
- 如果有问题，直接回退到上一个稳定版本。
说白了，就是给自己留条后路。别把规则文件改死了，改坏了还能救回来。
4.6 本章小结：DRC协同的核心就三点
啰嗦了这么多，其实核心就三点：
- 规则统一——一个项目一个规则文件，版本管理，专人维护。
- 分阶段检查——个人、模块、集成、签核，各司其职。
- 自动化+流程化——让机器替你盯着，让流程替你管着。
做到这三点，多人协作的DRC流程基本就不会出大乱子。
嗯，这章就到这里。下一章我们聊聊更具体的东西——怎么用脚本把DRC检查跑得更快、更准。
可可精品资料库