企业官网建设流程全解析

上个月接了个有点折腾的活：要把一批老项目的PADS 9.0原理图交给客户，客户那边的标准设计环境是OrCAD 17.2。文件数量不少，加起来几十页图纸，重新画一遍根本不现实，摆在面前的路只有一条：格式迁移。结果试了一圈才发现，PADS 9.0的老格式根本没法直接喂给OrCAD 17.2，OrCAD Capture不认PADS的.sch文件，网上的第三方转换工具导出来之后网络乱成一团。最后真正跑通而且能稳定复现的路线，是把AD 21.7.2拉进来当中转站：PADS先进AD，在AD里完成修复和整理，再导出成OrCAD Capture能识别的DSN文件。

这篇文章就是完整记录这条中转路线的。里面有我实测过的导入导出参数、调试过程、每一处容易翻车的细节，以及迁移完成后逐项核验的方法。如果你也在面对类似的任务，不管是把历史工程切到Cadence环境，还是给客户交付指定格式的原理图，甚至只是想让一批老设计活到新工具链里，这篇文章应该能帮你省下不少试错时间。

1. 为什么非绕不可：PADS 9.0要交给OrCAD 17.2，直线通路基本不存在

先说结论：PADS 9.0到OrCAD 17.2不存在官方转换通道。这不是哪个工具能力不行，而是两家厂商在设计数据互操作这件事上的策略完全不同。OrCAD Capture的原生格式是DSN，它能读的第三方格式主要是EDIF、旧版PCAD这些，从来没有支持过直接打开PADS的逻辑图；PADS 9.0的原理图又是封装得很紧的二进制格式，除了PADS Logic自己，别的工具基本没法直接解析。你在OrCAD里翻遍Import菜单的所有文件类型过滤器，也不会有PADS这个选项。

1.1 OrCAD 17.2的输入兼容边界

我最初也抱过侥幸心理，想着都是原理图，格式再怎么封闭，总该给留个口子。实际上OrCAD Capture 17.2的导入能力非常有限，你的选择基本只有：打开旧版DSN、导入EDIF 2.0.0网络表、导入老版本PCAD文件，以及一些通用的网表格式。PADS Logic的项目文件、PADS导出的ASCII文本，都不在可识别范围内。所以“让OrCAD直接打开PADS工程”这条直线路径，从一开始就不存在。

1.2 第三方转换器为什么靠不住

网上确实有一些宣称能转PADS原理图的工具或者在线服务，我也拿一个中等复杂度的设计试过：导出的DSN打开后确实有原理图的样子，但位号丢了大概三成，十几个网络被随机重命名成了看不出含义的字符串，还有好几条总线直接是空的。最坑的是它不会告诉你哪里错了，你挨个检查一遍的时间，比重新画一遍还要久。这种工具拿来转几个器件的小Demo还行，碰上几十页的真实设计基本是灾难。

1.3 中转站方案的技术逻辑

所以当时我把目光放在AD 21.7.2上，是因为它正好卡在一个特殊的位置：Altium Designer在第三方格式导入上做了很多年积累，Import Wizard能识别PADS系的设计文件，进而转成AD工程；反过来，它又提供了输出OrCAD Capture DSN格式的选项，还分版本可选。这样一个“两头都通”的工具，天然适合当翻译官。而且中间多了一步人工介入的机会，PADS转进AD后，我可以先修一遍电气错误、理一下网络标签、统一元件属性，再导出DSN，比一步到位的转换可控得多。

1.4 先统一认知：无损迁移到底指什么

一个必须说清楚的事：EDA工具之间跨厂商迁移，不存在逐字节级别的无损。所谓“无损”，指的是电路信息在业务意义上完整保留，包括器件位号、数值、封装、网络连接关系、分页结构这些核心内容。至于绘图注释、排版位置、线型颜色这类非电气信息，多多少少会变，这些不必强求，强求也没用。用这个标准衡量，AD中转方案是有能力做到“业务无损”的，前提是流程中每一步都不能省。

2. 出发前先做体检：PADS端的数据整理决定转换效果的上限

数据迁移这件事，永远是源头决定结果。转换工具能做的，是把文件里的信息从一种格式翻译成另一种格式；如果原文件里本身就有重复位号、特殊字符、悬空引脚，转换之后这些问题只会被放大，不会自动消失。我曾经偷懒，直接拿了一份带几十个重复位号的设计去做转换，结果AD导入后DRC报警几百条，光清理就花了大半天。所以现在的习惯是：不管多急，先花一两个小时在PADS端把数据整理清楚。

