4. SWB项目结构与实验管理

当仿真从“跑通一个器件”进入“系统化探索工艺窗口”阶段,真正决定效率的往往不是单次求解速度,而是项目组织方式。Sentaurus Workbench(SWB)本质上是一个以项目(Project)为容器、以节点(Node)为计算单元、以实验树(Experiment Tree)为组织骨架、以参数化扫描为探索手段、以结果存储为交付物的实验管理系统。理解这五者之间的层级与数据流关系,是自动化组织仿真的前提。

项目目录:一切自动化的物理基础

SWB 项目在磁盘上是一个标准目录结构,所有自动化脚本、参数定义、结果文件都落在这个结构里。典型项目根目录包含:

my_project/
├── project.conf          # 项目级配置:工具路径、默认节点、许可证
├── gtree.dat             # 实验树定义:节点、参数、分支关系
├── nodes/                # 每个节点的独立工作目录
│   ├── n1_1/             # 节点名 = 实验名_序号
│   │   ├── sde.cmd       # 结构编辑命令
│   │   ├── sdevice.cmd   # 器件仿真命令
│   │   ├── pp1_des.cmd   # 参数化后的实际命令
│   │   └── results/      # 该节点输出
│   └── n1_2/
├── params/               # 参数定义与扫描范围
│   └── variables.par
└── results/              # 汇总结果、曲线、日志

关键点在于:nodes/ 下每个节点目录是自包含的。这意味着并行执行时节点之间不会互相污染,也意味着结果存储必须按节点隔离。自动化脚本若直接读写这些目录,必须遵守“一个节点一个目录”的约定,否则并行调度会出错。

节点与实验树:从线性流程到分支探索

节点是 SWB 的最小执行单元,通常对应一条完整的“结构生成→器件仿真→结果提取”链路。实验树则把这些节点按参数维度组织成树状结构:根节点是基准实验,每个分支代表一个参数取值。例如基准器件栅长 Lg=50nm,实验树可以展开为 Lg ∈ {30, 40, 50, 60, 70} nm 五个分支,每个分支下再挂载不同的氧化时间 tox 取值,形成二维扫描网格。

实验树的价值在于可追溯:任意一个节点都能回答“它是在哪组参数下产生的”。自动化组织时,应把实验树视为唯一事实来源,所有脚本从 gtree.dat 或 SWB API 读取节点列表,而不是手工维护节点清单。

SWB 实验树与参数化扫描组织模型 根节点 → 参数分支 → 叶子节点 → 结果存储,每个节点独立目录 基准节点 n0 Lg=50nm, tox=2.0nm Lg=30nm 分支 B1 Lg=40nm 分支 B2 Lg=60nm 分支 B3 Lg=70nm 分支 B4 tox=1.5nm 节点 n1_1 tox=2.0nm 节点 n2_1 tox=2.5nm 节点 n3_1 tox=3.0nm 节点 n4_1 结果存储层 · results/ n1_1/iv_curve.dat n2_1/iv_curve.dat n3_1/iv_curve.dat n4_1/iv_curve.dat 参数化扫描定义 · params/variables.par Lg = 30, 40, 50, 60, 70 (nm) | tox = 1.5, 2.0, 2.5, 3.0 (nm) 扫描组合数 = 5 × 4 = 20 个节点,SWB 自动生成实验树并分配节点目录 基准节点 参数分支 叶子节点 结果存储

参数化扫描:从手工改参数到声明式定义

参数化扫描的核心思想是把“改哪个参数、改成什么值”从命令文件中抽离出来,集中定义在 params/variables.par 中。SWB 在生成节点时,会把参数值代入命令模板,生成每个节点专属的 pp*_des.cmd。例如:

# variables.par 示例
Lg   = 30 40 50 60 70      # 单位 nm
tox  = 1.5 2.0 2.5 3.0     # 单位 nm
Vd   = 0.05 0.5 1.0        # 漏电压扫描点

# sdevice.cmd 模板中引用
Physics {
  Recombination(SRH)
}
Electrode {
  { Name="gate" Voltage=0.0 Workfunction=4.6 }
  { Name="drain" Voltage=@Vd@ }
}

其中 @Vd@ 是 SWB 的参数占位符,运行时被替换为具体数值。自动化组织时,应把参数定义与命令模板分离,这样新增一个扫描维度只需修改 variables.par,不需要改动任何命令文件。

结果存储:按节点隔离与汇总提取

每个节点执行完毕后,结果默认写入该节点的 results/ 目录。自动化组织需要解决两个问题:一是节点级结果不丢失,二是跨节点结果可汇总。推荐做法是:节点级原始结果保留在 nodes/nX_Y/results/ 下,汇总脚本按实验树遍历所有节点,提取关键指标(如阈值电压 Vth、饱和电流 Idsat、亚阈值摆幅 SS)写入项目级 results/summary.csv。

# 汇总脚本伪代码
for node in experiment_tree.leaves():
    iv = read(node.results / "iv_curve.dat")
    vth = extract_vth(iv)
    idsat = extract_idsat(iv)
    ss = extract_ss(iv)
    summary.append(node.name, node.params, vth, idsat, ss)
write_csv("results/summary.csv", summary)

这样,实验树提供“谁是谁”,节点目录提供“原始数据在哪”,汇总文件提供“一眼看全”。三者分工明确,自动化脚本才能稳定运行。

实践建议:在项目初期就固定目录命名规范,例如节点名统一为 n{分支序号}_{叶子序号},参数文件统一放在 params/ 下,汇总结果统一写入 results/summary.csv。命名规范一旦确定,后续所有自动化脚本、可视化脚本、报告生成脚本都可以直接复用,不需要为每个项目重新适配。
常见陷阱:不要在命令文件中硬编码参数值。一旦硬编码,实验树就失去了参数追溯能力,后续想复现某个节点或扩展扫描维度时,只能手工比对命令文件,自动化组织将退化为手工管理。

总结来看,SWB 项目结构、节点、实验树、参数化扫描与结果存储构成了一条完整的自动化组织链路:项目目录是物理容器,节点是执行单元,实验树是逻辑骨架,参数化扫描是探索引擎,结果存储是交付出口。把这五者按规范组织好,后续的批量提交、并行调度、结果汇总和报告生成才能建立在稳定、可追溯的基础之上。