企业官网建设流程全解析

在 Cadence OrCAD 的电子设计流程里，DRC（Design Rules Check，设计规则检查）可能是最容易“跑完就算做完”的一步。实际项目里真正花时间的，往往不是运行检查本身，而是检查结束后那几十甚至上百条错误怎么浏览、怎么归类、怎么从一条错误文本反推到原理图上的某个引脚。OrCAD Capture 的 DRC 结果并不是只放在一个界面上，它同时存在于消息日志、报告文件和原理图标记三处，不熟悉这套输出链路的人，经常会出现“知道有多少错误，却不知道错误在哪一页”“双击错误不跳转”“报告文件打开不知道看哪列”的情况。

本文以 OrCAD Capture 为主要环境，整理一套适合 Cadence OrCAD 16.6 到 17.4 常见版本的 DRC 错误浏览顺序，解释 DRC 结果为什么分散在多处、每条错误应该怎么解读、怎样从错误定位到具体网络或元件，并补充 Allegro PCB Editor 中查看 DRC 的不同思路。内容适合正在做原理图检查、准备出网表、或者刚接触 OrCAD DRC 的硬件工程师和刚毕业的电子工程师阅读。

1. DRC 结果为什么难浏览：错误信息本身就分散在三个位置

1.1 原理图 DRC 检查的到底是什么

OrCAD Capture 作为 Cadence 前端原理图工具，它的 DRC 主要检查的是原理图阶段就能发现的电气连接问题，而不是 PCB 阶段的走线间距、过孔尺寸等物理规则。常见检查项包括未连接引脚、单节点网络、电源引脚未连接、总线宽度不匹配、元件封装缺失、重复位号、引脚类型冲突等。

这些规则有一个共同特点：每一条都对应一个具体的原理图对象。例如“未连接引脚”会精确到一个元件封装的某个引脚，“单节点网络”会精确到一个网络名或一对网络标签，“总线宽度不匹配”会落在某一段总线的起始或结束位置。所以 DRC 错误天然具有“结构化定位”的能力，问题只在于工具是否把这种定位清楚地暴露给了使用者。

需要区分的是，OrCAD Capture 的电路规则检查和 Allegro PCB Editor 的物理规则检查并不相同。前者发生在原理图阶段，后者发生在 PCB 布局布线之后。这篇文章的前半部分以 OrCAD Capture 原理图 DRC 为主线，最后一章再单独说明 PCB 阶段 DRC 的浏览差异。

1.2 一次 DRC 运行后，信息出现在三个位置

很多初学者以为 DRC 检查结束后，所有错误都会集中在一个类似“错误列表”的窗口里。实际不是这样。常见版本中，一次 DRC 运行完成后，结果至少会出现在三个地方：

这三处信息不是互相替代的关系。Session Log 适合实时操作，报告文件适合批量分析，DRC 标记适合确认最终残留问题。熟练的工程师通常是先看报告文件了解整体情况，再回到 Session Log 双击跳转，最后用 DRC 标记收尾检查。

1.3 浏览全部错误的核心逻辑：从文本定位回到图形定位

浏览全部 DRC 错误，本质上是在两条信息链之间来回切换。第一条链是错误文本链，它回答“哪条规则被违反、当时是什么错误内容”；第二条链是原理图对象链，它回答“这个错误发生在哪一页、哪一个位号、哪一个引脚、附近是什么网络”。

OrCAD 中双击 Session Log 中的错误条目时，工具会把原理图视图移动到该对象附近并选中它。这一步看起来简单，却是整个排错流程的关键。如果只盯着报告文本看错误内容，却不回到原理图确认实际连接，很容易误判错误原因；如果只凭 DRC 标记在图上一个个找，又容易漏掉那些没有生成标记或标记被隐藏的错误。所以下文先说明运行 DRC 前应该如何设置输出条件，再分三条路径说明浏览方法。

2. 运行 DRC 之前的选项设置，决定了你“能不能看到”全部错误

