企业官网建设流程全解析

简介：本资源是一份系统化、图文并茂的OrCAD电路设计入门与进阶教程，专为电子设计初学者及PCB工程师打造，聚焦信号完整性分析场景下的核心操作能力提升。教程基于于博士信号完整性研究网（sig007.com）权威内容整理，覆盖Capture CIS原理图绘制全流程：从工程创建、元件库管理（含自建与分裂）、不规则/多部分元件绘制，到网络表生成、总线连接、PI/SI分析基础等19个关键模块，尤其深入解析instance与occurrences等易混淆概念，直击实际设计痛点。资源为单个2.23MB的DOC文档，结构清晰、步骤详实、配图丰富，适合作为案头速查手册或系统学习指南。目前已有345人下载学习，内容完整覆盖原理图设计全链路操作，是掌握OrCAD信号完整性协同设计能力的高实用性参考资料。

1. OrCAD Capture CIS 图文教程：不是“画图软件”，而是信号完整性设计的第一道闸门

你有没有遇到过这样的情况：原理图明明画得一丝不苟，PCB布完线后一上电，时钟边沿就抖得像老式收音机调频——示波器上看不清上升时间，眼图张不开，串扰超标，电源噪声压都压不下去。查来查去，最后发现根源不在 layout，而在 Capture CIS 里一个管脚类型设成了 Passive，而不是 Input；或是一个电源网络没打上POWER属性，导致 PI 分析时直接被忽略；又或者分裂元件的各 part 之间 netname 没对齐，网表导出后电源引脚和地引脚在 Allegro 里根本连不上……这些不是“画错了”，而是原理图语义没建对。

OrCAD Capture CIS 不是 AutoCAD 那种纯图形工具，它是一套带电气语义的、可追溯的、支持 CIS（Component Information System）驱动的设计入口。它真正价值不在“能画多漂亮”，而在于：能否把芯片手册里的电气定义，无损、可验证、可复用地翻译成机器可读的连接逻辑。这份由信号完整性研究网整理的图文教程，不是教你怎么点菜单，而是帮你建立一套“从器件手册→原理图符号→管脚属性→网络命名→网表生成→SI/PI 分析”的闭环思维。它覆盖了从新建工程到输出 netlist 的全部关键链路，尤其聚焦于 instance/occurrences 区分、分裂元件建模、footprint 属性绑定、总线命名规范等容易被跳过的“语义锚点”。适合刚接手高速数字电路设计的硬件工程师、需要对接 SI/PI 仿真团队的原理图设计师，以及正在从 Altium 向 Cadence 生态迁移的团队——别急着画第一根线，先让 Capture 知道你画的到底是什么。

2. 理解 Capture CIS 的底层逻辑：instance 与 occurrences 是原理图可维护性的分水岭

2.1 为什么必须分清 instance 和 occurrences？——从“改一个 vs 改全部”说起

在 Capture CIS 中，instance指的是元件的逻辑模板，它定义了图形结构、管脚数量、电气类型（Input/Output/IO/Bidir/Power 等）、封装名（Footprint）、Part Number、Vendor ID 等所有可被多个实例共享的元数据；而occurrences是该 instance 在原理图页面上的具体放置体，它继承 instance 的全部定义，但可以拥有独立的位号（RefDes）、值（Value）、自定义属性（如SIGNAL_GROUP）、甚至局部修改的管脚属性（需显式更新 instance）。

这个区分直接决定你后续所有操作的颗粒度和风险等级。举个真实翻车案例：某项目中用了两片完全相同的 DDR3 PHY 芯片（型号一致、封装一致、手册一致），设计师在 page1 上放了一个 occurrence，右键 → Edit Part → 把第 12 脚（原为 VREF）临时改成 NC（No Connect），选了 Update Current。结果 design cache 里立刻多出一个同名但来源为.dsn的新 instance。第二片芯片放上去时，他没注意下拉框里有两个 AD9780，随手选了旧的那个——于是第二片芯片的 VREF 脚仍被识别为电源，SI 仿真时该网络被当作低阻抗电源处理，而实际硬件上它悬空，最终导致参考电压漂移，接收端误码率飙升。

