3.1 高階綜合的起伏：1980 年代的夢、失落與回歸#

一個遲到了三十年的承諾#

「工程師寫 C 語言，工具自動生成電路。」這句話在 2020 年代的 AI 加速器設計團隊裡聽起來理所當然，但它其實是一個誕生於 1980 年代、中途夭折、又在二十一世紀初復活的夢。高階綜合（High-Level Synthesis, HLS）的歷史，是 EDA 演算法史上最典型的「技術正確、時機錯誤、最終回歸」的故事。要理解今天 Vivado HLS、Vitis HLS、Cadence Stratus 這些工具，必須先理解它們的前輩們為什麼失敗。

1980 年代的黃金起點#

1980 年代的學界普遍瀰漫一股樂觀：既然邏輯綜合可以從布林方程式自動生成閘級電路，那麼再往上走一層，從行為描述自動生成 RTL，理論上沒有障礙。幾個重量級研究群幾乎同時啟動。

卡內基美隆大學（CMU）的 Daniel Gajski 是其中最具體系性的一位。他在 1980 年代初發展的 System Architect's Workbench（SAW），建立了至今仍是 HLS 教科書標準架構的三階段流程：排程（scheduling）決定每個運算在哪個時脈週期執行；資源分配（allocation）決定需要幾個加法器、乘法器、暫存器；綁定（binding）決定哪個運算用哪個硬體單元執行。Gajski 後來將這套思想整理進他與 Robert Walker 等人共同發展的理論框架，並在 1988 年前後於 UC Irvine 持續深化（他於 1988 年轉任爾灣加大），這個「排程—分配—綁定」三部曲將在 3.2 與 3.3 節詳細展開。值得一提的是，Gajski 在 1981 年與 Kuhn 合作的論文中首次系統性地提出了 behavior 層與 structure 層之間的 Y-chart，這張圖後來成為整個數位設計抽象層次教育的基礎。

同時期的德國並不缺席。Kaiserslautern 大學的 Peter Marwedel 從 1970 年代末就開始發展 MIMOLA 系統——這可能是最早的高階綜合系統之一。MIMOLA 的独特之處在於它面向微處理器設計，從類似組合語言的描述綜合出資料路徑與控制單元，後來更延伸出針對 ASIP（特殊應用指令集處理器）的自動設計方法，成為今日 RISC-V 客製化處理器生成器（如 ASIP Designer）的思想源頭。

歐洲大陸另一端的比利時 IMEC，則由 Hugo De Man 領導發展了 Cathedral 系列工具（1980 年代中期至 1990 年代初）。Cathedral 的目標極為明確：數位訊號處理（DSP）晶片，特別是音訊與電信應用中的濾波器、轉換器。De Man 的團隊深刻體認到一件事——通用 HLS 難以做好，但針對特定應用領域（domain-specific），把架構樣式（architectural style）固定下來，綜合問題就變得可解。Cathedral-I 針對位元串列（bit-serial）架構，Cathedral-II 針對平行倍率架構，Cathedral-III 針對位元平行遞迴濾波器。這種「架構模板 + 行為描述」的思路，比全面開放的通用綜合務實得多。De Man 後來有一句廣為流傳的判斷：設計瓶頸不在製造，而在設計生產力——這個洞見在 1990 年代被 ITRS（International Technology Roadmap for Semiconductors）量化為著名的 design productivity gap：晶體管密度每 18 個月成長約 58%，但設計生產力每年只成長約 21%，兩條曲線之間的裂口逐年擴大。HLS 正是針對這個裂口最直覺的藥方。

Berkeley 也有一支力量。Alice Parker 於 1979 年發表的 Facet（在南加大）是行為綜合的先驅之一；Berkeley 側則有以資料路徑為主的各類研究。日本方面，富士通的 Bob（裕）等人以及 NEC、東芝的內部工具也持續投入。整體而言，1980 年代末 HLS 已經累積了豐富的演算法資產——這些演算法（list scheduling、force-directed scheduling、圖著色綁定）至今仍是教科書內容，本書 3.2、3.3 節將完整講述。

失落的 1990 年代#

然而演算法的成功不等於商業的成功。1980 年代末到 1990 年代，一批 HLS 新創與大廠工具陸續上市，卻幾乎全軍覆沒。代表性的嘗試包括 Synopsys 的 Behavioral Compiler（1990 年代中期，源自其收購的技術與內部研發）、Ambit、以及更早的 Expiore／Milestone 等新創公司。它們失敗的原因值得細看。

第一是抽象層次與設計文化的錯配。當時 RTL 已經成熟，Verilog 與 VHDL 工程師的心智模型是「我寫的就是我要的暫存器與組合邏輯」。HLS 工具從行為描述生成電路，工程師卻無法預測與控制結果——面積大了 20%？時脈慢了？工程師不知道該改 C 描述的哪一行。在 1990 年代，晶片 NRE 已經很貴，沒有設計主管敢把公司存亡押在一個黑盒子工具上。這是文化與制度問題，不是演算法問題。

