企业官网建设流程全解析

简介：面向需要在 Linux 桌面环境搭建集成电路设计与验证流程的工程师、研究生及高年级本科生，这份文档围绕 Ubuntu 20.04 上部署 Cadence IC617（HotFix）、Spectre18、Calibre19 与 XCELIUMMAIN_18 展开，涉及模拟仿真、版图设计、物理验证和数模混合仿真等场景，重点解决依赖库缺失、许可证配置及环境变量设置等常见阻碍。

压缩包内为 1 个 docx 文件，大小约 3.08MB，以步骤说明、命令清单与配置示例组织，便于按软件模块顺序查阅，也可作为环境迁移时的对照手册。内容覆盖系统准备、依赖库补齐、安装目录规划、许可证服务配置与启动验证等环节，并单独提示 AVX2 指令集、字体显示、32 位兼容库等易被忽略的前置条件，读者可据此建立检查清单，减少因环境差异导致的重复试错。

目前已有 7693 人学习下载，适合从零搭建或重建 Cadence/Calibre 实验环境、需要排错思路与配置参考的读者。

1. 四套 EDA 工具挤进一台 Ubuntu 20.04：先弄清它们各自需要什么

Ubuntu 20.04 上装 Cadence IC617、Spectre18、Calibre19、XCELIUMMAIN_18 这件事，难的不是某一个安装包，而是这四个工具的依赖条件各不相同。IC617 要 32 位库和 csh，Spectre18 要 Java 8 和一套独立的仿真入口，Calibre19 要求 CPU 支持 AVX2 指令集，XCELIUMMAIN_18 又依赖 ncurses 的旧 soname。这些条件缺任何一项，表现都是装到一半没反应，或者启动后立刻闪退，日志还不一定告诉你缺什么。

这套安装介质把 IC617 的 Base 与 HotFix、Spectre18、Calibre19/20、INCISIVE152 和 XCELIUMMAIN_18 放在一起，按目录名对应取用即可。下面的顺序是我在一台虚拟机里实际走通的：先检查系统基础条件，再装 IC617，然后配置环境变量和 license，最后把四套工具的启动流程逐项验证。

2. 装前检查系统基础条件：AVX2、32 位库与三处兼容补丁

Ubuntu 20.04 相比 16.04 少了三样东西：libxp6、multiarch-support，以及 ncurses 5 的 soname 链接。这三样恰好都是老 EDA 二进制需要的。很多教程直接复制 16.04 的 apt 清单，到 20.04 就装不下去了，问题基本集中在这一块。另一个容易被忽略的是 CPU 指令集：Calibre 2019 之后的二进制按 AVX2 编译，虚拟机如果没把这个指令集暴露给客户机，安装过程可能一路正常，点开图标就直接 core dumped。

所以这一章的顺序是先验证硬件与虚拟化能力，再补充库，最后给安装器处理三处系统识别兼容。

2.1 指令集与资源：三条命令定生死

AVX2 这条我吃过亏。同一份 Calibre 安装包，在宿主机上能跑，克隆到另一台机器上就打不开，查了半天才发现是虚拟机处理器兼容性被设成了旧版本，AVX2 被屏蔽。这类问题不看日志根本想不到，先查一遍最省事。

# 1) 指令集：avx2 是 Calibre 2019 的硬门槛，有输出才算过 grep -m1 -o -w 'avx2' /proc/cpuinfo # 2) 顺带看一眼 avx512，有的话仿真会快一截 grep -m1 -o -w 'avx512f' /proc/cpuinfo # 3) 磁盘：四套工具加 HotFix 光盘，60G 是起步，100G 才不慌 df -h / /opt /home # 4) 内存与 swap，4G 能装，8G 以上画版图才不难受 free -h

第一条命令有avx2输出就说明客户机可见；没有输出就不要往下走了，先去虚拟机设置里把处理器类型改成跟随宿主机、把虚拟化相关选项打开，重启再看。第二条是可选优化，有则更好。第三条重点看/opt所在分区，IC617 一套解压完就要十几个 G，如果/只分了 20G，装到 Calibre 就会卡在写入阶段，报的错还是乱七八糟的磁盘错误。第四条的 swap 建议不低于 4G，Spectre 跑大一点的网表会把内存吃满，没有 swap 就是直接被 OOM kill。