提示：Capture CIS 默认不会自动同步 occurrence 对 instance 的修改。任何通过 Edit Part 做的改动，都必须明确选择 Update Current（仅更新当前 instance）、Update All（更新所有同名 instance）或 Cancel（放弃）。没有“默认全改”这回事。

2.2 实操验证：三步定位当前 occurrence 绑定的是哪个 instance

打开任意一张已放置元件的原理图页（如 page1），按以下步骤确认其底层绑定关系：

# 步骤1：选中目标 occurrence（例如 U1） # 步骤2：右键 → Properties（不是 Edit Part！） # 步骤3：在弹出窗口中查看 "Part" 栏 —— 这里显示的是 occurrence 的位号（U1）和所属 instance 的名称（AD9780） # 再看 "Library Path" 栏 —— 若路径指向 .olb 文件（如 C:\Cadence\SPB_17.4\tools\capture\library\analog.olb），说明绑定的是库 instance； # 若路径显示为 ".dsn" 或 "Design Cache"，说明该 occurrence 已脱离原始库，使用的是本地修改后的 instance。

这个Library Path就是你的“血缘证明”。它决定了：

• 当你更新元件库（比如厂商发布了新版 .olb）时，哪些 occurrence 会自动刷新（绑定库路径的）；
• 哪些 occurrence 会被跳过（绑定 .dsn 的），必须手动执行 Tools → Update Parts → From Library 才能拉取新定义；
• 在生成 BOM 时，“Part Number” 字段取自 instance 的属性，而非 occurrence 的 Value 字段——这也是为什么 Value 可以写成 “100nF”，而 BOM 表里必须显示 “GRM31CR71C104KA01L”。

2.3 instance 的生命周期管理：什么时候该新建，什么时候该复用？

注意：Capture CIS 的Design Cache不是缓存文件夹，而是当前设计数据库（.dsn）的内存映射视图。它实时反映所有已放置 occurrence 所引用的 instance 来源。不要试图手动删除.dsn\cache\下的文件——这会导致设计数据库损坏，轻则丢失元件关联，重则整个工程无法打开。

3. 工程创建与元件库加载：避开“空库陷阱”和“路径幻影”

3.1 新建工程时的三个致命选项：为什么不能选 OrCAD Capture？

启动程序时，界面弹出的组件列表中，必须选择 OrCAD Capture CIS，而非 OrCAD Capture。二者核心差异如下：

提示：若误选了 OrCAD Capture，关闭软件后需手动删除工程目录下的project.opj和project.dsn，再重新启动并选 CIS。切勿在错误环境下继续操作——已创建的.dsn文件无法升级为 CIS 模式。

3.2 加载元件库的正确姿势：add library ≠ 可用

很多新手以为点击Place → Part → Add Library选中discrete.olb就万事大吉，结果在 part list 里搜不到常用电阻。这是因为：Capture CIS 的库加载是“按需索引”，不是“全量加载”。Add Library只是告诉软件“这个 .olb 文件我可能要用”，但真正让元件出现在 part list 里，还需完成以下两步：

1. 确保库文件路径合法且无中文：
   Capture CIS 对路径中的空格、括号、中文字符极度敏感。例如C:\Program Files\Cadence\SPB_17.4\tools\capture\library\是安全路径；而D:\我的库\模拟器件\analog.olb极大概率导致加载失败，报错Cannot open library file。解决方案：将所有 .olb 文件统一放在C:\Cadence_Lib\这类纯英文无空格路径下。

2. 强制刷新库索引：
   即使路径正确，首次加载后也需手动触发索引重建：

   # 步骤1：主菜单 → Options → Preferences → Library # 步骤2：勾选 "Refresh library list on startup" 和 "Enable library indexing" # 步骤3：点击 "Rebuild Index" 按钮（位于窗口右下角） # 步骤4：重启 Capture CIS

   此时再打开Place → Part，discrete.olb 中的 RESISTOR、CAPACITOR、INDUCTOR 才会真实出现在 part list 中，且支持按Value、Tolerance等属性过滤。

3.3 元件库的层级真相：design cache 不是你想象的“缓存”

工程管理器中Design Cache文件夹下显示的元件，并非从 .olb 复制过来的副本，而是指向原始库文件的符号链接（Symbolic Link）。它的存在意义是：当多个 occurrence 引用同一 instance 时，Capture CIS 无需重复加载图形数据，节省内存；当库文件更新时，所有绑定该库路径的 occurrence 可一键同步。

