企业官网建设流程全解析

做硬件设计最怕听到一句话：“板子回来了，但就是没反应。”不少人第一反应是查PCB布线、查焊接、查物料，但我这几年的经验是，相当一部分问题在原理图阶段就埋下了——DRC该报的没报，或者报了没人重视。在OrCAD Capture 17.4里把Design Rules Check配置到位，是成本最低的一道防线。

这篇文章不聊虚的，就围绕Capture CIS 17.4的DRC功能，把规则体系、电气规则矩阵、物理规则、报告解读、实战配置流程，以及我踩过的坑一次性讲清楚。不管你是刚画完第一块STM32F103C8T6最小系统板的新手，还是整天和DDR4、电源方案打交道的老人，这套东西都用得上。至少我看过的绝大多数原理图评审问题，最后都能追溯到DRC漏检或规则误配。

1. 先复盘一次打样返工：原理图DRC漏检的代价

1.1 那颗没供电的传感器

去年我经手过一块控制板，电源部分是一个LDO从12V降到3.3V，再分给主控、传感器和一个通信模块。原理图是三个工程师协作出图的，每个人负责几页，最后合并到一块板子上。评审时大家把目光都放在主控电路和接口上，没人认真跑一遍全工程DRC。结果样片贴片回来，板上一颗传感器死活没有供电。

拉出原理图查了半天，问题非常低级：传感器电源引脚通过Off-page Connector“3V3_S”连接到另一页，但另一页的供电网络叫“3V3”，而且那一页根本没有同名Off-page Connector。在屏幕上看起来，引脚旁边有个网络名标注，大家都默认“这是连到3.3V的”，可Capture只认Off-page Connector的名字匹配，不认你屏幕上看到的文字。如果当时勾选了“Off-page connector or hierarchical port has only one connection”这条物理规则，这个错误会在DRC报告里直接红字报出来。可惜默认配置下，这条规则不一定被认真对待。

这种问题不是个例。我见过太多“跨页网络看起来连着，实际网表里是断的”的情况，要么是名称大小写不一致，要么是拼写多了个下划线，要么是干脆忘了放Off-page Connector。原理图DRC存在的意义，就是在你还不用花钱打样的时候，把这些连接逻辑上的错误揪出来。

1.2 原理图DRC和PCB DRC是两码事

很多人一听到DRC，第一反应是“PCB那边不是也有DRC吗”。我得先把这个概念掰清楚：OrCAD Capture里的Design Rules Check，查的是原理图的连接逻辑、引脚类型匹配、跨页连接、位号规范性，它不关心线宽、间距、过孔。而Allegro PCB Editor里的Constraint Manager（也就是PCB DRC），查的是走线物理规则、间距约束、长度匹配这些。KLayout这类版图工具里也有DRC，那是针对芯片版图的几何验证。三者名字都叫DRC，检查对象和侧重点完全不同。

这篇文章只讲原理图DRC。它的核心价值是验证“设计者的电气意图”：这个引脚该不该连、那个网络有没有驱动、两个输出是不是被短在一起了。这些事情如果等板子回来再发现，那就是真金白银的损失。原理图DRC查的是逻辑，PCB DRC查的是物理，逻辑错了，物理做得再漂亮也是白搭。

2. 总控台认识：Capture 17.4里DRC的入口、配置与报告

2.1 入口与检查范围

在Capture CIS 17.4里，DRC的入口在菜单栏的PSpice菜单下，叫Design Rules Check，工具栏上通常也有对应的图标。不同小版本的菜单位置可能稍微有点差异，但用菜单关键字搜索“Design Rules Check”一定能找到。

运行前有个关键选择：检查范围。在工程管理器里，选中整个.dsn根节点，DRC就跑全工程；如果只选中某一个Schematic Page，就只查当前页。我的习惯是，平时改完哪一页就单页跑一遍快速验证，提交评审或导网表前，再对整个.dsn做一次全量检查。单页检查速度快、报错集中，适合增量开发；全量检查是最终防线，绝对不能省。