第二是品質差距。1990 年代的 HLS 工具生成電路的品質通常比手工 RTL 差 20%–40%。當時設計產能不足但手寫 RTL 還撐得住，這個品質折價沒有市場願意付。

第三是商業模式的錯位。HLS 需要新語言（或 C 語言子集）、新驗證流程、新團隊技能，等於要客戶重整整個設計部門。工具公司賣的是一場革命，而客戶只願意買一次演化。

於是 1990 年代末，HLS 在學界被視為「做了三十年做不出來」的問題，論文數量驟減，儼然進入寒冬。

回歸：為什麼是 2000 年代#

轉折發生在 2000 年代初，而且關鍵驅動力大部分不在 EDA 業內。

第一個驅動力是系統公司的需求。隨著 SoC 時代來臨，演算法工程師（寫 C/MATLAB 的人）與 RTL 工程師之間的鴻溝成為真正的組織痛點：一個演算法要進硬體，得重新「翻譯」成 RTL，翻譯本身容易出錯，且兩套描述無法共享驗證。2004 年前後，電子系統層級（ESL, Electronic System Level）設計成為熱詞。

第二個驅動力是一連串商業收購與內部孵化。Fortune 語言與 CoWare 等嘗試之外，最關鍵的是台灣裔學者張宗林（Zhang Zhiruo 等人常被混淆，此處指清華大學與 UCLA 脈絡下的 AutoESL 團隊）——更準確地說，AutoESL 是 2006 年前後由 UCLA 的 Jason Cong 實驗室技術衍生而來的新創公司，其工具 AutoPilot 源自 Cong 團隊多年在 FPGA 高階綜合上的研究（xPilot 專案）。AutoPilot 以 LLVM 為編譯器基底，把 C/C++ 程式（含 pragma 指示的 pipeline、unroll、interface）綜合為 RTL，在 2010 年被 Xilinx 收購，2011 年起以 Vivado HLS 之名問世，後來演化為 Vitis HLS。AutoESL 路線的成功關鍵在於它把 HLS 定位為「FPGA 的生產力工具」——FPGA 非量產、可重燒、試錯成本低，正好繞過了 1990 年代「ASIC 不敢用黑盒子」的心理障礙。幾乎同時，Cadence 收購了 Forte Design Systems 的 Cynthesizer 技術（2000 年代中期至 2010 年，成為今日 Stratus HLS），Synopsys 則發展 C Compiler／後來的 Synphony，Apple 收購了 PA Semi 之後也在內部大量使用 HLS 開發影像與訊號處理單元，Intel 則在加速器設計中採用 HLS 流程。

第三個驅動力是 AI 與硬體加速的浪潮。2010 年代中期起，深度學習讓「演算法快、硬體慢」的矛盾空前尖銳，大量研究者與晶片團隊需要快速把 CNN、矩陣運算變成客製硬體。HLS 從「替代 RTL 的夢」轉型為「硬體原型與領域加速器的量產工具」，Google TPU 之外的許多學術加速器、以及 Xilinx/AMD 與 Intel FPGA 上的資料中心加速卡，大量使用 Vitis HLS 與 Intel oneAPI（其 HLS 引擎同樣源於學界技術）。

三十年的教訓#

回顧這段起伏，可以整理出一條清晰的因果鏈：1980 年代，演算法先於市場——排程與綁定的理論已經成熟，但 RTL 文化的穩固、ASIC 的高風險、以及工具品質差距，讓商業化失敗；2000 年代，市場先於完美——設計生產力 gap 與驗證成本逼著業界回頭，FPGA 提供了低風險的落地場景，LLVM 等現代編譯器基礎設施（這是 1980 年代不存在的）讓 C 前端的工程成熟度飛躍。技術幾乎沒變——今天 Vivado HLS 內部的排程引擎，其核心思想依然是 Paulin 與 Knight 在 1989 年提出的力導向排程的後裔。

換句話說，HLS 的復活不是演算法的勝利，而是生態的勝利：語言（SystemC、C++）、編譯器（LLVM）、目標（FPGA、加速器）、組織（演算法工程師直接參與硬體）四個條件在 2006 年之後才同時成立。

接下來兩節，我們將深入這套流程的兩大數學核心：3.2 講排程——把運算分配到時脈週期的演算法，從 ASAP/ALAP 的最直覺做法，一路講到力導向排程；3.3 講資源分配與綁定——把運算分配到硬體單元的圖論方法。這兩個問題構成了所有 HLS 工具，無論 1988 年的 SAW 還是 2024 年的 Vitis HLS——的共同骨架。