企业官网建设流程全解析

1. 两套EDA工具之间的原理图互转，到底难在哪里

硬件工程师的日常里，Altium Designer（下称AD）和OrCAD Capture（下称OrCAD）几乎是绕不开的两套原理图工具。大公司尤其是做通信、服务器、工控的老牌团队，历史项目库大多沉淀在OrCAD里；而中小团队、消费类电子、快速迭代的项目，AD的占有率又非常高。于是“把老OrCAD工程搬到AD里继续维护”或者“把AD画的图交给只认OrCAD的同事评审”就成了高频需求。

很多人第一次尝试互转，直觉反应是“另存为”或者“导出”，结果打开一看：元件符号全散了、网络标号丢了、总线断成一根根线、标题栏变成一堆乱码。这不是工具不行，而是两套软件的底层数据模型根本不一样。OrCAD的.dsn是二进制复合文档，符号、页、网络、属性都揉在一个文件里；AD的.SchDoc是分层的ASCII结构，符号库（.SchLib）和原理图是分离的。直接转换等于让两个说不同语言的人硬聊，必然鸡同鸭讲。

所以真正靠谱的互转，核心不是“转文件”，而是“转数据模型”——把符号、引脚、网络、属性这四样东西分别映射过去。标题里提到的“5个隐藏技巧”，本质上就是围绕这四样东西的映射做文章。下面我按实际项目里踩过的顺序，把整套流程拆开讲。适合正在做跨工具迁移的硬件工程师、需要维护历史项目库的团队，以及想搞懂EDA数据结构的进阶学习者。

2. 转换前的整体思路与方案选型

2.1 为什么不能直接“文件另存为”

先把这个坑说透。AD从很早的版本就提供了Import Wizard，理论上支持导入OrCAD的.dsn。但实测下来，这个向导对简单工程（几十个元件、单页）还能凑合，一旦遇到多页层次化设计、带变体（Variant）、带复杂总线别名的工程，导入后基本是灾难现场。原因在于向导走的是“几何图形级”转换：它把OrCAD里的线段、圆弧、文字当成图形搬过来，而不是当成“元件+引脚+网络”的语义对象。结果就是你看到一堆长得像电阻的图形，但AD不认为它是电阻，没有位号、没有封装、连不上网表。

注意：Import Wizard适合“看一眼老图长什么样”，不适合“接着往下画”。真正要维护的工程，必须走符号库+网表这条语义路线。

2.2 两条主流路线对比

实际项目里我总结出两条可行路线，各有适用场景：

我的建议是：如果这个工程后续还要改、还要评审，走第二条；如果只是拿来做参考或者直接进PCB，走第一条更快。下面重点讲第二条，因为它才是“隐藏技巧”真正发挥作用的地方。

2.3 转换的四个核心映射对象

不管走哪条路，你脑子里要始终盯着这四个东西：

• 符号（Symbol）：OrCAD的.olb库对应AD的.SchLib库，引脚编号、引脚名、引脚电气类型必须一一对应。
• 引脚（Pin）：这是最容易出错的地方。OrCAD的引脚有Passive、Input、Output、Power等类型，AD也有对应的Electrical Type，映射错了DRC会疯狂报错。
• 网络（Net）：网络标号、总线、电源符号的命名规则要统一，否则网表对不上。
• 属性（Parameter）：位号、值、封装、厂商料号这些自定义字段，是BOM的命根子，丢了就得重新填。

把这四个对象想清楚了，转换就从“玄学”变成了“体力活+细心活”。

3. 符号库转换的隐藏技巧

3.1 技巧一：用中间格式CSV做引脚映射，别硬转

OrCAD的.olb没法直接被AD读。网上有些教程说用“OrCAD导出EDIF再导入AD”，我试过，200个引脚以上的器件基本会丢引脚或者引脚名错位。更稳的办法是走CSV中间层。

具体操作：在OrCAD Capture里打开符号库，用Reports功能或者第三方脚本把每个符号的引脚信息导成CSV，字段包括Symbol Name, Pin Number, Pin Name, Pin Type, Position X, Position Y。然后在AD里用脚本（DelphiScript或VBScript）读这个CSV，批量生成.SchLib里的引脚。

为什么这么做更稳？因为CSV是纯文本，你能肉眼检查每一行，错了能改。而EDIF是嵌套结构，出错后你根本不知道错在哪一层。我做过一个484引脚的BGA，用EDIF转了三次都丢引脚，改用CSV后一次过，因为我在Excel里就能看到哪个引脚编号重复了。

提示：导出CSV时注意引脚的坐标单位。OrCAD默认用mil，AD也用mil，但有些版本OrCAD导出的是inch，要乘以1000。这个单位错了，符号会大得离谱或者小得看不见。

3.2 技巧二：引脚电气类型批量映射表

引脚类型映射是DRC报错的重灾区。OrCAD的引脚类型和AD的Electrical Type不是一一对应的，我整理了一张实测可用的映射表：