2.2 apt 依赖：分三组安装，缺哪组补哪组

把几十个包塞进一条命令，出错时根本不知道是哪个包引发的。我一般分三组：基础运行时、图形与字体、32 位兼容库。这样某组失败时，能立刻定位到是哪一类问题。

# 第一组：shell 与基础运行时，安装脚本和 license 工具链都靠它 sudo apt-get install -y ksh csh python3 net-tools # 第二组：Java 8 与终端，IScape 是 Java 写的，版本必须是 8 sudo apt-get install -y openjdk-8-jre openjdk-8-jdk xterm # 第三组：图形、ncurses 与 32 位兼容库 sudo apt-get install -y libncurses-dev libxtst6:i386 libxi6:i386 \ libstdc++6 lib32stdc++6 # 第四组：字体，不装的话 Calibre 的 GUI 字体非常难看 sudo apt-get install -y xfonts-75dpi xfonts-100dpi

第一组里的ksh和csh是必须的，Cadence 的启动脚本里有大量 csh 语法，缺了csh的现象是 virtuoso 启动时提示No such file or directory，但文件明明存在——那个报错其实是 shebang 找不到解释器。第二组的 Java 必须是 8，装成 11 或 17 之后 IScape 可能起不来，因为老版本对高版本 JRE 的模块化机制不兼容。

第三组里libxtst6:i386和libxi6:i386是给 IC617 内部的 32 位组件用的，要启用 i386 架构才能装，先执行sudo dpkg --add-architecture i386 && sudo apt-get update。libncurses-dev在 20.04 里替代了老教程写的libncursesw5-dev，如果照抄老教程报找不到包，换成这个即可。第四组装完要跑一次fc-cache -fv，否则字体缓存不刷新，重启也看不到效果。

2.3 libxp6 与 multiarch-support：20.04 已经移除的两个包

这两个包在 20.04 的官方源里已经被移除了，apt 直接装会报Unable to locate package。解决办法是从 Debian 的归档池里取对应的 deb 包手工安装，装完再用apt-get -f install补齐依赖链。顺序不能反，先装 multiarch-support 再装 libxp6，否则 libxp6 会因为缺少多架构支持而装不上。

# 从 Debian 归档池下载两个 deb，路径按目录名找即可 cd /tmp # multiarch-support 必须在 libxp6 之前装 sudo dpkg -i multiarch-support_2.28-10_amd64.deb # libxp6 是 X11 的老打印扩展，Calibre 的某些组件还在链接它 sudo dpkg -i libxp6_1.0.2-2_amd64.deb # dpkg 不解决依赖，用这条补齐 sudo apt-get -f install -y

dpkg -i只负责把文件放到位，不处理依赖关系，所以中途报依赖错误是正常的，最后那条apt-get -f install才是收尾动作。libxp6之所以还要装，是因为 Calibre 的版图查看器里有组件链接了libXp.so.6，缺了之后表现是版图窗口打开就崩，日志里能看到libXp.so.6: cannot open shared object file。这两步做完，用ldconfig -p | grep libXp确认一下库已经进了缓存。

2.4 让安装器接受这个系统：redhat-release、临时目录与两条软链接

Cadence 的安装器会读取系统发行版信息决定走哪套安装逻辑，认不出 Ubuntu 就会拒绝继续。通行做法是造一个假的/etc/redhat-release让它以为自己在 RHEL 上。同时安装器会往/usr/tmp写临时文件，这个目录在 20.04 里默认不存在，需要手工建并放开权限。

