数字设计--VCS

一 VCS 全解析：Verilog HDL 仿真编译工具使用指南¶

标签：单 job 不可拆分，视具体任务支持多线程编译 / 仿真，仿真阶段高 IO 写入特性，时序仿真存在大内存占用情况

核心定位：Verilog HDL 专用验证与编译工具，底层基于 gcc+gdb 定制开发，是数字前端设计中核心的仿真编译工具，与 Verdi 配合构成完整的数字前端开发仿真环境

1 背景知识¶

1.1 工具核心定义¶

VCS（Verilog Compile Simulator）是 Synopsys 公司推出的 Verilog HDL 专用验证工具，底层基于 gcc+gdb 架构进行定制开发，本质可视为Verilog HDL 的专用编译器，核心完成 Verilog/SystemVerilog 代码的编译、链接与仿真执行。

1.2 工程特性共性¶

VCS 工程项目的编译、管理特性与传统 Linux 软件编译工程基本一致，可直接复用 Linux 下的自动化编译工具（如 Makefile）进行项目管理，降低工程维护成本。

1.3 与同类仿真工具的本质区别¶

VCS 与 spectre 虽同属仿真工具，但核心定位、工作原理完全不同，核心差异如下：

工具	本质	核心任务	适用场景
VCS	gcc 定制编译器	代码编译、链接与逻辑仿真	数字电路设计（Verilog/SystemVerilog）
spectre	数值计算器	纯电路数值计算	模拟电路、数模混合电路仿真

1.4 VCS-MX 说明¶

VCS 分为原生 VCS 与 VCS_MX 两个分支，现阶段已完成版本合并，核心区别仅体现在对 VHDL 的支持上：

原生 VCS：最初仅支持 Verilog，后续迭代新增 SystemVerilog（SV）支持，无 VHDL 支持；
VCS_MX：混合 HDL 仿真器，支持 Verilog+SV+VHDL 混合代码仿真；
当前版本：两支版本合并，不再有单独的 VCS_MX 安装包，混合仿真能力集成至标准 VCS 中。

2 环境变量配置¶

VCS 的运行依赖指定环境变量的配置，需在 Bash 环境中通过setenv/prepend-path命令配置，以下为 O-2018.09-SP2 版本的标准配置，其他版本仅需替换VCS_HOME对应的路径即可：

# 配置VCS主目录
setenv        VCS_HOME             /fastone/software/synopsys/vcs/O-2018.09-SP2
# 指定架构为linux
setenv        VCS_ARCH_OVERRIDE    linux
# 添加可执行程序路径至系统PATH
prepend-path  PATH                 $env(VCS_HOME)/amd64/bin
prepend-path  PATH                 $env(VCS_HOME)/bin
prepend-path  PATH                 $env(VCS_HOME)/gui
# UVM路径（按需开启，注释为#prepend-path  PATH  $env(VCS_HOME)/etc/uvm）
# 添加动态链接库路径至LD_LIBRARY_PATH
prepend-path  LD_LIBRARY_PATH      $env(VCS_HOME)/amd64/lib

配置原则：环境变量需在执行 VCS 命令前完成配置，建议写入用户环境配置文件（如.bashrc/.cshrc），实现永久生效。

3 工程管理：Makefile 使用¶

由于 VCS 与 Linux 软件编译特性一致，Makefile 是 VCS 工程的标准管理工具，通过封装编译、仿真、波形查看、清理等命令，简化工程操作。GNU Make 作为 Linux 原生自动化编译工具，最初为 C 项目开发，现已适配 VCS 等硬件设计工具，核心要求为：每行命令必须以 Tab 缩进，换行需用 \ 标记。

3.1 典型 VCS Makefile 示例¶

# 编译并执行仿真
vcs:
        vcs -full64 -sverilog \
        -fsdb +define+FSDB \
        -P \
        ${VERDI_HOME}/share/PLI/VCS/LINUX64/novas.tab \
        ${VERDI_HOME}/share/PLI/VCS/LINUX64/pli.a \
        -f filelist.f \
        -l uart.log
        ./simv

# 调用Verdi查看仿真波形
verdi:
        verdi -f ./filelist.f 

# 清理编译产物与临时文件
clean:
        @rm -rf simv.* 
        @rm -rf _vcs* 
        @rm -rf nova* 
        @rm -rf ucli* 
        @rm -rf simv 
        @rm -rf verdiLog* 
        @rm -rf csrc
        @rm -rf *.fsdb 
        @rm -rf *.txt *.v temp 1
        @rm -f *.log

3.2 核心运行命令¶

在 Makefile 所在目录执行以下命令，完成对应操作：

make vcs   # 执行代码编译，生成并运行simv可执行文件（编译+仿真）
make verdi # 调用Verdi工具，读取文件列表并打开波形查看界面
make clean # 彻底清除上次编译的产物、仿真日志、波形文件等临时文件

3.3 VCS 核心编译参数说明¶

以下为示例中涉及的VCS 最基础、最常用参数，是数字前端工程的必备参数，更多高级参数可参考官方文档vcs_user_guide.pdf：

