企业官网建设流程全解析

1. 为什么要在 CentOS 7 上折腾 Synopsys DC

搞数字 IC 设计这行的，Synopsys Design Compiler（后面我统一简称 DC）基本是绕不开的一环。它是 Synopsys 家做 RTL 综合的主力工具，把 Verilog/VHDL 描述的寄存器传输级代码，映射到具体工艺库的门级网表，中间还要做时序约束、面积优化、功耗估算这一整套事情。说白了，你写的那些 always 块，最终能不能变成一颗能流片的芯片，DC 这一关是必经之路。

那为什么偏偏是 CentOS 7？这个问题我被问过太多次。原因其实很现实：DC 这类 EDA 工具对操作系统的兼容性极其挑剔，官方支持列表里长期把 RHEL/CentOS 系列列为首选，而 CentOS 7 因为生命周期长、库版本稳定、企业里存量机器多，成了绝大多数 IC 设计公司搭建综合环境时的默认底座。你可能会想用 Ubuntu，但实际踩过坑的人都知道，DC 在 Ubuntu 上跑起来各种 glibc 版本冲突、库缺失，折腾的时间够你把综合流程跑通好几遍了。CentOS 7 的 glibc 2.17、libXext、libXt 这些老库版本，恰好和 DC 各版本的依赖对得上，省心。

这篇内容适合谁看？如果你是刚进实验室或者刚入职的 IC 新人，手上拿到了一台装了 CentOS 7 的服务器或者虚拟机，需要把 DC 装起来跑通第一个综合脚本，那这篇就是给你写的。如果你是有几年经验但一直用公司现成环境、想自己搭一套练手环境的老手，里面关于 license 配置、库路径、报错排查的部分同样能帮你省时间。我会把安装、配置、环境变量、license、常见报错这几块拆开讲透，每一步都告诉你为什么这么做，而不是甩一堆命令让你照抄。

需要提前说明的是，DC 是商业 EDA 工具，安装包和 license 需要你通过正规渠道获取，本文只讨论安装配置的技术流程本身，不涉及任何授权获取途径。下面进入正题。

2. 安装前的整体思路与环境准备

2.1 先想清楚目录结构和版本匹配

很多人装 DC 失败，根子不在安装那一步，而在于一开始目录没规划好、版本没对齐。我建议你在动手之前，先把这几件事定下来。

第一是安装根目录。EDA 工具的习惯做法是统一放在一个独立分区下，比如/eda或者/tools，不要塞进/home或者/usr/local。原因有两个：一是 EDA 工具动辄几个 G，独立分区方便你后续扩容和备份；二是 license 和环境变量脚本通常按固定路径写死，路径一变全得改。我个人的习惯是/eda/synopsys作为 Synopsys 全家桶的根，下面再分dc、pt、icc等子目录。

第二是版本匹配。DC 的版本号和它依赖的库、以及你用的工艺库之间是有对应关系的。比如较新的 DC 版本可能要求更新的 glibc，而 CentOS 7 自带的 glibc 是 2.17，如果你拿到的是特别新的 DC 版本，可能就跑不起来。反过来，太老的 DC 版本又可能不支持你手上的工艺库格式。所以拿到安装包后，先看一眼版本号，对照 Synopsys 的官方兼容性说明确认一下。

第三是磁盘空间。DC 本体安装完大概 3 到 5 个 G，加上工艺库（标准单元库、IO 库、存储器库）轻松上到几十个 G。所以/eda分区至少留 50G 起步，做实际项目的话建议 100G 以上。

2.2 系统依赖库的补齐

CentOS 7 最小化安装之后，很多图形库和兼容库是缺的。DC 虽然有命令行模式，但design_vision和dc_shell -gui这些图形界面依赖 X11 相关库，缺了会直接报错退出。安装前先把这批库补上，能省掉后面一大堆error while loading shared libraries的麻烦。

yum install -y libXext libXt libXrender libXi libXpm \ libXau libXdmcp libXft libXfixes libXcursor \ libpng12 compat-libstdc++-33 glibc-devel \ ksh tcsh xorg-x11-fonts-75dpi xorg-x11-fonts-100dpi

这里有几个点值得说一下。ksh和tcsh是必须的，因为 DC 自带的很多脚本和 wrapper 是用这两种 shell 写的，缺了会导致工具启动脚本执行失败。compat-libstdc++-33提供的是老版本 libstdc++，一些老版本 DC 的二进制依赖它。字体包xorg-x11-fonts-*看着不起眼，但如果你要开 GUI，缺字体的话界面会显示成一堆方块甚至直接崩溃。

提示：如果你的 CentOS 7 是离线环境，没法直接用 yum 联网装，那就需要提前把对应的 rpm 包下载好，用rpm -ivh或者搭建本地 yum 源来装。离线环境下依赖关系容易漏，建议用yumdownloader --resolve把依赖一起拉下来。

2.3 创建专用用户与权限规划

我不建议用 root 直接跑 EDA 工具，也不建议用 root 去装。比较稳妥的做法是创建一个专用的工具管理用户，比如eda，把安装目录的属主给它。