2.1 DRC 入口和检查范围要先对齐

在 OrCAD Capture 中，比较常见的 DRC 入口是主菜单的Tools -> Design Rules Check...，或者在项目管理器中右键点击原理图根节点（.dsn），在菜单中选择 Design Rules Check。不同版本菜单位置略有差异，但核心是同一个 DRC 设置对话框。

进入 DRC 对话框后，首先要确认检查范围。常见范围选项包括“整个设计”和“当前选中内容”。如果工程是分层的，还要确认是只检查当前根原理图，还是把所有层次化模块一起检查。

这里有一个实际项目中经常犯的错：只在当前打开的那一页原理图上运行 DRC，处理完后以为全工程已经没有错误，结果导出网表时又报出一堆问题。正确做法是：在需要完整交付原理图时，选择对整个.dsn工程运行 DRC；在只需要验证局部修改时，才选择当前页或当前模块。

2.2 快速规则与完整规则组的选择会影响错误数量

DRC 对话框中通常会有类似“Use Quick Rules”的选项。快速规则的本意是提供一个轻量级检查，只覆盖少部分最明显的规则，运行速度快，但覆盖面很窄。它的设计目标不是替代完整 DRC，而是让工程师在画图过程中快速抓住明显问题。

如果某个工程只用快速规则跑了一遍，得到“0 错误”的结果，并不能说明原理图没有问题。这一点需要特别注意。为了让 DRC 结果能反映真实的电气连接风险，建议在正式检查时关闭 Quick Rules 选项，启用完整的电气规则组。常见的需要保留的规则包括：

• 检查未连接引脚；
• 检查单节点网络；
• 检查电源引脚连接；
• 检查引脚类型冲突；
• 检查总线与信号宽度匹配；
• 检查重复条目和位号冲突。

并不是所有规则都适合一次全部打开。有些规则在当前设计阶段还没有意义，比如元件库尚未完善时报出的封装缺失警告；有些规则会和其他规则重复报错。更安全的做法是先建立一套“当前项目专用的规则组合”，而不是每次运行都临时勾选。

2.3 报告文件与 DRC 标记必须提前打开

浏览错误的前提，是错误信息被完整输出。许多使用者运行 DRC 后，只在 Session Log 里看到几条摘要，以为 DRC 只发现了这些问题，其实是因为报告文件没有生成，或者 DRC 标记没有被创建。

DRC 对话框中有一类和报告输出相关的选项，建议在每次正式检查前确认：

• 创建 DRC 报告文件。勾选后工具会输出一个文本报告文件，常见后缀是.drc或.log。
• 在原理图上放置 DRC 标记。勾选后工具会在出错位置生成图形标记，方便图纸上定位。

如果不勾选 DRC 标记，Session Log 里的错误仍然可以双击跳转，但原理图上不会留下持久的标记，检查完一页再回来时难以确认漏了哪个区域。

注意：DRC 标记是帮助定位的辅助对象，不是原理图原本的电气元素。在交付图纸前，通常要再次运行 DRC 或手动清除标记，避免把无关标记带入后续评审。

2.4 运行之后先看摘要，再进入逐条浏览

点击确定运行 DRC 后，Session Log 会追加本次检查的入口信息、错误条目和结尾摘要。摘要里通常包含：

• 本次检查的工程或页面范围；
• Error 总数；
• Warning 总数；
• DRC 报告文件保存路径。

不要直接开始逐条处理。先花十秒钟看三个信息：错误总数是多少、报告文件被保存到了哪里、有没有生成 DRC 标记。如果错误数量非常大，比如超过几十条，推荐先打开报告文件，按错误类型或页码分组后安排处理顺序；如果错误只有几条，直接在 Session Log 里逐条双击处理更快。

3. 三种浏览 DRC 全部错误的具体方法

3.1 路径一：通过 Session Log 逐条跳转到原理图对象

Session Log 是 DRC 运行后最常见的实时输出位置。处理少量错误时，最直接的办法是让 Session Log 保持可见，然后逐条点击或双击错误条目。