参数	功能说明	注意事项
`-full64`	以 64 位模式运行并生成 64 位可执行程序 simv	主流 64 位 Linux 环境的默认必加参数，生成的 simv 仅能在 64 位 OS 运行
`-sverilog`	启用 SystemVerilog 语言支持	需代码中使用 SV 语法时添加，原生 VCS 默认仅支持 Verilog
`-fsdb`	指定生成 FSDB 格式的仿真波形文件	需配合 Verdi 查看波形，需同时定义`+define+FSDB`
`+define+XXX`	定义宏变量 XXX	示例中为 FSDB，用于开启波形生成功能
`-P`	启用 PLI 功能，加载指定的 PLI 表文件与库文件	核心用于提供对 Verdi 的支持，需指定 Verdi 的 novas.tab 与 pli.a 路径
`-f <filelist.f>`	加载待编译的文件列表文件	避免命令行直接拼接大量源文件，简化编译命令，filelist.f 中为所有 Verilog/SV 源文件路径
`-l <logfile>`	指定仿真日志的输出文件	示例中为 uart.log，所有编译、仿真信息均写入该文件，便于问题排查

3.4 PLI 功能补充¶

Verilog PLI（Programming Language Interface）是 Verilog 的编程语言接口，提供一套 C 语言函数库，核心作用为：

设计人员可通过 C 语言编写辅助程序，与 Verilog 代码集成；
RTL 编译时，PLI 程序会被整合至仿真环境中；
仿真运行时，可通过系统任务调用双向访问仿真数据结构：既可以读取仿真中的信号、寄存器数据，也可以主动修改仿真数据，实现自定义仿真逻辑。

4 VCS 工作底层逻辑¶

VCS 的工作流程与 gcc 编译 C 程序的流程高度一致，核心分为编译和链接两个阶段，最终生成可执行文件simv并执行仿真，完整流程如下：

源文件：输入 Verilog/SystemVerilog 源文件（如mem.v、cpu.sv），若有自定义 PLI 逻辑，需同时输入 C 语言源文件（如mem.c、cpu.c）；
编译阶段：将源文件编译为对应的目标文件（如mem.o、cpu.o），完成语法检查、逻辑解析；
链接阶段：将所有目标文件与 VCS 的底层库文件、PLI 库文件链接，生成64 位可执行程序 simv；
仿真执行：运行./simv，执行逻辑仿真，若开启-fsdb参数，会在仿真过程中生成 FSDB 波形文件，同时将仿真日志写入-l指定的日志文件。

核心产物：simv是 VCS 的核心可执行文件，仿真的核心逻辑均通过该文件执行，其运行依赖编译时的库文件路径与工程路径。

5、多线程、分布式与加速方案¶

VCS 的性能加速主要围绕多线程编译和多线程仿真展开，受工具架构限制，不支持分布式多机任务拆分和 GPU 加速，核心为纯 CPU 负载，加速效果与任务规模相关（过小任务无加速效果）。

5.1 核心加速限制¶

单 job 拆分多机任务：不支持；
GPU 加速：不支持，所有计算均由 CPU 完成；
多线程效果：视具体 CASE 而定，过小的仿真任务开启多线程无实际效果，甚至可能因线程调度产生额外开销。

5.2 多线程编译¶

通过-j参数开启多线程编译，-j 与线程数之间无空格，核心提升代码编译阶段的速度，适用于源文件数量多的大型工程：

vcs -j<threads_number> -full64 -sverilog [其他参数]
# 示例：开启8线程编译
vcs -j8 -full64 -sverilog -f filelist.f -l compile.log

5.3 多线程仿真¶

VCS 2017 版本后新增-fgp参数，支持simv 可执行文件的多线程仿真，是仿真阶段的核心加速方案，需在编译和仿真阶段同时指定相关参数：

步骤 1：编译阶段添加-fgp参数

vcs -fgp -full64 -sverilog -f filelist.f [其他参数]

步骤 2：仿真阶段指定 FGP 选项

./simv -fgp=[FGP-OPTIONS]
# FGP-OPTIONS为多线程仿真的具体配置，如线程数、仿真分区等

高级用法：关于-fgp的更多高级功能、配置选项及使用限制，可参考官方文档vcs_user_guide.pdf第 57-68 页。

5.4 Verdi 波形查看加速¶

VCS 仅负责生成 FSDB 波形文件，Verdi 在读入大体积 FSDB 文件时，可通过-max_mtr_count参数开启多线程加速，提升波形文件的加载和解析速度，适用于大型工程的波形查看：

verdi -max_mtr_count <线程数> -f filelist.f -ssf <xxx.fsdb>

6 与 Verdi 的关联关系¶

6.1 工具互补定位¶

VCS 的核心能力为代码编译与逻辑仿真，无图形化界面（GUI），无法直接查看仿真波形、进行断点调试；Verdi 是 Synopsys 推出的数字前端专用 GUI 工具，核心能力为波形查看、代码溯源、断点调试、逻辑分析。

VCS+Verdi构成 Synopsys 官方推荐的完整数字前端开发仿真环境，二者协同工作：VCS 负责生成仿真波形文件（FSDB）和仿真日志，Verdi 负责读取并解析 FSDB 文件，提供可视化的波形查看和调试能力。

6.2 协同工作流程¶

