ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

AD22原理图编译检查全攻略:从Validate到DCR闭环管理

2026/9/28 16:04:56 拓冰建站 浏览量
AD22原理图编译检查全攻略:从Validate到DCR闭环管理 画完原理图直接切到PCB这是很多硬件开发者的日常操作然后就是被一连串DRC报错教做人。说实话编译检查这一步要是省了后面填的坑远比你省下的时间多。这篇文章我基于 Altium Designer 22完整梳理一遍原理图编译检查该怎么做——从最基础的 Validate编译校验到编译完成后的 DCR 结果跟进把整条链路掰开揉碎。无论你是刚转行做硬件的新人还是被DRC报错折磨过好几轮的老手这中间都有值得对照检查一遍的地方。1. 为什么编译检查值得专门出一篇攻略AD22检查链路全景1.1 从绘图思维切换到工程思维原理图不只是画连线很多从学校出来的新手有个思维定式原理图嘛把元件拖出来Wire连上标上Net Label看起来跟参考设计一样就完事了。这个习惯最大的问题在于人眼识别的是视觉连接而 Altium Designer 识别的是网络连接两者经常对不上。举个例子你在画一个电源模块时从VCC网络拉了一根线但线头其实悬空在引脚旁边1毫米的地方肉眼看过去像是连上了编译后网络表里根本没这个引脚。这种问题在PCB阶段会演变成某引脚没有网络轻则功能缺失重则整个板子重新走线。编译检查就是把这些视觉误差强制转化为工程数据一次性扫出来。Altium Designer 22 的编译检查不是单一功能而是由校验动作、规则配置、结果处理三部分组成的完整链路。校验动作就是 Validate规则配置藏在 Project Options 里结果处理则落在 Messages 面板和后续的 DCR 跟进上。三者缺一不可。1.2 Validate、ERC、DRC、DCR四个术语到底谁管谁这四个人们容易搞混我先把概念理清楚。Validate验证/编译工程是整个检查流程的触发器快捷键 CtrlShiftV。它会编译整个工程把原理图中的电气连接关系、元件属性、网络标识等信息全部拉入编译引擎进行分析。ERCElectrical Rules Check电气规则检查是编译时执行的核心规则集藏在 Project Options 的 Error Reporting 和 Connection Matrix 里。它负责检查引脚是否悬空、输出是否有短路、电源连接是否异常等电气层面的问题。ERC 是 Validate 的一部分不是独立选项。DRCDesign Rule Check设计规则检查严格来说属于 PCB 编辑环境检查的是线宽、间距、过孔等物理设计规则。但原理图阶段也经常有人把 DRC 挂在嘴边实际指的还是 ERC 那些规则。我在文中用 DRC 时指的都是 PCB 阶段的设计规则检查别跟原理图编译检查混在一起。DCR在本文语境下我按工程实践中的常见理解来谈——它指的是Design Compiler Result的闭环处理也就是 Validate 跑完之后对编译引擎生成的结果逐条定位、判定、修复、确认的过程。很多人知道按 Validate 却不知道怎么消化编译结果DCR 就是把这后半段补齐。1.3 AD22的检查链路一条从原理图到PCB的必经之路完整的链路我按实际项目里的顺序列一下绘制/修改原理图确保工程文件结构完整.PrjPcb 工程下挂原理图库、PCB库、原理图、PCB。在 Project Options 里预配 Error Reporting、Connection Matrix、Comparator 三组规则。执行 Validate PCB Project触发编译与 ERC。Messages 面板弹出检查报告按级别分组查看。逐条定位错误双击跳转、交叉探测、筛选器修复后重新 Validate。重复步骤5直到关键错误清零必要时用 No ERC 标注刻意悬空或特殊连接。项目通过编译检查后通过 OutJob 输出 BOM、PDF、网表等交付物再进入PCB设计。这套链路里第2步和第5步是大多数人做得最不到位的。很多人装了 AD22 后默认规则一用就是一年矩阵里好几个关键引脚类型组合还是 No Report 状态等于把 ERC 关了半扇门。后面几章逐个展开说。2. 检查开始前必须确认的设置与工程环境2.1 工程文件结构与编译范围的坑先讲一个遇到无数次的问题点了 ValidateMessages 面板干干净净什么错都没报结果板子画完一打样就废。这种假通过十有八九是编译范围设置错了。选中工程文件.PrjPcb右键 → Project Options切到 Options 页签看 Net Identifier Scope网络标识符范围默认是 Automatic。如果是简单单图纸工程Automatic 通常没问题一旦涉及多图纸、层次设计这个值会影响网络标签Net Label、电源端口Power Port在不同图纸间是否互通。Automatic 对层次设计的识别有时会跟你的预期不一致稳妥的做法是单图纸工程选 Flat所有相同 Net Label 视为同一网络简单直接。层次设计工程选 Hierarchical按图纸符号Sheet Symbol的端口Port来建立跨图纸连接Net Label 只在单一图纸内有效。还有一个坑工程里的原理图如果没有真正加入工程处于 Free Documents 状态Validate 是不会检查它的。经常有人在工程外单独画了一张原理图怎么编译都不报错其实就是因为这张图压根不在编译范围里。检查方式在 Projects 面板里确认所有需要检查的原理图都在 .PrjPcb 节点下面而不是在 Free Documents 里。2.2 Project Options 三个入口Error Reporting、Connection Matrix、Comparator编译规则集中在三个页签里新用户最常忽略的是第三个。Error Reporting错误报告按规则大类列出几十种检查项例如 Unconnected Pin未连接引脚、Duplicate Part Designators重复位号、Net with multiple names网络多命名等等。每一项右侧都有报告级别下拉菜单可选 Fatal Error、Error、Warning、Info、No Report。这个页签管的是违反某条约定就报什么级别。Connection Matrix连接矩阵这是 ERC 的灵魂以引脚类型为横轴和纵轴交叉点定义某种类型的引脚连接某种类型的引脚时报告什么级别。里面涉及的引脚类型有 Input、Output、Bidirectional、Passive、Open Collector、Open Emitter、Power 等二十来种。矩阵默认值相对保守需要按项目需求人工收紧。Comparator比较器决定编译时是否对当前工程里的元件和库原件做对比以及对比出差异后如何报告。比如库里的电阻封装从 0603 改成 0402工程里的实体元件如果没有同步Comparator 就会生成差异记录并可能产生 ECOEngineering Change Order工程变更命令。这个页签的关键是把各类差异的报告级别设置合理否则每次编译刷出一堆无意义的元件已变更消息真实风险被淹没。2.3 关于运行环境大工程编译卡顿与内存占用的处理AD22 对多图纸、多通道的大工程编译时内存占用会肉眼可见地涨。很多人画着画着发现电脑越来越卡尤其是原理图界面缩放、拖拽都开始掉帧这时候先别怪电脑不行多半是编译器在后台维护大量编译数据。我实测过几个办法及时关闭不用的面板右下角 Panels 里把没在用的 Properties、Components 等面板关掉节省 GPU 和内存开销。清理 Messages 记录Messages 面板存的编译记录太多也会拖慢界面工程检查通过后右键清空。减少全工程高亮ShiftC清除过滤器是常用操作检查时别让过滤高亮残留太长时间。编译时关闭其他程序AD 是单核友好度有限的大型软件编译时开着几十个浏览器标签页会影响速度编大型工程前我会临时关掉非必要的软件。这些不是官方优化方案但实践中对 AD22 在大型工程场景下的稳定性帮助很明显。如果修改原理图后内存只增不减大概率是工程里加载了过多的孤立的库或者无效图片资源逐个排除也是一种能力。3. Validate实操把编译规则变成可执行的检查项3.1 一次标准的Validate操作流程操作本身很简单但细节决定成败。确认当前工程处于活动状态Projects 面板里工程文件名加粗说明它是当前工程。按 CtrlShiftV或者菜单 Project → Validate PCB Project。编译完成后 Messages 面板自动弹出显示所有错误/警告/Info。如果有层次设计注意看 Compiling 输出信息里是否包含所有子图缺失子图会导致部分网络无法参与编译。Validate 不是只能在一张原理图上执行它是针对整个工程的。所以即使你只改了其中一页图纸编译结果也会反映其他图纸相关联的问题比如跨图纸的网络名冲突、端口不匹配等。有一个 AD22 的新老版本差异可以提一下老版本里 Validate 的快捷键有时会被输入法吃掉导致按了没反应。这时候用鼠标点菜单最稳。3.2 严重级别怎么定Fatal、Error、Warning 别乱用报告级别不是越高越好。全设成 Fatal Error 的结果是Messages 刷出几百条红色真正致命的短路反而淹没在里面全设成 Warning 的结果是错误不红不黑容易跳过。我实践中建议这样分级级别适用场景Fatal Error出现这种问题设计根本无法进入 PCB 设计。例如 Power 引脚输出到 Power 引脚、Output 直接连 Output、重复位号导致元件无法区分Error电气连接存在明确风险进入 PCB 前应该清零。例如未连接引脚、悬空 Input、电源端口网络名拼写不一致Warning设计可疑但不一定错需要人工确认。例如元件在原理图中的位置重叠、某些引脚没有连接网络但有 No ERC 标记Info / No Report纯信息类提示或公司规范里明确允许的情况。例如某些网络命名风格提示、备用逻辑门的空置输入引脚已经做过处理我的习惯是把重复位号Output 对 Output 短路Output 对 Power 短路引脚没有连接到网络设为 Fatal Error 或 Error把元件描述缺失重复的网络名Off-grid 对象设为 Warning把无源元件引脚方向这类规范性问题设为 Info。具体怎么配每个团队有自己的 check list但核心原则是让红色保留给真正必须处理的电气问题。3.3 Connection Matrix 矩阵详解连线冲突怎么被发现的Connection Matrix 的原理可以用一句话讲它规定了A 类型引脚连接到 B 类型引脚时编译器要报告什么级别。打个比方你有一个运放输出Output直接和一个电源芯片输出Output接到同一个网络这在现实中是典型的输出互怼轻则功能异常重则器件烧毁。矩阵里 Output 行与 Output 列交叉点如果还是绿色的 No Report编译器就一声不吭这个隐患直接带到PCB。你需要在矩阵里把这个交叉点改成 Error 或 Fatal Error。我每次新建工程都会做一次矩阵瘦身必调的交叉点Output → Output必须报 Error防输出互怼。Output → Power必须报 Error防止输出直接短接到电源轨除非你是双电源轨切换设计并做了明确处理。Open Collector → Power可以 Warning因为开集电极输出经常上拉到电源这是正常用法。Passive → PowerWarning 或 No Report因为电阻、电容这类无源器件接到电源是常规连接。Input → Open CollectorNo Report开集电极驱动输入是标准接法。Power → PowerError两个不同电源网络短路的问题在这种检查里能暴露出来。矩阵是二维对称布局设置时经常会鼠标点混行列。我调完矩阵后都会故意做一个测试引脚连接来验证配置是否生效比肉眼检查可靠得多。3.4 Comparator 与 ECO库更新时如何避免误报Comparator 设置的原理理解起来不费力但实际使用中陷阱不少。它检查的对象是工程中的元件实例与源库中的元件定义之间的差异。典型场景你修改了集成电路库.SchLib里的一个运放符号把引脚1的名称从 IN- 改成了 FB保存后回到原理图执行 ValidateComparator 会报告运放 U1 的引脚 1 名称发生变化同时自动生成一个 ECO问你要不要把这些变化同步到原理图。我遇到过一个反面案例某个同事把库里的电阻符号批量调整了引脚位置画法不同但引脚含义没变Comparator 把每一个使用该电阻的图纸都报了引脚位置变更的 Error整个 Messages 面板被几百条同类信息塞满真正的连接错误反而被刷掉了。处理思路是Comparator 里对不影响电气连接的差异如引脚图形位置、引脚长度、线与线之间的视觉间距设为 No Report 或 Info对影响电气连接的差异如引脚名称、引脚编号、引脚电气类型设为 Error。这样既不会漏掉真变更也不会被无害差异刷屏。4. DCR环节从编译结果到可处理的错误清单4.1 先明确DCR在本文中的含义编译结果闭环管理进入 PCB 前把 Validate 产生的结果逐条消化掉我习惯称之为 DCR——Design Compiler Result 的闭环处理。它不是一个独立按钮而是一套工作方法拿到编译结果后不急着机械修改而是先分组、定位、评估风险、修复、复验直到 Messages 面板里没有一条需要处理的记录。那些用过多年 Altium 的人都有经验Validate 只是考试DCR 才是改错题。考试谁都会报名改错题才是拉开效率差距的地方。DCR 这项工作在 AD22 里主要依赖三个工具Messages 面板、交叉探测、筛选器。三者配合起来一个几百条报错的大工程也能在一小时内清完电气错误剩下的人工确认项再逐个过。4.2 Messages面板的正确用法分组、过滤、一键跳转Messages 面板看起来就是个列表但里面的分组功能被严重低估。面板底部有几个页签Class Type 和 Document 是最常用的分组方式。按 Document 分组能看出哪张原理图是错误重灾区优先处理按 Class Type 分组能把未连接引脚重复位号网络名冲突这类同类问题集中处理效率远高于上下翻列表。双击任意一条 Messages 记录原理图会自动跳到对应对象并放大到合适比例。这个跳转在 AD22 里很跟手定位率接近百分之百。如果你双击后没反应先检查 Messages 面板是不是处于锁定状态面板右上角图钉图标解锁后跳转才正常。我习惯的处理顺序是先把 Fatal Error 全部解决因为这类问题通常是全局性的比如位号重复会导致整个设计数据混乱修完以后很多 Error 会跟着消失它们可能是连环错误。然后按网络逐个处理 Error最后扫 Warning。处理完一条Messages 里条目会自动消失或变灰直到全部清空或确认无问题。4.3 交叉探测与筛选器从原理图反查错误点交叉探测Cross Probe是定位复杂网络的利器在 Messages 里选中一条记录右键 → Cross ProbeAD 会同时在高亮原理图中的目标并把相关网络的所有连接对象高亮显示。配合筛选器使用效果更佳。选中目标网络里的某个节点后在原理图右下角打开 Filter 面板输入 IsNet目标网络名整个网络的所有引脚、导线、标号都会被过滤出来其他对象变灰。这时候一眼就能看出这个网络上挂了多少个引脚、有没有引脚标了 No ERC、是否存在某个引脚没有真正连上。筛选器的另一个用处是反查某网络是否被编译识别。有时候你明明画了一根导线但网络名怎么都对不上筛选器输入目标网络名后如果什么都不过滤出来说明这个网络在编译数据里根本不存在原因大概率是导线只是视觉搭上而没有真正吸附到引脚端点。4.4 错误分级处理策略哪些必须清零哪些可以放行DCR 的结果不必是零错误零警告才允许进 PCB那些强行清零的做法反而会让你被迫对正常设计动刀。我的放行标准是电气错误Error 及以上强制清零没有任何商量。每个 Error 都代表一个电气隐患。Warning逐条人工确认。比如Unconnected Pin如果是刻意悬空且有 No ERC 标记就可以放行如果是真的忘了连必须修。Info可以保留在 Messages 里但要有意识看一遍。Info 往往提示设计习惯问题比如元件没有指定 PCB 封装这类问题不会影响电气连接但会在 PCB 阶段成为隐患。No Report代表不检查适合设置给你明确知道这个点不需要提示的规则。一个教训是放行的 Warning 要能在审核时被解释清楚。我在评审前会导出当前 Messages 面板的快照PDF 或截图标注哪些是确认放行的哪些是本次修复的。这样评审时不会被追问你这里为什么还有个警告。5. 高频编译报错的定位与修复实录5.1 位号重复与位号丢失最容易被忽略的低级错误报错信息类似[Error] Duplicate Part Designators: U1 at 120,250 and 180,250位号重复的根源几乎都是复制粘贴。比如你画一个运算放大器电路觉得结构类似直接 CtrlC 复制了一份新元件还保留着 U1 的位号两个 U1 出现在同一张图纸上。此时编译检查会判定两个元件无法区分整个设计数据都不可信。修复方式很简单菜单 Tools → Annotation → Annotate Schematics Quietly让 AD 自动重新编号。如果 Quietly 无法解决比如原工程已经有大量手工编号且被锁定就用 Force Annotate All 强制重排。重排前留意工程是否有跨图纸引用的位号习惯强制重排会改变所有图纸的位号评审和物料清单都会受影响。位号丢失比如新建的元件位号为空的报错通常出现在手动放置符号或从其他工程拷贝元件时。处理方式是选中该元件在 Properties 面板补上位号并加一个 Designator 注释然后重新 Validate。5.2 未连接引脚与孤立的单端网络报错记录长这样[Warning] Unconnected Pin: U3 Pin 6 (IN) [Error] Net N0-123 has only one pin未连接引脚的处理难点在于区分故意悬空还是忘记连接。比如一个双运放只用了一半另一半的输入端如果悬空输出状态不确定还可能通过寄生通路影响电源。规范做法是把未用运放的输入接成跟随器输出反馈到反相输入端或把输入接到一个确定电平而不是放任不管。如果你确定引脚就是故意不接比如某些测试点预留或者 IC 的 NC 引脚给引脚放一个 No ERC 标记放 X 符号或设置引脚属性里的 No ERCMessages 就不会报。注意别滥用我曾经在一个同事的图纸上看到整个芯片十几个引脚全挂了 No ERC结果有一个真正该连接的电源引脚也被遮住了最后上电烧了器件。网络只有一个引脚往往意味着导线没连到目标引脚或者 Net Label 打字少了一个关键字符。定位方法双击报错条目跳到对应网络把原理图放大到 400% 以上看导线是否从引脚端点有一个小方点吸附标记延伸出来。5.3 电源网络命名不一致与隐含连接报错信息[Error] Net VCC and VCC_3V3 are connected in a wire电源网络命名不一致是大型工程里最隐蔽的坑因为人眼看起来 VCC 和 VCC_3V3 好像没冲突但网络表里这是两个毫无关系的网络。典型场景一个电源模块的原理图里用 VCC主控部分的原理图里用 VCC_3V3两边都接到同一个电源芯片的输出结果编译后出现两个独立的电源网络PCB 里可能只连了一路另一路缺电。这个问题的修复要先改命名规范确定全工程标准电源网络名比如统一用 VCC_3V3然后全工程替换。替换时用菜单 Edit → Find Similar Objects在 Net Name 里填旧名把所有同类对象选出来统一改成新名。改完重新 Validate。关于大小写AD22 默认网络名不区分大小写VCC 和 vcc 会被当成同一网络。但如果你在工程选项里改了 Net Identifier Scope 或者个别库里的网络名用了大小写区分编译时可能把 vcc 和 VCC 当作两个网络。我的建议是规范统一用小写或大写别依赖系统的大小写容错。5.4 输出引脚对电源地的短路矩阵告警报错信息[Error] Net VOUT contains Output pin U2 Pin 4 and Power pin J1 Pin 2这类报错来自 Connection Matrix 里 Output→Power 组合的检查。它的本质是你的设计里把一个芯片的 Output 引脚直接连到了电源网络VCC/VDD/GND上。常见的合法场景有几个LDO 的反馈引脚其实是输入不是输出、开漏输出Open Collector/Drain连接上拉电阻到电源、某些传感器信号输出直接可以由外部电源驱动。这些场景分别对应矩阵里的不同引脚类型如果编译器还是报错说明你原理图里引脚类型属性设置不对。比如一个开漏输出芯片的引脚在原理图库里被误标成 Passive 或 Output编译器当然按 Output 处理。修复时打开源库把该引脚类型改成 Open Collector如果库里有这个类型可选或者放一个 No ERC 标记并在评审时说明。被动挨打不如主动把库修好这对整个团队都有益。5.5 一个综合排查案例从报错到解决的完整链路我举一个实际的排查链路帮助你把前面的知识点串起来。某次评审前工程编译结果有一条[Error] Net SDA_PWR contains Output pin U5 Pin 3 and Power pin R12 Pin 2看到这个我的第一反应不是改规则而是先搞清楚电路设计意图。U5 是一个 I2C 电平转换芯片Pin 3 是 SDA 侧的输出/双向引脚R12 Pin 2 接的是 3V3 上拉电阻。按矩阵默认规则Output 到 Power 是 Error。但 I2C 总线的 SDA/SCL 本来就是开漏/开集电极结构上拉是标准用法。我打开 U5 的源库检查引脚类型发现 Pin 3 被设成了 Output。实际应该设为 Bidirectional因为是双向数据线或 Open Collector。修改库中引脚类型保存并更新原理图里的元件实例Update Schematics再次 Validate这条 Error 变成了 Info问题解除。这个案例说明矩阵报错不一定是接线错也可能是元件库引脚类型定义不准确。排查时先看电路意图再看库属性最后才考虑是否放行。6. 编译检查之后输出文档、评审与交接6.1 用OutJob把编译报告整理成标准化交付物编译检查通过后除了原理图和 PCB还有一件重要的事把检查结果固化成文档。AD22 的 OutJobOutput Job文件就是干这个用的。在工程里新建一个 OutJob 文件File → New → Output Job可以配置多个输出任务生成 PDF 原理图、生成 BOM物料清单、生成网表、生成编译检查报告等。配置好一次后后续每次评审前只需打开 OutJob 点一下生成所有交付物批量输出省掉手工导出的重复操作。我最常用的一个组合是PDF 原理图带页码和位号、BOMExcel 格式、Messages 报告快照记录本次检查的错误/警告数量三条输出链一套带走。评审时直接给这三样东西比口述我检查过了有说服力得多。6.2 生成PDF原理图与检查记录的归档习惯归档这件事建议从项目第一天就养成习惯别到评审前才补。我见过太多项目因为版本混乱评审时不知道当前版本是 v1.2 还是 v1.3原理图里一堆旧网络名。我的归档流程是每次修改原理图并通过编译检查后在工程名上右键 → Save Copy As把工程另存为一个带版本号/日期的副本。同时用 OutJob 生成一份 PDF 原理图放到评审归档文件夹。用外部文件名标注检查状态比如2024-06-18_原理图编译检查_通过_版本v1.3.pdf文件名里就写清楚结果。PDF 原理图还有一个额外用途硬件评审时很多老工程师习惯在纸上标问题PDF 打印或标注都比直接在 AD 里看方便得多。6.3 与PCB设计交接前的最后清单编译检查通过不等于可以直接开始 PCB。下面这几项如果还没做PCB 阶段大概率会出幺蛾子所有元件都有有效封装编译时 Comparator 或属性检查会提示缺失封装确认每个元件都绑定了正确的 PCB Footprint。位号全部规范化编译后运行一次 Annotation确保没有空位号、重复位号。电源网络命名统一VCC/VCC_3V3/3V3 这类网络全工程统一。未连接引脚都有 No ERC 或合理处理刻意悬空引脚都标了 No ERC不会被误判也不会被遗忘。Messages 面板没有未处理的 ErrorWarning 可以放行但 Error 清零是底线。原理图页面没有 Off-grid 的对象在 DRC/编译检查阶段把原理图网格吸附打开避免导线端点不在网格上导致 PCB 导入时网络断裂。我给自己定的规矩每次改完原理图后的第一件事不是直接开 PCB而是 CtrlShiftV 编译一遍。这个习惯花不了十秒钟但能省下一个下午的查错时间。尤其是在用 AI 辅助生成原理图和 PCB 越来越普遍的今天自动生成的内容更要靠编译检查来兜底机器画图不一定比人更靠谱但编译检查一定能比人眼更快发现问题。