在常见版本中，Session Log 通常排列在主程序窗口底部，原理图编辑器会占用上方较大区域。如果 Session Log 没有显示，可以在主菜单的 Window 或 View 相关菜单里把它调出来，也可以尝试最小化当前原理图窗口，观察程序框架底部是否有 Session Log 标签。

操作顺序如下：

1. DRC 运行结束后，把 Session Log 窗口拖动到便于点击的位置。
2. 查看错误条目，每一条通常带有“#1”“#2”这样的序号，同时标注 Error 或 Warning。
3. 在需要定位的那一条错误上双击。原理图窗口会自动跳到相关页面，并选中出错对象。
4. 确认问题后回到 Session Log，继续处理下一条。

这个方法的优点是操作路径短，适合错误数量较少、页面相对集中的场景。缺点也很明显：当错误数量很多且散布在不同页面时，逐条双击会让视图频繁跳来跳去，容易迷失方位。建议在几十条错误以内使用。

如果出现双击后没有反应的情况，先检查当前光标是否落在错误条目的“文本”区域上，再检查原理图窗口是否已经打开。有的版本要求先单击激活原理图页面，再回到 Session Log 双击，第二次通常就能跳转。

3.2 路径二：通过 DRC 报告文件进行批量分析和筛选

当错误超过几十条，或者需要把 DRC 结果发给同事讨论时，Session Log 就不够用了。正确做法是打开工具生成的报告文件。

报告文件通常会保存在工程目录或用户配置的输出目录中，文件名一般与设计文件相关，例如demo.drc或demo.log。Session Log 末尾会给出本次报告文件的完整路径，这是最可靠的查找方式。

打开报告文件时，建议使用支持正则搜索和行号显示的文本编辑器，例如 Visual Studio Code、Notepad++ 或 Sublime Text。报告内容通常是纯文本结构，一个错误占一行或一个小段落，里面能看到：

• 错误编号；
• 错误类型或规则名；
• 错误所属的原理图页和坐标；
• 出错元件位号或引脚名；
• 错误的文字描述。

下面是一个用于说明思路的简化示例，真实版本中的文字可能不同：

#1 Error [DRCxxxx] Net has only one pin SCHEMATIC1 : PAGE1 : U2.5 #2 Warning [DRCxxxx] Unused input pin SCHEMATIC1 : PAGE1 : U3.B0

阅读这类报告时，真正有用的是后面那行“位置信息”。它把错误绑定到了SCHEMATIC1 : PAGE1这样的结构路径上，后面的U2.5通常表示元件位号 U2 的第 5 引脚。

在 Windows PowerShell 中批量统计错误数量，可以执行类似下面的命令：

Select-String -Path ".\demo.drc" -Pattern "^#\d+ Error" | Measure-Object

命令的含义是找出报告文件中以“数字编号 + Error”开头的行并计数。统计出错误数量后，还可以用文本编辑器的搜索功能，输入PAGE2、PAGE3这样的关键字，把同一页的错误全部筛出来。

建议把修复顺序和负责人直接写在报告文件后面的备注行中，例如“PAGE2 三处电源未连接由 B 同学确认”，这样 DRC 报告就变成了一个可追踪的整改清单。

3.3 路径三：利用原理图上的 DRC 标记进行图形化巡检

DRC 标记是在原理图上标注错误位置的图形符号。适合在不看 Session Log 的情况下，直接按图纸区域检查。标记得益于“所见即所得”，可以很快判断错误附近的电路结构。

处理 DRC 标记时要注意：一次 DRC 运行后，页面上可能出现很多标记，而且标记只代表“这一次运行”发现的问题。如果修改了原理图但没有重新运行 DRC，旧标记不会自动更新，可能指向已经修复的位置。

使用 DRC 标记的高效顺序是：