2.1 位号唯一性与多Part器件检查

在PADS Logic里先生成一份完整的位号清单，逐个排查有没有重复。尤其要注意多Part器件，比如74HC04这种一个封装里包含六个反相器的芯片，原理图上显示为U1A、U1B这类写法，这种不是重复位号，但要确认同一只器件的各个Part没有被拆成不同器件。如果拆了，转换后很难重新合成一个整体，迁移后你会发现同一个位号出现多次，后面出BOM、导网表都会出乱子。

2.2 特殊字符与中文注释必须提前处理

原理图里最常出现的特殊字符是微（μ）、欧姆（Ω）、正负（±）、乘（×），这些字符在AD和OrCAD之间流转时是重灾区。AD导入时可能把μF里的μ映射成扩展ASCII字符，再导出DSN后，到OrCAD里大概率变成乱码。解决办法是在PADS端提前把这些字符全部替换成标准写法：μF写成uF，Ω写成Ohm，±写成正负号或者直接写“+/-”。这不是将就，是为了保证跨工具稳定。

中文注释我也建议在迁移前处理好。如果下游不需要中文，直接改成英文或者删掉；如果需要保留说明，单独导一份PDF原始稿作为参考，别让中文出现在转换链路里。转换工具对多字节字符的支持普遍不稳定，乱码的产生速度比你想象中快得多，而且一旦混进网络名里，排查成本极高。

2.3 跨页连接符和网络标签规范化

PADS的Off-Page Connector在OrCAD里对应的结构不太一样，转换时经常出现连接符只剩名字、关联关系丢失的情况。出发前逐页检查跨页连接符号的命名，确保每页的同名连接符是成对出现的。同时要把网络标签的大小写统一：IO0和io0在AD里会被当成两个不同的网络，到了OrCAD里也一样。如果你原图里没统一规范，转换后网络数量会凭空多出一截，而且极难看出来。

2.4 图纸尺寸统一与基线文件备份

把每页原理图的图纸尺寸尽量统一成标准规格。自定义尺寸的图纸导入AD后，比例会变化，元件坐标会显得很乱，后续整理页面要花额外的时间。最后在PADS里导出三份东西：一份ASCII文件（.txt）用于AD导入，一份PDF用于后续逐页对照，一份BOM用于迁移后的核对。这三份文件就是整个迁移项目的基线数据，后面所有验证都以它们为准。

3. 第一跳实操：PADS 9.0到AD 21.7.2的导入与清理

PADS到AD这一跳，我踩过的坑大多集中在导入方式选择和导入后的DRC清理上。很多东西不实际转一遍真的注意不到，比如单位选错导致全图元件跑偏，或者位号重复导致AD直接罢工。

3.1 推荐导入路径：ASCII导入比直接打开.sch更稳

首选做法是在PADS Logic里通过导出功能把设计转成ASCII格式（.txt），然后在AD 21.7.2中执行File里的导入向导，选择PADS ASCII这一项，按向导选择文件即可。这个方式最稳，AD大多数情况下都能正确解析。

如果PADS环境已经找不到了，手里只有一个.sch源文件，也可以试试导入向导里的PADS Logic文件类型，AD版本新一些的通常能读出来，但我对效果没有十足把握，需要实测。不管哪种方式，导入后AD都会生成一个新的工程文件，这时候先别急着导OrCAD，在AD里把每一页翻一遍，排布是否正常一眼就能看出来。

3.2 导入参数里最容易忽略的单位设置

导入向导里会询问一些选项，重点要确认单位。原图如果是用mil画的、导出时也是mil，那就选mil；一旦选了mm，所有元件坐标都会被缩放，整张图纸的位置关系全乱，后期手动调整的工作量非常大。还有一个关键原则：凡是涉及“保留原始网络名”“保留组件信息”之类的选项，一律选择保留原信息。跨工具转换的目的是尽量多地带东西过来，而不是让工具给你重新生成一套命名。

3.3 导入后的DRC必须跑一遍才踏实

导入完成后，在AD里跑一次Design Rule Check，重点看三类报告：重复位号、悬空对象、单端网络。这三类问题在转换后出现的频率极高，凡是报出来的都要处理干净。特别是重复位号，AD是按位号来关联元件信息的，位号一重复，后续导出DSN的时候可能直接丢元件。悬空引脚和单端网络也要清零，否则这些内容带进OrCAD里，DRC会继续报，到时候再修就麻烦得多。

