1. 原理图编译检查到底在查什么1.1 从一次“翻车”经历说起画完原理图直接点“Compile”看到Messages面板里干干净净是不是就觉得万事大吉了我早年也这么想直到有一块板子打样回来上电后MCU的复位引脚一直处于低电平查了半天才发现是一个电源网络标号写错了一个字母而编译时居然没报错。那次之后我才认真去研究Altium Designer的编译检查机制才发现“编译通过”和“设计正确”之间隔着好几道关卡。Altium Designer 22的原理图编译检查本质上是一套基于规则的静态验证系统。它不会去理解你的电路功能对不对它只做一件事拿你设定的规则去比对图纸上的连接关系、网络命名、引脚属性把不符合规则的地方以警告或错误的形式抛出来。所以编译检查能帮你抓出“网络没连上”“两个输出脚怼在一起”“电源网络被短路”这类结构性问题但抓不出“这个电阻应该用10k却用了1k”这种设计意图问题。这套检查体系里最常被提到的两个词就是Validate和DCR。Validate是编译动作本身触发的即时校验你按下快捷键或者点菜单它立刻跑一遍DCR是Design Conflict Report设计冲突报告是编译后生成的一份结构化清单把所有违规项按严重程度分类列出来。很多人只盯着Messages面板看其实DCR才是更完整的入口。1.2 谁最需要把这套流程吃透如果你属于下面这几类人这篇内容值得你花时间看完刚转AD的硬件工程师从其他EDA工具过来不熟悉AD的编译逻辑经常被一堆莫名其妙的警告搞懵。独立开发者和小团队没有专门的评审流程原理图检查全靠自己编译检查就是最后一道防线。带新人的老手需要一套可复现的检查流程教给团队而不是每次靠“经验”口头传授。经常改板的人改一版编译一次如果规则没配好每次都要手动过滤大量噪音警告效率极低。我自己的习惯是原理图画到70%左右就编译一次把结构性问题先清掉画完再完整跑一遍DCR最后出图前再确认一次。这个节奏比画完再查要省心得多因为问题越早发现改动成本越低。1.3 编译检查的底层逻辑网络表与规则引擎要理解编译检查得先知道AD在编译时干了什么。简单说分三步构建网络表AD扫描所有原理图页把导线、网络标号、电源端口、引脚这些元素解析成一张“谁和谁连在一起”的网络表。这一步是基础如果网络表构建错了后面全错。应用规则拿工程里配置的Electrical规则比如“输出脚不能互连”“电源网络不能有多个驱动源”去逐条比对网络表。生成报告把违反规则的地方标记出来按Error、Warning、Info分级输出到Messages面板和DCR文件。这里有个关键点编译检查的严格程度完全取决于你的规则配置。默认规则很宽松很多潜在问题它根本不报。所以“编译通过”只代表“没有违反当前规则”不代表“设计没问题”。你得主动去收紧规则才能让它真正发挥作用。提示AD 22的默认电气规则里有些检查项是关闭的比如“Net with multiple names”同一网络多个不同名默认只给Warning如果你不关注就漏过去了。2. Validate与DCR两个入口一套逻辑2.1 Validate触发时机与操作路径Validate这个词在AD里出现的地方不止一处容易混淆。我梳理一下最常见的几个入口工程编译在Projects面板右键工程名选“Compile PCB Project”这是最完整的编译会重新构建所有网络表并应用全部规则。单页编译右键某一张原理图页选“Compile Document”只编译当前页速度快适合画图过程中快速自查。在线DRC在Preferences里开启“Online DRC”后画图时实时检查但原理图阶段这个功能用得少主要在PCB阶段。我一般用快捷键C CCompile PCB Project来触发完整编译用C DCompile Document来快速检查当前页。这两个快捷键建议记住比点菜单快得多。编译触发后AD会在后台跑一遍时间取决于图纸规模。小工程一两秒大工程十几秒。跑完后Messages面板会自动弹出如果没有弹出去右下角Panels里手动打开。2.2 DCR报告的生成与解读DCR不是单独一个按钮它是编译的产物。编译完成后在Messages面板里右键选“Export to Report”就能把当前所有消息导出成一份DCR文件。这份文件的价值在于可存档每次改版导出一份对比两版之间的差异能看出改动引入了哪些新问题。可分类DCR按违规类型分组比Messages面板的流水账清晰。可分享发给同事评审时对方不用打开工程就能看到问题清单。DCR里的每条记录包含几个关键字段严重级别Error/Warning/Info、违规类型如“Output Pin connected to Output Pin”、涉及对象具体是哪个元件哪个引脚、所在图纸。解读时优先看Error再看WarningInfo基本可以忽略。我踩过的一个坑是DCR里同一个问题可能重复出现多次因为AD会从不同角度报告同一个冲突。比如两个输出脚互连它可能既报“Output-Output冲突”又报“Net has multiple drivers”。这时候不要以为有很多问题去重后可能就一个。2.3 编译检查与ERC的关系ERC是Electrical Rule Check的缩写很多人把它和编译检查当成两回事其实在AD里编译检查就是ERC的实现方式。你配置的Electrical规则就是ERC的检查项。所以“跑ERC”和“编译工程”在AD语境下基本是一回事。区别在于有些EDA工具把ERC做成一个独立按钮AD把它融进了编译流程。理解这一点很重要因为这意味着你想调整ERC的严格程度不是去找某个“ERC设置”而是去改Electrical规则。注意AD 22里有个“Report Drc Violations”的选项那个是PCB阶段的别和原理图的DCR搞混了。3. 电气规则配置让编译检查真正有用3.1 打开规则配置的正确姿势规则配置入口在菜单Project → Project Options → Error Reporting和Connection Matrix两个标签页。这两个页面是配套的Error Reporting定义每种违规的严重级别Connection Matrix定义引脚类型之间的连接允许关系。我建议的配置顺序是先调Connection Matrix再调Error Reporting。因为Matrix决定了“什么算违规”Reporting决定了“违规后报什么级别”。顺序反了会来回改。Connection Matrix是一个二维矩阵行和列都是引脚类型Input、Output、Bidirectional、Passive、Power等交叉点的颜色代表允许程度绿色允许黄色警告红色错误。默认配置里有些红色其实过于严格有些绿色又过于宽松需要按项目实际情况调。3.2 关键规则项逐条拆解下面这张表是我自己项目里常用的规则配置列出来供参考规则项默认级别建议级别调整理由Output-Output冲突ErrorError必须保持两个输出互连会烧器件Output-Power冲突ErrorError输出脚直接接电源网络危险Input-Input冲突WarningWarning一般不致命但可能是设计疏忽Net with multiple namesWarningError同一网络多个名字极易导致连接错误Unconnected pinWarningWarning悬空脚需逐个确认是否有意为之Pin not drivenWarningError输入脚没有驱动源功能必失效Duplicate net namesWarningError重名网络必须查清把“Net with multiple names”和“Pin not driven”提到Error级别是我自己项目里抓出问题最多的两项调整。前者能抓出网络标号拼写不一致后者能抓出忘记接驱动的输入脚。3.3 规则配置的常见误区误区一把所有Warning都改成Error。这样会导致编译结果一片红真正的问题被淹没在噪音里。正确做法是分级处理致命的提Error可疑的保持Warning确认无害的降Info或关闭。误区二规则配一次就不管了。不同项目、不同设计阶段规则严格程度应该不同。比如画图初期可以宽松些出图前必须收紧。我习惯在Project Options里存几套配置按阶段切换。误区三忽略Connection Matrix。很多人只调Error Reporting不动Matrix。但Matrix才是决定“什么算冲突”的源头。比如你把Passive-Passive设成绿色那电阻电容之间的连接就永远不会报冲突哪怕实际连错了。提示AD 22支持把规则配置导出成文件团队协作时可以统一分发避免每个人配置不一致。4. 实操全流程从画图到出图的编译检查4.1 画图中期的快速自查画到一半的时候不用跑完整编译用C D编译当前页就够了。这时候重点看两类问题未连接的网络导线画了一半或者网络标号没放编译会报“Unconnected”类警告。明显的引脚冲突比如两个输出脚不小心连一起了。这个阶段不用追求零警告把Error清掉就行Warning留到后面统一处理。我一般每画完一个功能模块就编译一次这样问题定位范围小改起来快。4.2 完整编译与DCR导出画完之后跑一次完整编译C C。这时候Messages面板会列出所有问题。我的处理流程是先看Error逐条确认能改的立刻改改完重新编译。再看Warning分类处理网络命名类的批量改引脚悬空类的逐个确认。导出DCR右键Messages面板Export to Report存成HTML或文本格式。归档把DCR和工程一起存档作为这一版的设计记录。导出DCR的时候有个细节AD默认只导出当前Messages面板里的内容如果你之前清过面板历史记录就没了。所以建议编译完立刻导出别中途清面板。4.3 编译检查后的收尾动作编译检查通过不代表可以出图了还有几个收尾动作确认所有Warning都有合理解释比如某个引脚确实需要悬空那就在原理图上加个“No ERC”标记明确告诉AD这里不用检查。检查网络标号一致性用“Navigator”面板逐个网络点过去确认连接关系符合预期。更新PCB编译通过后用“Update PCB Document”把网络表同步到PCB如果同步时报错说明原理图还有隐藏问题。我自己的习惯是出图前把DCR里的每一条Warning都过一遍在图纸上做标记或者加注释这样评审的时候别人也能看懂为什么这里“故意违规”。5. 常见问题与排查技巧实录5.1 编译报错但找不到位置这是最常见的问题。Messages面板里双击某条消息AD会自动跳转到对应位置并高亮。如果跳转不准可能是图纸缩放比例问题按Ctrl End或者用Navigator面板手动定位。还有一种情况是消息指向的是“网络”而不是“元件”双击后跳到一个网络标号上但实际冲突在另一个地方。这时候用“Cross Probe”功能在Messages面板选中消息按Ctrl 点击消息AD会高亮所有相关对象。5.2 大量重复警告怎么过滤如果DCR里同一类警告出现几十次逐条处理效率太低。两个办法用规则降级如果确认这类警告无害去Error Reporting里把级别降到Info或关闭。用“No ERC”标记对特定引脚或网络加标记只屏蔽这一处不影响全局规则。我一般先用规则降级处理批量问题再用No ERC处理个别特例。两者结合能把噪音降到最低。5.3 编译通过但PCB同步报错这种情况通常是原理图里有“隐藏”问题编译规则没覆盖到。常见原因网络标号作用域问题AD的网络标号有全局和局部之分如果作用域设错编译时可能不报错但同步到PCB时网络表对不上。多图纸连接问题层次原理图里端口和页面的连接关系如果没配好编译可能漏检。元件封装缺失编译不检查封装但同步PCB时必须有封装缺了会报错。排查办法是在原理图里用“Compile”后再用“View → Workspace Panels → Navigator”逐个网络检查确认网络表构建正确。5.4 常见问题速查表现象可能原因排查动作编译无报错但功能异常规则太宽松漏检收紧Error Reporting级别同一问题重复报多次AD多角度报告去重后按一条处理双击消息跳转不准对象定位偏差用Cross Probe或Navigator警告太多无法处理规则未分级按严重程度分批处理编译通过但PCB同步失败网络表或封装问题检查网络作用域和封装5.5 几个我踩过的坑坑一忽略“Net with multiple names”。有次一个电源网络在两张图上分别叫“VCC_3V3”和“3V3”编译只给Warning我没在意结果PCB上这两个网络没连一起板子回来才发现。后来我把这项提到Error再也没漏过。坑二No ERC标记滥用。早期为了图省事给一堆引脚加了No ERC结果真正的问题也被屏蔽了。现在我的原则是每个No ERC标记都要写注释说明原因否则不加。坑三规则配置不随工程走。AD的规则配置默认存在工程文件里但如果换电脑或者重装配置可能丢。我现在的做法是把规则配置导出成文件和工程一起存版本库换环境时导入。坑四编译检查代替不了人工评审。编译检查只能抓结构性问题电气参数、器件选型、布局合理性这些它管不了。所以我的流程是编译检查人工评审双保险缺一不可。6. 把编译检查变成习惯说到底Altium Designer 22的编译检查不是什么高深技术它就是一个工具用好了能帮你省下大量调试时间用不好就是个摆设。我的建议是别把它当成出图前的一道“手续”而是把它融入画图的全过程。画一个模块编译一次改一处编译一次让问题在萌芽阶段就被抓出来。规则配置这块花半小时认真调一次后面每个项目都能受益。尤其是Connection Matrix和Error Reporting这两个页面值得反复琢磨。我自己的配置也是改了好几版才稳定下来现在基本能做到编译结果里Error为零Warning每条都有明确解释。最后分享一个小技巧AD 22支持把编译检查的结果直接生成PDF报告在Messages面板里选“Print”就能导出。评审的时候发给同事比截图清晰多了。这个功能我用得不多但在需要正式评审的场合挺实用。