VCS 编译时添加-fsdb +define+FSDB -P参数，开启波形生成并适配 Verdi；
运行simv执行仿真，生成 FSDB 格式的波形文件；
执行make verdi或直接调用verdi命令，Verdi 读取文件列表和 FSDB 文件，打开图形化界面；
在 Verdi 中进行波形查看、信号筛选、代码溯源、仿真断点调试等操作。

6.3 版本匹配原则¶

最佳实践：VCS 与 Verdi 的版本需严格一致，精确到小版本号（如 VCS O-2018.09-SP2 对应 Verdi O-2018.09-SP2），版本不匹配会导致波形文件无法读取、PLI 功能异常等问题。

7 IT 视角下的 VCS 任务特性与运维建议¶

从 IT 运维、资源调度角度，VCS 的编译和仿真过程存在特定的资源需求和注意事项，需重点关注IO 负载、内存占用、路径一致性，避免因资源不足或环境问题导致仿真失败。

7.1 编译阶段：与常规软件编译一致¶

VCS 编译阶段的资源消耗、执行逻辑与 Linux 下 gcc 编译 C 程序基本一致，无特殊资源需求，常规编译节点即可满足。

7.2 仿真阶段：高 IO 写入特性¶

若编译时指定了-fsdb参数，运行 simv 执行仿真的阶段会产生大量的文件写入操作，主要为 FSDB 波形文件的写入，会导致 NFS Server 的写负载大幅增加，运维需重点关注：

NFS Server 的磁盘 IO 利用率；
工程所在网络的带宽负载，避免网络拥塞导致仿真卡顿 / 失败

7.3 Verdi 波形查看：大内存占用风险¶

FSDB 波形文件的体积随工程规模、仿真时间增加而急剧增大，Verdi 读入大体积 FSDB 文件时会占用大量内存，易导致登录节点（login node）发生 OOM（内存溢出），运维建议：

将 Verdi 运行在大内存专属节点上，避免在登录节点直接打开；
对超大型 FSDB 文件，可通过 Verdi 的信号筛选功能，仅加载核心信号，降低内存占用。

7.4 环境迁移：路径与版本严格一致¶

VCS 编译生成的 simv 可执行程序，其底层链接的库文件、源文件路径均为写死的绝对路径，且对工具版本高度敏感，环境迁移时若路径 / 版本不一致，会导致 simv 无法执行，核心迁移原则：

工程路径：迁移前后的工程绝对路径完全一致；
工具版本：迁移前后 VCS（及 Verdi）的版本精确到小版本号一致；
软件路径：迁移前后 VCS 的安装主目录（VCS_HOME）完全一致。

7.5 产物依赖：simv 的库文件链接检查¶

可通过ldd simv命令检查 simv 所链接的动态库文件路径，确认所有库文件均存在且路径正确，避免因库文件缺失导致仿真失败，示例输出如下：

ldd simv
linux-vdso.so.1=>(0x00007fff3441f000)
libvirsim.so=>/fastone/software/synopsys/vcs/O-2018.09-SP2/linux64/lib/libvirsim.so (0x00002acefbcaa000)
libc.so.6=>/lib64/libc.so.6(0x00002acf03489000)
# 其余库文件链接信息...

8 补充注意事项¶

日志排查：VCS 的编译和仿真信息均会写入-l指定的日志文件，仿真失败时优先查看日志文件，定位语法错误、路径错误、逻辑错误等问题；
临时文件清理：仿真完成后需及时执行make clean清理临时文件，避免 simv.、_vcs、*.fsdb 等大体积文件占用磁盘空间；
UVM 支持：VCS 原生支持 UVM（通用验证方法学），需开启环境变量中的 UVM 路径，配合+uvm系列参数使用；
64 位环境要求：-full64参数生成的 simv 为 64 位程序，必须在 64 位 Linux 操作系统中运行，32 位环境不支持；
时序仿真：VCS 进行时序仿真时，因需要加载时序库、进行延时计算，会存在显著的大内存占用特性，需为仿真节点分配足够的内存资源。

二 Design Compiler (DC) 全解析：数字前端 RTL 综合工具使用指南¶

标签：支持多线程（DC NXT 及以上版本）、工程项目级可拆分、需手动拆分模块做分布式综合、纯 CPU 负载

核心定位：Synopsys 推出的数字集成电路前端核心RTL 综合工具，将 Verilog/VHDL 的 RTL 级描述转化为满足功耗、时序、面积约束的门级网表，是数字 IC 设计流程中从设计到实现的关键环节

1 核心基础信息¶

1.1 工具核心功能与应用场景¶

核心功能：完成RTL 综合，将寄存器传输级（RTL）的 Verilog/VHDL 代码，结合工艺库（PDK）、IP 库、标准单元库（Stand cell），转化为门级网表（netlist），同时满足用户指定的功耗、时序、面积等约束条件。
应用场景：数字集成电路前端设计流程，是 RTL 设计完成后、物理实现前的核心步骤。
工具分支：主流版本为DC NXT（新一代综合工具，支持多线程等高级特性），旧版本为传统 Design Compiler（无自适应多线程等功能）。

1.2 任务核心特性¶

多线程支持：支持多线程运行，但受商业功能限制，仅 DC NXT 及以上版本提供完整多线程能力；
拆分级别：工程项目级可拆分，单个 DC 工程可按模块（Topview to block）拆分为多个独立 job，不支持单 job 内自动拆分；
负载类型：纯 CPU 负载，无 GPU 加速支持，综合过程的性能瓶颈为 CPU 核心数与算力；
调度支持：可通过LSF（推荐，需加载 lsf wrapper）或fsched调度器实现分布式任务分发，适配集群化部署。

