第三章：设计规则与约束管理

大家好，我是你们的讲师。今天咱们聊聊设计规则与约束管理。说实话，这块内容在EDA工具里看着不起眼，但实际项目中，80%的协同问题都出在规则管理上。我见过太多团队，因为DRC规则没统一，最后投板前发现几百个错误，改得人仰马翻。

所以这一章，咱们就掰开揉碎了讲：统一DRC规则、约束文件的版本管理、规则冲突的解决机制。嗯，都是实战中踩过的坑，我尽量把经验都倒出来。

3.1 统一DRC规则的制定

DRC（Design Rule Check）说白了就是检查你的设计有没有违反工艺厂的制造能力。比如线宽不能太细、间距不能太小、过孔不能太靠近焊盘等等。每个工艺厂都会给一份DRC规则文件，但问题来了——这份文件通常有几百条规则，而且很多是“建议值”而非“强制值”。

我个人的习惯是：先做减法，再做加法。

• 减法：把工艺厂给的规则文件里，那些“建议值”全部删掉，只保留“强制值”。比如线宽最小0.1mm，那就只保留0.1mm，别留0.12mm这种“建议值”。
• 加法：根据项目特点，增加一些自定义规则。比如高速信号需要等长，那就加一条“差分对等长误差不超过5mil”。

举个例子，我之前做过一个射频项目，工艺厂给的规则里，过孔到铜皮的间距是0.2mm（建议值）。结果我们团队有人用了0.15mm，有人用了0.25mm，最后合图时发现一堆间距违规。后来我强制统一为0.2mm，问题就解决了。

3.2 约束文件的版本管理

约束文件（比如Allegro的.dcf、Altium的.DRC、PADS的.rul）是DRC规则的载体。但很多团队对约束文件的管理非常随意——有人直接改原始文件，有人用邮件传来传去，有人甚至用U盘拷贝。结果就是：版本混乱，谁都不知道当前用的是哪个版本。

我建议用Git来管理约束文件。具体做法如下：

1. 创建专用仓库：在Git上创建一个“项目约束文件”仓库，只放约束文件，不放其他设计文件。
2. 命名规范：文件名包含项目名、版本号、日期。比如：ProjectA_DRC_v2.1_20250315.dcf。
3. 提交信息：每次修改后，提交信息要写清楚修改了什么。比如“修改了差分对等长规则，从5mil改为3mil”。
4. 分支管理：主分支（main）只放经过评审的稳定版本。开发分支（dev）放正在修改的版本。

我曾经遇到过一个项目，因为约束文件版本混乱，导致两个工程师用了不同的规则，最后合图时发现200多个DRC错误。后来我们用Git管理，再也没出过这种问题。

3.3 规则冲突的解决机制

规则冲突是协同设计中最头疼的问题。比如：布局工程师想把电容放近一点，但布线工程师说间距不够。或者信号完整性工程师要求加粗走线，但工艺厂说线宽不能超过0.3mm。

解决规则冲突，我总结了一个三步法：

步骤	操作	说明
第一步	识别冲突类型	是工艺规则冲突？还是设计规则冲突？还是两者都有？
第二步	评估影响范围	这个冲突会影响多少信号？会影响多少层？会影响多少面积？
第三步	制定妥协方案	是放宽规则？还是调整布局？还是修改工艺？

举个例子，我之前做过一个高速数字项目，信号完整性工程师要求差分对间距不小于0.2mm，但工艺厂给的规则是0.15mm。冲突了怎么办？

我当时的做法是：先评估影响范围。发现只有3对高速信号受影响，其他信号都没问题。于是我们决定：这3对信号按0.2mm走线，其他信号按0.15mm走线。然后在约束文件里加了一条自定义规则，只针对这3对信号。

你看，规则冲突不一定非要“非黑即白”。灵活处理，才是实战中的常态。

3.4 知识体系总览

为了让大家更直观地理解本章内容，我画了一张图。这张图展示了设计规则与约束管理的核心逻辑：从规则制定，到版本管理，再到冲突解决，形成一个闭环。

这张图里，三个模块是顺序执行的：先统一规则，再管理版本，最后解决冲突。但注意，底部有个闭环箭头——规则冲突的解决方案，反过来会优化规则本身。这就是为什么我说“规则管理是一个持续迭代的过程”。

3.5 实战避坑指南

最后，分享几个我踩过的坑，希望能帮大家少走弯路：

• 坑1：规则文件里留了太多“建议值”。结果不同工程师理解不同，导致规则不统一。解决方案：只保留强制值，建议值全部删掉。
• 坑2：约束文件用邮件传来传去。结果版本混乱，有人用了旧版本。解决方案：用Git管理，每次修改都提交。
• 坑3：规则冲突时，直接改全局规则。结果影响了其他信号。解决方案：先评估影响范围，再制定局部妥协方案。

好了，这一章就讲到这里。下一章咱们聊聊协同布局中的信号完整性管理，到时候见。