还有个前置条件容易被忽略：原理图必须先保存。Capture在DRC时读取的是磁盘上的当前设计状态，如果你改了图没保存，跑的其实是旧文件，等于白跑。我见过有人跑完DRC显示0错误，结果导出网表时才发现刚才的原理图根本没存，这种低级失误尽量避免。

2.2 配置对话框的三个Tab

进入Design Rules Check对话框后，核心配置集中在几个标签页里。不同版本布局略有区别，但逻辑大同小异：

• Electrical Rules选项卡：这是电气规则检查的主开关。里面列出了各项ERC检查项，勾选即启用。旁边通常有一个进入Electrical Rules Matrix（电气规则矩阵）的入口，矩阵是ERC最深层的配置，下一章专门讲。
• Physical Rules选项卡：物理规则检查项在这里，包括Off-page Connector匹配、层次端口连接、位号规范性、重复位号等。
• Options选项卡：输出设置。包括报告文件路径、是否在原理图上放置DRC Markers、是否把报告回写到Session Log等。

每个选项卡里都有大量开关，新手最容易犯的错是“全勾上”——把所有检查项全部打开，结果跑出来几百个警告，直接懵了；然后干脆全部关掉，只求网表能导出来。这两种做法都不可取。正确思路是按项目类型决定哪些规则必须为Error、哪些为Warning、哪些直接关闭，这需要理解每条规则背后的含义。

2.3 报告文件怎么读

DRC运行完成后，在Options里指定的路径下会生成一个纯文本报告，扩展名通常是.drc，和设计同名。打开报告文件，你会发现内容分两大类：Error和Warning。Error是必须处理的，它代表明确违反电气规则的问题；Warning是提醒，不一定错，但需要你确认。

报告里的每一条错误，通常包含规则名、对象信息（器件位号、引脚名、网络名）、出错坐标。有的版本还会在Session Log里输出摘要，比如“Errors: 3, Warnings: 12, DRC completed successfully”。

我的阅读顺序是这样的：先只看Error，把每条都定位到原理图上处理掉；然后回头过Warning，逐条判断是真实问题还是合理场景（比如POWER引脚接PASSIVE引脚这种常见但通常没问题的组合）。对于Warning，如果确认无风险，最好在矩阵里把它对应的组合关掉或降级，而不是每次跑都忍受那一堆噪音。

3. 电气规则矩阵拆解：引脚类型之间的“红绿灯”

3.1 引脚类型分类

电气规则矩阵是整个DRC系统的灵魂，但偏偏很多人从没打开过它。要理解矩阵，先要理解Capture给每个引脚分配的类型。在原理图库里，每个引脚都有Pin Type属性，常见的有：

• INPUT：输入引脚，只能接收信号。
• OUTPUT：输出引脚，驱动信号。
• BIDIRECTIONAL：双向引脚，既能输入也能输出。
• OPEN_COLLECTOR / OPEN_EMITTER / OPEN_DRAIN：开集/开发射极/开漏引脚，这类引脚允许线与连接。
• PASSIVE：无源引脚，电阻电容这类器件没有方向性。
• POWER：电源引脚，接电源网络。
• NC：内部无连接引脚，正常设计不应连接。
• THREE_STATE / HI_Z：三态或高阻引脚。
• UNSPECIFIED：未指定类型，通常是建库时偷懒留下的。

这些类型不是装饰。Capture判断两个引脚能不能连在一起，就是看它们类型组合在矩阵里是什么状态。如果建库时引脚类型乱设，矩阵再合理也白搭。

3.2 常用连接组合的默认诊断

电气规则矩阵是一张二维表，行和列都是引脚类型。某个交叉格的三种颜色状态，代表“这种连接组合”的处理级别：绿色是允许不报告，黄色是警告，红色是报错。双击格子可以切换颜色。

