一、简介

Design Flow Definition（简称 DFD，扩展名为 .dfd）是企业内部用于描述集成电路设计流程的标准文件格式。

DFD 文件用于：

• 规范描述设计流程的步骤、参数、资源依赖
• 作为 Ticket 文件执行时的流程 blueprint
• 支持嵌套 flow、symbolic link、参数覆盖等机制
• 结合 DFA 实现流程自动化管理

DFD 主要面向流程设计工程师开发，终端使用者通常不直接编辑。

二、设计概念

1. DFD 角色定位

• DFD：流程 blueprint → 定义执行结构与逻辑
• Ticket：执行实例配置 → 填写输入、输出、参数

2. 执行原理

• Ticket 通过 FLOW_ID 指定 DFD
• DFA 解析 DFD，展开 step 依赖、 symbolic link
• 最终形成完整 Makefile 执行流程

3. 支持嵌套机制

• step 可引用其他 flow，形成层次化流程
• 支持多层嵌套，形成复杂工艺流程链

4. 参数传递机制

• flow 层级 param 可通过 @ 传递至 step
• 可由 Ticket 覆盖 flow 层级 param
• 支持上下文变量替换 ${VAR_NAME}

三、DFD 文件格式结构

1. 标准格式说明（.dfd 语法）

字段	说明	格式
FLOW	定义流程的唯一名称，与 Ticket FLOW_ID 对应	对应 Ticket 中的 FLOW_ID
INPUT	定义流程层级的输入资源	格式为 ref_id = 文件路径 例如：     INPUT  netlist_in = design.v
OUTPUT	定义流程层级的输出资源	格式为 ref_id = 文件路径 例如：     OUTPUT rpt_out    = result.rpt
PARAM	定义流程层级的预设参数及默认值	格式为 param_id = 默认值 定义预设参数值，例如：     PARAM mode = func
STEP	定义流程步骤step，支持嵌套 flow
+ <	定义 step 的 input link	+ <step_input_id> < flow_input_ref_id
+ >	定义 step 的 output link	+ <step_output_id> > flow_output_ref_id
@	定义参数传递	@ <step_param_id> = flow_param_id
PRECHECK / EXECUTE / POSTCHECK / EXECDQI	指定各阶段脚本
;	结束当前流程步骤step 定义
END	标识 flow 结束

2. STEP 结构

STEP 为流程的最小执行单元，每个 step 可视为一个 flow 的实例，也可以嵌套其他 flow。

语法：

STEP <step_dir_name> <step_ref_id>
+ <step_input_id> < flow_input_ref_id
+ <step_output_id> > flow_output_ref_id
@ <step_param_id> = flow_param_id
;

• step_dir_name：步骤子目录，指定生成的工作目录
• step_ref_id：引用的 flow 名称，系统会载入对应的 .dfd 文件
• +：定义 symbolic link，为 input/output 指向 flow 层级的定义
  • <：step 输入 ← flow 输入
  • >：step 输出 → flow 输出
• @：参数映射，将 flow 层级参数传递给 step
• ;：结束当前 step 定义

例如：

    STEP run_sta sta_step
    + in_netlist  < netlist_in
    + out_report  > rpt_out
    @ flow_mode   = func

3. 预设脚本字段

字段	说明
PRECHECK	步骤前置检查脚本
EXECUTE	主流程脚本
POSTCHECK	流程完成后检查脚本
EXECDQI	自动提取 DQI 指标脚本

4. 结束标识

END：结束整份 flow 定义

票据（ticket）文件会透过 FLOW_ID 指向相对应 .dfd 档，覆写其中 INPUT 与 PARAM 定义。

---

四、JSON 结构定义（Schema）

.dfd 也对应一份 JSON Schema，提供程序可解析与验证的数据结构：

{
  "FLOW": "string",
  "INPUT": { "ref_id": "string" },
  "OUTPUT": { "ref_id": "string" },
  "PARAM": { "param_id": "string" },
  "STEP": [
    {
      "id": "string",     // 可为本地 step 或嵌套 flow 名称
      "dir": "string",
      "input": { "input_ref_id": "string" },   // step input 对应 flow input
      "output": { "output_ref_id": "string" }, // step output 对应 flow output
      "param": { "param_id": "string" }        // step param 对应 flow param
    }
  ],
  "PRECHECK": "string",
  "EXECUTE": "string",
  "POSTCHECK": "string",
  "EXECDQI": "string"
}

此 JSON Schema 将成为自动化工具与验证机制的依据。

五、语法示例

1. 示例：单一 flow

FLOW  510-RCX
INPUT  NETLIST_FILE = design.v
OUTPUT SPEF_FILE = design.spef.gz
PARAM  RC_CORNER = Typ_85c

STEP rcx_stage 510-RCX
+ netlist_in  < NETLIST_FILE
+ spef_out    > SPEF_FILE
@ rc_corner   = RC_CORNER
;

PRECHECK   run_precheck.sh
EXECUTE    run_flow.sh
POSTCHECK  run_postcheck.sh
EXECDQI    extract_dqi.sh
END

2. 示例：多 step flow

FLOW  521-DEF2SDF
INPUT  DEF_FILE = design.def
OUTPUT SDF_FILE = design.sdf.gz
PARAM  rc_corner = WC

STEP rcxt_spef 510-RCX
+ def_in     < DEF_FILE
+ spef_out   > spef_temp
@ rc_corner  = rc_corner
;

STEP spef2sdf 511-SPEF2SDF
+ spef_in    < spef_temp
+ sdf_out    > SDF_FILE
@ rc_corner  = rc_corner
;

END

---