前言

前幾天把 LSF 環境架起來了，也稍微看過 APR 工程師的工作現場。
今天想講的不是某家 EDA 工具按哪個按鈕，而是我們每天真正在做的那件事：跑 APR Flow。

概念很單純，單純到可以用童年遊戲來形容。

APR Flow 的本質，就是一場規則很嚴的蘿蔔蹲。
誰先蹲、誰可以一起蹲、誰必須等前面那個人站起來——整條 flow 幾乎都在回答這三個問題。差別只是：遊戲裡講錯會被笑，晶片上講錯會重跑十幾個小時。

最精簡的 APR 日常，長這樣：

FloorPlan  → Place → CTS → Route → ChipData

這條 flow 就是典型的蘿蔔蹲：FloorPlan 蹲完，Place 才能蹲；Place 蹲完，CTS 才能蹲。 沒有前一棒的結果，後一棒根本不該進場。

基礎的 flow 看起來相當的單純且線性對吧？接下來我們在每個 stage 後面加一個 quality check。

旁掛 QC：可以一起蹲的人，不該擋住下一棒

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

現在規則變了。每個 stage 跑完之後，QC 跟下一棒可以同時開跑。

不是所有人都必須排成一列。Place 做完，CTS 可以開始；同時 Q_PLACE 也可以開始驗 Place 的產出。CTS 不必等 QC ——除非你公司的流程明文規定「沒過不准往下」。但那就是產品決策。

以我的認知，APR 的主 flow 在這邊大致就打住了。再複雜一點，頂多是某個階段再 branch-out 出另一個版本。真正開始令人困擾的，是後面的驗證：

• Physical Verification（PV）：layout 符不符合晶圓廠規則、有沒有短路斷路
• Static Timing Analysis（STA）：訊號跑得夠不夠快、能不能在時脈邊界前到達

做一顆晶片很貴。APR 工程師花最多時間的地方，從來不是「再按一次 Route」，而是驗證跟修改之間的來回。

STA：一個人喊，一排人同時蹲

一個非常簡單的 STA 示意。實務上還會有更多 corner、更多條件重複使用：

				  +--> [RCWorst+SS_125C] -> [PrimeTime] ----+
                  |                                         |
				  |--> [RCWorst+TT_25C] -> [PrimeTime] -----|
[ChipData] -----> |                                         | -----> [Summary]
				  |--> [RCBest+FF_-40C] -> [PrimeTime] -----|
				  |                                         |
				  +--> [CWorst+ SS_125C] -> [PrimeTime] ----+

ChipData 一完成，四個（或四十個）corner 可以一起丟進 LSF。它們彼此不互等，但 Summary 必須等全部 PrimeTime 回來。這不是直線，是有方向、可分叉、可匯流、但不准繞回來的圖。

所以 APR Flow 幾乎都是 DAG

Directed Acyclic Graph，有向無環圖。對 APR 來說，它剛好對上現場的幾條紀律：

• 有方向：Parent → Child，先做完才能做後面
• Child 不回連 Parent：Route 的結果不會倒回去改 Place 的起點（那是另一次 iteration，另一次 flow）
• 沒有 Cycle：一有環，排程器就不知道誰該先蹲
• 一個節點可以有多個 Parent 或 Child：QC 旁掛、STA fan-out、Summary 匯流，全靠這個

看到 DAG，敏銳的朋友大概已經想到 Airflow。據我所知，業界確實有人把 Airflow 拿來管 EDA Flow，而且做出不錯的成果。

個人仍覺得 Airflow 在 EDA 現場會撞上幾件事：

1. Dynamic DAG 有彈性，但生成邏輯還是得有人養。 ECO、驗證策略、corner 組合一變，圖就得重編。
2. 節點一多，維護成本跟視覺化複雜度會一起漲。 APR 的圖不是「每天跑同一條 ETL」，可能會這週多三個 corner、下週多一個 PV deck。
3. Airflow 的設計目標是資料處理流程（Data Pipeline），不是晶片設計流程（EDA Flow）。 兩者都能用 DAG 描述，面對的問題並不完全一樣：我們要對的是 LSF 帳號、queue、cpu、.done marker，以及「這個 block 是誰的責任」。

更何況，我們的工作環境通常不友善——不一定能 pip install 東西、也不一定能長駐數台 Airflow server。所以這個 side project 想走另一條路：不依賴任何第三方套件，看看能不能用最單純的方法，把這場蘿蔔蹲的口令寫清楚。

流程圖上看不到的依賴

講 DAG 時，有人會直覺以為：Child 的 input 應該全部來自 Parent 的 output。

真實的 EDA Flow 不是這樣。一個節點除了等 Parent 的結果，往往還要吃一批靜態資源：netlist、sdc、lef/def、Rule Deck、foundry 的 PV deck。它們不是 flow 裡的某個 job 生出來的，是 designer 或 SDK 早就放在那裡的。

以 Root Node 的 FloorPlan 為例：它沒有任何 Parent，但沒有 netlist 照樣開不了工。這種依賴通常不會被畫成獨立節點——沒有人會為了「讀一個 sdc」專門建一個 Stage。所以從流程圖上看，Root 更像是憑空開始；實際上，flow 上的連線只是在描述「誰先蹲完誰才能蹲」，圖外可能還會有一些檔案必須就位。

今日小結

• PV / STA 才是分叉與匯流開始爆炸的地方
• 多數 APR Flow 適合用 DAG 描述，但 DAG 圖上可能看不到全部依賴