useradd -m -d /home/eda eda mkdir -p /eda/synopsys chown -R eda:eda /eda

用专用用户的好处是权限边界清晰，工具产生的临时文件、日志都归在这个用户下，不会污染系统目录。而且团队协作时，多个工程师可以共享这个安装目录，通过用户组权限来控制读写。你可以再建一个icdesign组，把需要用 DC 的同事都加进去，安装目录设成组可读可执行。

3. DC 安装过程与核心配置细节

3.1 安装包解压与安装脚本执行

Synopsys 的安装包通常是分卷的 tar 包或者一个自解压的 installer。以常见的SynopsysInstaller加产品包的形式为例，流程大致是这样。

先把 installer 解压出来，运行安装器：

cd /eda/synopsys tar -xzf SynopsysInstaller_v5.x.tar.gz cd SynopsysInstaller_v5.x ./installer -gui

如果你在无图形界面的服务器上，就用命令行模式./installer -console，一路按提示走。安装器会问你几个关键信息：安装源目录（你解压出来的产品包所在位置）、目标目录（比如/eda/synopsys/dc/O-2018.06-SP1）、以及要安装哪些组件。

这里有个经验：目标目录里带上版本号。比如dc/O-2018.06-SP1，而不是直接装到dc/下。这样你以后想升级版本，新版本装到dc/O-2020.09，两个版本并存，环境变量切一下就能换，不用卸载重装。这个习惯在 EDA 环境管理里非常重要，因为不同项目可能锁定不同工具版本。

安装过程会持续十几分钟到半小时，取决于磁盘 IO。装完之后，目标目录下会有bin、linux64、syn、admin等子目录。

3.2 环境变量的正确设置方式

环境变量是 DC 能不能跑起来的关键。核心要设的就几个：PATH、SNPSLMD_LICENSE_FILE（或者LM_LICENSE_FILE）、以及一些工具自身的变量。

我习惯把环境变量写成一个独立的脚本，比如/eda/synopsys/env.sh，需要的时候 source 一下，而不是直接塞进.bashrc。这样切换版本、切换项目的时候更灵活。

# /eda/synopsys/env.sh export SYNOPSYS_HOME=/eda/synopsys export DC_HOME=$SYNOPSYS_HOME/dc/O-2018.06-SP1 export PATH=$DC_HOME/bin:$DC_HOME/linux64/syn/bin:$PATH export SNPSLMD_LICENSE_FILE=27020@license-server export LM_LICENSE_FILE=$SNPSLMD_LICENSE_FILE

几个细节解释一下。PATH里我加了两个路径，bin下面是工具的主启动脚本，linux64/syn/bin下面是一些底层可执行文件，两个都加上能避免某些子命令找不到。SNPSLMD_LICENSE_FILE是 Synopsys 自家 license 管理器的变量，格式是端口@主机，如果你用的是 license 文件而不是服务器，就写成文件的绝对路径。LM_LICENSE_FILE是通用的 license 变量，有些工具会读这个，两个都设上保险。

注意：SNPSLMD_LICENSE_FILE和LM_LICENSE_FILE同时存在时，某些版本的工具会有优先级冲突。如果遇到 license 读取异常，先只保留SNPSLMD_LICENSE_FILE试试。

3.3 工艺库的配置与 target_library 设置

DC 光装好还跑不了综合，你得有工艺库。工艺库一般由 Foundry 提供，包含.db格式的时序库、.lib格式的源库、以及各种 memory、IO 库。这些库要放到一个固定目录，然后在 DC 的启动脚本或者综合脚本里指定。

DC 里几个关键的库变量：

target_library一般用慢速角（worst case）的库，因为综合要保证时序在最差情况下也满足。link_library里的*表示先搜索已经加载到内存的库，这是个约定俗成的写法，别漏了。

我通常会在项目目录下建一个.synopsys_dc.setup文件，DC 启动时会自动读取当前目录下的这个文件，把库配置写进去，这样每个项目独立配置，互不干扰。

# .synopsys_dc.setup set search_path [list . /eda/lib/smic18/db] set target_library "slow.db" set link_library "* slow.db fast.db mem.db io.db" set symbol_library "smic18m.sdb"

4. License 配置与常见报错排查实录

4.1 License 服务的基本原理

Synopsys 的 license 用的是 FlexLM 机制（Synopsys 自己叫 SNPSLMD）。原理不复杂：license 服务器上跑一个lmgrd守护进程，读取 license 文件，监听一个端口；客户端工具启动时，通过SNPSLMD_LICENSE_FILE指定的地址去连服务器，申请一个 feature 授权。拿到授权才能跑，拿不到就报错退出。

license 文件里最关键的是SERVER行和DAEMON行，以及每个 feature 的INCREMENT行。SERVER行里的主机名和 MAC 地址必须和服务器实际的一致，这是 FlexLM 绑定的依据。DAEMON行指向snpslmd这个守护程序的路径。

启动 license 服务的命令大概是这样：

/eda/synopsys/SCL/linux64/bin/lmgrd -c /eda/synopsys/license/synopsys.dat -l /eda/synopsys/license/lmgrd.log