2 调度器环境初始化¶

DC 的分布式综合依赖调度器完成子任务分发，LSF 为默认推荐调度器，使用前需先初始化 wrapper 环境、加载对应环境变量，根据终端 shell 类型选择执行命令，初始化后才可进行分布式任务提交。

# 适用于csh/tcsh shell用户
source /opt/fastone/wrappers/lsf/cshrc.lsf  

# 适用于bash/sh shell用户
source /opt/fastone/wrapper/lsf/profile.lsf

3 DC 工作底层原理¶

DC 的综合过程是将抽象的硬件描述转化为具体门级电路的过程，输入为 RTL 代码和各类约束 / 库文件，输出为满足约束的门级网表，完整流程如下：

输入层：Verilog/VHDL 的行为级 / RTL 级描述、IP 库 / PDK 工艺库 / 标准单元库、用户指定的功耗 / 时序 / 面积约束；
综合层：DC 通过逻辑优化、工艺映射，将 RTL 代码转化为寄存器级的电路描述，再进一步映射为门级描述（与 / 或 / 非、触发器等基础逻辑门）；
输出层：生成满足所有约束条件的门级网表（netlist），该网表为物理实现（布局布线）的输入基础。

核心原则：综合过程的结果受约束条件直接影响，需根据设计需求合理定义时序（如时钟频率）、面积（如芯片面积限制）、功耗（如低功耗设计）约束。

4 分布式综合实现方案¶

DC 不支持单 job 自动拆分为多机任务，分布式综合需手动完成模块拆分，核心思路是将大型设计拆分为多个独立功能模块，通过调度器将各模块的综合任务分发到集群不同子节点，并行完成综合，最后可合并各模块网表得到整体设计网表。

4.1 分布式综合核心步骤¶

模块拆分：手动划分设计中的独立功能模块（可按 1 个或多个.v/.vhd 文件为一个模块，确保模块间无跨模块的强耦合依赖）；
脚本编写：为每个拆分后的模块编写单独的综合脚本，脚本中指定该模块的源文件、约束条件、库文件、输出网表路径；
任务分发：通过 LSF/fsched 调度器，将各模块的综合脚本分发到集群的不同子节点（host1/host2/.../hostN）；
并行综合：各子节点独立执行对应模块的综合脚本，完成模块内的 RTL 综合，生成模块级门级网表；
网表合并：所有模块综合完成后，根据设计的顶层结构，将各模块级网表合并为整个项目的顶层门级网表。

4.2 分布式综合架构¶

登录节点（submit node）：提交分布式任务、管理整体设计
    ↓ 分发任务
子节点1（host1）：执行模块1的综合脚本
子节点2（host2）：执行模块2的综合脚本
...
子节点N（hostN）：执行模块N的综合脚本
    ↓ 结果回传
登录节点（submit node）：收集所有模块网表、完成顶层合并

5 多线程使用全攻略¶

DC 的多线程功能是提升综合效率的核心手段，仅 DC NXT 版本支持完整的多线程特性，包含自适应多线程、多线程全局布线、指定核心数、并行执行报告命令四大核心功能，所有多线程配置均在 DC 的交互命令行中执行。

5.1 核心配置原则¶

多线程功能需先通过set_host_options -max_cores指定可用 CPU 核心数，默认核心数为 1（单线程），最大支持 16 核；
DC 会自动检查节点的实际核心数和负载，若指定核数超过实际可用核数，会自动降级并抛出 UIO-230 警告；若节点负载过高，会减少核数使用并抛出 UIO-231 警告；
需禁用上述检查时，可设置disable_multicore_resource_checks true（不推荐，易导致工具卡顿）。

5.2 指定单个节点最大可用核数¶

set_host_options是多线程配置的基础命令，用于指定 DC 综合过程中可使用的最大 CPU 核心数，是开启所有多线程功能的前提。

语法与示例

# 查看当前host配置状态
status set_host_options

# 指定最大可用核数为N（N为整数，1≤N≤16）
set_host_options -max_cores N

# 示例：指定节点最多使用4个CPU核心
set_host_options -max_cores 4

# 禁用多线程（恢复单线程）
set_host_options -max_cores 1
# 或
remove_host_options

5.3 DC NXT 自适应多线程¶

dcnxt_adaptive_multithreading为 DC NXT 专属特性，实现工作负载与可用 CPU 资源的动态适配，提升高负载机器下的多线程性能，无需用户额外配置。

核心属性

项目	说明
类型	布尔值（true/false）
支持版本	仅 DC NXT（非拓扑 / 拓扑模式均支持），传统 DC/DC Explorer 不支持
默认值	DC NXT 中默认为 true（开启）
核心作用	动态适配工作负载，机器负载超物理核数时优化执行时间，负载较低时无影响
特性优先级	高于`disable_multicore_resource_checks`，开启后会自动禁用该参数的资源检查

配置示例

# 开启自适应多线程（DC NXT默认开启，可省略）
dcnxt_adaptive_multithreading true

# 关闭自适应多线程
dcnxt_adaptive_multithreading false