3.4 总线是最容易静默损坏的部分

原图如果有总线，导入后一定要展开总线看看内部信号。常见问题是总线名还在，但总线里头的网络标签丢了，导致总线只是一个空壳，实际没有连上任何引脚。总线在DSN里最容易被静默损坏，因为它的信息结构比普通导线复杂，转换器很可能只保留了部分字段。所以每一条总线都要点开确认，别嫌麻烦，这个检查能拦住后面大部分网络错误。

3.5 与原始PDF逐页对照的优先级

在AD里把修好的图纸导出一份PDF，和PADS导出的原始PDF逐页做一遍对比。不需要追求画面像素级一致，但要按优先级核对：电源和地网络的去向、每个页面的主要元件位号、跨页连接标志、总线走向。这个步骤看着费时间，但能拦下大量隐藏问题。实际跑完你会发现，真正影响电气连接的差异基本都能在这轮对照里曝光。

4. 第二跳关键：AD 21.7.2导出OrCAD DSN的参数选择与坑

AD导出OrCAD DSN这一步，是整个流程里最容易“看起来成功”的环节。因为DSN文件只要不损坏就能打开，真正的问题都藏在打开之后，不会在文件加载阶段报错。

4.1 导出DSN的具体操作路径

AD 21.7.2里一般通过Save As或者Export命令，文件类型里选择OrCAD Capture Design（.dsn）。导出选项里会有目标版本相关设置，针对OrCAD 17.2要选17.x那一档。DSN格式的向下兼容性一直做得还行，实际使用中17.2打开同代的DSN没什么压力。如果你在当前菜单里找不到这个选项，直接在AD的帮助里搜“OrCAD”三个字母，基本上就能定位到具体入口，不同小版本的菜单位置会有细微差异。

4.2 导出前在AD里先清零ERC

我的习惯是导出前先在AD里做一次完整的ERC电气规则检查，并且把Warning级别的提示也过一遍。原因很简单：AD导出DSN并不是一个无损序列化过程，你在AD里的电气错误会被DSN的保存逻辑固化下来，到了OrCAD里还是同一个错误。与其等到了OrCAD里再处理，不如在源头清零。这一步花不了多长时间，收益却很直接。

4.3 元件自定义属性的映射规则

自定义属性是全流程最容易丢的部分。PADS里的Description、Manufacturer Part Number这类字段，在AD里能看到，但导出DSN后不一定能对应上OrCAD的属性表。解决办法是：导出前在AD里用Parameter Manager把要用到的元件属性统一整理一遍，命名成OrCAD习惯的字段名，比如Value、Footprint、Description，并且确保每一颗元器件都带着这几个参数。整理完再导出，丢失率会大幅下降。

4.4 导出后的网络名异常怎么分辨

总线网络或带特殊字符的网络导出后，有时会变成带前缀或编码形式的名称出现在OrCAD中。这不一定是错误，DSN内部记录网络名的方式决定了某些字符必须转义。但如果你发现原始业务信号名被随意加了后缀、改了前缀，那就得回AD检查网络标签本身的命名规范。网络标签越简单、越标准，出问题的概率越低。命名这件事上，任何工具都偏爱规规矩矩的ASCII字符串。

4.5 电源符号与普通连线的差异

AD的Power Port在DSN里会映射成OrCAD的电源符号，但如果原图里用的是普通导线加网络标号，而不是Power Port，导出后就只是普通网络连线，不会自动变成电源符号。这在电气连接上没问题，但会影响你在OrCAD里的DRC分类和排错效率，也会降低图纸可读性。所以真正讲究的做法，是在AD里把全局电源和地统一改成Power Port样式，再执行导出。

5. 迁移后的无损核验：照着这份清单逐项确认

迁移做没做干净，不能靠感觉，要靠逐项核验。我一般把核验拆成五个维度，全部过一遍才敢说这个迁移收工了。打开DSN不报错只代表文件完整，离“无损”还差得很远。

5.1 分页结构不必强求位置一致，但数量和名称必须对

先拿原始PDF和OrCAD页面做结构对比。最常见的迁移结果是页顺序错位，AD里Sheet的排列顺序不一定跟PADS原始页顺序相同，导出后需要手动调整。元件位置不一定要100%保留，OrCAD打开DSN后重新排布位置是正常的，不影响电气属性。真正要注意的是标题栏信息，PADS标题栏里的项目名、图纸名大多数情况下不会被迁移到OrCAD的Title Block里，这部分需要手动重新填写。