1. 先按页码浏览，每一页都看一眼标记分布。
2. 双击标记，让工具展开或选中对应对象。
3. 结合对象周围的网络标签、电源符号和引脚，判断实际电气连接是否有问题。
4. 修复后不要马上删除标记，留到整轮 DRC 重新运行后再统一清理。

如果原理图上没有出现 DRC 标记，最常见原因是运行 DRC 时没有勾选创建 DRC 标记的选项。此时可以回到 DRC 对话框重新运行一次，或者检查图形窗口中 DRC 标记图层/对象的显示开关是否被关闭。

3.4 三种方法的配合顺序

三种浏览方法不是三选一，而是一套从整体到局部的工作流。推荐顺序是：先看 DRC 报告文件的摘要和错误分布，决定从哪一页或哪一类问题入手；再回到 Session Log 逐条双击，定位到具体对象完成修复；最后用 DRC 标记做一轮图形化巡检，确认没有明显遗漏。

实际项目中，这种配合方式可以把“浏览错误”从简单点击提升为一次可管理的整改过程。

4. 浏览 DRC 错误时最常见的几个卡点

4.1 双击 Session Log 错误条目不跳转

现象：双击错误条目后，原理图页面没有切换，看不到任何被选中对象。

排查顺序：

• 确认当前是否存在打开的原理图页面。DRC 结果基于某一版本原理图生成，如果原理图文件被关闭，跳转就没有目标。
• 确认双击位置是否正确。有些版本只响应双击错误文本区域，双击空白处无效。
• 确认是否处于其他编辑命令状态。如果当前正在执行放置器件、放置网络标签等命令，可能无法跳转，先按 Esc 退出当前命令再试。
• 确认错误位置是否真的存在于当前工程中。如果原理图经过大改，旧 DRC 结果可能指向已删除对象，这时需要重新运行 DRC。

这类问题多数和视图刷新有关，而不是工具损坏。尝试最小化后再恢复原理图窗口，通常能立即看到跳转效果。

4.2 检查结果显示 0 错误，但导出网表时错误很多

现象：DRC 提示通过，导出网表或进入 Allegro 后却报出电源断开、器件缺失等严重问题。

这类情况通常与检查范围或规则组设置有关。常见原因包括：

• 勾选了 Quick Rules，只检查了很少一部分规则；
• 检查范围只选了当前页，没有覆盖整个工程；
• 相关错误在 Warning 级别被忽略，没有进入 Error 统计；
• 缺失的是封装库层面的问题，原理图 DRC 阶段并不负责检查封装是否存在，这个检查通常发生在生成网表或导入 PCB 阶段。

处理建议：重新运行完整 DRC，取消快速规则，把检查范围改为整个设计，并将关键规则提升为 Error 级别。对于封装缺失类问题，不能指望原理图 DRC 替你发现，需要在 Allegro 导入网表前单独核对封装清单。

4.3 报告文件中只有描述，没有精确坐标

现象：打开.drc报告文件后看到错误描述，但找不到类似页码、位号、引脚这样直观的位置记录。

原因有两种可能。一种是被检查对象本身没有明确的原理图位置，例如工程级的规则冲突；另一种是报告文件里使用了你在当前界面看不懂的表示方式。比如位置信息可能包含原理图页名、元件位号、网络名，需要和工程结构树对照着看。

处理建议：回到 Session Log，双击该条错误，以工具本身认定的“出错对象”为准。如果工具能跳转，说明对象在原理图中是明确存在的，报告文件里只是表达得更浓缩。

4.4 OrCAD Capture 与 Allegro PCB Editor 的 DRC 浏览差异

当设计进入 PCB 阶段，Allegro PCB Editor 中也有 DRC，但浏览方式与原理图阶段明显不同。PCB 上的 DRC 错误以图形符号形式散布在板内，关注的是间距、线宽、钻孔、跨接、开路短路、未连线和制造约束等物理规则。