5.4 多线程全局布线（Zroute）¶

spg_enable_multithreaded_zroute用于开启多线程确定性 Zroute 全局布线，仅在 DC NXT 拓扑模式下支持，配合compile_ultra -spg命令使用，提升布线阶段的效率。

核心属性

项目	说明
类型	布尔值（true/false）
支持版本	仅 DC NXT，传统 DC 不支持；仅拓扑模式生效，非拓扑模式不支持
默认值	DC NXT 拓扑模式下默认为 true（开启），DC Explorer / 传统 DC 拓扑模式为 false
触发条件	需使用`compile_ultra -spg`，且开启`placer_enable_enhanced_router`/`set_ahfs_options -global_route`（默认编译设置不触发）
结果特性	核数相同则布线结果可重复，核数不同则结果略有差异（不影响约束满足）

配置示例

# 开启多线程Zroute全局布线（DC NXT拓扑模式默认开启）
spg_enable_multithreaded_zroute true

# 关闭多线程Zroute，使用单核心布线
spg_enable_multithreaded_zroute false

5.5 并行执行报告 / 检查命令¶

parallel_execute用于将多个报告命令 / 检查命令并行执行，提升设计分析效率（如同时生成时序报告、QoR 报告、单元报告），适用于综合完成后的设计验证阶段。

核心特性

需先执行update_timing更新时序信息，否则报告结果可能不准确；
需通过set_host_options指定核数，默认最多使用 8 核，指定超过 8 核会被自动降级；
命令列表需用双引号包裹，多命令用[list ...]封装；
支持将输出重定向到单个 / 多个文件，自动处理写入 / 追加模式。

语法与示例

# 语法：基础并行执行
parallel_execute [list "命令1" "命令2" ... "命令N"]

# 语法：将所有输出重定向到指定文件
parallel_execute -out 文件名 [list "命令1" "命令2" ... "命令N"]

# 语法：查看所有支持并行执行的命令
parallel_execute -list_all

# 示例1：并行执行4个报告命令（指定4核）
update_timing
set_host_options -max_cores 4
parallel_execute [list "report_qor" \
        "report_timing -from a -to z2 -path_type short" \
        "report_cell -connections -verbose {t_bar}" \
        "report_design"]

# 示例2：将两个报告命令的输出追加到同一日志文件（指定2核）
set LOG "qor_report.log"
update_timing
set_host_options -max_cores 2
parallel_execute [list \
        "report_timing -input_pins -nets -path_type only > $LOG" \
        "report_qor -summary >> $LOG"]

# 示例3：将所有报告输出到单个日志文件
set LOG "all_report.log"
update_timing
set_host_options -max_cores 2
parallel_execute -out $LOG [list "report_timing" "report_qor" "report_cell"]

6 多线程运行 DC 任务完整流程¶

以 DC NXT 拓扑模式为例，开启多线程完成 RTL 综合 + 并行报告的完整操作流程（DC 交互命令行中执行）：

# 步骤1：初始化环境，指定最大可用核数为8
set_host_options -max_cores 8

# 步骤2：开启DC NXT自适应多线程（默认开启，可省略）
dcnxt_adaptive_multithreading true

# 步骤3：开启多线程Zroute全局布线（DC NXT拓扑模式默认开启，可省略）
spg_enable_multithreaded_zroute true

# 步骤4：执行RTL综合（以compile_ultra -spg为例，触发多线程布线）
read_verilog ./rtl/top.v  # 读取RTL源文件
read_lib ./lib/tsmc18_stdcell.lib  # 读取标准单元库
set_clock_uncertainty 0.1 [get_clocks clk]  # 设置时序约束
compile_ultra -spg  # 执行高级综合，触发多线程Zroute

# 步骤5：更新时序信息，为并行报告做准备
update_timing

# 步骤6：并行执行多个报告命令，分析综合结果
parallel_execute -out ./report/synth_report.log [list "report_qor -summary" "report_timing -max_paths 10" "report_area" "report_power"]

# 步骤7：保存门级网表
write -format verilog -hierarchy -output ./netlist/top_netlist.v

7 IT 视角下的 DC 任务特性与运维建议¶

从 IT 运维、集群资源调度角度，DC 综合任务存在明确的资源需求和操作规范，需重点关注版本特性、资源分配、分布式调度，避免因资源不足或配置错误导致综合失败。

版本与功能匹配：多线程、分布式综合仅 DC NXT 及以上版本支持，传统 DC 版本为单线程，需根据工具版本合理分配资源；
CPU 资源分配：DC 为纯 CPU 负载，综合过程对 CPU 核心数敏感，单个模块的综合任务建议分配4-16 核（根据模块规模），避免单节点分配过多核数导致集群资源耗尽；
分布式任务调度：使用 LSF 调度器时，需确保所有子节点已完成 wrapper 初始化、DC 环境变量配置一致，且各子节点均可访问共享的源文件、库文件、脚本文件（如 NFS 共享目录）；
文件存储：综合过程中会生成大量中间文件，建议将工程目录部署在高 IO 性能的 NFS Server，避免因文件读写卡顿影响综合效率；
日志排查：综合过程的报错、警告信息会输出到 DC 交互终端或指定的日志文件，需重点关注UIO-230/231（核数不匹配 / 节点负载过高）、约束违例（时序 / 面积 / 功耗不满足）类错误；
资源检查：执行大型综合任务前，可通过status set_host_options检查核数配置，通过uptime查看节点负载，确保资源满足需求