SCL是 Synopsys Common Licensing 的缩写，是独立于 DC 的一个组件，需要单独安装。-c指定 license 文件，-l指定日志文件。启动后可以用lmstat查看状态：

/eda/synopsys/SCL/linux64/bin/lmstat -c 27020@license-server -a

4.2 常见报错速查与解决

下面这张表是我这些年踩坑攒下来的，基本覆盖了 90% 的启动报错。

我重点说几个高频的。libXm.so.3这个报错特别常见，CentOS 7 默认装的是新版 openmotif，但 DC 要的是老版本 so。解决办法是装openmotif的兼容包，或者从别的机器拷一个libXm.so.3放到/usr/lib64下并建软链接。

Design Compiler is not enabled这个报错，八成是 license 没连上。先用lmstat确认服务器活着，再用telnet license-server 27020确认端口通。如果服务器在另一台机器上，防火墙可能挡了端口，CentOS 7 默认的 firewalld 要放行。

提示：排查 license 问题时，养成先看日志的习惯。lmgrd.log里会记录每一次 checkout 请求和失败原因，比工具端的报错信息详细得多。

4.3 一个真实的排查案例

有次同事的环境，DC 启动就报Unable to checkout license，但lmstat显示 license 明明有空闲。折腾了半天，最后发现是 license 文件里SERVER行的主机名写的是短名licsrv，而客户端解析这个短名解析到了另一台机器上。把/etc/hosts里加上正确的映射，或者把SNPSLMD_LICENSE_FILE里的主机名换成 IP，问题就解决了。

这个案例的教训是：license 相关的主机名解析一定要确认清楚。FlexLM 对主机名的处理有时候很微妙，能用 IP 就用 IP，能少一层解析就少一层。

5. 跑通第一个综合脚本验证环境

5.1 准备一个最小可综合的 RTL

环境装完，得跑个东西验证一下。写一个最简单的计数器，别搞太复杂，目的是验证工具链通不通。

// counter.v module counter ( input wire clk, input wire rst_n, output reg [7:0] cnt ); always @(posedge clk or negedge rst_n) begin if (!rst_n) cnt <= 8'd0; else cnt <= cnt + 1'b1; end endmodule

5.2 编写综合约束与脚本

综合脚本分两部分：约束文件和 DC 执行脚本。约束文件用 SDC 格式，先给个时钟，其他约束后面慢慢加。

# counter.sdc create_clock -name clk -period 10 [get_ports clk] set_input_delay -clock clk 2 [remove_from_collection [all_inputs] [get_ports clk]] set_output_delay -clock clk 2 [all_outputs]

DC 执行脚本：

# run_dc.tcl set search_path [list . /eda/lib/smic18/db] set target_library "slow.db" set link_library "* slow.db" analyze -format verilog {counter.v} elaborate counter link source counter.sdc compile report_timing report_area write -format verilog -hierarchy -output counter_netlist.v

5.3 执行与结果解读

启动 DC 跑脚本：

dc_shell -f run_dc.tcl | tee dc.log

跑完之后看dc.log，重点看几个地方。report_timing会给出关键路径的 slack，如果是正数说明时序满足，负数就是违例。report_area给出综合后的面积。如果这两个报告都正常输出，说明你的环境从工具到库到 license 全通了。

第一次跑大概率会遇到时序违例，别慌，这是正常的。8 位计数器在 10ns 周期下，如果工艺库比较慢，可能刚好卡在边界。你可以把周期放宽到 20ns 再试，先确认流程通，再调约束。

注意：elaborate之后一定要link，否则compile会因为找不到库单元而报错。这个顺序是 DC 综合的标准流程：analyze 读源码，elaborate 建层次，link 连库，compile 映射优化。

6. 环境维护与长期使用建议

6.1 多版本共存与切换

前面提过，安装目录带版本号。实际用的时候，我会准备多个 env 脚本，比如env_dc2018.sh、env_dc2020.sh，需要哪个 source 哪个。项目组里通常会在项目根目录放一个setup.sh，里面 source 对应版本的环境，新人进来直接 source 一下就能干活，不用记一堆路径。

6.2 定期检查 license 与磁盘

license 服务是长期运行的，偶尔会因为网络抖动或者进程异常挂掉。我习惯写个简单的巡检脚本，定时lmstat一下，发现异常就告警。磁盘方面，DC 跑综合会产生大量中间文件和日志，尤其是大设计，一个项目跑下来几个 G 很正常。定期清理work目录和旧日志，别让磁盘满了导致综合中途失败。

6.3 备份你的配置

.synopsys_dc.setup、SDC 约束模板、常用的综合脚本，这些是你的核心资产。我见过太多人环境崩了之后，脚本找不回来，只能重写。建议用 git 管理起来，哪怕只是本地仓库，也比裸文件强。

我个人在实际操作中的体会是，DC 环境搭建这件事，难点从来不在安装本身，而在于对依赖关系、license 机制、库配置这三块的理解。你把这三块搞明白了，后面换版本、换工艺库、换机器，都是照葫芦画瓢的事。第一次装可能会花你一整天，但装通一次之后，再搭第二套环境，一两个小时就能搞定。踩过的坑都记下来，下次就是你的经验了。