EDA 计算环境标准化：Modulefiles 多版本工具链管理
EDA 运维最常见的现场：一台服务器上装着 VCS 三个版本、Verdi 两个版本、ZeBu 一套，用户的配置文件里堆了十几行 export，PATH 冲突、库冲突，新人来了三天配不好环境。用 Environment Modules 把工具链收进 modulefile，版本切换就是一条命令的事。
一、为什么不用 export 堆 PATH
export 是追加式的，只进不出：切版本要手动把旧路径抠出来，很容易漏；用户各自为政，每个人的配置文件都不一样，出了问题没法复现；升级风险大，改了全局脚本，所有用户一起受影响，回滚全靠备份。工具一多，这套做法迟早失控。
二、Environment Modules 入门
# 看有哪些模块可用
module avail
# 加载 / 卸载 / 查看已加载
module load vcs/2023.03
module unload vcs/2023.03
module list
# 全部清掉，从干净状态开始
module purgemodulefile 本质上是 Tcl 脚本，放在 $MODULEPATH 指向的目录下，按“工具名/版本号”分目录放。加载时它帮你改 PATH、改环境变量；卸载时再原样摘掉，不留尾巴。
三、给 EDA 工具写 modulefile（以 VCS + Verdi 为例）
#%Module1.0
# /eda/modules/vcs/2023.03
conflict vcs
prepend-path PATH /eda/synopsys/vcs/2023.03/bin
prepend-path LD_LIBRARY_PATH /eda/synopsys/vcs/2023.03/linux64/lib
setenv VCS_HOME /eda/synopsys/vcs/2023.03
setenv SNPSLMD_LICENSE_FILE 27000@lic-server几个要点：conflict vcs 保证同一时间只加载一个 VCS 版本，避免两个版本打架；prepend-path 比直接改 PATH 安全，卸载时自动摘掉；license 变量放在 modulefile 里，换 license 服务器只改一处，不用逐个通知用户改配置文件。
ZeBu 这类成套环境也一样，一个 modulefile 把 ZEBU_ROOT、VCS_HOME、VERDI_HOME、ZEBU_IP_ROOT 一起配好，用户只用记一个名字。注意 csh 和 bash 的区别：module 命令两种 shell 都支持，但 modulefile 里写的是 Tcl 的 setenv，两种 shell 都能用；用户自己的启动脚本里，csh 用 setenv，bash 用 export，别混。
四、多版本切换与默认版本
# 切到旧版本跑历史回归
module unload vcs/2023.03
module load vcs/2020.03
# 看当前加载了什么
module list默认版本用 .modulerc 指定，比如让 module load vcs 默认指向 2023.03。项目组级别可以再进一步：不同项目 source 不同的环境脚本，每个脚本里统一 load 该项目要用的模块版本，项目交接就是交接一个脚本。
五、踩坑清单
LD_LIBRARY_PATH别无限追加：modulefile 里用prepend-path，unload 会自动摘掉，手动 export 的摘不掉。- license 变量别写死在用户 home 目录：放 modulefile，换服务器只改一处。
- csh 的坑：变量后面跟冒号要写
${VAR}，直接写$VAR:会报Bad : modifier。 - 升级先在新版本 modulefile 上验证，别直接改正在用的，验证通过再切默认版本。
- modulefile 本身进版本管理（git），改动可审计、可回滚。
环境标准化的目标是：新人第一天就能跑起来，老环境随时能复现。modulefile 就是 EDA 环境的说明书，写好了，运维就轻松一半。