在 Allegro PCB Editor 中，查看全部 DRC 的错误数量通常会使用显示状态相关菜单，通过状态面板可以获知当前几种主要规则的错误数量。对具体某一条 DRC，更常用的是在图上点击 DRC 符号，让工具把对应的两条或一组对象高亮出来，从而判断是哪两个铜箔、哪个过孔、哪条网络发生了冲突。

也就是说，Capture 的 DRC 浏览偏向“从目录到对象”，Allegro 的 DRC 浏览更偏向“从对象图还原冲突关系”。不能在 Allegro 中照搬 Capture 的处理习惯，也不能把 Allegro 的规则当成原理图规则来查。

5. 从一条 DRC 错误开始，完成从查看到修复的最小闭环

要验证“浏览全部 DRC 错误”的方法是否有效，可以找一个典型场景走一遍完整流程。下面用“未连接的电源引脚”类型错误作为示例，思路可以推广到其他错误类型。

假设本次 DRC 运行后，Session Log 中出现一条类似下面的错误，文字仅供参考：

#12 Error [DRCxxxx] Power pin has no connection SCHEMATIC1 : PAGE2 : U5.8

按修复流程走一次：

第一步，双击该条目，OrCAD 会把当前视图切换到 PAGE2 并放大到 U5 附近。此时仔细看 U5 第 8 脚附近有没有电源符号、网络标签或连接线。

第二步，确认该引脚的类型。如果它是电源引脚，却没有接电源符号，那错误成立，需要把对应的电源网络接到这个引脚。常见做法是连接一个电源符号，或者放置与电源网络同名的网络标签。

第三步，修复完成后，返回 Session Log，继续处理下一条。不要在同一处标记上停留太久。

第四步，当 Session Log 中可见的错误都处理完，再打开 DRC 报告文件搜索整个工程的Error关键字，确认修复过程中没有漏掉其他页面。

第五步，在整个工程所有页面都处理完毕后，重新运行一次完整 DRC，观察错误总数是否下降。如果错误数量没有减少或只减少了一部分，回到报告文件检查是否仍然存在同一页码的同类错误。

这套流程的核心是“每改一次，都要重新用一次 DRC 结果同步位置信息”。因为修复动作会改变原理图对象的结构，旧 DRC 结果中的位置信息可能失效。

6. 把 DRC 错误浏览固化为一套项目检查习惯

DRC 错误浏览的质量，最终取决于项目里的检查习惯。工具只是提供定位手段，浏览是否高效，还是看使用者有没有一套固定的处理顺序。

下面是一份可以直接复用的 DRC 前检查清单：

实际项目中，错误修复顺序建议按“先全局、后局部”处理。所谓全局，就是会导致网表失败或大量连带错误的项目，例如重复位号、缺失封装、网络名冲突；所谓局部，就是只影响当前页面电气连接的细节问题，例如某个未连接引脚、某个短暂未指认的输入。先处理全局问题，再局部排查，可以避免修完局部错误后，因为全局问题需要重新梳理而白做。

当项目设计到分层结构时，DRC 浏览还建议按层次模块来分配。比如基层模块由各模块负责人各自检查并负责清除错误，顶层最后再统一跑一次完整 DRC。此时报告文件的作用非常重要，因为顶层错误往往来自多个子模块，只有把报告文件按原理图页路径分组后，才能把错误准确地分配给对应负责人。

在后面做更高效率提升时，可以考虑维护一份“本团队常用 DRC 规则集”。不同项目对电气规则的严格度不一样，但同一团队常见项目之间有很多共性。把当前项目验证过的规则组合保存为模板，下次新项目直接导入，能减少因临时勾选或漏选项导致的无效 DRC。

对刚开始接触 OrCAD DRC 的工程师，练习建议很明确：不要只盯着 Session Log 里的错误总数，而是从一条错误出发，练习“双击跳转、查看报告、处理标记、重新运行”这个循环。当你能在一份 50 条错误的 DRC 报告里快速说出“哪些错误集中在 PAGE2、哪些是电源连接问题、哪些是总线问题”时，浏览 DRC 就不再是阻碍效率的环节。