下面是我个人认为最有参考价值的连接组合诊断，默认值基础上结合我自己的工程经验修正过：

注意，默认矩阵里OUTPUT到OUTPUT通常是红色，这正是“多驱动源”检查的底层机制。如果你把某个芯片输出脚类型错设成PASSIVE，那它和另一个OUTPUT短接时，矩阵可能只给黄色甚至绿色，问题就被掩盖了。这也是为什么说“引脚类型错误是DRC失灵的根源”。

3.3 改矩阵之前先想清楚的事

矩阵的格子看起来可以随便点，但我建议改之前问自己三个问题：这种连接在当前电路里确实会出现吗？出现是设计常态还是异常？异常时我希望它报Error还是Warning？

举几个实际场景。数字电路板上，一个MCU的GPIO配置成开漏输出，外部接上拉电阻，这时GPIO引脚类型如果设为OUTPUT，那它连到上拉电阻的PASSIVE引脚时，默认可能是绿色，没问题；但如果同一网络上有另一个开漏输出，OUTPUT到OUTPUT就会报红色。正确做法是把真正开漏的引脚类型设成OPEN_COLLECTOR或OPEN_DRAIN，这样多条开漏线并处时矩阵给绿色，符合设计意图，同时如果误把普通推挽输出和开漏输出短接，矩阵依然能抓住。

再比如POWER到POWER，我在做多电源域电路时特别小心。如果两个不同的电源网络（比如3.3V和1.8V）不小心短接，而它们的端口类型都是POWER，矩阵可能只是黄色警告。我的做法是在矩阵里把POWER到POWER改成红色，宁可在后续设计里逐个确认正常情况，也不让真正的电源短路溜过去。

4. 物理规则与Options标签：跨页连接、位号与标记

4.1 Physical Rules逐项说明

电气规则矩阵管的是引脚“能不能连”，物理规则管的是图纸元素“规不规范”。Physical Rules选项卡里的检查项，逐个说意义：

• Off-page Connector检查：检查跨页连接器是否有且仅有成对出现。只有一端的Off-page Connector就是网络断头，必须报Error。多页原理图里，这是我最看重的一条规则。
• Hierarchical Port检查：层次原理图里，模块的端口和下层原理图的Hierarchical Pin必须匹配。名称不一致、类型不匹配，这里都会检出来。
• Duplicate Reference Designator检查：重复位号，比如两个R3。这种情况多发生在复制粘贴block后忘了重新标注，导网表时会互相覆盖，必须报Error。
• Part with no Reference Designator检查：器件没有位号。新放置的元件从库里调出来但如果没放置到位号，或者位号被误删，就能查出来。
• Invalid Reference Designator检查：位号格式非法，比如包含非法字符、以数字开头等。
• Same Part Number, Same Value, Different Reference检查：同封装同型号但位号不连续或异常，这个看团队规范，可开可关。

物理规则相对直白，不像矩阵那么抽象。我的建议是：默认物理规则全部打开，不要轻易关掉。它们误报率很低，一旦报错基本就是真问题。

4.2 Options里容易被忽略的选项

Options选项卡里有一堆容易被当成“无关紧要设置”的东西，实际影响很大。挑几个重点讲：

• 报告文件路径和命名：默认路径有时藏在工程目录的深处，不好找。建议设置一个显眼的DRC输出目录，方便直接打开。
• 在原理图放置DRC Markers：这个强烈建议勾选。运行后，问题位置会直接在图上有标记，双击标记可以快速定位到出错引脚或网络。不勾的话，你只能对着报告里的坐标猜位置。
• 检查深度：对于层次化设计，有些版本支持选择展开层次还是保持层次检查。我的经验是，最终全量检查时要选择展开到最底层，不然某些子模块内部的问题可能查不到。
• 报告详细程度：一些版本可以设置报告里是否包含每个网络/引脚的细节清单，如果只要错误摘要，可以关掉细节输出，报告会干净很多。

