📚 课程目录第3章全局参数配置

3. 全局参数配置：Tcl 脚本架构解析、全局变量定义、设计名称与工艺节点设置、日志与报告输出路径

好，咱们进入第三章。这一章看起来是配置，其实是在搭骨架。你想想看，一个芯片后端项目，少则几十个脚本，多则上百个。如果没有一套清晰的全局参数体系，后面改个工艺节点或者换条路径，那真是牵一发动全身，改到你怀疑人生。

我个人习惯，在项目一开始就把全局参数这块夯死。哪怕后面要改，也只需要改一个地方。今天我们就来拆解一下，OpenROAD 的 Tcl 脚本架构到底该怎么搭，全局变量怎么定义，设计名、工艺节点、日志路径这些基础配置怎么设才不容易翻车。

3.1 Tcl 脚本架构：别写成意大利面条

很多新手喜欢把所有的命令写在一个大脚本里，跑完一步注释掉下一步。嗯，我刚开始也这么干过。结果有一次不小心注释错了行，整个 floorplan 阶段的数据全乱了，查了半天才发现是某条命令被误关了。

所以，我建议你把脚本拆成模块化的结构。一个典型的 OpenROAD 项目，脚本目录大概长这样：

project_root/
├── scripts/
│   ├── 00_setup.tcl          # 全局参数配置
│   ├── 01_import_design.tcl   # 导入设计
│   ├── 02_floorplan.tcl       # 布局规划
│   ├── 03_placement.tcl       # 标准单元放置
│   ├── 04_cts.tcl             # 时钟树综合
│   ├── 05_routing.tcl         # 绕线
│   ├── 06_signoff.tcl         # 签核
│   └── utils/
│       ├── procs.tcl          # 自定义过程
│       └── colors.tcl         # 颜色定义（调试用）
├── logs/                      # 日志输出
├── reports/                   # 报告输出
└── results/                   # 结果数据

每个脚本只干一件事。00_setup.tcl 就是今天的主角，它被所有后续脚本 source 进来。说白了，它就是整个项目的「总控室」。

核心原则：全局参数脚本只定义变量和路径，不执行任何物理操作。这样你 source 它的时候，不会意外触发任何流程步骤。

3.2 全局变量定义：命名规范与作用域

变量命名这件事，看起来小，但坑特别多。我曾经在一个项目里看到有人用 design_name，有人用 DESIGN_NAME，还有人用 DESIGN。结果后期集成的时候，两个脚本互相覆盖，跑出来的结果完全不对。

我个人的规范是这样的：

变量类型	命名风格	示例	说明
设计常量	全大写 + 下划线	`DESIGN_NAME`	设计名称、工艺节点等不变参数
路径变量	全大写 + DIR/ FILE 后缀	`LOG_DIR`, `REPORT_DIR`	目录和文件路径
流程控制	小写 + 下划线	`enable_cts`, `skip_route`	布尔开关或流程选项
临时变量	小写 + 下划线	`tmp_file`, `cell_count`	只在当前过程内使用

为什么要这么分？因为你在脚本里一眼就能看出这个变量是干什么的。全大写的，你不敢随便改；小写的，你知道它是临时的。

小技巧：在 00_setup.tcl 的开头加一段注释，列出所有全局变量的用途和取值范围。这样半年后你自己回来看，或者交接给同事，都不会一脸懵。

3.3 设计名称与工艺节点设置

设计名称和工艺节点，这两个参数是所有后续配置的基石。我见过有人把工艺节点硬编码在脚本的各个角落，结果换工艺的时候改了十几个文件，还漏了两个。

正确的做法是：在 00_setup.tcl 里统一定义，其他地方只引用变量。

# ============================================
# 00_setup.tcl - 全局参数配置
# ============================================

# --- 设计基本信息 ---
set DESIGN_NAME    "my_chip_top"
set DESIGN_VERSION "v1.2"
set TOP_MODULE     "my_chip_top"

