我們有飛機、汽車、輪船、自行車、地鐵、高鐵、公交車、雙腿等各種交通工具，各自有優缺點，舉個例子，阿呆從上海出差去北京賣書，整個流程是：

1. 打車到虹橋高鐵站：靈活機動，運量小，24小時運營，經常堵車；

2. 坐高鐵到北京南站：高速，運量大，路線、時間和起始站點有限制，建設周期長；

3. 從北京南站坐地鐵到奧林匹克公園地鐵站：市內速度穩定，運量大，時間和起始站點有限制，建設周期長；

4. 從地鐵站走路到國家會議中心新書簽售：慢，但是方便，兩條腿，沒有路都能走出一條路。

可以看出，一次旅行，其實結合了各種交通工具的優點。隨著摩爾定律的失效和CPU在AI等并行計算方面的缺陷，目前數據中心的計算機，已經不僅僅是CPU一種計算芯片，還要結合GPU和FPGA做異構計算體系。

CPU是出租車，方便靈活，但是要等紅綠燈，市區內道路多，有限速，運量小，車多了還堵車；FPGA是高鐵和地鐵，運量大，但是建設周期長，只能部署在人流量最大的線路上。

我們做異構計算的軟硬件分割也是遵循同樣的思想，普通的控制程序還是交給CPU執行，把計算量最大、最耗時間的任務轉移到FPGA上執行，達到硬件加速的目標。

軟硬件最佳分割方案：理論上無解

如下圖，一個程序，通過對程序進行分割，把任務分解到CPU和FPGA、GPU、AI芯片等加速器執行。如果我們把程序分成N段，那么每一段都有兩個選擇：軟件或者硬件，最后N段程序有2^N種分割方案，所以，最終要分段程序，尋找分配到軟硬件的最佳方案是一個數學上有名的NP難題，解不出來。。。

我們沒辦法算出一個理論上的最佳方案，只能是不斷逼近，沒有最好，只有更好。

我們希望有一天能做到像下面這張圖一樣，我們寫好的C/C++/Java等代碼，編譯后，自動分解成軟硬件執行的程序，軟件的交給CPU執行，硬件的讓FPGA執行。盡管很難，但是還是要有夢想，萬一實現了呢？

阿姆達爾定律

現在有很大一批人，對新的產品和技術比較排斥，覺得很low，沒有技術含量。可是，任何一個新東西，剛出來的時候就是很簡單，慢慢才變得復雜。比如區塊鏈、深度學習、量子通信這些熱門的技術，一開始實踐的時候并不是很復雜。

1967年，有一位IBM的計算機科學家叫做阿姆達爾（Amdahl），他寫了一個很簡單的公式，卻成了并行計算領域的基本定律。阿姆達爾定律說，一個程序能被硬件加速多少倍，其實取決于不能被硬件加速的那段程序。比如四分之三的程序可以通過并行計算、流水線等技術被硬件加速，但是有四分之一的程序還是得順序執行，那么加速最大的倍數就是四分之三的程序幾乎不花時間就算完了，用了四分之一的時間執行剩下不能加速的程序，最終可以加速4倍。

我們也知道這叫短板效應，木桶的容積是最短的那塊板決定的。我們中國現在高鐵、電視、冰箱、移動支付、共享單車、輪船都能做到世界第一，但就是芯片不能造，導致國家還是受制于人（美帝）。

當然，這個程序的占比不是按照代碼的長短算的，而是按照程序執行的時間劃分。為了達到最好的硬件加速效果，我們要把最占時間的程序都放到FPGA去。

關于這個定律的詳細解釋請參考科大陳國良院士的《并行計算機體系結構》一書2.3.1節。

90%/10%定律

上面這張圖是對一個程序中執行最多的的10段代碼占用時間的累計，符合90%/10%定律：10%的代碼執行占用了90%的程序運行時間。

所以我們很幸運，不需要操心那么多軟件代碼，只需要把最關鍵的10%代碼轉移到FPGA就可以了。

軟硬分割的考慮因素

我們在對一個程序做軟硬分割時，需要回答以下幾個問題：

1. 程序分段粒度多大？

2. 分割方案的評估

3. 每段分區有哪些實現方案？

4. 軟硬件如何交互？

5. 計算占用的面積。

程序分段粒度多大？

其實就是要把程序里的哪幾段代碼下放到硬件去，開小灶。這個代碼段要分到多細？如果太粗，那么操作比較簡單，花的時間少，但是最終效果可能沒那么好。分的太細，又太花時間，每一段都要分析和推算，考慮軟硬件交互，甚至需要專門的工具去做。

最簡單的辦法就是挑幾個關鍵的函數、算法或者for/while循環放到硬件去加速。

分割方案的評估

如果我們要確定軟件和硬件分工的方案，就需要評估和對比幾個方案，從性能、成本、功耗等幾個方面來評價。項目一開始，其實做不了太精確的評估，只能是粗糙的做一個估算，看看到底要用到多少LUT、RAM和乘法器、硬件IP等資源，再估算性能和延遲。

等到大體確定了一個目標方案，就可以寫代碼，用綜合工具做一個綜合，就能得到比較精確的資源占用情況。

不同的實現方案怎么選擇？

對于每一段要硬件加速的軟件程序，硬件上都有不同的實現方案。如下圖，是100個乘法的例子，有三個方案：

(a)方案用了100個乘法器，性能最強，用的資源也最多；

(b)方案用了1個乘法器，要排隊乘100次才能算完，性能最差，用的資源最少；

(c)方案用了10個乘法器，每個用10次，性能和資源都比較折中。

所以，最終采用什么方案要根據實際的需求和FPGA的大小來確定，FPGA不是ASIC，資源沒有那么多，能省則省。

軟硬件如何交互？

本來是一個順序執行的軟件程序，我們拆出了一部分放到FPGA去執行，所以就涉及到軟硬件交互的問題。如下圖(a)，

左邊是同步方案，軟件干完，就讓FPGA干，軟件在旁邊等，這樣交替干活。這種方案比較傻瓜式，簡單易行。而且性能不一定差，因為硬件計算快，軟件可能等一會兒就好了。

右邊是異步方案，軟件和硬件各干各的，同時工作，效率高，但是控制比較復雜，畢竟涉及到一些共享的數據，處理起來比較麻煩。如果硬件計算時間長，軟件等得久，就可以考慮這種模式。

另外，還要考慮軟硬件的通信方式，如上圖(b)，是各種通信方案，有的通過共享內存，有的是通過CPU直連、共享緩存，還有像牛郎織女一樣搭一座橋互聯。還有幾個硬件加速器之間綁定在一起和CPU通信，還是分開，都需要考慮到。

用AI輔助軟硬件劃分

傳統的硬件加速項目流程如下：

1. 確定要加速的軟件程序；

2. 架構師通過評估和統計數據、性能計算確定軟硬件分離方案和硬件架構；

3. 工程師開始寫代碼、仿真、驗證、測試。

但是，也有一些自動化工具來智能評估軟硬件分割方案。前面說過，理論上是找不到最佳方案的，因為計算量是個天文數字，我們只能不斷逼近。逼近的方法如下：

1. 把程序切分成幾段，給出軟件和硬件時間、硬件資源，算出一個評估結果。

2. 再隨機把程序分段，算出一個評估結果，看看是不是更好，如果更好，就用這個方案。

3. 繼續迭代。

上面的方法采用了隨機數的方法，不斷找到更優解。但是，如今隨著AI的日漸成熟，我們相信，也會有人會用AI技術來尋找更好的自動化軟硬件分離方案。