8 补充注意事项¶

约束优先原则：DC 的综合结果以满足约束为核心，若约束设置过于严格（如时钟频率过高），会导致综合失败或设计面积 / 功耗急剧增加，需根据工艺库特性合理设置约束；
库文件一致性：分布式综合时，所有子节点使用的 IP 库、PDK 库、标准单元库必须版本一致、路径一致，否则会导致模块网表无法合并；
模块拆分规范：拆分模块时需确保模块间的接口信号完整，避免因接口缺失导致综合后的模块网表无法正常连接；
多线程结果一致性：DC NXT 的多线程综合结果与核数相关，相同核数多次运行结果可重复，不同核数结果可能略有差异，但均会满足约束条件；
报告命令并行限制：parallel_execute仅支持报告 / 检查类命令，不支持综合、优化类命令（如compile_ultra、elaborate）

三 ICC/ICC2 全解析：数字集成电路后端自动布局布线工具使用指南¶

标签：支持工程项目级拆分与分布式执行、仅布线阶段支持多线程 / 分布式、读写阶段为单线程 IO 瓶颈、纯 CPU 负载

核心定位：Synopsys 推出的数字集成电路后端核心自动布局布线（APR）工具，ICC 为经典版本，ICC2 为升级版本，二者均承接前端 DC 综合生成的门级网表，完成从物理布局到布线的全流程后端设计，是芯片流片前物理实现的关键环节。

1 核心基础信息¶

1.1 工具核心功能与应用场景¶

核心功能：实现数字芯片后端的自动布局布线（Auto Place & Route），将前端 RTL 综合后的门级网表，结合 PDK 工艺库、物理约束，完成芯片的单元布局、电源地（PG）网络创建、全局布线、细节布线等，最终生成可用于流片的物理版图数据。
应用场景：数字集成电路后端设计流程，承接 DC/DC NXT 的综合结果，是物理实现的核心步骤。
版本差异：ICC 为传统经典版本，ICC2 为新一代升级版本，核心工作原理一致，多线程 / 分布式的命令与参数指定方式不同，ICC2 对分布式任务的支持更精细化。

1.2 任务核心特性¶

拆分与分布式：支持工程项目级拆分，单个 ICC/ICC2 工程可按模块（Topview to block）拆分为多个独立 job，通过调度器实现分布式执行；
多线程支持：仅布线（route）阶段支持多线程，前期布局、规则设定、文件读写等阶段均为单线程，无多核心加速能力；
负载类型：纯 CPU 负载，布线阶段对 CPU 核心数敏感，无 GPU 加速支持；
调度支持：仅支持LSF 调度器（Fsched 需使用 lsf wrapper），分布式任务需通过 LSF 完成子节点分发。

1.3 调度器环境初始化¶

与 DC 一致，ICC/ICC2 使用 LSF 调度器进行分布式任务提交前，需先初始化 wrapper 环境、加载对应环境变量，根据终端 shell 类型选择执行命令，初始化后才可进行分布式任务配置与运行：

# 适用于csh/tcsh shell用户
source /opt/fastone/wrappers/lsf/cshrc.lsf  

# 适用于bash/sh shell用户
source /opt/fastone/wrapper/lsf/profile.lsf

2 ICC/ICC2 工作底层原理¶

ICC/ICC2 的核心工作是将前端的门级网表转化为物理版图，整体流程围绕布局和布线展开，仅布线阶段支持分布式 / 多线程，也是后端设计中最耗时的核心环节。

2.1 整体工作流程¶

输入层：前端 DC 综合生成的门级网表、PDK 工艺库、物理约束（如芯片面积、引脚位置、线宽规则）、电源地约束；
布局阶段：完成标准单元的自动布局、电源地（PG）网络创建，此阶段为单线程执行，无多线程 / 分布式支持；
布线阶段：分为全局布线和细节布线，是唯一支持多线程单机执行和分布式多机执行的阶段，也是性能优化的核心环节；
输出层：完成所有布线后，生成满足物理规则和时序约束的物理版图数据（GDSII），为后续流片做准备。

2.2 分布式布线核心原理¶

ICC/ICC2 的分布式执行仅针对布线阶段，由主节点（Master） 统一管理，子节点（Host） 并行执行模块内布线，最终由主节点完成模块间互联，核心步骤如下：

主节点划分：主节点处理顶层（TOP View）设计，完成各功能模块的布线区域划分，并定义统一的布线规则；
任务分发：主节点通过 LSF 调度器，将划分好的各模块（Block）及对应的布线规则分发到集群的不同子节点；
子节点并行布线：各子节点独立执行对应模块的内部布局布线工作，完成后将结果回传至主节点；
主节点互联：主节点收集所有子节点的模块布线结果，完成模块之间的信号线、电源地网络的跨模块布线互联；
全局验证：主节点对整体设计进行物理规则和时序验证，确保无布线违例、时序满足要求。

分布式架构：

主节点（Master/TOP View）：划分模块、分发任务、完成模块间互联、全局验证
    ↓ 分发模块+布线规则