# 伪造发行版标识，内容按 RHEL 6 的格式写 sudo tee /etc/redhat-release <<'EOF' Red Hat Enterprise Linux release 6.12 EOF # 安装器以普通用户身份也会写这个文件，权限要放开 sudo chmod 777 /etc/redhat-release # 安装器的临时目录 sudo mkdir -p /usr/tmp sudo chmod -R 777 /usr/tmp # 老二进制按 soname 找库，20.04 只有新版本，做两条软链接兜底 sudo ln -sf /lib/x86_64-linux-gnu/libncursesw.so.5.9 /lib/libtermcap.so.2 cd /lib/x86_64-linux-gnu sudo ln -sf libcrypto.so.1.1 libcrypto.so.6

第一条用 heredoc 写入，比gedit更适合脚本化，也避免了编辑器的编码问题。软链接那条要特别注意：libcrypto.so.6指向libcrypto.so.1.1是权宜之计，某些老程序调用到 1.1 里已删除的接口时仍然会崩，但绝大多数 license 相关工具跑得通。libtermcap.so.2指向libncursesw.so.5.9是解决libtermcap.so.2: cannot open shared object file的标准做法，这个报错在启动 virtuoso 时很常见。

Java 环境变量也要在这一步配好，写在/etc/profile里，追加到文件末尾：

export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 export JRE_HOME=$JAVA_HOME/jre export CLASSPATH=$JAVA_HOME/lib:$JRE_HOME/lib:$CLASSPATH export PATH=$JAVA_HOME/bin:$JRE_HOME/bin:$PATH

写完必须source /etc/profile让它生效，然后java -version确认输出是 1.8 系列。这一步没做的话，后面 IScape 启动会直接返回提示符，不给任何有意义的错误信息——这是第一个容易误判的地方。

3. 用 IScape 装 IC617：HotFix 先装、Base 后补的完整顺序

IScape 是 Cadence 的通用安装器，IC617、Spectre18、XCELIUMMAIN_18 都通过它安装，Calibre 则走 Mentor 自己的一套脚本。理解这一点很关键：很多人把 IScape 拷贝到本地再运行，结果因为共享目录里的相对路径和符号链接丢失而失败。它本来就是个临时工具，直接在挂载点运行最稳。

3.1 IScape 不落地：从共享目录直接启动

VMware 的共享文件夹固定挂在/mnt/hgfs下，路径里带空格或中文会导致 IScape 解析失败，所以安装介质所在的目录名必须是纯英文。启动时用sudo，因为目标目录/opt普通用户写不进去。

# 先确认共享目录挂上了 ls /mnt/hgfs # 进入 IScape 的 bin 目录，路径按实际目录名对应 cd /mnt/hgfs/CadenceIC/IScape04.23-s010lnx86/iscape.04.23-s010/bin # 必须 sudo，安装过程要往 /opt 写 sudo ./iscape.sh

第一行如果看不到共享目录名，说明 VMware Tools 没装好或者共享文件夹没在虚拟机设置里勾选。这一步建议在装系统时就配好，装完 VMware Tools 再回头加共享目录，容易出现挂载点存在但内容为空的情况，重启一次通常能解决。

sudo ./iscape.sh执行后会出现图形界面。如果界面一闪就退，先回看 2.4 里的 Java 变量有没有source，这是最主要的原因。

3.2 HotFix 与 Base 的先后：那个"选 2、选 n"分别在选什么

IC617 的安装介质分成 Base 盘和 HotFix 盘，HotFix 是补丁，必须叠加在 Base 之上。安装顺序是先跑 HotFix 安装器，中途它会提示插入 Base 盘，此时把源路径切到 Base 目录。整个交互里有两处容易选错：

第一处是提示添加 Base CD 时的选项，原文里选 2，含义是手动指定 Base 所在路径，而不是从光驱读取。选错会卡在"等待介质"状态，看着像死机。

第二处是询问是否安装 OA（OpenAccess）时的选项，原文里选 n，含义是跳过内置 OA，使用安装包自带的版本。这一步必须记住界面上显示的 OA 路径，通常形如/opt/cadence/IC617/oa_v22.50.043，后面配环境变量要用到这个版本号，写错了 virtuoso 起不来。

其余提示一律确认即可。装完检查目录结构：

