1. 课程导入与工程环境搭建

数字后端自动化脚本工程，本质上是把 Innovus、Tempus、Voltus、Genus 等 Cadence 工具从"手工敲命令"升级为"可版本化、可复用、可回归"的工程化能力。它要解决的核心问题不是"会不会写 Tcl"，而是当设计规模从几十万实例增长到上亿实例、当流程从单点跑通扩展到多工艺多项目并行时，如何让脚本本身成为可维护的资产，而不是散落在个人目录里的临时文件。

一、先看清工具链与脚本接口的分工

Cadence 数字实现工具链通常按阶段划分：Genus 负责综合（RTL → 门级网表），Innovus 负责布局布线（floorplan、place、CTS、route、opt），Tempus 负责签核级静态时序分析（STA），Voltus 负责功耗与 IR-drop 分析。它们共享同一套 Tcl 命令体系，但命令前缀、数据库对象模型和启动方式各不相同。

关键接口有三类。第一类是启动与批处理接口：Genus 用 genus -batch -f script.tcl，Innovus 用 innovus -batch -files script.tcl，Tempus 用 tempus -batch，Voltus 用 voltus -batch。批处理模式下没有图形界面，所有输出依赖日志与报告文件，这正是自动化脚本的立足点。第二类是命令与对象接口：Innovus 中 get_cells、get_pins、get_nets 返回数据库对象集合，配合 dbGet 可访问底层属性；Tempus 中 report_timing、report_constraint 输出可被解析的文本。第三类是数据交换接口：DEF、LEF、Verilog、SPEF、SDC、lib、lef 等文件在工具间传递，脚本工程必须明确每个阶段的输入输出契约。

二、搭建可复用的脚本工程目录

一个可复用的脚本工程，目录结构应当让"流程"与"项目数据"分离。推荐如下组织方式：

backend_flow/
├── scripts/              # 流程脚本，与项目无关
│   ├── common/           # 通用过程：日志、错误处理、变量校验
│   ├── genus/            # 综合阶段脚本
│   ├── innovus/          # 布局布线阶段脚本
│   ├── tempus/           # STA 阶段脚本
│   └── voltus/           # 功耗分析阶段脚本
├── config/               # 项目配置，与流程脚本分离
│   ├── project_a/
│   │   ├── setup.tcl     # 工艺库、变量、路径
│   │   └── constraints/  # SDC、MMMC 配置
│   └── project_b/
├── run/                  # 运行目录，每次执行生成时间戳子目录
├── reports/              # 汇总报告
├── logs/                 # 工具原始日志
└── tools/                # 版本控制与运行环境脚本

这样划分的好处是：scripts/ 可以跨项目复用，config/ 只存放项目差异，run/ 保证每次执行可追溯。配置文件中只定义变量，不写流程逻辑；流程脚本只读变量，不硬编码路径。例如 setup.tcl 中定义：

set DESIGN_NAME   "core_top"
set LIB_PATH      "/pdk/tsmc28/lib"
set LEF_PATH      "/pdk/tsmc28/lef"
set SDC_FILE      "./constraints/core_top.sdc"
set MAX_ROUTING_LAYER "M8"

Innovus 主脚本则通过 source $CONFIG_FILE 引入这些变量，再执行 read_lef、read_verilog、read_sdc、floorplan、place_opt_design 等命令。变量与逻辑分离后，切换项目只需换一个配置文件。

三、版本控制与运行环境

脚本工程必须纳入 Git 管理。建议只跟踪 scripts/、config/、tools/，忽略 run/、logs/、reports/ 等生成物。分支策略上，main 保持稳定可发布，dev 用于日常开发，每个项目可开 proj/project_a 分支存放项目专属配置。提交信息应包含阶段与影响范围，例如 innovus: fix CTS skew target for project_a。

运行环境方面，Cadence 工具对操作系统、license、环境变量敏感。建议用环境模块（module）或容器固定工具版本，并在脚本入口处做一次环境自检：检查 INNOVUS_HOME、CDS_LIC_FILE 是否设置，检查工具版本是否匹配，检查磁盘剩余空间是否足够。自检失败时立即退出并打印明确原因，避免跑到一半才报错。

四、一次最小可运行闭环

环境搭好后，先用一个最小设计验证链路是否通畅。以 Innovus 为例，执行顺序是：启动批处理 → 读取配置 → 读入 LEF/Verilog/SDC → 执行 floorplan 与 place → 输出报告 → 检查日志中是否有 error。判断成功的依据不是"命令没报错"，而是：日志末尾出现 Innovus finished successfully，reports/ 下生成了时序与面积报告，且报告中 setup 的 WNS 在可接受范围内（示例中可假设为 -0.05 ns 以内）。若 WNS 严重为负，说明约束或库配置有误，应先修配置再继续。

把上述结构固定下来后，后续每一章都会在这个骨架上增加具体能力：约束管理、多模式多端角（MMMC）配置、时序报告解析、功耗分析自动化、回归与签核。本章的目标不是把流程跑完，而是让工程骨架立起来——目录清晰、配置与逻辑分离、版本可追溯、运行可复现。做到这四点，后面的自动化才有稳定的落脚点。