# --- 工艺节点 ---
set TECH_NODE      "28nm"
set LIB_CORNER     "typical"
set VOLTAGE        1.05

# --- 工艺文件路径 ---
set TECH_LEF       "./tech/gsclib045_tech.lef"
set CELL_LEF       "./tech/gsclib045_cell.lef"
set LIB_FILES      [list \
    "./lib/gsclib045_typical.lib" \
    "./lib/gsclib045_slow.lib" \
]

# --- 设计约束 ---
set SDC_FILE       "./constraints/my_chip_top.sdc"

这里有个细节：LIB_CORNER 和 VOLTAGE 我建议单独拎出来，而不是直接写在 lib 文件名里。为什么？因为有时候你需要在同一个工艺节点下切换不同的 corner 做分析，单独定义方便你批量替换。

注意：工艺节点字符串（如 "28nm"）不要用于文件路径拼接。不同工具对节点名称的解析方式不同，直接用变量做路径容易出问题。路径应该用完整的 TECH_LEF 这类变量来管理。

3.4 日志与报告输出路径

日志和报告，是后端工程师的「黑匣子」。出了问题，第一反应就是翻日志。如果日志路径乱七八糟，找起来能急死人。

我习惯把日志、报告、结果分开三个目录，并且按日期和版本打标签。

# --- 输出路径 ---
set PROJECT_ROOT  [file dirname [file normalize [info script]]]
set LOG_DIR       "${PROJECT_ROOT}/logs/${DESIGN_NAME}_${TECH_NODE}"
set REPORT_DIR    "${PROJECT_ROOT}/reports/${DESIGN_NAME}_${TECH_NODE}"
set RESULT_DIR    "${PROJECT_ROOT}/results/${DESIGN_NAME}_${TECH_NODE}"

# --- 自动创建目录 ---
foreach dir [list $LOG_DIR $REPORT_DIR $RESULT_DIR] {
    if {![file exists $dir]} {
        file mkdir $dir
        puts "INFO: Created directory: $dir"
    }
}

# --- 日志文件命名 ---
set LOG_FILE      "${LOG_DIR}/flow_${DESIGN_VERSION}.log"
set SUMMARY_FILE  "${REPORT_DIR}/summary_${DESIGN_VERSION}.rpt"

你看，这里用了 file dirname 和 file normalize 来获取脚本所在目录的路径。这样不管你在哪个目录下运行脚本，路径都不会乱。这个坑我踩过——有一次在服务器上跑，当前目录是 /tmp，结果所有输出都写到了 /tmp 下面，找了一下午。

另外，日志文件名里带上版本号，方便回溯。同一个设计跑多个版本，日志不会互相覆盖。

3.5 知识结构总览

下面这张图，把全局参数配置的核心逻辑串起来了。你可以把它当作本章的「思维导图」。

3.6 避坑指南：我踩过的几个雷

最后，分享几个我实际项目中遇到的坑，希望能帮你省点 debug 的时间。

路径中的空格：我曾经把项目放在 /home/user/my project/ 下面，结果 OpenROAD 解析路径的时候直接报错。Tcl 对空格很敏感，要么用花括号括起来，要么路径里别加空格。
相对路径的陷阱：如果你用 source ./00_setup.tcl，这个 ./ 是相对于当前工作目录的，不是脚本所在目录。所以一定要用 file normalize 转成路径。
变量覆盖：多个脚本 source 同一个全局配置时，如果某个脚本里不小心用了 set DESIGN_NAME "temp"，后面的脚本全乱套。我后来加了个惯例：全局变量只在 00_setup.tcl 里定义，其他脚本只读不写。
日志轮转：跑大型设计时，日志文件可能上 GB。如果不做轮转或按阶段拆分，打开日志都能卡半天。我习惯在每个阶段脚本里单独开日志，比如 floorplan.log、placement.log，最后再合并一个总日志。