子节点1（host1）：执行Block1的内部布线
子节点2（host2）：执行Block2的内部布线
...
子节点N（hostN）：执行BlockN的内部布线
    ↓ 回传模块布线结果
主节点（Master/TOP View）：整合结果、跨模块互联、全局验证

3 ICC 多线程与分布式使用指南¶

ICC 为经典版本，多线程仅支持布线阶段的route_opt命令，分布式需通过set_distributed_route初始化、run_distributed_tasks运行，仅经典路由器（classic router）支持，Zroute 路由器不支持

3.1 单机多线程布线¶

ICC 的多线程仅用于细节布线和布线修复，通过route_opt命令的-num_cpus参数指定核心数，最大支持 63 核，默认单核心执行。

核心前提

使用前需通过set_distributed_route命令开启多 CPU 模式，否则-num_cpus参数无效

语法与示例

# 步骤1：开启多CPU模式（为多线程布线做准备）
set_distributed_route

# 步骤2：执行多线程布线，指定核心数（全局布线阶段，32核）
route_opt -stage global -num_cpus 32

# 示例：细节布线阶段，使用16核执行
route_opt -stage detail -num_cpus 16

关键参数说明¶

-stage：指定布线阶段，global为全局布线，detail为细节布线；
-num_cpus <count>：指定布线使用的 CPU 核心数，1≤count≤63，仅经典路由器支持

3.2 分布式多机布线¶

ICC 的分布式布线基于 LSF 调度器实现，需先初始化分布式网络、指定调度器参数，再运行分布式任务，核心命令为set_distributed_route和run_distributed_tasks

核心语法

# 初始化分布式布线，指定LSF调度器，可选指定分区（partition）
set_distributed_route -lsf [-lsf_advanced bsub_options]

# 运行分布式布线任务
run_distributed_tasks

常用示例

# 设定分布式任务，使用LSF调度器，指定集群分区为hpc
set_distributed_route -lsf -P hpc

# 启动分布式布线任务，由LSF分发到各子节点
run_distributed_tasks

扩展参数说明

set_distributed_route支持精细化配置子节点资源，核心扩展参数：

-jp_machines {m1 m2 m3}：指定仅在 m1、m2、m3 子节点运行分布式任务；
-jp_limit {m1 8 m2 16}：限制子节点的核心使用数，如 m1 最多 8 核，m2 最多 16 核；
-jp_bin {m1 /path/bin}：指定子节点的 ICC 可执行文件路径；
-jp_lib {m1 /path/lib}：指定子节点的工艺库文件路径。

3.3 ICC 性能优化：解决单线程 IO 瓶颈¶

ICC 存在固有单线程 IO 瓶颈，与存储、网络无关，是工具自身读写策略导致，主要体现在：

大版图设计时，前期读文件、加载工艺库为单线程，耗时占比高；
布线完成后写入结果文件为单线程，无并行加速；
多线程布线阶段之间，常穿插单线程处理步骤，集群资源利用率波动大。

核心优化建议：减少非必要的单线程操作

ICC 中部分命令会触发单线程 IO 和磁盘读写，执行时计算节点负载极低，需尽量减少非必要使用，核心需避免的命令：

derive_pg_connection：推导电源地连接；
verify_pg_nets：验证电源地网络；
save_mw_cel：保存设计数据库。

具体优化措施

合并 check/save 动作：连续执行多个布线流程（如全局布线→细节布线→布线修复）后，再统一执行一次verify_pg_nets/save_mw_cel，避免每步流程后都执行；
减少中间文件保存：仅在关键节点（如布局完成、全局布线完成、最终布线完成）保存设计数据库，避免频繁保存；
提前加载库文件：在任务调度前，提前在子节点加载工艺库，减少分布式任务中库文件的重复读取

4 ICC2 多线程与分布式使用指南¶

ICC2 为 ICC 的升级版本，核心工作原理与 ICC 一致，但分布式 / 多线程的命令体系完全重构，对模块级分布式执行的支持更灵活，提供run_block_script和run_block_compile_pg两大核心分布式命令，分别用于模块脚本分布式执行和电源地网络分布式创建。

4.1 核心分布式命令 1：run_block_script¶

用于将指定的 Tcl 脚本分布式执行在多个模块（Block） 上，支持自定义运行顺序、工作目录、节点参数，是 ICC2 分布式布局布线的核心命令。

核心语法

run_block_script \
    -script <脚本名> \          # 要分布式执行的Tcl脚本路径
    -cells <单元集合> \         # 目标物理单元集合
    -blocks <模块名列表> \      # 要执行的模块名列表（如{block1 block2 block3}）
    -run_order <执行顺序> \     # 执行顺序：bottom_up（自底向上）/top_down（自顶向下）
    [-host_options <节点参数>] \# 分布式处理的节点参数（如核心数、分区）
    [-var_list <变量键值对>] \  # 传递给脚本的变量（如{var1 val1 var2 val2}）
    [-work_dir <工作目录>] \    # 子节点的工作目录
    [-force] \                  # 强制覆盖已有文件
    [-name <任务名>]            # 分布式任务的名称（便于调度器管理）

常用示例

# 分布式执行布线脚本route.tcl，在block1/block2/block3上运行，自底向上执行，指定工作目录
run_block_script \
    -script ./tcl/route.tcl \
    -blocks {block1 block2 block3} \
    -run_order bottom_up \
    -work_dir ./dist_block \
    -name icc2_dist_route

