📚 课程目录第4章 StarRC命令行与运行模式

4. StarRC命令行与运行模式

StarRC 的寄生提取签核通常以命令行方式驱动，理解 starrc 命令的选项体系与运行模式，是把它稳定接入数字后端流程、控制资源占用并复现结果的前提。StarRC 的运行可以概括为三层：最外层是 starrc 可执行程序及其命令行选项，中间层是它读取的提取命令文件（通常以 .cmd 或 .nxtgrd 配套的配置形式存在），最内层是提取引擎实际执行的寄生参数计算。命令行选项负责指定输入、输出、运行模式与并行策略，命令文件负责描述工艺、提取规则与输出格式，两者分工明确。

starrc 命令的基本形态与关键选项

最典型的调用形式如下，其中 -c 指定提取命令文件，-o 指定输出数据库，-f 指定输出格式：

starrc -c chip_top.cmd \
       -o chip_top.spef \
       -f SPEF \
       -log chip_top.log \
       -threads 8

常用选项可以按功能分组理解。输入类：-c 指定命令文件，是提取行为的核心描述；-g 或 -tech 用于指定工艺文件或 ITF 相关映射；-layer 可限定只提取某些金属层，用于快速评估或分阶段签核。输出类：-o 指定输出文件名，-f 指定格式（SPEF、DSPF、SPICE、GPD 等），-log 指定日志文件，-report 可输出统计报告。运行控制类：-threads 控制线程数，-distributed 或分布式相关选项控制多机运行，-mode 可切换批处理与交互模式，-verbose 提升日志详细程度，-version 查看版本。

需要特别注意的是，-o 与 -f 必须匹配：如果 -f SPEF 却把输出写成 .dspf，后续工具可能无法识别。签核流程中建议把输出格式、单位、坐标精度在命令文件里显式声明，而不是依赖默认值。

批处理模式：签核的主力运行方式

批处理模式是 StarRC 在签核流程中的默认形态：启动后读取命令文件，完成全部提取，写出结果并退出，不等待人工输入。它适合在回归脚本、Makefile 或作业调度系统中调用。批处理模式的关键在于可复现与可观测：所有输入路径、工艺版本、线程数、输出格式都应在命令行或命令文件中固定，日志中应能看到提取的层次、网络数、寄生元件数与耗时。

一个实用的批处理封装思路是：把公共参数抽成变量，把每次运行的差异（block 名、输出目录、线程数）作为参数传入。例如：

BLOCK=chip_top
THREADS=16
starrc -c ${BLOCK}.cmd \
       -o out/${BLOCK}.spef \
       -f SPEF \
       -log out/${BLOCK}.log \
       -threads ${THREADS} \
       -verbose 2

运行结束后，先看日志末尾是否出现正常结束标记，再检查输出文件是否非空、SPEF 头部是否包含正确的设计名与单位。若日志中出现 “Error” 或 “Fatal”，应优先定位到具体层次与网络，而不是直接重跑。

交互模式：调试与探索的入口

交互模式适合在规则调试、局部网络排查或快速验证命令文件语法时使用。进入交互模式后，StarRC 会给出提示符，允许逐条输入命令、查看中间状态、只提取指定网络或层次，而不必每次跑完整芯片。典型用途包括：确认某条 EXTRACT 语句是否被正确解析、检查某个网络的 RC 网络拓扑、验证 layer 映射是否命中目标金属层。

交互模式与批处理模式应配合使用：先在交互模式中把命令文件的关键片段调通，再固化为批处理脚本进入签核回归。这样能显著减少“整芯片跑完才发现语法错误”的浪费。

多线程与分布式运行配置

StarRC 的并行能力主要体现在两个维度：单机多线程与多机分布式。单机多线程通过 -threads N 启用，适合单台大内存服务器；分布式运行则把不同层次、不同网络或不同 corner 拆分到多台机器上并行，再汇总结果。

线程数并非越大越好。提取过程受内存带宽、I/O 与网络规模影响，线程数超过一定值后加速比会明显下降。工程上建议先做一次线程扫描：固定同一 block 与命令文件，分别用 4、8、16、32 线程运行，记录 wall time 与峰值内存，选择性价比拐点。下表是一个示例性的扫描记录格式（数值为示例，非实测）：

线程数	Wall time（示例）	峰值内存（示例）	相对加速比
4	120 min	48 GB	1.00
8	72 min	52 GB	1.67
16	48 min	60 GB	2.50
32	42 min	78 GB	2.86

分布式配置的核心是任务拆分与结果合并。常见做法是按层次或按 corner 拆分：每个子任务使用相同的工艺与命令文件，只改变输入网表范围或 corner 变量，输出各自的 SPEF，再由上层脚本合并或分别签核。拆分时必须保证每个子任务的单位、坐标精度、层映射完全一致，否则合并后的寄生数据会出现量纲或命名冲突。

分布式运行时，建议为每个子任务单独指定日志与输出目录，避免多个进程写同一文件导致结果损坏。合并前先校验各子任务日志均正常结束。

不要在同一输出路径上并发运行多个 StarRC 实例；也不要在线程数超过物理核数时盲目加大 -threads，否则上下文切换会拖慢整体签核。

把选项、模式与并行策略落到签核流程

实际签核中，建议按以下顺序组织：先用交互模式确认命令文件语法与层映射；再用小规模 block 做线程扫描，确定 -threads 的合理值；随后把参数固化为批处理脚本，接入回归；当单机内存或时间无法满足时，再按层次或 corner 拆分为分布式任务。每一步都保留日志与输出，便于在结果异常时回溯到具体选项或命令文件片段。

最后强调一个容易被忽略的点：-threads 与分布式拆分都会影响运行时间，但不应影响寄生提取的数值结果。若发现不同线程数下 SPEF 出现差异，应优先检查是否存在非确定性输出、浮点舍入或输出顺序问题，而不是简单认为“多线程就是更快”。签核工具的可信度，建立在结果可复现之上。