# 确认 OA 版本目录存在，版本号以安装时显示的为准 ls -d /opt/cadence/IC617/oa_v22.50.043 # 确认 dfII 目录在，virtuoso 的入口在这里 ls /opt/cadence/IC617/tools/dfII/bin/virtuoso

两条都有输出才算装完。第一条没有输出说明 OA 那一步选错了，需要重装；第二条没有输出说明安装路径填错了，常见原因是路径末尾多了一个斜杠或者用了中文目录名。

3.3 目录规划：四个工具分开放，别塞进同一个目录

我见过把所有东西装进/opt/cadence一个目录的做法，升级时非常难受。合理的做法是按工具分目录，Spectre 和 Xcelium 各自独立，这样单独升级其中一个不影响其他。

# 一次建好，避免安装时临时建目录出现权限问题 sudo mkdir -p /opt/cadence /opt/mentor/Calibre2019 /opt/mentor/license sudo chown -R $USER:$USER /opt/cadence /opt/mentor

把所有权改成当前用户是有意为之：后续安装器以普通用户运行时不会因为权限被拒，license 文件也能直接编辑。这一步看着不起眼，但能省掉后面一堆Permission denied。

3.4 Spectre18 与 XCELIUMMAIN_18：同一套流程，别装错介质

这两个工具的安装方式和 IC617 一致，也是启动 IScape 后选择对应介质目录，区别只在目标路径。Spectre18 就是早期的 MMSIM，负责电路仿真；XCELIUMMAIN_18 是早期的 INCISIVE，负责数模混合仿真，入口命令是xrun。两个都装完之后，/opt/cadence下应该有三个并列的目录。

Calibre 不走 IScape。Mentor 的安装介质里通常有一个install.ixl或者.run结尾的可执行文件，直接运行它：

# Calibre 用自己的安装器，交互流程和 IScape 完全不同 cd /mnt/hgfs/Calibre2019 ls | grep -E 'install|\.run$' # 找到后直接执行，安装路径填 /opt/mentor/Calibre2019 sudo ./install.ixl

第一条ls | grep是为了确认介质里的安装器叫什么名字，不同批次的命名不一样，硬记容易出错。安装路径必须和表格里的一致，因为后面环境变量要指向它。Calibre 装完不校验 AVX2 也能装成功，但运行时才崩，所以 2.1 那步真的不能跳过。

4. 环境变量与 license：PATH 顺序与端口号容易出错

装完之后不配环境变量，所有命令都找不到。配了环境变量但路径顺序错了，会出现"仿真跑通了但结果不对"这种更麻烦的问题——因为 IC617 自带一个旧版 spectre，PATH 顺序决定了你调用的是哪一个。license 那边同理，Cadence 和 Calibre 用的变量名不一样，混用会导致其中一个工具永远拿不到授权。

4.1 一份可复用的 profile 片段

我一般把 EDA 相关的变量单独写成一个文件，在~/.bashrc里 source 它，这样换机器时只要拷一个文件。写成/etc/profile全局也行，但会污染所有用户的环境，多用户机器上不建议。

# ---- Cadence IC617 ---- export CDS_INST_DIR=/opt/cadence/IC617 export PATH=$CDS_INST_DIR/bin:$CDS_INST_DIR/tools/bin:$CDS_INST_DIR/tools/dfII/bin:$PATH # ---- Spectre18，放在 IC617 之后，确保优先调用 ---- export SPECTRE_HOME=/opt/cadence/SPECTRE18 export PATH=$SPECTRE_HOME/bin:$PATH # ---- Calibre19 ---- export MGC_HOME=/opt/mentor/Calibre2019 export PATH=$MGC_HOME/bin:$PATH # ---- XCELIUMMAIN_18 ---- export XCELIUM_HOME=/opt/cadence/XCELIUM18 export PATH=$XCELIUM_HOME/tools/bin:$PATH # 统一走 64 位，避免一半插件加载 32 位库失败 export CDS_AUTO_64BIT=ALL # 网表输出用模拟格式，数模混仿时不用再改 export CDS_Netlisting_Mode=Analog