Options设置不当最典型的后果是：跑完DRC，报告生成在你找不到的地方，原理图上一个标记都没有，几百条警告只能靠人工在几百页图里翻——然后你就放弃了。我第一次用Capture时就是这种体验，后来养成习惯，每次新建工程先检查Options几项是否按团队标准配置好，后面省心得多。

5. 从零配置一套可复用的DRC模板

5.1 配置前置：画图阶段的三个习惯

DRC配置再合理，也救不了画图阶段的脏习惯。我总结三个影响DRC效果的前置习惯，这些比规则本身更基础：

第一，统一电源符号与引脚类型。从库中调用的电源符号，POWER引脚必须保证是POWER类型。很多人画原理图时图省事，直接放一个网络名标签当电源用，引脚类型可能是UNSPECIFIED，结果矩阵完全失效。正确的做法是使用Place Power符号（VCC/GND），并在元件库属性里确认Pin Type是POWER。

第二，不用的引脚必须放No Connect符号。悬空的引脚如果不加No Connect，DRC会报Unconnected pin；加了NC符号，Capture会知道这是故意不连。小技巧是画完一页后，先批量检查一下有没有漏放NC的悬空脚，再跑DRC。

第三，先Annotate再DRC。原理图复制粘贴模块时很容易产生重复位号。每次大改动后，先执行Tools菜单下的Annotate，做一次重新编号，再跑DRC。不要带着一批R?待定位号或重复位号去跑，否则报错里有一半是无效噪音。

5.2 分步配置流程

下面是我在17.4里从零配置DRC的完整流程，每一步都是实操验证过的，可以直接照着做：

第1步：打开DRC对话框。在工程管理器里选中.dsn根节点，菜单PSpice -> Design Rules Check，打开配置界面。

第2步：配置电气规则。在Electrical Rules选项卡里，勾选以下核心检查项：

• Unconnected Pins（未连接引脚）
• Unconnected Bus Nets（未连接的总网络）
• Single Node Nets（单节点网络）
• No Driving Source（无驱动源）
• Off-page Connector / Hierarchical Port有单一连接
• Output引脚连接Output引脚

第3步：配置电气规则矩阵。打开矩阵，按项目类型调整组合诊断。数字电路项目，我建议把OUTPUT到OUTPUT设为红色，POWER到POWER设为黄色，NC到任何类型设为红色。模拟电路项目，把POWER到PASSIVE设为绿色并人工确认，避免电源经过电阻的常见结构产生噪音。

第4步：配置物理规则。Physical Rules里全部勾选，包括重复位号、非法位号、无位号、Off-page Connector、层次端口匹配。

第5步：配置Options。设置清晰的报告输出路径，勾选放置DRC Markers，选择检查整个设计。

第6步：运行DRC。先处理所有Error，再逐条看Warning。修完一轮后重新运行，直到报告干净。

第7步：导出配置。如果这个配置用着顺手，把它保存成模板文件，放到团队共享目录。新工程直接加载模板，不用每次重新配。我所在的小组现在所有新项目都加载同一套DRC模板，评审时的规则基准完全一致。

5.3 不同电路类型的推荐配置

不同类型的电路，DRC配置的重点完全不同。我做了个小表格，把数字电路、模拟电路、电源板的推荐配置对个比：

数字电路里，总线网络多、驱动关系复杂，重点抓多驱动源和总线断头；模拟电路里，大量PASSIVE引脚和反馈网络，太严格的Power→Passive会让报告充满噪音；电源板最重要的就是电源域隔离，POWER到POWER必须按Error处理，绝不能放过任何电源短接的可能。

6. 高频报错排查链路与我的使用习惯

6.1 六类高频报错处理链路

配置好规则只是第一步，真正考验人的是报错出来之后怎么快速定位。下面按我遇到频率从高到低，把六类典型报错的完整排查链路写出来：

