上个月接了个有点折腾的活要把一批老项目的PADS 9.0原理图交给客户客户那边的标准设计环境是OrCAD 17.2。文件数量不少加起来几十页图纸重新画一遍根本不现实摆在面前的路只有一条格式迁移。结果试了一圈才发现PADS 9.0的老格式根本没法直接喂给OrCAD 17.2OrCAD 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样式再执行导出。检查位置高发问题预防措施网络名特殊字符被转义、加前缀网络标签统一用ASCII标准命名元件属性Description、Part Number丢失导出前用Parameter Manager统一字段电源符号Power Port退化成普通连线在AD中统一改成Power Port样式总线内部信号丢失、标签失效展开每条总线逐项检查图纸页页面顺序与原始设计不一致导出后手动核对并调整顺序5. 迁移后的无损核验照着这份清单逐项确认迁移做没做干净不能靠感觉要靠逐项核验。我一般把核验拆成五个维度全部过一遍才敢说这个迁移收工了。打开DSN不报错只代表文件完整离“无损”还差得很远。核验项方法通过标准分页结构在OrCAD工程窗格查看Sheet列表页数、页名称与原始设计一致元件属性生成BOM并与原始BOM对比位号集合、Value、Footprint完全一致位号唯一性运行Annotate检查不应存在重复或缺失位号网络连接抽查电源、地、时钟、复位等关键网络每个网络的引脚列表与原始设计一致跨页连接检查所有Off-Page Connector同名连接符成对存在没有悬空总线信号展开每条总线总线名和内部信号名与原始设计一致DRC/ERC在OrCAD中运行设计规则检查无ErrorWarning逐条确认可接受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里逐项验证占三分之一。这三个环节没有哪一步是可以省略的仪式感省掉的那一步一定会在后面的某个环节加倍找回来。如果你自己动手时撞上了没遇到过的新坑大概率还是出在特殊字符、总线、自定义符号这三类问题上围着它们重点排查比重新满世界找工具靠谱得多。