关键在于SPECTRE_HOME/bin要排在CDS_INST_DIR之后，因为后者内部也有一份spectre可执行文件。顺序反了的话，IC617 会调用自己带的旧版仿真器，跑小电路看不出来，跑带新模型的网表就会报模型语法不认。验证方式很简单，which spectre和spectre -v一起看，输出路径和版本号对不对得上。

CDS_AUTO_64BIT=ALL这条在纯 64 位系统上尤其重要，不设的话部分组件会尝试加载 32 位库，而 20.04 的 32 位库又不全，表现是 virtuoso 启动到一半退出。CDS_Netlisting_Mode=Analog影响导出的网表格式，做数模混仿时必须是 Analog，设成 Digital 会丢器件参数。

4.2 license：三个变量各管一段，别混用

Cadence 和 Calibre 的 license 变量名不同，端口也可以不同，但必须和 license 文件里SERVER行写的保持一致。常见的错法是只设了LM_LICENSE_FILE，结果 Calibre 找不到授权，因为它读的是MGLS_LICENSE_FILE。

# Cadence 系：CDS_LIC_FILE 是主变量，LM_LICENSE_FILE 作为兜底 export CDS_LIC_FILE=5280@licsrv export LM_LICENSE_FILE=5280@licsrv # Calibre 系：认 MGLS_LICENSE_FILE，端口可以和上面不同 export MGLS_LICENSE_FILE=1717@licsrv

licsrv这个主机名必须是机器上hostname命令的真实输出，不能随手写。license 文件里的SERVER行有固定格式，主机名和 MAC 地址两项都要和实际机器对得上：

# 两个都要和 license 文件里的 SERVER 行一致 hostname ip link show | grep -m1 'link/ether'

虚拟机克隆之后 MAC 地址会变，这是 license 失效最常见的原因，而且现象很迷惑：license 进程明明在跑，端口也通，工具就是说拿不到授权。解决方法是把 license 文件里的 MAC 改成新的，然后重启 license 服务。

4.3 首次启动验证：四条命令逐个看回显

装完配完之后，不要急着开工程，先跑四条命令确认每个工具都能独立起来。这一步花两分钟，能省掉后面几小时的误判。

# 四个工具各跑一次，看版本回显 virtuoso -version 2>&1 | head -3 spectre -v 2>&1 | head -3 calibre -v 2>&1 | head -3 xrun -version 2>&1 | head -3

四条都通了，说明环境和授权都没问题，可以进工程了。任何一条卡住，直接去第 5 章对号入座。

5. 排错清单：从闪退到 illegal instruction 的五类现场

安装类问题最麻烦的地方在于，报错信息往往指向的不是真正的原因。下面这五类是我在这套环境里反复遇到的，按出现频率从高到低排。每条都按现象、原因、解决的顺序写，方便直接对照。

5.1 IScape 一闪就退，终端没有任何有意义的报错

现象：执行sudo ./iscape.sh后，终端刷几行就回到提示符，图形界面根本没出来。

原因：Java 环境变量没生效，或者系统里默认的 Java 不是 8。IScape 启动脚本会去找JAVA_HOME，找不到就用系统默认的java，而 20.04 如果装过别的软件，默认可能是 11 或 17，老安装器不认高版本的模块化机制，直接退出且不打印堆栈。

解决：先echo $JAVA_HOME确认变量在，再java -version确认是 1.8。变量写了但没生效，是因为改完/etc/profile没source，或者是在非登录 shell 里跑的命令。临时改法是在当前终端里直接export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64再启动。

5.2 virtuoso 起来了，但菜单和字体全是方块

现象：主界面能开，但文字显示成一个个方块，菜单基本没法用。

原因：X 字体缺失。20.04 的最小安装不带 75dpi 和 100dpi 的位图字体，而老版本 Cadence 的界面用的是位图字体，不是 TrueType。

解决：回 2.2 装xfonts-75dpi和xfonts-100dpi，然后跑一次fc-cache -fv刷新缓存，重启机器。如果只装字体不刷缓存，有时候仍然不生效，这是第二个容易误判的地方。Calibre 的界面同理，字体难看也是这个原因。