这张表看着简单，但如果你不批量处理，一个几百引脚的FPGA符号手动改类型能改到你怀疑人生。我的做法是在CSV里加一列AD_Type，用Excel的VLOOKUP把OrCAD类型映射成AD类型，再让脚本直接读这一列。这样映射规则集中在一处，改起来也方便。

3.3 技巧三：多Part器件的Part编号对齐

运放、逻辑门这类多Part器件（一个物理封装里有多个单元）是转换的另一个大坑。OrCAD里叫Parts per Package，AD里叫Part Count，但两者的Part编号逻辑不一定一致。比如OrCAD可能把电源引脚单独放在Part 5，而AD默认电源引脚跟着Part 1走。

处理办法：在CSV导出时，把每个Part单独导出一行，标注Part Number。在AD里生成符号时，用脚本按Part Number分组，确保每个单元的引脚归属正确。转换完一定要在AD里放一个完整器件，检查Part切换时引脚是否跟着变。我见过有人转完LM324，结果四个运放的引脚全挤在Part A里，PCB阶段才发现封装对不上，返工两天。

3.4 技巧四：符号图形用“最小可用”原则重建

很多人纠结OrCAD里符号画得漂不漂亮，想连图形一起搬过来。我的经验是：图形可以重建，但别追求100%还原。AD的符号绘制工具其实比OrCAD顺手，尤其是矩形、引脚阵列这些。转换时先把引脚和属性搞对，图形用AD的Place Rectangle和Place Pin快速画个方框加引脚就行。

为什么？因为符号图形不影响电气连接，只影响可读性。你花三天把图形1:1还原，不如花三小时画个清晰的新符号，剩下时间用来核对引脚。而且AD的符号库有自己的风格规范，硬搬OrCAD的图形反而显得格格不入。

3.5 技巧五：库文件命名和版本管理

转换完的.SchLib别随便起名。我的习惯是原库名_AD_日期.SchLib，比如MCU_STM32_AD_20240115.SchLib。这样一眼能看出源库、目标工具和转换日期。同时用Git或者SVN把库管起来，每次改动都有记录。硬件团队最怕的就是“这个符号谁改的、什么时候改的”说不清楚，版本管理能省掉大量扯皮。

4. 原理图图形与网络迁移的实操过程

4.1 第一步：在OrCAD侧做“体检”

动手转之前，先在OrCAD里把工程检查一遍。这一步很多人跳过，结果转到一半发现原图就有问题。检查清单：

• 运行OrCAD的DRC（Design Rules Check），把报错清干净。原图有错，转过去只会错上加错。
• 确认所有元件都有位号（Reference）和值（Value），没有?开头的未标注位号。
• 确认所有网络都有明确的网络标号，没有靠“自动命名”的隐式网络。
• 确认电源符号统一，别一半用VCC一半用VDD。
• 导出PDF备份，转换过程中随时对照。

注意：OrCAD的DRC和AD的DRC规则不一样，OrCAD过了不代表AD能过。但OrCAD这边先清一遍，能减少至少一半的转换后报错。

4.2 第二步：导出网表作为“连接真相”

在OrCAD里用Tools > Create Netlist导出.NET格式网表。这个网表是纯文本，记录了每个元件的每个引脚连到哪个网络。它是你转换后的“标准答案”——AD里重建完原理图，导出网表跟它对比，一致就说明连接没错。

网表长这样：

U1 STM32F103C8T6 U1-1 VDD U1-2 GND U1-3 PA0 ...

转换过程中，这个文件要一直开着，随时比对。

4.3 第三步：逐页迁移图形并重连网络

打开AD，新建.SchDoc，把OrCAD的每一页单独处理。我的做法是：

1. 在OrCAD里选中一页，复制（Ctrl+C）。
2. 在AD里粘贴（Ctrl+V）。这时候粘过来的是图形，AD不认元件和网络。
3. 用AD的Tools > Convert > Convert Selected Objects to...或者手动把图形替换成第3章转好的符号。
4. 重新连网络标号。这一步最费时间，但也是最不能省的。

有个提效技巧：AD支持从网表反标（Back Annotation）。你可以先把网表导入AD，让AD自动生成网络连接，再对照OrCAD的图形调整布局。这样比纯手工连线快很多。

4.4 第四步：网络标号与总线命名对齐

OrCAD和AD对总线的写法有差异。OrCAD里总线可能是DATA[0..7]，AD里要写成DATA[0..7]才认。如果OrCAD用了DATA0:7这种老写法，AD会当成普通网络。转换时统一改成AD的方括号格式。

电源网络也要注意。OrCAD的电源符号（Power Symbol）在AD里对应Power Port，但名字要一致。如果OrCAD用+3.3V，AD里也建一个+3.3V的Power Port，别用3V3，否则网表对不上。

4.5 第五步：网表比对验证

全部转完后，在AD里Design > Netlist > Create Netlist导出网表，跟OrCAD的网表做文本比对。用Beyond Compare或者WinMerge这类工具，逐行看差异。常见差异有三类：

• 引脚顺序不同：不影响连接，忽略。
• 网络名大小写不同：AD默认不区分大小写，但最好统一。
• 多出或少了网络：这是真问题，必须查。