Unconnected Pins（未连接引脚）。报告里会给出器件位号和引脚号。定位到原理图后，先看这个引脚是不是故意悬空。如果是，放NC符号；如果不是，把连线补上。有一种情况容易迷惑人：引脚明明连上了总线，但总线段另一头没有对应网络名，或者Total Segment没有闭合。检查时把连着引脚的整条总线走一遍，确认不是“看着连上也断了”。

Single Node Net（单节点网络）。报告显示某个网络只有一个连接点。最常见原因是跨页连接器缺失或网络名不一致。用Filter功能选中这个网络，把网表里所有连接端列出来，数一数到底有几个节点。如果只有一个节点，基本可以断定是跨页断头。这时候去查这个网络名在别的页有没有同名Off-page Connector，没有就补，拼写不一致就改。

No Driving Source（无驱动源）。网络上有输入引脚，但找不到任何输出引脚。先检查是不是漏放驱动芯片或晶振起振电阻，再看驱动端引脚类型是不是被设成了PASSIVE或UNSPECIFIED，导致矩阵识别不出它是个输出。还有一种隐蔽情况：电源网络用POWER引脚驱动，但下游输入引脚类型被错误设成INPUT，矩阵判断不出来。

Output connected to Output / Multiple Drivers（多驱动源）。报错会列出冲突的两个引脚位置。先确认这两个输出是不是真的需要短接。如果是有意为之（OC门线与、总线切换），把引脚类型改成OPEN_COLLECTOR或THREE_STATE，并保证矩阵允许该组合；如果是无意短接，删掉多余连接。我的原则是：多驱动源必须搞清楚设计意图，没有明确依据的，一律按错误处理。

Off-page Connector has only one connection（跨页连接器单端）。报告给出断头的网络名。在全工程范围内搜这个名字，看是否只有一处。这种情况基本就是另一页的工程师用了不同的命名，或者忘了放连接器。修复后建议重新全量跑一遍，确认两侧连上了。

Duplicate Reference Designator（重复位号）。定位到两个相同位号后，用Annotate工具重新编号。注意，如果重复位号来自复制的模块，Annotate前最好先Reset Part Reference，再重新编号，避免新旧位号错乱。复用模块时，位号前缀统一，DRC出来的结果会清爽很多。

6.2 把DRC嵌进日常流程的经验

最后分享几个我多年养成的使用习惯，这些不是配置项，但比任何配置都重要。

第一，别等画完整个工程才跑DRC。DRC不是最终验收工具，是过程检查工具。我每画完一个模块就单页跑一遍，把问题消灭在产生当下。全图堆积到最后再跑，几十上百个报错铺过来，人的第一反应是烦躁而不是耐心排查。

第二，DRC报告要放进评审清单。我们团队每次原理图评审，第一件事就是打开DRC报告，从Error到Warning过一遍。没跑DRC或者报告有Error的图，直接打回。这能逼着每个人在评审前把自己的图收拾干净，比评审时肉眼找茬效率高太多。

第三，理解和尊重每一条警告背后的问题。我最不认可的处理方式，是一看到Warning就扔一句“这是误报”然后忽略。确实有误报，但在确认误报之前，先想想这条规则当初为什么要存在。比如POWER到PASSIVE的警告，确实常见，但偶尔它就是提醒你“这个电阻本来不该出现在电源回路上”。低噪音、高可信度的DRC配置，值得你花一个上午去调。

第四，遇到新类型报错，多留个心眼。如果你在原器件库、新封装或新集成芯片上遇到以前没见过的DRC报错，很可能是库的引脚类型建得不规范。这时候修的不是原理图，而是库。把库修对，全公司的人跟着受益，这比在原理图里硬塞NC符号漂亮得多。

老实说，DRC这套东西放在整个硬件设计流程里，看着不如布局布线那么“有技术含量”，但它恰恰是性价比最高的一环。多数打样返工的问题，在原理图阶段跑好DRC是能拦住的。希望你下次画完图，能认认真真把那份报告打开看一遍。