前言

昨天的 WinFlow 2.0 架構圖裡，有一份檔案被畫在正中間：描述 Flow 的 JSON。

Generator 產出它，Runner 消費它，GUI 編輯的也是它。如果把 WinFlow 看成引擎，這份 JSON 就是燃料。引擎可以共用，燃料配方不能。

因為每一家 IC 設計公司的 Flow，可能都長得不太一樣。

這不是文案，是現場。Queue 名稱不一樣、stage 切法不一樣、QC 要不要擋主鏈不一樣、有沒有 PostCTS / PostRoute 不一樣。如果把流程寫死在 Python 裡，每一次調整都會是改程式、發版本、重新部署。

所以 2.0 的底層原則：

把 Flow 定義與程式碼分離。程式負責執行；Flow 本身由 JSON 描述。

同一套引擎，三種常見配方

有些公司的 flow 很短：

FloorPlan -> Place -> CTS -> Route

有些公司會在中間插入優化：

FloorPlan -> Place -> CTS -> Post_CTS -> Route -> PostRoute

有些公司要求特定階段就同步開 QA：

FloorPlan -> Place -> CTS -> Route ---> PV
    |                               |-> QA
    +--> PV                         |-> IR
    +--> QA
    +--> IR

這三張圖都還是昨天說的蘿蔔蹲，只是口令不同。WinFlow 不想當「某家公司的 APR script 集合」，它只想當能讀懂口令的引擎。口令寫在 JSON 裡，換公司就換檔案，不必換程式。

一個最簡單的 Flow，對應到節點

以前幾天的 APR + QC 為例：

FloorPlan ───► Place ───► CTS ───► Route
    │           │         │          │
    └──► QC     └──► QC   └──► QC    └──► QC

在 WinFlow 裡，畫面上的每一個方塊，都會被定義成一個工作節點（Job Node）。Stage / Task 是給人看的分組標籤；真正會被送進 LSF 的，是裡面那一顆 job。

一個工作節點裡面有什麼？

以範例中的 FLOOR_PLAN 為例：

{
  "name": "FLOOR_PLAN",
  "command": "./example_flow/FLOOR_PLAN.csh",
  "queue": "tpdsd1",
  "cpu": 1,
  "inputs": ["example.v"],
  "outputs": [
    "example_flow/out/FLOOR_PLAN.done"
  ],
  "parents": [],
  "children": [
    "FLOOR_PLAN/Q_FLOOR_PLAN/Q_FLOOR_PLAN",
    "PLACE/PLACE/PLACE"
  ]
}

有兩個地方特別值得盯：

1. parents / children 用的是完整 key，不是短名字。
   因為不同 stage 裡可能都有叫 QC 的東西。身份必須是 FLOOR_PLAN/Q_FLOOR_PLAN/Q_FLOOR_PLAN 這種三層路徑。
2. inputs 裡的 example.v 不會出現在任何 parent 的 outputs。
   這就是昨天說的「圖外道具」。Flow 圖上 FloorPlan 沒有父親，但仍要 netlist 才開得了工。

Runner 實際在做的事，比 JSON 看起來更笨

系統不會把 stage 陣列從頭掃到尾就當執行順序。它從 Root（parents 為空）開始，每完成一個 job，就去問它的 children：

       [FLOOR_PLAN] 完成
              |
              v
   嘗試放行 Q_FLOOR_PLAN 與 PLACE
              |
              v
   這兩個 job 的所有 parent 都完成了嗎？
              |
              v
      條件滿足才正式 bsub

對這張 APR + QC 圖來說：

• Q_FLOOR_PLAN 只有一個父親 FLOOR_PLAN → FloorPlan 一結束就可以送
• PLACE 同樣只等 FLOOR_PLAN → 可以跟 QC 同時送
• 後面的 Q_PLACE 等 Place，不等 Q_FLOOR_PLAN

JSON 把「誰可以一起蹲」寫成資料，Runner 就不必為每一家公司特製 if/else。

不會真的都靠人工去編這份檔案

看完這些欄位，你應該已經發現：如果完全靠手維護這份 JSON，最後大概不是編錯 key，就是編到懷疑人生。少一個逗號、children 指到不存在的節點、QC 不小心變成下一主站的 parent，每一種狀況都可能會害你半夜加班。

WinFlow 2.0 的思路是把人從字串裡救出來：

1. 先把公司內常用的 Job Node 標準化（一塊積木一個 JSON）
2. 讓使用者用 GUI 拖曳、連線，拼出自己的 Flow
3. 再提供幾份預設 Flow，需要時微調，而不是從空白開始

也就是說，使用者不必直接編這份 JSON。GUI 組裝，系統產出最終定義檔。出錯機率下降，不同專案也可以共用同一套標準節點。

引擎還是同一顆；各家公司差的是積木目錄、預設範本、以及 queue / cpu 這些站點數字。

小結

• 每家公司的 APR 口令不同，所以 Flow 不能寫死在程式裡
• flow.json 是 Generator 與 Runner 之間的唯一契約
• Job 上真正重要的是 command、資源、I/O、以及 parents / children
• Stage / Task 是分組；排程只認 parents / children
• inputs 可以來自 Parent，也可以來自 flow 外的靜態檔
• 這份檔不該靠手刻，該靠標準節點 + GUI + 範本生成