我一般会写个简单的Python脚本做比对，把两个网表解析成{元件: {引脚: 网络}}的字典，然后对比差异。这样比肉眼快得多。

def parse_netlist(path): result = {} with open(path) as f: for line in f: parts = line.split() if len(parts) >= 2 and '-' in parts[0]: ref, pin = parts[0].split('-') net = parts[1] result.setdefault(ref, {})[pin] = net return result orc = parse_netlist('orcad.net') ad = parse_netlist('ad.net') for ref in orc: for pin in orc[ref]: if ad.get(ref, {}).get(pin) != orc[ref][pin]: print(f'差异: {ref}-{pin} OrCAD={orc[ref][pin]} AD={ad.get(ref,{}).get(pin)}')

这段脚本我用了好几年，每次转换都跑一遍，省了大量核对时间。

5. 常见问题与排查技巧实录

5.1 转换后元件“飞线”乱成一团

现象：打开AD原理图，元件之间全是飞线，但明明连了线。

原因：AD不认你画的线是“电气连接”，只当它是图形。AD里只有用Place Wire画的线才带电气属性，从OrCAD粘过来的线是Line不是Wire。

解决：选中所有线，用Tools > Convert > Line to Wire转换。或者干脆删掉重画，用Place Wire。我一般建议重画，因为转换后的Wire有时候网络归属还是乱的。

5.2 引脚名显示成乱码或问号

现象：符号引脚名变成???或者方块。

原因：OrCAD库用了非ASCII字符或者特殊字体，AD的字体不支持。

解决：在AD符号库里选中引脚，把Name字段改成纯ASCII。中文引脚名在跨工具转换里基本没有好下场，建议全部改英文。如果原图有中文注释，放到Comment字段里，别放引脚名。

5.3 位号重复或丢失

现象：转换后两个元件位号都是R?，或者位号直接空了。

原因：OrCAD里位号是实例属性，AD里位号是元件属性，转换时没映射过去。

解决：在AD里用Tools > Annotation > Annotate Schematics重新标注。但注意，重新标注会改变位号，如果PCB已经画了，位号不能变。这种情况要手动把位号填回去，用Properties面板批量改。

5.4 封装字段丢失导致PCB无法导入

现象：原理图转好了，导入PCB时提示“找不到封装”。

原因：OrCAD的封装字段叫PCB Footprint，AD里叫Footprint，字段名不一样。

解决：在AD里用Tools > Parameter Manager批量把PCB Footprint的值复制到Footprint字段。或者转换时在CSV里就把字段名改好。

5.5 常见问题速查表

5.6 独家避坑心得

说几个文档里不会写、但实际会遇到的坑：

第一，OrCAD的.dsn文件如果被高版本打开过又存回低版本，内部结构会变，转换成功率下降。转换前确认OrCAD版本，最好用和原工程相同的版本打开。

第二，AD的Import Wizard在导入OrCAD时，如果工程路径里有中文或空格，大概率失败。把工程复制到纯英文无空格路径下再转。

第三，转换大工程时，别一次性全转。按页转，转一页验一页。我见过有人一口气转完50页，结果第3页有个网络名错了，导致后面全错，排查花了整整一周。

第四，符号库转完后，在AD里跑一遍Component Rule Check，能提前发现引脚类型、重复引脚号这些问题。

第五，如果团队长期要维护两套工具，建议建一个“转换规范文档”，把映射表、命名规则、验证流程写进去。人员流动时，新人照着文档就能上手，不用每次都来问你。

6. 转换后的收尾与长期维护建议

转换完成、网表比对通过，不代表事情结束了。还有几件收尾工作要做。

首先是原理图的“可读性修复”。OrCAD的图形风格和AD不一样，转过来后字体、线宽、颜色可能很别扭。花点时间统一成AD的默认风格，后续评审时大家看着舒服。AD的Properties面板可以批量改字体和颜色，别一个个改。

其次是建立AD侧的符号库规范。转换过来的符号库往往命名混乱、分类不清。按功能分类，比如MCU、Power、Interface、Passive，每个库文件别放太多符号，控制在50个以内，方便查找和版本管理。

然后是文档记录。把这次转换的源工程版本、目标工程版本、转换日期、参与人、遗留问题都记下来。硬件项目周期长，半年后有人问“这个图怎么来的”，你能翻出记录，省很多事。

最后说个长期建议：如果团队同时用AD和OrCAD，最好指定一个“主工具”，另一个只做只读参考。双向维护两套原理图，迟早会不同步。我见过最惨的案例是一个项目两边都改，最后PCB用的是AD的网表，BOM用的是OrCAD的，采购回来的料跟板子对不上，整批板子报废。工具是为人服务的，别让人被工具牵着走。

转换这件事，说到底是个细心活。技巧再多，核心还是“引脚对引脚、网络对网络”地核对。我自己的习惯是转换完先跑网表比对，再跑DRC，最后人工抽查10%的网络。这三步走完，基本可以放心往下做PCB了。