5.2 BOM对比是“业务无损”的核心判据

生成两份BOM，一份是PADS导出的原始BOM，一份是OrCAD生成的新BOM。用Beyond Compare或者Excel的VLOOKUP把位号列拉齐，逐行确认每一颗元器件的Value和Footprint是否一致。不要只对比总数，总数一致但具体位号错位的情况太常见了。这一步是判断“无损”最硬核的标准，过了这关，迁移的电气属性层面基本就有底了。

5.3 关键网络的抽检比全面检查更高效

在OrCAD里选中电源网络，右键查看连接的引脚列表，再对GND做同样操作。然后挑两三条关键信号，比如MCU的复位、外部晶振、ADC基准电压，逐个确认网络上的引脚与原始设计一致。电源、地、时钟、复位这些网络的出错后果是整板失效，优先覆盖；普通逻辑网络出错的概率相对低一些，按比例抽检就行。这个策略能把有限的时间花在最关键的风险点上。

5.4 发现问题时的回滚路径，千万别在OrCAD里手动改

如果某个Page发现了网络性问题，不要在OrCAD里直接动手改。因为OrCAD不是这次迁移的源头，你在OrCAD里手动修改等于把这个Page重新画了一遍，下次再走一遍转换流程，问题依然会复现。正确做法是：记下问题，回到AD里找到对应Sheet修复，再重新导出整个DSN，替换掉原文件。虽然看着多花了一点时间，但流程是闭合的，问题不会反复。

6. 来回折腾几趟后，我会这么推进这类迁移

最后聊一点流程上的体会。这类跨工具迁移，决定成败的往往不是某一项技术，而是整个流程的节奏和习惯。PADS到AD再到OrCAD这条链路本身不难理解，难的是在每个环节都保持足够的耐心和细致。

6.1 先做小范围试迁移，别拿大项目开刀

第一次跑PADS到AD再到OrCAD的完整迁移，不要直接拿最大的项目开整。挑一个只有一两页、但元件类型足够丰富的原理图，把完整流程先跑一遍。这一遍你能摸清自己这批设计的脾气，哪些符号会乱、哪些属性会丢、哪些页面会对不顺。有了这份经验再批量迁移，心里会非常有底。我见过不少人跳过这一步直接处理上百页的设计，最后花了成倍时间在几百条DRC错误里挣扎。

6.2 分批处理，每批留下中间存档

我通常以二十到三十页为一个批次，每处理完一个批次就导出一份PDF存下来。一旦后面发现某个问题扩散到了之前的批次，能通过存档快速定位范围，不需要把所有文件重新翻一遍。批量迁移这件事，过程管理和结果管理同样重要。

6.3 自定义符号不要硬撑，该换就换

PADS里如果画了特别复杂的自定义符号，比如带超长引脚的自制IC，导入AD后引脚间距可能被压缩，甚至引脚名互相重叠。这种情况不要在符号内部硬调整，把AD里显示异常的那个符号删掉，用AD标准库里功能等效的符号替换，然后手动重新连线。虽然操作上要多花一点时间，但至少导出DSN后的结果是可控的，不会给你留一个不知道什么时候会爆的雷。

6.4 走到“导网表给PCB”这一步才叫真正闭环

DSN能在OrCAD 17.2里正常打开，只是第一步。真正让迁移闭环的，是从OrCAD导出网表给PCB工具，PCB工具能无错解析网表里的所有网络和元件，这时候迁移才算真正可靠。我自己就遇到过一回，打开DSN一切正常，DRC也没有报错，结果PCB那边导入网表时发现某个网络死活找不到，回OrCAD一查，是个总线标签映射问题。这类问题用眼睛看很难看出来，只有在网表环节才会暴露。所以有条件的话，务必把迁移后的设计走到“导出网表给PCB”这一步再做交付。

跑过几轮完整的PADS到AD再到OrCAD迁移之后，我最大的感受是：跨工具迁移的本质不是转换，而是验证。文件能不能打开只是及格线，从源头整理、中转修复到目标环境核验，每一步都有它的账要还。以后我再接到类似任务，会把时间明确切成三块：整理源头占三分之一，在AD里修复占三分之一，在OrCAD里逐项验证占三分之一。这三个环节没有哪一步是可以省略的仪式感，省掉的那一步，一定会在后面的某个环节加倍找回来。如果你自己动手时撞上了没遇到过的新坑，大概率还是出在特殊字符、总线、自定义符号这三类问题上，围着它们重点排查，比重新满世界找工具靠谱得多。