但这也带来一个隐蔽风险：如果你把discrete.olb复制到工程目录下并Add Library，那么Design Cache中的元件路径会变成.\discrete.olb。一旦你移动工程文件夹，路径失效，所有 occurrence 显示为红色叉号（Missing Part），且无法通过Update Parts恢复——因为软件找不到相对路径下的 .olb。

正确做法：所有 .olb 库文件必须放在固定全局路径（如C:\Cadence_Lib\），并在Options → Library Path中添加该路径。这样无论工程移到哪，只要库路径不变，design cache 就永远有效。

4. 创建与编辑自定义元件：从“画不准”到“语义准”的四层校验

4.1 创建新元件前必做的四件事

不要急着点File → New → Library。在新建任何自定义元件前，请完成以下校验，否则后续 80% 的问题都源于此处：

4.2 用 Pin Array 批量添加管脚：参数设置决定效率生死

对于 24 脚以上的芯片（如教程中的 CS5381），绝不要手动一个一个 Place Pin。正确做法是使用Place → Pin Array，但关键在参数设置：

# 弹出对话框后，按此顺序填写： Pin Count: 24 # 总管脚数，必须准确 Start Number: 1 # 起始编号，通常为 1 Increment: 1 # 编号步进，通常为 1 Pin Name: {num} # 动态命名模板：{num} 自动替换为 1,2,3... Pin Type: Input # 初始类型，后续批量修改 Orientation: Left # 管脚朝向：Left/Right/Top/Bottom Spacing: 100 # 管脚间距（mil），必须匹配封装 pitch Row/Column: 1/24 # 单行排列（1 行 × 24 列）

逻辑说明：{num}是 Capture CIS 的内置变量，它会按Start Number和Increment自动生成1,2,3...。若芯片管脚名不连续（如跳过 13 脚），则需先填24个，再用 Spreadsheet 批量删改。Spacing值必须与实际封装焊盘中心距一致（如 SOIC-16 为 100mil，QFP-100 为 20mil），否则图形比例失真，影响后续布局参考。

4.3 批量编辑管脚属性：Spreadsheet 是唯一高效方案

双击单个管脚修改属性，面对 100+ 管脚就是自杀行为。必须用Edit → Properties（Ctrl+E）调出 Spreadsheet 视图：

注意：Spreadsheet 中修改后，必须点击左上角的磁盘图标保存，否则关闭窗口即丢弃所有更改。这是新手最常踩的坑——以为点了 OK 就生效，实际只是关闭了窗口。

5. 分裂元件（Multi-part Package）：不是“拆着玩”，而是为 SI/PI 仿真铺路

5.1 homogeneous vs heterogeneous：选错等于给 SI 分析埋雷

教程第 7 节提到的homogeneous（同质）和heterogeneous（异质）选项，本质是告诉 Capture CIS：“这 N 个 part 之间的电气关系是什么？”——这直接决定网表如何聚合网络。

• homogeneous：适用于内部模块完全相同、仅管脚编号不同的器件，如双运放 LM358（两个独立 op-amp，共用 VCC/GND，但输入输出引脚编号不同）。此时所有 part 的Power/Ground网络自动合并为同一 net，SI 分析时视为一个电源域。
• heterogeneous：适用于功能模块完全不同、需独立供电/参考的器件，如 Xilinx FPGA：Bank 0（I/O Bank）需 1.8V，Bank 1（Memory Interface）需 1.5V，Core（内核）需 0.9V，MGTAVCC（高速收发器）需 1.0V。此时每个 part 的Power属性必须单独设置，网表中生成VCCO_0,VCCO_1,VCCAUX,VCCINT等独立网络，PI 分析才能为每个域分配不同电源模型。

血泪经验：某 FPGA 项目因误选homogeneous，所有电源网络被合并为VCC一条 net，PI 仿真时用单一 1.0V 模型驱动全部 Bank，结果实际测试中 Bank 1 的 1.5V 域电压跌落超 10%，FPGA 配置失败。从那以后，我每次创建 FPGA 元件，第一件事就是打开Option → Package Properties，确认Package Type为Heterogeneous，然后逐个 part 设置PCB Footprint和Power属性。

5.2 分裂元件的网表生成规则：四条铁律