4.2 核心分布式命令 2：run_block_compile_pg¶

专门用于电源地（PG）网络的分布式创建，支持顶层和模块级 PG 网络的并行生成，解决 ICC 中 PG 网络创建单线程的效率问题，是 ICC2 的核心升级点之一

核心语法

run_block_compile_pg \
    [-skip_top] \               # 跳过顶层设计的PG网络创建，仅处理模块级
    [-host_options <节点参数>]   # 分布式处理的节点参数（如核心数、LSF分区）

常用示例

# 分布式创建所有模块（含顶层）的PG网络，指定LSF节点参数
run_block_compile_pg -host_options lsf_hpc

# 仅分布式创建模块级PG网络，跳过顶层
run_block_compile_pg -skip_top -host_options lsf_hpc

4.3 ICC2 多线程与分布式核心特点¶

命令重构：摒弃 ICC 的set_distributed_route/run_distributed_tasks，采用更灵活的run_block_script/run_block_compile_pg，支持自定义脚本和精细化模块管理；
PG 网络分布式：ICC 中 PG 网络创建为单线程，ICC2 通过run_block_compile_pg实现分布式创建，大幅提升后端设计前期效率；
运行顺序可控：支持bottom_up/top_down两种模块执行顺序，适配不同的设计层级结构；
资源精细化配置：通过-host_options可统一指定所有子节点的资源参数，无需为每个节点单独配置

5 IT 视角下的 ICC/ICC2 任务特性与运维建议¶

从 IT 运维、集群资源调度角度，ICC/ICC2 的后端设计任务存在明确的资源需求和操作规范，核心需围绕单线程 IO 瓶颈、布线阶段资源分配、分布式节点一致性做优化，避免因资源配置不当导致任务卡顿或失败。

CPU 资源分配策略：仅布线阶段分配多核心（建议 16-63 核，根据模块规模），布局、读写、PG 网络创建（ICC）等单线程阶段仅分配 1-2 核，避免集群资源浪费；
分布式节点一致性：所有子节点需满足三一致——ICC/ICC2 版本一致、PDK 工艺库版本 / 路径一致、LSF wrapper 环境一致，否则会导致模块布线结果无法合并；
存储与 IO 优化：将工程目录部署在高 IO 性能的 NFS Server，缓解单线程读写的 IO 瓶颈；对大版图设计，可将工艺库缓存至子节点本地磁盘，减少远程库文件的重复读取；
LSF 调度器配置：分布式任务建议为 ICC/ICC2 创建专属 LSF 分区（如 hpc_icc），避免与其他任务抢占资源；根据模块规模设置子节点的核心数上限，防止单任务耗尽节点资源；
任务监控重点：监控子节点的CPU 利用率和磁盘 IO，布线阶段 CPU 利用率应保持高位，若出现长时间低利用率，大概率为单线程 IO 步骤，可优化脚本减少非必要 check/save；
大版图任务拆分：超大规模芯片设计需按功能模块 + 物理区域双重拆分，避免单个模块的布线任务过大，导致单节点内存溢出；建议单个模块的设计规模不超过 100k 标准单元。

6 ICC 与 ICC2 核心特性对比¶

为便于快速区分和选型，核心对比 ICC 和 ICC2 在多线程 / 分布式、核心命令、性能优化等方面的差异：

特性	ICC（经典版本）	ICC2（升级版本）
核心工作原理	自动布局布线，仅布线阶段支持并行	与 ICC 一致，布局布线流程完全兼容
多线程支持	仅 route_opt 命令，最大 63 核，仅经典路由器支持	集成至分布式命令，通过 host_options 指定核数
分布式核心命令	set_distributed_route + run_distributed_tasks	run_block_script + run_block_compile_pg
PG 网络创建	单线程执行，无分布式支持	分布式执行（run_block_compile_pg），支持模块级并行
执行顺序控制	无，由调度器随机分发	支持 bottom_up/top_down，适配设计层级
脚本灵活性	仅支持布线命令分布式，自定义性差	支持任意 Tcl 脚本分布式执行，自定义性强
单线程 IO 瓶颈	存在，读库、写结果、check/save 均为单线程	仍存在，但可通过分布式 PG 创建减少单线程耗时
路由器支持	仅经典路由器，Zroute 不支持并行	支持经典路由器和 Zroute，均适配分布式

7 补充注意事项¶

路由器选型：ICC 的-num_cpus参数仅支持经典路由器，若使用 Zroute 路由器，多线程 / 分布式参数均无效，需注意命令适配；
结果一致性：多线程 / 分布式布线的结果与核心数 / 子节点数相关，相同配置下多次运行结果可重复，不同配置下结果略有差异，但均需满足物理规则和时序约束；
内存需求：后端布局布线对内存要求极高，大版图设计需为节点分配足够的物理内存（建议≥256G），避免内存溢出导致任务中断；
版本兼容：ICC2 完全兼容 ICC 的设计数据库，但 ICC 无法读取 ICC2 的高版本数据库，升级后建议统一使用 ICC2 流程；
全局验证：分布式布线完成后，必须在主节点执行全局物理规则检查（DRC）和时序签核（STA），避免模块间互联存在违例。