5.3 calibre -v 直接 Illegal instruction (core dumped)

现象：命令一执行就崩，连版本都不打印。

原因：CPU 没暴露 AVX2 指令集。Calibre 2019 的二进制是按 AVX2 编译的，指令不存在时内核直接发 SIGILL，没有任何提示。

解决：先在客户机里跑grep -m1 -o -w avx2 /proc/cpuinfo，没输出就是这个问题。虚拟机设置里把处理器类型改成跟随宿主机，确认虚拟化相关选项已勾选，重启客户机。宿主机 BIOS 里如果关了相关选项，也要一并打开。这一步没得绕，指令集不是软件层面能补的。

5.4 license 进程在跑，工具却说拿不到授权

现象：license 服务明明起来了，端口也能连，virtuoso 启动还是报 check out license 失败。

原因：两种可能，一是 license 文件里SERVER行的主机名和实际hostname不一致，二是虚拟机克隆后 MAC 地址变了。后者尤其常见，而且从表面完全看不出来。

解决：hostname和ip link各看一眼，和 license 文件的前两行逐字对比。不一致就改文件，然后重启 license 进程。改完不要忘记把改过的 license 备份一份，下次再克隆机器时可以直接对照。

5.5 xrun 报 libncurses.so.5 找不到

现象：error while loading shared libraries: libncurses.so.5: cannot open shared object file。

原因：20.04 只带libncurses.so.6，XCELIUMMAIN_18 的二进制按老 soname 链接。

解决：装libncurses5包，或者做一条软链接指向 6 的版本。软链接是快办法但有风险，ncurses 5 和 6 之间改过 ABI，某些调用会出问题，如果只是启动阶段加载，通常没事。更稳的做法是装libncurses5和libtinfo5两个包，让系统同时存在两套库。

6. 验收固化：四条命令跑通链路并留一份版本快照

四套工具各自能启动，只是第一步。真正的验收是让它们在同一条链路上跑通：virtuoso 画原理图、导出网表、spectre 仿真、calibre 做物理验证、xrun 做数模混仿。我一般用一个小规模的反相器链做冒烟测试，从原理图到仿真结果跑一遍，全程不需要大网表，十分钟内能完成。这套流程能暴露 90% 的环境问题，因为每一步都会用到不同的工具入口和不同的 license 特性。

跑通之后一定要把版本信息固化下来。这套环境最烦的场景是：过了三个月，某个工具突然起不来，你想不起当时装的是哪个小版本，也记不清改过哪些系统文件。我的习惯是每次动/opt之前和之后各拍一次快照。

# 把四个工具的版本一次性写进文件，出问题时先比对这里 { date '+%Y-%m-%d %H:%M:%S' virtuoso -version 2>&1 | head -2 spectre -v 2>&1 | head -2 calibre -v 2>&1 | head -2 xrun -version 2>&1 | head -2 } > ~/eda_versions.txt

这个脚本输出的文件只有几十行，但排查问题时价值极高。配合dpkg -l | grep -E 'libxp|ncurses|multiarch'一起存，能还原出当时的依赖状态。我现在还会额外存一份/etc/redhat-release和软链接的指向，因为这两处是最容易在系统升级时被悄悄改掉的。

还有一个细节值得固化：把环境变量从/etc/profile挪到~/.bashrc里 source 一个独立文件。系统升级时/etc/profile有可能被包管理器覆盖，而家目录下的文件不会。这个习惯带来的好处平时感觉不到，等哪天升级完系统发现所有命令都找不到了，就知道后悔药在哪。

从那以后我每次动/opt下的任何东西之前，都强制先跑一遍版本快照，再开始操作。这套流程救过我至少两次，一次是系统更新把libcrypto的软链接冲掉了，一次是有人改了/etc/redhat-release导致安装器行为异常，两次都是靠快照比对十分钟内定位的。安装文件按 Base/HotFix、Spectre、Calibre、Xcelium 分目录整理在一起，按需取用即可。希望帮到你。

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