Capture CIS 导出 netlist 时，对分裂元件的处理遵循以下不可违背的规则：

1. 同一 package 下的所有 part，必须使用完全相同的Part Number和PCB Footprint：
   若U1A的PCB Footprint是BGA686，而U1B是BGA686_V2，netlist 中会生成两个独立器件，Allegro 导入时报错Footprint not found for U1B。

2. 所有 part 的Power/Ground管脚，必须显式命名且不重复：
   U1A的 VCC 引脚名必须是VCC_0，U1B的 VCC 引脚名必须是VCC_1，不能都叫VCC。否则 netlist 中所有 VCC 被合并，失去域隔离。

3. 总线网络必须跨 part 一致命名：
   若U1A有DATA[0..7]，U1B有DATA[8..15]，则 netlist 中必须生成DATA[0..15]总线；若U1B写成D[0..7]，则变成两条独立总线，SI 仿真无法分析数据眼图。

4. 每个 part 的Reference Designator后缀必须可解析：
   U1A,U1B,U1C是合法后缀；U1-1,U1-2是非法后缀（破折号不被 netlist 解析器识别），会导致 Allegro 导入后位号变为U1?。

5.3 验证分裂元件是否建对：三步终端检查法

建完分裂元件后，不要直接画图，先做以下终端验证：

# 步骤1：在原理图中放置一个 occurrence（如 U1） # 步骤2：双击 U1 → 弹出元件编辑窗口 → 点击 View → Package（看到所有 part） # 步骤3：对每个 part，依次执行： # a) 右键 → Properties → 检查 "PCB Footprint" 是否一致 # b) 在图形上右键 → Show Hidden Pins → 确认所有 Power/Ground 引脚可见且命名合规 # c) 选中任意 Power 引脚 → 右键 → Properties → 检查 "I/O Type" 是否为 "Power" # 步骤4：Tools → Create Netlist → 生成 netlist 文本 → 搜索 "U1" → 确认： # - 所有 part 出现在同一 DEVICE 行（如 "U1 U1A U1B U1C"） # - 每个 Power 网络有独立 netname（如 "U1A.VCC_0", "U1B.VCC_1"） # - 总线网络按预期聚合（如 "DATA[0..15]"）

注意：Show Hidden Pins是关键开关。很多设计师建完元件后没打开它，导致电源引脚被隐藏，netlist 中直接缺失该网络——这是 PI 分析失败的头号原因。

6. 生成可交付 netlist：从原理图到 SI/PI 仿真的最后一道质检

6.1 netlist 生成前的五项强制检查清单

在点击Tools → Create Netlist之前，必须逐项确认以下五点，缺一不可：

6.2 生成 netlist 的正确参数配置：Allegro 兼容性开关

Create Netlist对话框中，以下参数决定 netlist 能否被 Allegro 17.4+ 无缝导入：

提示：生成后立即打开myproject.net文本文件，搜索DEVICE关键字，确认所有元件（包括分裂元件）均以U1 U1A U1B形式列出；搜索NET，确认VCC_0、VCC_1等电源网络独立存在，而非合并为VCC。

6.3 用命令行快速验证 netlist 健康度：三行脚本救急

当项目紧急、无法逐项检查时，可用以下 Windows 命令行快速扫描 netlist 常见缺陷：

:: 进入 netlist 目录 cd /d E:\myproject :: 检查是否有未定义 footprint 的元件（返回空行表示正常） findstr /i "UNKNOWN" myproject.net :: 检查是否有非法总线命名（如 [0-31] 或 [0,31]） findstr "\[.*[-,].*\]" myproject.net :: 检查电源网络是否被错误合并（正常应有多条 VCC_*，而非单条 VCC） findstr /c:"VCC_" myproject.net | find /c ":"

• 若第一行有输出，说明存在 footprint 为空的元件；
• 若第二行有输出，说明存在非法总线语法；
• 若第三行输出数字 < 2，说明电源网络未按 Bank 分离（如只有一条VCC:而非VCC_0:,VCC_1:）。

从那以后我每次生成 netlist，都会在命令行跑这三行。它不能替代人工检查，但能在 5 秒内揪出 90% 的低级错误，避免把问题带到 Allegro 里再花 2 小时排查。希望帮到你。

本文还有配套的精品资源，点击获取